Как не надо внедрять регламенты

История, с которой столкнулась в своей работе консультант ПОЛЕ:Т консалтинг. Действующие лица в ней останутся анонимными в целях конфиденциальности.

Итак, в компании Х собственники решили “навести порядок”.

Аргументы более чем разумные:
— если кто-то уволится, знания не должны исчезнуть;
— повышается количество операций, а значит..
— пора внедрять регламенты.

Для этого каждому сотруднику поставили KPI - раз в месяц описывать любой процесс, который он выполняет:

Проведение планёрки.
Онбординг нового сотрудника.
Работа с клиентской заявкой.
Что угодно.

Без общей архитектуры.
Без объяснения, зачем это нужно.
Без понимания, какие процессы критичны, а какие второстепенны.

И главное — сами процессы в компании ещё не были выстроены.

Сотрудники восприняли это как:
— дополнительную нагрузку;
— формальность ради галочки;
— попытку «контролировать» и «подстраховаться» на случай увольнений.
Появилось сопротивление.

Кто-то начал запрашивать инструкции «как должно быть» у ИИ.
Кто-то формально описывал очевидные шаги.
Кто-то игнорировал задачу, откладывая “на потом”.

Через несколько месяцев в компании появилось:

• несколько десятков разрозненных документов;
• ни одного реально работающего унифицированного регламента;
• ещё больше раздражения в команде.

Собственники сделали вывод:
“Люди не хотят нормально работать”.
На самом деле проблема была в другом.

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

Регламенты начали писать до того, как:

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

Фактически компания пыталась документировать хаос.
Но хаос нельзя описать — его сначала нужно упорядочить.

Что нужно было сделать иначе

1. Определить критические процессы, влияющие на деньги и результат.
2. Разобраться, где есть повторяемость, а где каждый раз «по-своему».
3. Назначить владельцев процессов.
4. Сначала выстроить понятную логику работы.
5. И только потом фиксировать её в документах.

Регламент — это описание работающей системы, а не способ проектирования системы с нуля.

Если вы сейчас внедряете регламенты, спросите себя:

• Вы описываете работающую систему или пытаетесь бороться с хаосом, придумывая «правила» из головы или из интернета?
• Ваши сотрудники понимают, зачем это делается и как это упростит им жизнь — или просто выполняют распоряжение?
• У вас есть владельцы процессов, отвечающие за результаты — или просто исполнители?

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

Если вы узнаёте в этой истории свою компанию — проблема, скорее всего, глубже, чем отсутствие регламентов.