Почему цифровая трансформация не работает без собственника архитектуры
Большинство программ цифровой трансформации в крупном бизнесе ЦА проваливаются не на технологиях, а на отсутствии собственника архитектуры на уровне правления. Этот текст разбирает, почему эта роль критична, чем она отличается от CIO, и как её правильно встроить в управление компанией.
Обсудить задачуАвторская позиция: цифровая трансформация в крупном бизнесе ЦА не работает без собственника архитектуры с реальным мандатом на уровне правления. Эта роль критически важна, недостаточно её декларировать — нужны конкретные права и ресурсы.
Как это проявляется в жизни
В компании работает программа цифровой трансформации с бюджетом, командой, отдельным CDO или вице-президентом по цифровизации. Запущены десятки проектов в разных продуктовых блоках. Через 18-24 месяца совет директоров обнаруживает, что измеримых результатов мало, бюджет освоен, но картина целевой архитектуры не сформировалась. Каждый продуктовый проект имеет свою интеграционную работу, свою клиентскую модель, свой подход к данным. Стоимость владения растёт нелинейно. Любое регуляторное требование превращается в отдельный болезненный проект.
Почему так получается
Структура управления крупной компании построена по продуктовым блокам или функциям. У каждого блока своя ответственность за бизнес-результат. Цифровая трансформация воспринимается как набор продуктовых задач — поэтому каждый блок решает их сам, со своими подрядчиками и своими решениями. Архитектура считается технической функцией, делегированной CIO или ИТ-директору. Но CIO отвечает за работоспособность ИТ-инфраструктуры и операционные расходы, не за стратегическое архитектурное видение. Между бизнес-блоками и ИТ образуется пустота, в которой архитектурные решения принимаются ad hoc или вообще не принимаются.
Что обычно пробуют — и почему это не помогает
- Назначают вице-президента по цифровой трансформации без архитектурного мандата — он отвечает за «программу», но не имеет права принимать решения по архитектуре отдельных продуктов
- Привлекают консалтинг big-4 для разработки архитектурного видения — получают красивую презентацию, которую никто не реализует, потому что нет внутреннего собственника
- Создают архитектурный комитет — он собирается раз в квартал, обсуждает общие принципы, не принимает реальных решений
- Делегируют архитектуру CIO — он принимает решения через призму операционной устойчивости, не стратегической трансформации
- Пытаются обойтись без отдельной роли — каждый блок имеет своего архитектора, договорённость между ними отсутствует
Что реально нужно
Нужна постоянная роль на уровне правления с прямым мандатом принимать архитектурные решения, обязательные для всех продуктовых блоков. Эту роль можно называть Chief Architecture Officer, Chief Digital Officer, Chief Technology Officer — название менее важно, чем содержание мандата. Ключевые элементы: подчинение CEO, не CIO; право вето на архитектурно несовместимые продуктовые решения; собственный бюджет на инфраструктурные и платформенные инвестиции; голос в кадровых решениях продуктовых ИТ-руководителей. Без хотя бы трёх из этих элементов роль остаётся декоративной.
Что проверить до старта
- Кто в компании имеет право сказать «нет» продуктовому блоку, если его архитектурное решение несовместимо с целевой моделью
- Есть ли формальный архитектурный комитет, и принимает ли он реальные решения, а не обсуждает общие принципы
- Какой бюджет выделен на платформенные и инфраструктурные инвестиции, не привязанные к конкретному продукту
- Кто принимает решения о выборе технологического стека для новых продуктов — каждый блок сам или есть централизованная позиция
- Сколько раз за последние 12 месяцев возникал конфликт между продуктовым решением и архитектурным видением, и как он разрешался
Как двигаться шаг за шагом
- Сформулировать целевую архитектурную модель компании — что должно стать общей платформой, что остаётся продуктово-специфичным
- Определить мандат роли собственника архитектуры — права, ответственность, ресурсы, отношения с CIO и продуктовыми руководителями
- Найти кандидата — внутреннего из ИТ или продуктового блока с архитектурным мышлением, или внешнего с опытом крупного бизнеса
- Получить мандат на уровне правления и совета директоров — формальное решение с публичным анонсом
- Запустить первые архитектурные решения — выбор платформенных инвестиций, отказ от несовместимых продуктовых инициатив, начало работы архитектурного комитета с реальной повесткой
- Через 6-9 месяцев — первая ревизия результатов, корректировка мандата при необходимости
Что ещё стоит изучить
Темы из этой же области, которые часто разбираем вместе с этой
CRM
Не коробочный CRM, а правильно выстроенный контур управления клиентами — от первого контакта до лояльности.
→РешениеBI
Аналитика — не красивые графики на стене. Это ответ на вопрос 'почему?' до того, как проблема станет убытком.
→РешениеКонтакт-центр
Контакт-центр — не телефонная станция, а точка, где клиент решает: остаться с вами или уйти. Вопрос в том, как он устроен внутри.
→РешениеОнбординг
Онбординг — первое впечатление клиента о вашей компании. Если оно занимает 5 дней и 12 бумажных форм, второго впечатления не будет.
→Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.
Обсудить применение →Готовы обсудить вашу задачу?
Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.
Обычно отвечаю в течение нескольких часов