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

Почувствуйте разницу.

Именно поэтому регламенты не приживаются.

Не потому, что люди плохо пишут. А потому что начинают не с того конца.

В моём подходе регламент - финальный артефакт.

Путь к нему выглядит так.

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

Без прикрас.

Нотация (BPMN, SIPOC или другая) здесь не даёт уйти в красивые формулировки - это один из главных эффектов моделирования.

Нельзя просто нарисовать стрелку и написать «согласование». Придётся ответить: что именно согласуется, с кем, в какой срок и что происходит, если не согласовали.

Потом - модель TO BE. Как процесс должен работать с учётом узких мест, потерь и реальных возможностей команды. Это и есть оптимизация - не абстрактная, а основанная на данных модели.

Дальше - согласование с командой.

Это, пожалуй, самый недооценённый этап. Люди, которые работают в процессе каждый день, видят его изнутри. Их возражения - это не сопротивление изменениям, очень часто это самая ценная информация о том, почему TO BE не взлетит в текущем виде.

Проговорили, скорректировали, договорились.

И только после этого из согласованной модели агрегируется регламент. Не пишется консультантом в тихой комнате, а складывается из того, что команда сама обсудила, проверила и приняла.

Вот почему такой регламент приживается.

Его не спустили сверху. Его фактически написали сами сотрудники - просто с правильной методологией и внешним взглядом консультанта.

Пробовали по-другому? Работает?

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