← Ко всем статьям
КейсыДенис Михин · · 6 мин чтения

Почему дополнительный контроль ухудшил ситуацию

Когда процесс начинает сбоить, одна из самых естественных управленческих реакций — усилить контроль.

Почему дополнительный контроль ухудшил ситуацию

Когда процесс начинает сбоить, одна из самых естественных управленческих реакций — усилить контроль.

Больше статусов.

Больше отчётности.

Больше согласований.

Больше точек проверки.

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

Но именно здесь часто и возникает ошибка.

Дополнительный контроль не всегда повышает управляемость.

Иногда он делает систему медленнее, осторожнее и зависимее от руководителя.

Всё началось с правильного намерения

Представим проект, который начал регулярно отклоняться от сроков.

Руководство видит несколько симптомов:

задачи двигаются медленно;

часть рисков обнаруживается слишком поздно;

между командами возникают задержки;

статусы выглядят неполными.

Решение кажется очевидным.

Нужно повысить прозрачность.

Появляется дополнительный еженедельный статус.

Затем ежедневный отчёт по критическим задачам.

Потом обязательное согласование изменений.

Затем отдельная встреча по рискам.

В первые недели действительно становится спокойнее.

Информации больше.

Руководители лучше понимают, что происходит.

Но затем система начинает меняться совсем не так, как ожидалось.

Контроль начал забирать время у самой работы

Первый эффект был почти незаметным.

Каждая новая точка контроля требовала подготовки.

Нужно было собрать данные.

Обновить таблицу.

Объяснить отклонения.

Подготовиться к встрече.

Зафиксировать решения.

Разослать протокол.

По отдельности всё это занимало немного времени.

Но в сумме несколько команд начали тратить значительную часть недели не на движение работы, а на описание её состояния.

Возник парадокс.

Контроль должен был ускорить проект.

Но добавил новую работу, которая не создавала ценность для результата.

Это особенно характерно для сложных систем: дополнительный управленческий слой увеличивает количество взаимодействий и информационных потоков, которые тоже требуют координации. PMBOK прямо рассматривает координацию коллективных усилий как отдельную управленческую задачу, причём её форма должна соответствовать контексту, а не становиться самоцелью. PMBOK7

Люди начали управлять статусом, а не результатом

Следующее изменение было более опасным.

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

Появляется новая рациональная стратегия:

главное — чтобы статус выглядел управляемым.

Проблемы начинают формулироваться осторожнее.

Риски дольше остаются «под контролем».

Красный статус превращается в жёлтый.

Жёлтый — в зелёный с комментариями.

Не потому, что люди хотят обмануть руководство.

А потому, что система начинает наказывать за плохую картину сильнее, чем за позднее обнаружение проблемы.

Именно так контроль, который должен был повышать прозрачность, начинает снижать её.

Чем больше контроля, тем меньше самостоятельности

Параллельно происходило ещё одно изменение.

Раньше команда могла самостоятельно решать часть проблем.

Теперь любое отклонение стало попадать в отчёт.

А значит — привлекать внимание руководителя.

Руководитель включался.

Уточнял.

Предлагал решение.

Иногда менял приоритет.

Иногда подключал другого руководителя.

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

если сложное решение всё равно будет пересмотрено наверху, безопаснее сразу вынести его на согласование.

Так дополнительный контроль начал постепенно забирать у команды право на самостоятельное решение.

Количество эскалаций выросло.

Руководители стали ещё сильнее перегружены.

Решения начали приниматься медленнее.

И организация увидела новый симптом:

команды недостаточно самостоятельны.

Хотя часть этой несамостоятельности система только что создала сама.

Руководитель стал узким местом

В какой-то момент количество информации превысило способность руководителя её обработать.

Он участвовал в статусах.

Читал отчёты.

Принимал решения.

Разбирал исключения.

Согласовывал изменения.

Работал с рисками.

Чем больше он пытался контролировать, тем больше задач начинало зависеть непосредственно от него.

Появилась очередь.

Команда ждёт решения.

Смежное подразделение ждёт согласования.

Проект ждёт изменения приоритета.

Сам руководитель работает всё больше, но система движется всё медленнее.

Это классическая системная ловушка.

Попытка увеличить управляемость через централизацию решений превращает самого управляющего в ограничение системы.

Контроль лечил не ту причину

Главная проблема обнаружилась позже.

Сроки сдвигались не потому, что руководитель недостаточно внимательно следил за проектом.

Причина была в другом.

Одновременно выполнялось слишком много инициатив.

Между ними существовали ресурсные конфликты.

Приоритеты разных функций не совпадали.

Часть задач зависела от команд, которые вообще не считали этот проект главным.

То есть исходная проблема находилась в архитектуре портфеля.

А лечили её отчётностью.

Дополнительный контроль сделал проблему заметнее.

Но не устранил механизм, который её создавал.

Системное мышление как раз требует искать не ближайшее объяснение события, а структуру причинно-следственных связей, которая воспроизводит похожий результат снова и снова. сист мышление (3) (1)

После этого изменили не частоту контроля, а его логику

Перелом произошёл тогда, когда перестали обсуждать:

«Как ещё лучше контролировать команды?»

И начали обсуждать:

«Какая информация действительно нужна для принятия решений?»

Часть статусов убрали.

Оставили один регулярный контур синхронизации.

Из отчётности исключили подробное описание каждой задачи.

В фокус вынесли только то, что требовало управленческого действия:

критические зависимости;

изменение сроков;

риски;

конфликт ресурсов;

решения, которые команда не может принять самостоятельно.

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

Командам вернули часть решений.

Руководитель перестал вмешиваться туда, где система могла справиться сама.

Контроля формально стало меньше.

Управляемости — больше.

Сильный контроль работает по отклонениям

Контроль сам по себе не является проблемой.

Проблема начинается тогда, когда контролируется всё.

Зрелая система не требует, чтобы руководитель постоянно видел каждое действие.

Ему нужно видеть состояние системы и те точки, где требуется вмешательство.

Это принципиально другой подход.

Не:

«Что вы сделали вчера?»

А:

«Что мешает получить результат?»

Не:

«Почему эта задача ещё не закрыта?»

А:

«Есть ли здесь системное ограничение?»

Не:

«Пришлите ещё один отчёт».

А:

«Какое решение невозможно принять без моего участия?»

Так контроль перестаёт быть наблюдением за людьми.

И становится механизмом управления отклонениями.

Избыточный контроль всегда имеет скрытую цену

Эта цена редко появляется в финансовом отчёте отдельной строкой.

Она распределена по системе.

Время руководителей.

Время сотрудников.

Ожидание согласований.

Снижение инициативы.

Замедление решений.

Рост количества встреч.

Потеря ответственности.

Стремление скрывать плохие новости.

В сумме всё это может стоить значительно дороже той проблемы, ради которой контроль вводился.

Поэтому перед добавлением нового отчёта или согласования полезно задать простой вопрос:

«Какое конкретное решение станет лучше благодаря этому контролю?»

Если ответа нет, возможно, создаётся не инструмент управления.

А дополнительный управленческий шум.

Главный вывод

Дополнительный контроль ухудшил ситуацию не потому, что контроль вреден.

Он ухудшил её потому, что был добавлен поверх неправильной архитектуры.

Проблема была в приоритетах, ресурсах и зависимостях.

А вмешательство происходило на уровне отчётности.

В результате система стала тратить больше энергии на обслуживание управления, но сама причина отклонений осталась.

Это хороший пример более общего принципа:

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

Иногда системе действительно нужен дополнительный контроль.

А иногда ей нужно ровно обратное:

меньше согласований,

меньше отчётности,

более ясная ответственность,

и больше решений там, где непосредственно выполняется работа.

Потому что управляемость создаётся не количеством контроля.

Она создаётся качеством архитектуры управления.

Данный материал носит исключительно ознакомительный и дискуссионный характер и отражает личное мнение автора.

Денис Михин

Автор статьи

Денис Михин

Денис Михин — практик управления, HR, проектного менеджмента и организационных изменений. Автор экспертного журнала и образовательных программ по управлению, Agile, системному мышлению и искусственному интеллекту.

Начать программу

Почему дополнительный контроль ухудшил ситуацию

Перейти

Навыки

Развиваемые навыки

Связанные рабочие задачи

Эта статья поможет, если…