В операционном управлении есть классическая ловушка: регламент написан, согласован со всеми отделами и торжественно положен в корпоративную базу знаний. Но через две недели выясняется, что по нему никто не работает. Сотрудники вернулись к привычным чатам, ручным согласованиям и устным договоренностям. Когда начинаешь разбираться, почему процесс встал, слышишь стандартное: «Я думал, это делает смежный отдел», «Мне не сказали, что нужно согласовать» или «Мы всегда так делали, зачем менять?». Проблема здесь не в саботаже или лени людей. Проблема в том, что в документе описаны действия, но не разграничена архитектура власти и ответственности, а само внедрение прошло мимо правил управления изменениями.

Анатомия «мертвого» регламента

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

Если в инструкции написано «Отдел продаж совместно с производством формирует заявку на запуск», на практике это означает, что заявку не сформирует никто. Продажи будут ждать инициативы от технарей, а производство будет уверено, что сделку еще не дожали. Размытая формулировка «совместно» — главный враг скорости и прозрачности в компании.

Инструмент 1: Жесткая фиксация ролей по матрице RACI

Чтобы процесс двигался без пинков со стороны собственника, в каждом узле должна быть предельная ясность. В проектах RL Expert мы оцифровываем ответственность через классическую матрицу RACI, переводя её на понятный бизнесу язык:

* R (Responsible — Исполнитель). Кто делает задачу руками. Важное правило: на конкретном микрошаге исполнитель может быть только один. * A (Accountable — Владелец результата). Тот, кто отвечает головой за итог и принимает работу. Если «А» больше одного — за процесс не отвечает никто. * C (Consulted — Эксперт/Консультант). Тот, чье мнение или техническую экспертизу нужно запросить до принятия решения (например, юрист или главный инженер). * I (Informed — Информируемый). Тот, кого просто ставят в известность после завершения этапа (через автоуведомление в Kaiten или CRM), без права блокировать или тормозить задачу. Как только вы раскладываете спорный процесс по этим четырем буквам на одной странице, 80% конфликтов на тему «кто кому что должен» исчезают сами собой. Вы сразу видите перегруженных руководителей, которые пытаются быть «А» и «С» в каждой мелкой задаче, и пустые зоны, где нет ни одного владельца.

Инструмент 2: Профилактика саботажа через ADKAR Даже идеальная матрица ролей не взлетит, если спустить её на команду приказом сверху. Любое изменение вызывает естественное сопротивление. Чтобы регламент прижился, мы проводим команду по модели управления изменениями ADKAR:

* Awareness (Осознание). Объясняем, почему старая схема больше не работает (например: «мы теряем по три часа в день на пересылки файлов в мессенджерах и срываем сроки клиентам»). * Desire (Желание). Показываем личную выгоду сотрудника от нового правила («с этой матрицей тебя перестанут дергать по вечерам по чужим вопросам»). * Knowledge (Знание). Даем четкий инструмент — ту самую страницу в Notion и 3-минутный скринкаст, куда нажимать. * Ability (Способность). Проводим тестовый прогон на реальных задачах, убирая технические барьеры в системе. * Reinforcement (Закрепление). Вводим контроль на первых порах: возвращаем задачи, пущенные в обход процесса, пока новый маршрут не станет автоматической привычкой.

Порядок в бизнесе начинается там, где заканчиваются устные ожидания «по умолчанию».

А с чем вы чаще сталкиваетесь при внедрении новых правил в своей компании: с тем, что на этапе забыли назначить единственного ответственного, или с тихим сопротивлением команды, которой удобнее работать по старинке?