От «черного ящика» к цифровому конвейеру: как делать нужное на метриках
Когда бизнес просит ИТ «сделать кнопку», а получает её через год, это не вина программистов, а симптом отсутствия процессов управления. А что еще важнее, разрыва в языке: бизнес говорит на языке выручки и эффективности, а ИТ на языке сроков и технологий.
В этой статье Макаров Дмитрий Александрович, директор по цифровой трансформации ЭТМ, поделился подходом, который позволяет пройти путь от «диктатуры ИТ» и «анархии запросов» к управляемой модели, где каждый проект оценивается не по факту сдачи кода, а по достигнутым бизнес-метрикам.
Расскажу, как превратить хаос в конвейер цифровых инициатив и почему без изменения роли самой функции ИТ здесь не обойтись.
Этап 1. «Диктатура ИТ» и «Анархия запросов»: две стороны одной медали зрелости
В любой растущей компании рано или поздно наступает момент, когда внутренняя кухня начинает напоминать классический сценарий корпоративного конфликта.
Бизнес (логистика, продажи, закупки) пишет заявку и… попадает в «черный ящик». Приоритеты расставляются по непрозрачным критериям, понятным только внутри ИТ. Сроки исполнения измеряются месяцами, а результат часто не совпадает с ожиданиями.
Бизнес не понимает, почему его задача «висит в очереди» годами, а ИТ искренне не успевают обрабатывать вал противоречивых требований, поступающих по всем возможным каналам: от личных сообщений в мессенджерах до устных просьб в курилке.
В попытке ускориться, некоторые подразделения начинают создавать решения самостоятельно с помощью доступных инструментов. Появляются десятки «табличек-монстров», теневые процессы и, что самое опасное: скрытые бюджеты на разработку, которые никто не контролирует.
Эти решения закрывают локальную задачу «здесь и сейчас», но создают колоссальный хаос, риски для информационной безопасности и, в конечном счете, увеличивают совокупную стоимость владения (TCO) в масштабах всей компании.
Это путь к потере доверия и скорости.
Чтобы выйти из этого порочного круга, нужна система, которая, с одной стороны, обуздает «анархию», а с другой: сделает работу ИТ прозрачной и предсказуемой для бизнеса. Нужен переход от реактивного «тушения пожаров» к управлению портфелем проектов, где у каждой инициативы есть понятная бизнес-логика и измеримая цель.
Этап 2. Создание конвейера: разделение инициатив
Первый шаг: жесткая классификация всего потока работ. Нельзя смешивать «стратегию» и «текучку».
Все запросы нужно типизировать, например, так:
1. Инвестиционные проекты.
Это крупные, стратегические инициативы, требующие отдельного бюджета и выделенного руководителя проекта (РП). Их цель: измеримый бизнес-эффект, напрямую влияющий на стратегические показатели компании: рост оборота, снижение издержек, выход на новые рынки. Такие проекты должны проходить полноценную предпроектную оценку с расчетом ROI и TCO.
2. Операционные задачи.
Развитие существующих продуктов в рамках выделенных «стримов» или продуктовых команд. Например, доработка CRM для отдела продаж или расширение функционала мобильного приложения. Приоритеты здесь расставляет бизнес-владелец вместе с продуктовой ИТ-командой на регулярных комитетах.
Бюджет на такие задачи, как правило, заложен в постоянных затратах на команду, не важно свою или наёмную.
3. Регулярные запросы.
Небольшие доработки, инциденты, техническая поддержка. Они уходят в отдельный поток и решаются по четким SLA, не отвлекая ресурсы от стратегических и операционных задач. Если не отвлекать ресурсы не получается, то они встают в очередь по понятным приоритетам.
Такое разделение позволяет объективно оценить реальную загрузку команд и, что важнее, перестать забивать «стратегический» конвейер «операционкой».
Если к этому создавать дашборды по тикетной системе и по проектам, то бизнес наконец увидит, почему одни задачи взлетают в топ, а другие откладываются, а также реальную скорость команд и Time-To-Market задачи и проектов.
Вам также может быть интересен материал Клуба ИТ-лидеров Global CIO:
ИТ-стратегия как видение лидера и драйвер бизнес-результатов
Выстроить конвейер — первый шаг. Следующий — сделать так, чтобы инициативы в нём действительно достигали цели. До 80% цифровых инициатив не доходят до результата не из-за технологий, а из-за управляемости изменений. Как диагностировать разрывы в зрелости, выстроить stage-gate для портфеля, разделить контуры стабильности и развития — и перевести ценность ИТ в бизнес-метрики.
Этап 3. Организационная перестройка: Интеграция, а не изоляция
Классификации, конечно, недостаточно, нужны структурные изменения. Ключевая ставка: на децентрализацию и взаимное проникновение бизнеса и ИТ.
1. Проектный офис и аналитика под одной крышей.
Объединение функции проектного управления и системного анализа под единым центром компетенций позволяет каждому проекту с самого старта получать не только сроки и ресурсы, но и четкую бизнес-оценку: зачем мы это делаем, какую гипотезу проверяем, какую выгоду ожидаем и как будем ее измерять.
Тут же закладывается ресурсное планирование, даже при высокой степени неопределенности.
2. Продуктовые стримы вместо функциональных бункеров.
За каждым бизнес-доменом (логистика, маркетинг, продажи) стоит закрепить кросс-функциональную ИТ-команду. У такой команды должен быть понятный «бизнес-владелец» из профильного департамента, который вместе с ней ежеквартально приоритезирует задачи, исходя из KPI направления и текущих приоритетов бизнеса.
Так запускаются регулярные комитеты, где решения принимаются совместно, а не спускаются сверху в виде «указаний из ИТ». Вовлекается бизнес в ИТ процессы, а ИТ в метрики бизнеса.
3. Роль архитектора как связующего звена.
Отдельное внимание стоит уделить корпоративной архитектуре. Архитектор в такой модели не просто «рисовальщик схем», а ключевой участник проектного управления. Он вместе с командой оценивает, как то или иное решение впишется в целевую архитектуру, не создаст ли критический технический долг, не нарушит ли устойчивость legacy-систем.
Это позволяет двигаться к современной сервисной архитектуре, не останавливая текущий бизнес, считать ТСО, не забывая про сервера, людей, ПО и так далее.
Этап 4. Пост-проектный контроль: ловушка для «пустых» проектов
Самый опасный враг проектного офиса: считать проект успешным в момент подписания акта приемки. Необходимо ввести жесткое правило пост-проектного мониторинга.
Каждый проект должен проходить три контрольных точки после выхода в промышленную эксплуатацию: через 3, 6 и 12 месяцев. На каждом этапе бизнес-заказчик вместе с руководителем проекта отчитывается перед стратегическим комитетом о достижении фактических метрик.
И здесь часто ждут открытия: красиво обещанный в уставе ROI далеко не всегда материализуется. Чтобы это не было просто «бумажным эффектом», стоит внедрить процедуру Root Cause Analysis (RCA).
Если фактические показатели устойчиво отклоняются от плана более чем на 15-30%, запускается расследование: это ошибка в исходных гипотезах, изменились рыночные условия или недоработка на этапе внедрения? Такой подход позволяет не искать виноватых, а учиться на каждом проекте, обновляя базу знаний и корректируя будущие инициативы.
Что в итоге?
Пройдя путь от «черного ящика» и «анархии» к прозрачному конвейеру цифровых изменений, компания получает главное: бизнес понимает, почему его проект в работе, а другой: отложен. ИТ перестает быть «бутылочным горлышком», становясь равноправным партнером в достижении стратегических целей.
Скорость вывода новых цифровых продуктов растет, но главное: появляется способность честно измерять их реальную ценность для бизнеса.
Конечно, это путь постоянных улучшений, но фундамент закладывается именно через изменение культуры: от конфликта: к кооперации, от ощущения «сделано»: к пониманию «это работает и приносит прибыль».
Следующий логический шаг после выстраивания проектного управления: системная работа с рисками, которые неизбежно возникают при такой трансформации.
Но это уже тема для отдельного разговора.
Бонус: что делать, если не подходит RICE, WSJF и прочие методики приоритизации? Разработать свою!
Мы в компании создали модель «FUCR»:
- Финансовая ценность проекта «F»
- Пользовательская ценность «U»
- Сложность реализации «C»
- Рискованность проекта «R»
И всё это в калькуляторе Excel
