Почему Action-план не реализует стратегию: как построить отдельный контур управления стратегическими изменениями

Я Максим Поклонский. Более 18 лет занимаюсь стратегией и проведением стратегических сессий для бизнеса, участвовал более чем в 280 стратегических проектах в компаниях из разных отраслей.
После разработки стратегии организация обычно получает несколько артефактов:
-
стратегические цели;
-
портфель инициатив;
-
Action-план;
-
владельцев проектов;
-
KPI или OKR;
-
сроки.
Выглядит как законченная система.
Но спустя несколько месяцев можно обнаружить довольно странную картину.
Стратегия по-прежнему существует.
Никто формально её не отменял.
Руководители продолжают соглашаться с выбранными приоритетами.
При этом стратегические проекты практически не двигаются.
Проблема здесь часто не в разработке стратегии, а в архитектуре её исполнения.
Action-план описывает, что должно произойти, но сам по себе не создаёт механизма, который заставляет организацию регулярно принимать необходимые для этого решения.
Почему существует разрыв между strategy design и strategy execution
Операционная система компании обычно значительно сильнее стратегической.
У неё уже существуют:
-
регулярные встречи;
-
KPI;
-
бюджет;
-
владельцы;
-
сроки;
-
системы учёта;
-
управленческая отчётность;
-
механизмы эскалации.
Если падают продажи, информация быстро попадает к руководителю.
Если возникает проблема с бюджетом, включается финансовый контур.
Если ломается операционный процесс, появляется эскалация.
Со стратегическими инициативами часто устроено иначе.
После сессии появляется Action-план, но отдельный цикл управления не создаётся.
И постепенно возникают два контура.
Контур 1 — operating system
Выручка.
Маржа.
Клиенты.
Производство.
Бюджет.
Персонал.
Текущие задачи.
Контур 2 — strategic change
Новые продукты.
Новые рынки.
Изменение бизнес-модели.
Организационные трансформации.
Цифровые проекты.
Новые компетенции.
Если второй контур не встроен в регулярное управление, первый практически всегда выигрывает конкуренцию за внимание.
Почему дело не просто в дисциплине
Можно предположить:
Руководителям нужно просто лучше выполнять Action-план.
Но стратегические проекты имеют несколько свойств, которые отличают их от обычных операционных задач.
Они часто:
-
затрагивают несколько функций;
-
требуют перераспределения ресурсов;
-
не имеют устоявшегося процесса;
-
содержат большое количество неопределённости;
-
зависят от решений топ-команды;
-
меняют существующую организацию.
Из-за этого назначение одного владельца не всегда создаёт реальную ответственность.
Руководитель может отвечать за проект, но не иметь:
-
бюджета;
-
команды;
-
полномочий;
-
возможности менять процессы;
-
права приоритизировать работу других функций.
Формальная ownership есть.
Реальной управляемости нет.
Система исполнения должна связывать несколько объектов
У стратегической инициативы полезно явно держать как минимум семь элементов:
1. Стратегическая цель
Зачем проект существует.
2. Инициатива
Что именно меняется.
3. Владелец
Кто отвечает за продвижение.
4. Ресурсы
Какие люди, бюджет и компетенции требуются.
5. Метрики
По каким признакам можно понять, что проект движется.
6. Блокеры
Что сейчас ограничивает движение.
7. Решения
Что должна сделать управленческая система, чтобы следующий шаг стал возможен.
Если последний элемент отсутствует, проект легко превращается в объект наблюдения:
Красный статус уже третий месяц.
Но статус сам по себе ничего не исправляет.
Трекинг — это не monitoring
Здесь полезно различить два режима.
Monitoring
Собрать информацию о состоянии.
Например:
Проект выполнен на 65%.
Management
Изменить состояние системы.
Например:
Проект остановлен из-за отсутствия архитектора. Для продолжения требуется до 15 октября перевести специалиста из проекта B. Решение принимает CEO.
Вторая формулировка значительно полезнее.
Она содержит управленческий запрос.
Поэтому смысл регулярного трекинга — не максимальная точность статусов.
Главное — уменьшать количество нерешённых ограничений, мешающих реализации стратегии.
Типология блокеров
В стратегических проектах блокеры часто повторяются.
Ресурсные
Не хватает:
-
бюджета;
-
людей;
-
компетенций;
-
времени.
Межфункциональные
Два подразделения имеют разные интересы или приоритеты.
Decision bottleneck
Требуется решение CEO, собственника или топ-команды.
Dependency
Проект B не может двигаться до завершения проекта A.
Strategic uncertainty
Изменились исходные предпосылки, и команда больше не уверена, что инициативу вообще нужно продолжать.
У каждого типа блокера свой механизм решения.
Поэтому фраза:
Проект немного задерживается
почти бесполезна.
Фраза:
Проект нельзя продолжить до решения X, которое должен принять Y
уже позволяет управлять системой.
Почему портфель инициатив требует отдельного управления
Представим, что после стратегической сессии компания выбрала 30 проектов.
Допустим, каждый требует в среднем участия четырёх руководителей.
Получаем до 120 потенциальных связей между инициативами и управленцами.
При этом руководители не перестали заниматься текущим бизнесом.
В такой системе проблема быстро становится не проектной, а портфельной.
То есть вопрос уже не:
Как ускорить проект №17?
А:
Какие проекты вообще должны получать ресурсы организации сейчас?
Это другой уровень управления.
Закон ограничения внимания
Можно иметь 30 стратегических инициатив.
Но нельзя иметь 30 главных инициатив.
У компании ограничены:
-
капитал;
-
headcount;
-
квалифицированные люди;
-
количество параллельных изменений;
-
внимание руководителей.
Последний ресурс обычно недооценивается.
Сильный функциональный директор может быть одновременно подключён к:
текущему бизнесу;
бюджету;
найму;
трём стратегическим проектам;
кризисной ситуации;
новому продукту.
Формально каждый проект имеет ресурс.
Фактически ни один не получает достаточной концентрации.
Поэтому portfolio review является частью исполнения стратегии, а не административной процедурой.
Стратегический портфель должен уметь уменьшаться
Типичный портфель со временем только растёт.
Была стратегия — 20 проектов.
Через полгода появились ещё пять.
Потом возникли новые инициативы.
Ещё через год проектов стало 35.
При этом производственная мощность управленческой системы не изменилась.
Логичный результат — увеличение WIP, то есть work in progress.
Чем больше параллельной работы, тем выше:
-
число зависимостей;
-
стоимость переключения контекста;
-
конкуренция за специалистов;
-
время принятия решений;
-
средняя длительность инициатив.
Поэтому полезная система трекинга должна поддерживать четыре операции:
continue
accelerate
pause
stop
Последняя особенно важна.
Если система умеет только запускать новые инициативы и не умеет закрывать старые, стратегический портфель почти неизбежно перегружается.
Почему остановка проекта — не обязательно провал
Допустим, инициатива была выбрана год назад.
С тех пор:
изменился рынок;
появился новый конкурент;
стала другой стоимость капитала;
не подтвердилась продуктовая гипотеза;
возникла более сильная возможность.
Рациональное решение может заключаться в закрытии проекта.
Но внутри организации часто работает sunk cost:
Мы уже вложили столько ресурсов.
Продолжение неэффективного проекта только потому, что в него уже инвестировали, не делает стратегию последовательной.
Наоборот, способность отказаться от него высвобождает ресурсы для более важных инициатив.
Почему одних KPI недостаточно
Классическая управленческая система хорошо описывает текущее состояние бизнеса.
Например:
-
revenue;
-
EBITDA;
-
gross margin;
-
CAC;
-
retention;
-
производительность;
-
оборотный капитал.
Но стратегическая инициатива часто направлена на создание будущего состояния.
Например:
Выйти в новый клиентский сегмент.
Текущий P&L может долго не показывать прогресс.
Поэтому нужна промежуточная система показателей.
Условно можно разделить метрики на три группы.
Lagging indicators
Конечный бизнес-результат.
Например, выручка нового направления.
Leading indicators
Показатели, предсказывающие движение.
Например, число подтверждённых клиентских гипотез.
Delivery indicators
Фактическое продвижение проекта.
Например, завершение пилота.
Это не означает, что для каждого проекта нужен сложный dashboard.
Но один процент выполнения задачи редко даёт достаточную картину.
Как настроить контур реализации
Этап 1. Зафиксировать исходное состояние
Не менять систему сразу.
Сначала определить:
-
какие стратегические документы существуют;
-
сколько инициатив находится в портфеле;
-
кто ими владеет;
-
как сейчас отслеживается прогресс;
-
какие KPI / OKR используются;
-
какие встречи уже проходят;
-
где проекты чаще всего блокируются.
Это своего рода execution baseline.
Этап 2. Проверить связность
Для каждой стратегической инициативы полезно пройти цепочку:
Цель → Инициатива → Владелец → Метрика → Ресурс → Блокер → Решение.
Если связь где-то обрывается, это потенциальный execution gap.
Например:
Цель есть → проекта нет.
Стратегическое пожелание не переведено в действие.
Проект есть → метрики нет.
Непонятно, что считать прогрессом.
Владелец есть → ресурсов нет.
Ответственность номинальная.
Блокер есть → эскалации нет.
Проект может месяцами находиться в одном состоянии.
Этап 3. Ограничить strategic WIP
Не все инициативы обязательно должны идти одновременно.
Полезно определить:
-
active;
-
queued;
-
paused;
-
stopped.
Это позволяет отличить:
Мы решили сделать проект
от:
Мы делаем его сейчас.
Разница принципиальная.
Стратегическая приоритизация — это не только порядок важности.
Это порядок допуска к ограниченным ресурсам.
Этап 4. Настроить cadence
Частота зависит от типа инициатив.
Например:
еженедельно — для динамичных трансформаций;
раз в две недели — для большинства активных проектов изменений;
ежемесячно — для более длинных стратегических циклов.
Но важнее самой частоты неизменность цикла.
Стратегия должна иметь зарезервированный слот в operating cadence компании.
Этап 5. Перестроить содержание встречи
Плохой формат:
Каждый владелец рассказывает статус своего проекта.
Хороший формат фокусируется на исключениях.
Например:
-
красные и жёлтые инициативы;
-
новые риски;
-
изменение стратегических предпосылок;
-
блокеры;
-
межфункциональные зависимости;
-
решения;
-
пересмотр портфеля.
Тогда встреча становится значительно короче и полезнее.
Decision log важнее длинного протокола
Один из простых инструментов — фиксировать не всё обсуждение, а принятые решения.
Например:
|
Дата |
Инициатива |
Решение |
Владелец |
Deadline |
|---|---|---|---|---|
|
10.09 |
Новый рынок |
Утвердить пилот |
CEO |
15.09 |
|
10.09 |
CRM |
Заморозить до Q1 |
COO |
— |
|
10.09 |
Новый продукт |
Добавить 2 FTE |
HRD |
01.10 |
На следующей встрече можно проверять не только проектный статус.
Можно проверить качество самой управленческой системы:
Решили ли руководители то, что обещали решить?
Как понять, что трекинг стал бюрократией
Есть несколько характерных признаков.
1. Встреча состоит почти полностью из отчётов
Много информации, мало решений.
2. Обсуждаются операционные задачи
Стратегический контур превращается в обычную оперативку.
3. Красные проекты месяцами остаются красными
Значит, система наблюдает проблему, но не устраняет её.
4. Ни один проект никогда не останавливается
Вероятно, портфель не управляется.
5. Владельцы готовят презентации специально для трекинга
Если обновление статуса требует значительных административных затрат, сама система начинает съедать ресурсы исполнения.
Что должно измениться после настройки
Хороший execution contour создаёт несколько эффектов.
Strategy cadence
Стратегия постоянно присутствует в календаре руководителей.
Portfolio clarity
Понятно, какие инициативы активны сейчас.
Living Action-plan
План меняется по мере реализации, а не замораживается сразу после стратегической сессии.
Escalation mechanism
Есть понятный путь для блокеров, которые владелец не способен устранить сам.
Resource reallocation
Компания может перемещать ресурсы между инициативами.
Strategic feedback
Из исполнения возвращается информация, которая может изменить первоначальные предположения стратегии.
Последний пункт особенно важен.
Реализация стратегии — не линейный процесс:
сначала придумали → потом три года выполняем.
Execution генерирует новые данные.
Стратегия должна уметь их воспринимать.
Роль внешнего контура
В некоторых компаниях всю систему вполне можно построить внутренними силами.
Но есть три системных риска.
Первый — срочность операционных задач почти всегда выше.
Второй — функциональные руководители естественным образом защищают локальные приоритеты.
Третий — регулярность требует дисциплины.
Поэтому внешний участник иногда полезен не как человек, который управляет проектами вместо команды, а как механизм поддержания cadence:
-
удерживает структуру;
-
возвращает команду к принятым решениям;
-
помогает формулировать блокеры;
-
отделяет стратегическое от операционного;
-
фиксирует необходимые решения.
Но ownership стратегии всё равно должен оставаться внутри компании.
Диагностический тест
Можно проверить систему одним вопросом.
Попросить собственника, CEO и нескольких членов топ-команды независимо назвать:
Какие стратегические инициативы прямо сейчас являются главными?
Если ответы существенно различаются, существует проблема фокуса.
Затем второй вопрос:
Какие решения топ-команда должна принять в ближайший цикл, чтобы эти инициативы двигались?
Если никто не может назвать конкретные решения, возможно, система больше занимается monitoring, чем management.
И в этом, на мой взгляд, главное различие.
Action-план отвечает на вопрос:
что мы собираемся сделать?
Контур реализации отвечает на другой:
какие решения мы должны регулярно принимать, чтобы это действительно произошло?
Стратегия становится частью системы управления только во втором случае.
Автор: Maks_Poklonsky

