Из 117 ИТ-проектов до реальной ценности дожили меньше десяти

Когда я впервые поднял список согласованных ИТ-инициатив, там было 117 уникальных проектов. Это после первичной консолидации. До неё - больше.

Через несколько месяцев в работе остались меньше десяти.

Это не провал управления. Это и была нормальная работа.

Прежде чем разбирать экономику, нужно зафиксировать один управленческий факт, без которого всё остальное бессмысленно.

Проекты в компании делают те же сотрудники, которые параллельно ведут операционную работу.

Если человек может 100% времени отдавать проектам - верно одно из двух: либо его наняли специально под этот проект, либо на основной должности он ничего не делает и его можно уволить.

Поэтому при любом планировании утилизация людей считается только от согласованного процента отвлечения. Это и определяет реалистичность сроков. А контроль утилизации позволяет заранее видеть, где именно проект пойдёт на срыв.

Я видел другую модель - когда операционный и проектный офисы физически разделены. Там 1000+ активных проектов живут относительно спокойно. Но это другая организационная конструкция, другие бюджеты и другая логика управления.

В моём случае конструкция была стандартная: один общий ИТ-департамент на 120+ человек, внешние подрядчики, огромный входящий поток запросов.

Холдинг. Несколько независимых коммерческих подразделений с собственными ЛПР, каждый из которых считает свои задачи приоритетными. Один общий ИТ-блок - как буфер между всеми этими интересами.

Запросы шли постоянно: автоматизировать, интегрировать, внедрить, ускорить, оцифровать.

Фоном - привычный негатив: «ИТ ничего не делает», «всё долго», «нужно быстрее и дешевле».

Цель, которую я услышал в первые недели, звучала просто: сделать всё, в срок и подешевле.

Я начал с инвентаризации.

Собрал список инициатив, уже согласованных ЛПР. И обнаружил следующее:

4 разных проекта от разных подразделений - про одно и то же. Аналитики и разработчики уже тратили на это ресурсы. Никто не видел пересечений, потому что никто не смотрел на весь портфель целиком.

После первичной консолидации осталось 117 уникальных проектов.

Дальше магия закончилась. Началась экономика.

Я не занялся приоритизацией в классическом смысле. Я не ранжировал проекты по «стратегической важности» и не собирал матрицы срочности-важности.

Я перевёл каждый проект на язык P&L.

Каждая инициатива получила простую финансовую модель:

Оценку эффекта давал бизнес. Я её не проверял. Важен был один вопрос, который я задавал каждому ЛПР после того, как он называл цифру: «Ты готов за эту цифру отвечать?»

Ответ на этот вопрос отсеивал половину «уверенных» инициатив.

Часть проектов в портфеле шла без окупаемости. Обоснование - «имидж» или «политическая необходимость».

Я не спорил с формулировками. Я считал.

Логика простая: если проект не даёт финансового эффекта, значит компания несёт чистые расходы. Чтобы эти расходы не ухудшили P&L, нужно дополнительно заработать выручку, которая их перекроет - с учётом маржинальности бизнеса.

Для большинства таких проектов формула выглядела так: 10 млн расходов требуют 80-100 млн дополнительной выручки.

Внезапно «стратегические» проекты стали стоить очень дорого. Некоторые - неприлично дорого.

С собранной экономикой по всем 117 проектам я построил два сценария.

Сценарий 1: реализация с текущими ресурсами. Срок - 10+ лет. Дано: утилизация команды, текущий ФОТ, физические ограничения по параллельности изменений.

Сценарий 2: реализация за 2 года. Требует нанять 300+ сотрудников только в ИТ. Плюс инфраструктура, лицензии, онбординг, кривая производительности. Всё это - тоже в деньгах, тоже в P&L.

Впервые разговор на уровне акционеров стал не про «ИТ тормозит», а про «бизнес готов за это платить?»

Это сдвиг рамки. Небольшой, но критичный.

Проекты сортировались по трём критериям:

Скорость реализации - не потому, что «быстро хорошо», а потому, что долгие проекты несут скрытые OPEX-риски: люди уходят, требования меняются, окно возможностей закрывается.

Скорость окупаемости - период возврата инвестиций. Проекты с окупаемостью 5+ лет автоматически попадали под дополнительное обоснование.

Системная согласованность - и вот здесь самое интересное.

Один из проектов предполагал автоматизацию машинного двора, чтобы склад мог принимать 100 фур в сутки вместо 30. Хороший проект, понятный эффект.

Но размещение на складе было физически ограничено 35 фурами. Расширение инфраструктуры - за пределами текущих инвестиционных планов. Реальный потолок - около 50 фур при оптимистичном сценарии.

Автоматизация «до 100» - это дорогая иллюзия прогресса. Локальная оптимизация без системной связности не создаёт ценности. Она создаёт затраты и ощущение движения.

Это тот момент, который редко называют прямо.

Большое количество одновременных изменений - это почти гарантированный путь к потерям.

Не потому, что люди слабые. А потому, что каждое изменение создаёт нагрузку на смежные процессы, роли и системы. Когда меняется всё сразу - где-то обязательно «стреляет». И часто не там, где ожидали.

Практический вывод: менять безопасно можно один крупный контур за раз. Это не консерватизм. Это управление рисками.

С этим набором цифр мы вышли наверх.

Что произошло дальше:

Закрыты все проекты с отрицательной экономикой. Без дискуссии. Когда цифры в таблице, дискутировать не о чем.

Все проекты потеряли метки «имидж» и «политика». Потому что эти метки обнулились при первом же вопросе: сколько нужно дополнительно заработать, чтобы позволить себе эти расходы?

Попытки «сохранить всё-таки этот проект» разбивались о простую формулу: на 10 млн расходов нужно принести 80-100 млн выручки. Готов отвечать за эту цифру? Почти никто не был готов.

Дальше стало ещё интереснее: часть «положительных» проектов после пересмотра собственных оценок резко ушла в минус. Бизнес переоценил свои же цифры, когда под ними появилась персональная ответственность.

Двухлетний роадмап перестал обсуждаться. Новые расходы нужно было перекрывать ростом выручки, несопоставимым с реальными планами роста.

Меньше десяти проектов. По каждому из них выполнялось одновременно четыре условия:

Каждый оставшийся проект был закреплён за конкретным ЛПР с персональной ответственностью за финансовый результат. Не за «выполнение задачи». За деньги.

Полемика «ИТ ничего не делает» исчезла.

Не потому, что ИТ стал работать лучше или быстрее. А потому, что разговор сдвинулся с задач на деньги. Когда у каждого проекта есть цена, владелец и финансовый эффект, за который он отвечает головой - «ИТ тормозит» перестаёт быть аргументом.

Мы не расширяли ИТ. Мы просто перестали делать то, что никому не нужно за собственные деньги.

В результате в ИТ высвободилось 30+ человек. Но это уже другая история - про то, что делать с освободившейся мощностью.

Если в вашем ИТ больше 20 активных проектов одновременно - с высокой вероятностью половина из них не имеет подтверждённой экономики.

Проверить просто: попросите по каждому проекту финансовую модель с CAPEX, OPEX реализации, OPEX владения, финансовым эффектом и сроком окупаемости. И один вопрос ЛПР: «Ты готов за эту цифру отвечать?»

Ответы на эти вопросы сократят портфель быстрее любого приоритизационного комитета.

Проблема не в том, что ИТ не справляется. Проблема в том, что портфель изменений никогда не проходил через экономическую фильтрацию.

Пока у проектов нет цены, владельца и персональной ответственности за результат - они будут копиться, пересекаться и конкурировать за один и тот же ресурс. И виноватым всегда будет ИТ.

Инструмент здесь один: перевести портфель на язык P&L. Всё остальное - следствие.

Что в вашем портфеле прямо сейчас живёт без подтверждённой экономики - и за какую цифру никто не готов отвечать?

#итстратегия #управление #цифроваятрансформация #cio #портфельпроектов