Как используя Capability Based Planning разработать стратегию для ИТ-департамента и помочь ему перейти от позиции исполнителя запросов к партнёру и советнику для бизнеса.
Ситуация
Часто бизнес-функции воспринимаются как «исполнители заказов». Типичный пример — ИТ-департамент: бизнес фокусируется на текущих потребностях и формирует свои «заказы» к департаменту, ожидая их чёткого исполнения. Естественно, задачи бизнеса выполнять нужно, и сервисы — это необходимая база для ИТ-департамента. Но концентрация на сервисной модели работы часто приводит к перекосу в сторону краткосрочных потребностей в ущерб проектам департамента, направленным на создание долгосрочных преимуществ для компании.
В такой ситуации нужен системный подход, который позволит ИТ-департаменту перейти от роли поставщика услуг, отвечающего на запросы, к проактивной роли генератора ценности.
Проблема
Для того чтобы приносить максимальную ценность, необходима реализация двух условий:
- Чёткое понимание, в чём заключается ценность для бизнеса и для компании в целом.
- Приоритеты ИТ-департамента должны быть не просто поняты и согласованы с бизнесом и руководством компании, но приняты ими.
Выполнить эти условия можно при наличии единого языка и прозрачной системы приоритизации. Но, как правило, бизнес мыслит деньгами и прочими целями, а ИТ-департамент — в терминах проектов и систем. В итоге ИТ очень сложно доказывать свой вклад в достижение стратегических целей компании.
Решение
Для решения указанной проблемы создан фреймворк разработки стратегии на основе методики Capability Based Planning. Посмотреть можно тут: https://archistrateg.ru/f/?view=id-bc8e278ea8024f989d5f33135840df81
Как это работает
В основе процесса разработки стратегии лежит инженерный подход, применяемый при разработке систем:
- Построение карты бизнес-способностей департамента.
- Формирование требований, продиктованных стейкхолдерами, стратегией, внешней средой, параметрами компании.
- Приоритизация бизнес-способностей департамента, оценка целевой зрелости способностей, фиксация и оценка разрывов (Gap).
- Проектирование изменений в бизнес-архитектуре, подготовка проектов изменений, формирование дорожной карты.
- Реализация изменений.
Разберём по шагам:
Шаг 1. Разработка карты бизнес-способностей
В большинстве случаев при появлении запроса на разработку функциональной стратегии у функции/департамента бизнес-способности не задокументированы. И поскольку карта бизнес-способностей является центральным артефактом, лучше начать именно с неё.
- Готовится референсная карта бизнес-способностей. Для этого можно использовать другие референсные карты и модели, реестр процессов и т. д. У автора, например, был опыт композиции процессов и формирования карты бизнес-способностей на основе имеющегося описания должностных обязанностей и операций по сотрудникам.
- Собранная референсная карта является хорошей основой для уточнения с заказчиком (в нашем примере — с руководством ИТ-департамента), чем департамент занимается на самом деле и что должен уметь.
- Проводится оценка уровня зрелости бизнес-способностей.
Таким образом мы получаем первую версию карты бизнес-способностей ИТ-департамента. В дальнейшем эта карта будет уточняться.
Шаг 2. Разработка требований
Далее необходимо подготовить требования к ИТ-департаменту — примерно так же, как мы готовили бы их для ПО:
1. Требования, вытекающие из стратегии компании.
Стратегия компании, как правило, содержит указания на обстоятельства, которые могут оказать существенное влияние на бизнес-способности департамента.
2. Требования, вытекающие из трендов внешней среды.
Если стратегия разрабатывается для компании, то внешняя среда учитывается всегда. Для функциональной стратегии кажется, что внешнюю среду можно учитывать не всегда. Но на практике это не так — какую функцию ни возьми, почти везде обнаружится влияние изменений в технологиях, поведении людей и регуляторных нормах.
3. Требования от стейкхолдеров.
Среди стейкхолдеров ИТ-департамента — бизнес как внутренние заказчики, другие обеспечивающие подразделения (бухгалтерия, юристы) и руководство предприятия. У каждого из стейкхолдеров могут быть как явные требования, так и ожидания от департамента, которые тоже нужно перевести в требования.
4. Ограничения, диктуемые компанией.
К таким ограничениям можно отнести бюджетно-финансовые, организационные и структурные, операционные и технические, компетентностные, а также особенности корпоративной культуры и стиля управления.
Собранные и разработанные требования фиксируются в реестре требований.
Шаг 3. Проецирование требований на карту бизнес-способностей
Бизнес-способности связываются с требованиями. Основной рабочий инструмент здесь — матрица «способность — требование». Также возможно, что мы увидим недостающие бизнес-способности и дополним карту.
Шаг 4. Анализ и приоритизация бизнес-способностей
Бизнес-способности анализируются по двум критериям:
- Стратегическая значимость.
- Текущий уровень зрелости.
Оптимально оценивать зрелость бизнес-способностей по модели CMMI. Сочетание высокой стратегической значимости и низкого уровня зрелости — это очевидные кандидаты для формирования проектов развития.
Шаг 5. Оценка целевой зрелости (исходя из приоритетов и возможностей инкрементов)
Более-менее окончательно определить приоритеты позволяет оценка целевой зрелости бизнес-способностей. В первую очередь стоит посмотреть на способности, выявленные на предыдущем шаге (высокая стратегическая значимость и низкий уровень зрелости). Но и для остальных способностей нужно оценить целевую зрелость.
Оценку стоит проводить из реальных возможностей развития инкрементами (постепенное повышение зрелости, а не «скачок сразу на 5»). Типичная ошибка на этом шаге — стремление все способности вытянуть на высший уровень зрелости. Например, зачем вам 5-й уровень зрелости для бизнес-способности, отвечающей за уборку в офисе?
Этот шаг задаёт реалистичный вектор развития ИТ-департамента.
Шаг 6. Оценка разрывов (Gap)
Сравнивая текущую зрелость (шаг 4) с целевой (шаг 5), можно выявить разрывы (GAP). Каждый разрыв будет ответом на вопрос: «Чего именно не хватает, чтобы достичь целевого состояния?»
Например:
- Для способности «Аналитика данных» разрыв означает отсутствие BI-платформы, нехватку аналитических компетенций в команде, неформализованные запросы от бизнеса.
- Для способности «Управление инцидентами» — отсутствие SLA, автоматизированной системы оповещений, размытую ответственность.
Шаг 7. Проектирование изменений
На основе выявленных разрывов необходимо спроектировать целевую бизнес- и информационную архитектуру:
- Согласовать единое видение будущего ИТ-департамента.
- Убедиться в отсутствии дублирований, конфликтов и новых разрывов до того, как потрачены деньги на развитие.
- Создать прозрачную базу для инвестиционных решений с учётом зависимостей и рисков.
- Сменить мышление команды с «внедрили систему Х» на «повысили зрелость способности Y».
Шаг 8. Формирование проектов изменений и дорожной карты
Спроектированные изменения превращаем в конкретные проекты и инициативы. Каждый проект получает:
- Жёсткую привязку к бизнес-способности, которую он развивает.
- Целевой результат (например, «повысить зрелость способности X до уровня Y»).
- Предварительную оценку сроков, бюджета и эффектов.
Проекты группируются в дорожную карту на 12–18 месяцев с выделением:
- «Быстрых побед» (2–3 месяца, малые затраты).
- Системных проектов (4–6 месяцев, доработка ИТ-ландшафта).
- Стратегических инициатив (более 6 месяцев, создание новых способностей).
Шаг 9. Управление / Архитектурный надзор
И последний обязательный этап — в процессе реализации всех спроектированных изменений:
- Регулярные архитектурные ревью ключевых этапов (дизайн, разработка, тестирование, интеграция).
- Контроль соответствия реализуемых решений утверждённой целевой архитектуре.
- Участие в приёмке результатов.
Это позволяет избежать типичной ситуации, когда «внедрили CRM, а способность не выросла». Каждый проект оценивается не только по факту сдачи, но и по факту повышения зрелости способности.
Результаты
Внутренние результаты ИТ-департамента
ИТ-департамент получает не просто расписанную стратегию, но рабочий инструмент управления развитием:
- Функциональная стратегия, где цели выражены через повышение зрелости конкретных бизнес-способностей и привязаны к измеримой ценности как для департамента, так и для бизнеса.
- Прозрачную систему приоритизации, позволяющую выстраивать приоритеты на основе объективных показателей.
- Обоснованную дорожную карту, понятную и руководству, и команде департамента, и топ-менеджменту компании, и бизнес-заказчикам.
Изменение роли ИТ-департамента в компании
Реализация стратегии на основе предложенного фреймворка по сути означает трансформацию департамента, поскольку он переходит к проактивному развитию бизнес-способностей, создающих ценность для бизнеса.
Появляется инструмент донесения информации о создаваемой ценности бизнесу и руководству — концепция бизнес-способностей позволяет делать стройные логические выкладки для презентаций и отчётов и доносить их до бизнеса.
Всё это позволяет перейти от реакции на запросы от бизнеса к диалогу и партнёрским отношениям, в результате чего роль ИТ-департамента меняется — от исполнителя запросов к советнику (а при правильной постановке работы — и к лидеру трансформации и развития).
Пример из «лучших практик»
Вот как подобную трансформацию описывают коллеги из Metis Strategy.
Проблема до трансформации
В растущей технологической компании ИТ-департамент воспринимался как «исполнитель заказов» (order-taker). Бизнес приходил с конкретными запросами, ИТ их реализовывал, но на стратегические проекты, которые могли бы добавить реальную ценность, бюджет практически не выделяли. Руководители бизнес-функций формулировали цели высокого уровня, которые руководству ИТ-департамента было сложно перевести в конкретные действия. А руководство ИТ-департамента часто подходило к проблеме «от технологии», оставляя бизнес-результат на втором плане. В итоге через полгода «цифровой трансформации» компания получала набор разрозненных проектов без единой приоритизации и понимания их взаимосвязей.
CIO компании был намерен изменить эту ситуацию и превратить ИТ-департамент в стратегического партнёра. Но для этого нужен был системный подход, который позволил бы перейти от «разовых проектов» к управлению развитием способностей.
Что сделали
Команда Metis Strategy предложила подход, основанный на карте бизнес-способностей (business capabilities). Вместо того чтобы спрашивать «какую систему внедрить?», они вместе с руководителями бизнеса ответили на вопрос: «Какими ключевыми умениями должна обладать компания, чтобы достичь стратегических целей?».
Далее команда последовательно прошла четыре шага:
1. Сегментация и приоритизация способностей. Не все способности одинаково важны для конкуренции. Их разделили на две категории:
- Конкурентное преимущество — способности, которые создают уникальное рыночное положение. Клиенты выбирают компанию именно из-за них.
- Паритет — способности, которые поддерживают ожидания клиентов и операционные потребности; они нужны, чтобы не проиграть, но сами по себе преимущества не дают.
Эта сегментация практически не меняется год от года (если только не происходят серьёзные изменения на рынке) и задаёт долгосрочный вектор развития.
2. Оценка текущей и целевой зрелости. Для каждой способности оценили текущий уровень зрелости и определили целевой. При этом в Metis Strategy подчёркивают: оценка зрелости — это столько же искусство, сколько наука. Сам процесс обсуждения «почему способность незрелая» часто важнее самого числового значения.
3. Выявление разрывов (GAP). Разрыв между целевой и текущей зрелостью показал, куда нужно направлять инвестиции в первую очередь. Причём инвестиции требовались в трёх измерениях: люди (компетенции), процессы и технологии.
4. Формирование дорожной карты (backlog развития способностей). Инициативы сгруппировали в дорожную карту, где каждый проект получил жёсткую привязку к конкретной способности и целевой уровень её зрелости. ИТ-департамент при этом отвечал за выравнивание технологической архитектуры, но всегда в контексте того, как должен измениться бизнес-процесс.
Кроме того, такая карта позволила увидеть дублирования (например, несколько систем, поддерживающих одну способность) и «дыры» (приоритетная способность вообще не обеспечена технологической архитектурой).
Полученный результат
Совместная работа бизнес- и ИТ-команд, ориентированных на общие бизнес-результаты, позволила навести мост от стратегии к исполнению. Приоритеты перестали определяться «громкостью голосов» — инвестиции пошли в те способности, которые были действительно важны для бизнеса. Команда получила объективные критерии для принятия сложных компромиссных решений.
В результате ИТ-департамент перестал быть просто исполнителем и превратился в стратегического советника для бизнеса.
Вместо заключения
Разработка функциональной стратегии ИТ-департамента на основе бизнес-способностей — это не просто ещё одна методика. Это системный подход, который превращает ИТ из «поставщика услуг» в равноправного партнёра, создающего ценность для бизнеса.
Дополнение к этому кейсу
Смотрите кейс «Как найти внутренние резервы для развития предприятия»: https://archistrateg.ru/kak-naiti-vnutrennie-rezervy-dlya-razvitiya-predpriyatiya
PS: Забрать PDF можно тут https://vk.ru/wall23330051_5175