#МетодологияВнедрения О стандартах и стандартизации процессов и не только

Как бы не называли мы тот или иной метод организации работ проекта, любой процесс возможно устроить только, если зададим структуру на входе.

По большому счету совершенно неважно, что внедрять - HR-процессы, IT-процессы или запускать производственную линию..

Я как-то не задумывалась над этим до поры до времени. Обычно, к необходимости стандартизации процессов мы приходим при возникновении вопросов взаимодействия, когда требуется настроить коммуникации при стыке подпроцессов или... внедрении изменений.

Когда проект внедряется однажды и больше не повторяется, достаточно просто либо провести встречу (ряд встреч) на информирование или обучение, либо просто выполнить задачу вместе с подразделением, где происходят изменения и сильно не думать об этом больше - внедрили и ладно - может, ошиблись где или затянули со сроками, но задача выполнена, а значит и думать в эту сторону не надо. Когда же требуется повторять цикл внедрения несколько раз, то и каждый раз придется начинать с нуля. А если внедряешь в подразделении, где все сотрудники привыкли работать структурно, то и внедрение "сразу по живому" может и не пойти вовсе.

Что же делать? Недавно меня так спросили, а что делать, если внедряемый процесс при входе сам не описан? То есть как проводить обучение тому, чего еще нет?

Тогда то я и поняла, что описание методики по принципу "матрешки" - тоже своего рода стандартизация. Стандартизация методологии внедрения.

Перед каждым запуском необходимо прописать методику применения самого продукта или услуги и методику внедрения - шаг за шагом: так, чтобы было предельно ясно всем участником - что должно быть на выходе, и как этого достичь. Если же результат известен в общих чертах, то методику следует корректировать, основываясь на обратной связи участников проекта. В любом случае на входе имеется некий алгоритм или стандарт, достаточно гибкий и чувствительный к изменениям - механизм улучшений закладывается тут же, в начале проекта, в виде определенных правил.

Кажется, что правила и стандарты усложняют взаимодействие и тормозят процесс. Это случается только в том случае, если стандарты и алгоритмы строятся без учета поступления обратной связи участников и изменений внедряемых процессов. Если же стандарты не фиксируются, а являются непрерывным процессом стандартизации и улучшений, то фактически из этапа внедрения плавно перетекают на этап эксплуатации и рабочего режима, трансформируясь в инструменты управления уже построенного внедренного процесса. Интересно, правда?

Мысли вслух,

Денисова Елена

 Присоединяйтесь ко мне в Facebook на странице Денисовой Елены

Автоматизация бизнес-процессов как способ выявления потерь производства

В бережливом производстве Тойота говорится, что чтобы обнаружить производственные потери во времени, в расходе ресурсов и в методах выполнении работы, необходимо связать процесс. Это действительно так.

Пока процессы не прописаны, ведутся хаотично и отдельно друг от друга (имеют собственные графики работы, периоды, начала и окончания, не зависящие от соседних процессов), практически невозможно разобраться, где что неверно делается, и где именно происходят провалы.

Но вот, что интересное обнаруживается при упорядочивании существующих процессов, как-то так работающих. Когда выстраиваешь четкую логику и взаимосвязи между объектами и субъектами процесса во времени и определенной последовательности, понимаешь, что "идеальный процесс" будет отличаться от реального.

При написании бизнес-требований к автоматизации сталкиваешься с множеством теоретических вопросов типа "а что если?". Ведь написание данной документации - это умственно логическое умозаключение - почти чистая теория, хотя ты и примеряешь написанное на реальные работы. Тем не менее, когда продумываешь будущее, то, естественно, точно сказать сразу, начиная с нуля выстраивать процесс, что будет не так, предугадать очень сложно. Более того, все случайности и шероховатости исключить сразу же невозможно!

В результате, при внедрении новой технологии сталкиваешься с множеством возражений - мол, а вдруг что-то пойдет не так, и снова придется вносить изменения. Если смотреть на вероятность проявления неточностей и вариаций процесса, как на проблему, то действительно, имеет ли смысл начинать вообще дело?

Да, действительно, связанный процесс, пускай даже на бумаге, уже выявляет какие-то особо острые моменты, которые видны на поверхности и которые можно решить тут же на бумаге. И это хорошо - это первая выгода, которую получают проектировщики и исследователи текущего процесса. В идеале, хорошо бы продумать весь процесс целиком, отработать его вручную, без автоматизации, шаг за шагом, проверяя на возможные прорывы и узлы, как проверяют ёлочную гирлянду - скрупулезно, не пропуская не единого звена. А затем уже автоматизировать чистый отработанный процесс.

К сожалению, в век огромных массивов информации, которые мы обязаны перерабатывать ежедневно по много раз, выясняется, что многие работы, ключевым успехом которых является скорость передачи и обработки информации, вручную не только проверить и выверить на всевозможные потери, просто невозможно как раз из-за ограниченности человеческих ресурсов - без автоматизации рутинной работы процесс попросту невозможен.

И какой вывод я делаю в итоге. Если ставить целью в конечном результате иметь работающий процесс, его необходимо связать во едино, чтобы были четко определены взаимосвязи объектов и субъектов на бумаге, продумать все возможные отклонения, которые видны сразу и автоматизировать по этому "идеальному шаблону". Результатом будет не реальный, конечно, процесс, но после того, как запущена первая тестовая версия, применимая к реальности, начнут всплывать и те проблемы, которые нельзя было учесть ранее. И это не есть проблема - это возможность, которую предоставляет автоматизация для решения. Автоматизация под этим углом зрения является лакмусовой бумажкой, позволяющей определить реальные проблемы, требующие решения с помощью правильно построенной системы обратной связи в виде различных отчетов, системы уведомлений и возможности фиксировать проблемные точки.

Конечно, автоматизация как и связывание процесса является очень тонким инструментом. Чтобы воспользоваться таким способом выявления подводных камней, нужно заранее ответить на вопрос - готов ли менеджмент в оперативном порядке решать все острые моменты, вскрываемые связанным процессом и автоматизацией. Система не должна быть железобетонной и зацементированной навеки. Она должна быть гибкой и редактируемой, управляемой, в случае необходимости, человеком-оператором.

Выявление проблем - это первый и необходимый шаг, но проявленные трудности могут и погубить процесс, если их не решить в скором порядке. Если же процесс постоянно развивать и развивать саму систему, можно добиться огромных успехов в долгосрочной перспективе. Не нужно забывать, что путь к совершенству лежит в бесконечности - постоянное наблюдение, развитие, корректировка и изменение. Это путь успешности.

Это мои мысли "вслух" и поэтому буду рада любой критике и комментариям от вас. Пишите, и я отвечу.

С уважением,

Денисова Елена,

twitter: @EDDenisova

https://www.facebook.com/profile.php?id=100004487832154