Управленческий кейс: от проблемы к решению

Одной из самых распространённых ошибок в управлении является стремление как можно быстрее перейти к решению проблемы.

Падает показатель — нужно срочно исправить.

Срываются сроки — необходимо усилить контроль.

Возникают жалобы — требуется немедленно реагировать.

На первый взгляд такой подход выглядит логичным.

Руководитель обязан действовать быстро.

Однако практика показывает, что многие управленческие решения оказываются неэффективными именно потому, что были приняты слишком рано.

Проблема была замечена.

Решение найдено.

Но причина проблемы так и осталась неизвестной.

В результате через некоторое время ситуация повторяется вновь.

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

Оно начинается с понимания проблемы.

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

Исходная ситуация

В одном из подразделений компании руководство столкнулось с неприятной тенденцией.

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

Сначала задержки составляли несколько дней.

Затем стали измеряться неделями.

Клиенты начали задавать вопросы.

Внутри команды росло напряжение.

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

На первый взгляд причина выглядела очевидной.

Команда не успевает выполнять работу в срок.

Самым простым решением казалось усиление контроля.

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

Более детальная отчётность.

Жёсткий мониторинг задач.

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

Шаг первый. Изучение фактов

Вместо поиска виноватых команда начала анализировать реальные данные.

Были изучены:

• сроки выполнения задач;
• загрузка сотрудников;
• история изменений проектов;
• этапы согласования;
• количество возвратов на доработку.

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

Большинство сотрудников работали с высокой загрузкой.

Сроки выполнения собственных задач соблюдались.

Однако проекты всё равно задерживались.

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

Шаг второй. Поиск системного ограничения

После анализа процессов обнаружилась интересная закономерность.

Практически все задержки возникали на этапе согласования решений.

Документы ожидали утверждения.

Изменения долго рассматривались.

Некоторые вопросы проходили несколько кругов обсуждений.

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

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

Именно здесь находилось настоящее ограничение.

Очень часто проблема находится не там, где её впервые заметили.

Шаг третий. Проверка гипотезы

Прежде чем менять процесс полностью, команда решила проверить своё предположение.

Для нескольких проектов был внедрён упрощённый порядок согласования.

Часть решений передали на уровень руководителей направлений.

Количество обязательных согласующих сократили.

Сроки прохождения отдельных этапов начали отслеживаться отдельно.

Через несколько недель результаты стали очевидны.

Проекты стали двигаться быстрее.

Количество задержек сократилось.

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

Гипотеза подтвердилась.

Шаг четвёртый. Изменение системы

После успешного эксперимента изменения были масштабированы.

Компания пересмотрела правила согласования.

Были определены:

• владельцы процессов;
• уровни принятия решений;
• сроки согласования;
• критерии обязательной эскалации вопросов.

Кроме того, появилась прозрачная система отслеживания статусов.

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

Что изменилось

Через несколько месяцев организация получила заметные результаты.

Сроки реализации проектов стали более предсказуемыми.

Количество внеплановых совещаний снизилось.

Сотрудники начали тратить меньше времени на ожидание решений.

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

При этом компания не увеличивала штат.

Не внедряла дорогостоящие системы.

Не усиливала контроль.

Основное изменение заключалось в устранении системного ограничения.

Именно это дало наибольший эффект.

Почему стандартные решения не помогли бы

Интересно представить альтернативный сценарий.

Если бы руководство сразу усилило контроль, скорее всего:

• увеличилось бы количество отчётов;
• выросло число встреч;
• сотрудники получили бы дополнительную нагрузку;
• сроки могли временно улучшиться за счёт повышенного внимания.

Но основная причина задержек сохранилась бы.

Через некоторое время проблема вернулась бы снова.

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

Что можно взять из этого кейса

Подобные ситуации возникают практически в любой организации.

Меняются только детали.

Иногда проблема скрывается в коммуникациях.

Иногда в распределении ответственности.

Иногда в перегруженности отдельных этапов процесса.

Но логика решения остаётся одинаковой.

Полезно последовательно пройти несколько шагов:

1. Определить проблему.
2. Собрать факты.
3. Найти закономерности.
4. Выявить системное ограничение.
5. Проверить гипотезу.
6. Изменить систему.
7. Оценить результат.

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

Но позволяет находить решения, которые работают долго.

От реакции к управлению

Главное отличие зрелого руководителя заключается не в скорости принятия решений.

Оно заключается в качестве мышления.

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

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

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

За ними стоят особенности системы.

Настоящие улучшения начинаются тогда, когда руководитель перестаёт спрашивать «Кто виноват?» и начинает спрашивать «Почему система работает именно так?»

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

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