Когда я собрал список всех ИТ‑инициатив в холдинге, их оказалось 117. Это уже после нормализации — до неё было больше. Четыре проекта с разными названиями, разными авторами, разными бюджетами — про одно и то же: автоматизацию конкретного складского процесса. Каждый руководитель запустил «свою» инициативу, не зная о трёх остальных. Аналитики и разработчики уже тратили ресурс параллельно на все четыре.

До реальной реализации дожили меньше десяти проектов. Это оказалось лучшей новостью для бизнеса за тот год.

Контекст

Холдинг с несколькими независимыми коммерческими подразделениями. Один общий ИТ‑департамент — 120+ человек плюс внешние подрядчики. Постоянный поток запросов на автоматизацию, «цифровизацию» и «инновации» от каждого подразделения отдельно. Фон: «ИТ ничего не делает», «всё долго», «нужно быстрее и дешевле». Причина: все хотят всего одновременно, ресурс один, приоритетов нет, за результат никто персонально не отвечает.

Шаг первый: собрать и нормализовать

Прежде чем что-то оптимизировать — нужно понять, что вообще существует.

Я собрал все инициативы: официально согласованные, устные договорённости с руководителями, задачи в трекере без явного статуса, проекты в состоянии «мы же договорились». Свёл в единый реестр.

Минимальная структура:

Плюс финансовые поля — CAPEX, OPEX_run, OPEX_own, ожидаемый эффект — они заполняются на следующем шаге.

На этапе нормализации нашлись дубли — четыре проекта про один процесс, каждый с другим названием и другим спонсором. После дедупликации — 117 уникальных инициатив.

Шаг второй: ресурсное ограничение, которое обычно не считают

Один принцип, без которого любой портфельный анализ превращается в список желаний.

Проекты делают те же люди, которые параллельно ведут операционную работу. Реальный проектный ресурс — это согласованный процент отвлечения от операционки. Срок проекта считается от эффективных часов, а не от календарных:

Календарный срок = оценка трудозатрат / доступная проектная доля ресурса

Пример. Разработчик загружен операционными задачами на 70%. Согласованное отвлечение на проект — 30%. Задача оценена в 2 человеко‑месяца. Реальный календарный срок — 6–7 месяцев. Если параллельно у него ещё три «приоритетных» проекта — умножайте.

Когда я посчитал суммарный ресурс под все 117 проектов с реальными процентами отвлечения — получил первый сценарий.

Сценарий А: текущие ресурсы, все 117 проектов — горизонт реализации 10+ лет.

Этот слайд я показал первым. Не чтобы напугать. Чтобы зафиксировать точку отсчёта: разговор про «ИТ тормозит» в контексте десятилетней очереди звучит иначе.

Шаг третий: P&L для каждого проекта

Дальше я не расставлял приоритеты. Я перевёл каждый проект в финансовую модель:

Пример расчёта:

CAPEX: 8 млн

OPEX_run: 4 млн

OPEX_own: 0,5 млн / месяц

Эффект: 1,5 млн / месяц

Оценку эффекта давал сам бизнес. Я не проверял её независимо — у меня не было данных, которых не было бы у самого бизнеса. Но я фиксировал baseline (то, от чего считаем, со слов бизнеса), метрику (что именно изменится), владельца, дату проверки и место, где эффект должен появиться в P&L.

Это превращало «мы рассчитываем» в конкретное обязательство с проверяемой точкой.

После этого задавал один вопрос: «Ты готов за эту цифру отвечать?»

За вопросом стоял чёткий чек‑лист:

• Кто владелец эффекта?

• Какая метрика изменится?

• От какого baseline считаем?

• Когда проверяем результат?

• Где эффект будет виден в P&L?

• Что делаем, если эффект не наступил?

Вопрос убил большинство проектов. Не потому что цифры были неправдивые. А потому что «мы рассчитываем получить эффект» и «я персонально отвечаю за этот эффект» — разные вещи. При прямом вопросе большинство инициаторов пересматривали оценку вниз. Иногда значительно.

Шаг четвёртый: имиджевые и политические

Отдельная категория — проекты без окупаемости с метками «имидж», «стратегия», «политика». Для них считал иначе:

Сколько дополнительной выручки нужно заработать, чтобы покрыть расходы и не ухудшить P&L?

При марже 10%: каждые 10 млн расходов требуют 100 млн дополнительной выручки. «Имиджевый» проект за 50 млн — это 500 млн дополнительного оборота сверх плана.

«Это важно для имиджа» быстро превращалось в «мы готовы ради этого принести столько‑то в выручке». Почти никто не был готов.

Шаг пятый: системная согласованность

Проект с положительной экономикой — ещё не основание для запуска. Дополнительный фильтр: находится ли узкое место системы там, где проект его устраняет — или ограничение в другом месте?

Конкретный пример. Один из проектов обещал увеличить пропускную способность машинного двора: склад должен был принимать 100 фур вместо 30. Экономика положительная. Ресурс есть. Запускаем?

Нет.

Физическая инфраструктура склада вмещает одновременно 35 машин. Для выхода на 50+ нужна реконструкция, которой нет в плане. Автоматизировать пропускную способность ворот при ограничении внутри - значит оптимизировать компонент при системном ограничении в другом месте. Ворота будут пропускать 100 фур. Склад — принимать 35.

В большинстве портфелей этот фильтр не проходит, потому что проекты оцениваются локально. Команда делает всё правильно, результат не масштабируется, все удивляются.

Второй сценарий и выход к акционерам

После всех фильтров — два числа.

Сценарий А: все 117 проектов, текущие ресурсы — 10+ лет.

Сценарий Б: только проекты с положительной экономикой, прошедшие системный фильтр, срок 2 года — нужно нанять 300+ человек только в ИТ. Стоимость найма, адаптации и ФОТ посчитана полностью.

С этим я пошёл к акционерам. Что произошло:

• закрыты все проекты с отрицательной экономикой

• метки «имидж» и «политика» перестали быть аргументом: либо проект окупается, либо его стоимость осознанно принимает акционер

• часть «положительных» после пересмотра бизнесом стала отрицательными — оценки брались без персональной ответственности за них

• сценарий с наймом 300+ человек сняли: чтобы отбить такой рост ФОТ, выручку нужно было увеличить в 10 раз. Желающих гарантировать это не нашлось.

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

Что осталось

Несколько проектов, одновременно удовлетворяющих трём условиям: подтверждённый финансовый эффект — и ЛПР за него отвечает лично; текущих ресурсов достаточно при реальных процентах отвлечения; системное ограничение именно там, где проект его устраняет.

За каждым — закреплён владелец с персональной ответственностью за результат.

Полемика «ИТ не делает» исчезла. В ИТ высвободилось 30+ человек без найма и реструктуризации. Мы просто перестали делать то, за что никто не готов был отвечать своей оценкой.

Backlog изменений сократился с 3 лет до 3 месяцев.

Где метод не работает

Нет управленческого учёта. Если P&L не ведётся или ведётся формально, эффект негде проверить. Модель строится, но точкой контроля становится не цифра в отчёте, а ощущение руководителя.

Эффект нельзя отделить от внешних факторов. Выручка выросла — это проект или рынок? Если метрику нельзя изолировать, владелец эффекта всегда найдёт объяснение.

Compliance‑проекты, обязательные к реализации. Они запускаются независимо от ROI. Их включать в модель нужно — но в отдельную категорию с другой логикой приоритизации.

У бизнеса нет владельца метрики. Если за конкретный P&L‑показатель никто не отвечает, вопрос «ты готов отвечать за эту цифру?» повисает в воздухе. Это сигнал не про проект — про структуру управления.

Ресурсная загрузка людей не измеряется. Без хотя бы грубой оценки утилизации первый сценарий (10+ лет) посчитать невозможно. Остаётся приоритизация на интуиции.

Портфель проектов — это не список задач

Это модель ограничений: денег, людей, времени, ответственности и физики процесса.

Если хотя бы одно ограничение не посчитано — компания управляет не портфелем. Она управляет очередью обещаний.