Совет директоров объявляет цифровую трансформацию стратегическим приоритетом и утверждает амбициозный план внедрения передовых технологий — при этом никто не провёл честную диагностику текущего уровня зрелости цифровых возможностей компании. Оказывается, компания находится на начальном, хаотичном уровне цифровой зрелости, а план построен так, будто компания уже обладает продвинутыми возможностями, — разрыв между реальностью и амбицией делает план невыполнимым с самого начала.
Хрестоматийный реальный пример практической силы такой модели зрелости — программное обеспечение управления полётом Space Shuttle (PASS, Primary Avionics Software System), разработанное подразделением IBM Federal Systems Division по контракту с NASA, полученному ещё в 1974 году. К 1989 году организация, отвечавшая за PASS, первой в истории достигла максимального пятого уровня CMM — той самой шкалы зрелости, которую данная методика адаптирует к любым организационным возможностям. Итоговая система (около 420 000 строк исходного кода PASS плюс порядка 1,4 млн строк вспомогательного тестового кода, команда около 275 человек, требуемая надёжность на уровне 10⁻⁷–10⁻⁹ отказов в час) эволюционировала более 15 лет через систематический, дисциплинированный процесс — согласно официальному кейс-стади Национальной академии наук США, философия команды формулировалась как «качество должно закладываться в софт», а не проверяться постфактум тестированием. Резервная система управления полётом, разработанная на случай отказа основной, ни разу не была задействована в реальном полёте — редчайшее для программной инженерии подтверждение того, что систематическая, высокая зрелость процессов реально переводится в надёжность результата.
Нельзя спланировать движение к цели, не зная точно, откуда стартуешь.
Происхождение и исследовательская база
Модели зрелости возможностей развивались в консалтинговой практике (в том числе McKinsey) как адаптация более раннего подхода Software Engineering Institute (SEI, Университет Карнеги — Меллон) к оценке зрелости процессов разработки ПО. Основу заложил Уоттс Хамфри в 1987 году по заказу Министерства обороны США, которое нуждалось в инструменте оценки способности софтверных подрядчиков поставлять качественное ПО в срок; формальная модель Capability Maturity Model была опубликована командой под руководством Марка Пола в 1991 году (версия 1.1 — в 1993-м). Применительно к широкому кругу организационных возможностей — от цифровых технологий до управления рисками, от процессного управления до работы с данными — модель систематически оценивает, находится ли конкретная возможность компании на начальном хаотичном уровне или на уровне систематической оптимизации.
Ключевые идеи и принципы
Принцип: Стандартизированная шкала уровней зрелости
Модель использует последовательную шкалу — от начального/хаотичного уровня (процессы непредсказуемы, зависят от отдельных людей) через повторяемый, определённый, управляемый уровни до оптимизированного (процессы систематически совершенствуются на основе данных) — каждый уровень имеет чёткие, проверяемые критерии.
Принцип: Применимость к разным типам организационных возможностей
В отличие от узкоспециализированных моделей зрелости для одной конкретной области, общий подход McKinsey применим к широкому спектру возможностей — цифровые технологии, управление данными, процессное управление, риск-менеджмент — с адаптацией конкретных критериев под специфику каждой области.
Принцип: Честная диагностика как основа реалистичного плана развития
Ценность модели реализуется только при честной, а не оптимистичной оценке текущего уровня — заниженная оценка сложности перехода на следующий уровень зрелости приводит к нереалистичным планам развития, построенным на ложном представлении о стартовой точке.
Ограничения, слепые зоны и критика
Оценка уровня зрелости во многом субъективна и зависит от того, кто и как её проводит, — организации нередко склонны переоценивать собственный уровень зрелости, особенно если оценка проводится внутренними силами без внешней проверки. Модель также предполагает линейное движение от низких уровней к высоким, что не всегда отражает реальность — некоторые организации могут одновременно демонстрировать признаки разных уровней зрелости в разных аспектах одной и той же возможности.
Типовые ошибки
Ошибка 1: Оценка уровня зрелости проводится оптимистично, без внешней проверки.
Внутренняя команда оценивает собственный уровень зрелости завышенно, что приводит к нереалистичному плану развития, построенному на ложной стартовой точке.
Как избежать: Привлекать внешнюю или независимую оценку для проверки честности внутренней самооценки уровня зрелости.
Ошибка 2: План развития перескакивает через промежуточные уровни зрелости.
Компания на начальном уровне зрелости пытается сразу внедрить практики, характерные для оптимизированного уровня, минуя необходимые промежуточные этапы развития.
Как избежать: Планировать последовательное развитие через промежуточные уровни зрелости, а не пытаться перепрыгнуть сразу к продвинутому состоянию.
Ошибка 3: Уровень зрелости воспринимается как самоцель, а не инструмент для бизнес-результата.
Организация инвестирует в повышение формального уровня зрелости ради самого сертификата или отчётного показателя, теряя связь с тем, какую реальную бизнес-проблему это должно решить — усилия уходят на демонстрацию зрелости, а не на реальное улучшение результатов.
Как избежать: Явно формулировать, какую конкретную бизнес-проблему решает переход на следующий уровень зрелости, прежде чем инвестировать в него ресурсы.
Ошибка 4: Модель применяется формально, без учёта конкретики измеряемой возможности.
Одна и та же общая шкала уровней механически накладывается на очень разные по природе возможности (управление данными, разработка ПО, работа с рисками) без адаптации критериев к специфике конкретной области — оценка становится размытой и малополезной для планирования.
Как избежать: Адаптировать конкретные критерии каждого уровня зрелости под специфику оцениваемой возможности, а не применять универсальные формулировки без конкретики.
Ошибка 5: Не закладывается регулярная переоценка уровня зрелости.
Диагностика проводится один раз, план развития составляется — но регулярная повторная оценка не закладывается, из-за чего организация не замечает как прогресса, так и деградации ранее достигнутого уровня зрелости со временем.
Как избежать: Закладывать регулярный цикл переоценки зрелости (аналогично тому, как это делала команда PASS на протяжении 15 лет непрерывного совершенствования процесса), а не считать однократную оценку финальной.
Главное, что нужно знать
Модель зрелости возможностей McKinsey оценивает текущий уровень организационной возможности по стандартизированной шкале от начального хаотичного до оптимизированного уровня — ценность модели реализуется только при честной, независимо проверенной оценке текущего состояния, служащей реалистичной стартовой точкой для планирования последовательного развития через промежуточные уровни зрелости.
План внедрения
Неделя 1: выбрать конкретную организационную возможность для оценки зрелости.
Неделя 2: провести честную диагностику текущего уровня, желательно с внешней проверкой.
Неделя 3: определить целевой уровень зрелости и разрыв с текущим состоянием.
Неделя 4: составить план последовательного развития через промежуточные уровни.
Далее: регулярно переоценивать уровень зрелости и корректировать план развития.
Как реализовать этот план с помощью фрейма McKinsey Capability Maturity Model в OrgDevTools
Фрейм «Модель зрелости возможностей McKinsey» построен как сетка из четырёх карточек, напрямую отражающих последовательность плана внедрения выше: «Текущий уровень» — честная, желательно независимо проверенная диагностика (неделя 2 плана); «Целевой уровень» — реалистичная цель, обоснованная конкретной бизнес-потребностью, а не абстрактным стремлением к максимальному уровню (неделя 3); «Разрыв» — что именно отделяет текущее состояние от целевого; «План развития» — последовательные шаги через промежуточные уровни зрелости, без попытки перепрыгнуть этапы (неделя 4).
Каждая карточка — свободный список записей. Явное разделение на четыре отдельные карточки не позволяет пропустить ни один из шагов плана — например, сразу перейти от «Текущего уровня» к «Плану развития», минуя честную формулировку конкретного разрыва, что и есть одна из типовых ошибок применения модели.