Запрос почти всегда одинаковый: описать процессы, навести порядок, чтобы всё работало без ручного управления. Договорились, начали - и где-то на середине всё останавливается.

Чаще всего по трём причинам.

🔺Пропустили AS IS - сразу нарисовали идеал. Получается красивая модель TO BE, которая не имеет отношения к реальности. Внедрять непонятно что, стартовать непонятно откуда.

🔹Как надо: сначала честно зафиксировать AS IS – честно, без прикрас. Со всеми обходными путями и негласными договорённостями.

Это неприятно, долго, иногда дорого. Но именно через AS IS становится видно, где на самом деле проблемы.

🔺Описали - и положили в стол. Модель есть, регламент есть. Владельца процесса нет, контрольных точек нет, никто не договорился кто следит за исполнением. Документ живёт своей жизнью, процесс - своей.

Встречаются эти сущности друг с другом редко и даже не здороваются друг с другом.

🔹Как надо: назначить владельца процесса до старта проекта, зафиксировать его полномочия и KPI. Регламент без владельца - это просто файл на сервере.

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

Сопротивление - не вредность. Это нормальная реакция на чужое решение про твою работу.

🔹Как надо: вовлекать команду на этапе моделирования - открыто говорить о целях оптимизации процессов и позволять им полноценно взаимодействовать с консультантом.

Не для галочки - а потому что они знают процесс изнутри лучше любого консультанта. И регламент, в создании которого они участвовали, они же и будут соблюдать.

Все три истории объединяет одно: проект по описанию процессов воспринимается как задача с дедлайном. Написали - сдали - закрыли.

А дальше само.

Спойлер: не само.

Процессы - только в начале проект. Потом это режим работы.

Еще больше обо мне | sergey-suslov.ru