Хаос возвращается: системные причины провалов внедрений

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

Сценарий почти всегда одинаковый:

Все прекрасный слайды о победах показаны C-level, шампанское выпито, команда внедрения (будь то внешние консультанты или внутренние сотрудники) получила бонусы и переключилась на новые проекты. В отчетах сплошной успех.

Проходит три месяца и начинают закрадываться сомнения. Стоит заглянуть под капот «обновленной» машины, выясняется неудобная правда: все осталось как было. Сотрудники все также продолжают вести дела через чаты и личные контакты – новые регламенты соблюдаются номинально. Все «единые» системы если не заполняются мусором, то ведутся «для галочки» – использовать их для управленческих решений невозможно (менее рискованно тут выглядит таро). Новые метрики – сплошной старый изломанный KPI, под который компания подбивает свои результаты (лишаться премий никто не хочет). И все это «под соусом» новых слов типа «agile», «scrum» и так далее, которые трактуются так, как сиюминутно удобно отчитывающимся.

Почему так происходит? Обычно топ-менеджмент винит «ригидную команду» или отдельных «звезд-токсиков». Но реальная причина лежит глубже (и не важно – это внедрение AI-решения или банального таск-трекера). Это системные ошибки, заложенные еще на старте: словно попытка посадить здоровое растение в токсичную почву.

В первую очередь, изменения проваливаются не потому, что их плохо «продали» или «подали». Чаще всего причина провала в среде, которая физически не способна их принять.

Стандартное требование заказчика для команды внедрения выглядит так: сделать

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

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

2. «Инфоцыгане» в менеджменте. Ситуация, когда на среднем (а иногда и высшем) уровне управления находятся люди, продающие модные тренды вместо реального управления. Они требуют внедрения AI, Agile, Data-driven или Бирюзы, не имея ни стратегии, ни понимания процессов. Для них изменения – это способ построить личный бренд за счет компании, а не решать бизнес-задачи.

3. Карго-культ. Замена реальной работы имитацией. «Мы теперь Agile, поэтому у нас нет документации / сроков / планов». «Мы цифровая компания, поэтому увольняем джунов».

В таких условиях от команды внедрения требуют натянуть фасад эффективности на гнилой каркас. Это можно сделать на слайдах, но не в реальности.

Вторая системная причина провалов – ошибка «Hit & Run» или «Внедрил и Сбежал».

Любое, даже самое грамотное внедрение, требует фазы Приживления. Это период от 3 до 9 месяцев после формального запуска, когда команда изменений должна работать «в полях»: собирать и анализировать обратную связь, прорабатывать негатив, докручивать процессы и, фактически, работать техподдержкой и психологами в одном лице.

В 80% случаев этот этап либо не бюджетируется, либо игнорируется.

Без присмотра система мгновенно начинает регрессировать к состоянию минимальных энергетических затрат – то есть к привычному. Но так как сверху требуют «инноваций», сотрудники включают защитный механизм – терминологический камуфляж.

Старые хаотичные планерки переименовываются в «Дейли» или «Синки».

Старые отчеты перебиваются в новые, более сложные формы (трудозатраты удваиваются: делаем работу + имитируем отчетность) и так далее.

Суть деятельности не меняется.

Третья причина – драйверы. Так в компании действуют три ключевые силы, которые часто тянут изменения в разные стороны:

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

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

Перестать искать виноватых среди линейных сотрудников, которые «не хотят осваивать новое». Проблема не в них.

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

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

Для всего этого нужна архитектура интегрированного управления, которая связывает Стратегию, Контроль и Исполнение в единый контур.

Автор статьи

P.S. Больше о моем опыте, подходах и форматах работы можно узнать на сайте. Там же доступны для скачивания дополнительные материалы по теме управления