На квартальных совещаниях проекты не запускались. Они размножались.
Когда я собрал единый реестр, получилось 117 инициатив. До этого четыре разных руководителя уже параллельно тратили ресурсы на одно и то же - просто не знали друг о друге.
Предыдущий материал был про итог: почему из 117 инициатив до реальной ценности дошли меньше десяти. Этот - про другое. Про то, как технически и управленчески собрать портфель так, чтобы собственник мог открыть любую строку и понять: зачем проект, кто отвечает, сколько стоит и почему он вообще живёт.
Что было внутри этих 117
Ситуация типичная для компаний, которые росли быстро и где ИТ по привычке воспринималось как функция, которая "должна успевать". Инициативы появлялись где угодно - на планёрках, в мессенджерах, в протоколах стратегических сессий.
Каждый руководитель знал про свой проект. Никто не знал про все.
Ресурсы уходили одновременно на все утверждённые инициативы. Не потому что так решили, - просто не было механизма отказа. Проект попал в протокол - значит, делается. Когда именно, чьими руками и за чей счёт - это как-то само разрешалось.
Когда я посмотрел глубже - на то, что реально делали разработчики, - картина оказалась хуже, чем я ожидал. Из каждых десяти задач шесть делали то, что никогда не применялось в работе. Это не оценка на глаз - считали через фактические часы разработчиков. По трудозатратам это съедало большую часть доступной разработки. Компания платила ФОТ за то, что никому не было нужно.
Почему CEO не может управлять приоритетами вручную
Параллельно работал механизм, который я для себя называю чайка-менеджментом. Топ-менеджер приходит к CEO: "мой проект не делают". CEO реагирует. Все бросают текущее и переключаются. Через неделю прилетает следующий топ с тем же вопросом. Цепочка повторяется.
Это нормальная реакция на отсутствие системы, а не злой умысел. Если нет объективных приоритетов, выигрывает тот, кто громче пришёл последним. CEO в этой модели превращается в ручной коммутатор ресурсов. Каждую неделю.
Собственник платит за это дважды. Первый раз - деньгами на задачи, которые никогда не применялись. Второй раз - временем CEO на разруливание конфликтов, которых в нормальной системе просто не должно быть.
Шаг первый. Единый реестр
Начали с того, что давно нужно было сделать, но откладывалось, - собрали всё в одном месте. Прошлись по почте, мессенджерам, протоколам совещаний, Excel-файлам в разных папках разных подразделений. Нормализовали названия - потому что одна и та же инициатива в разных источниках называлась по-разному. Убрали дубли.
117 строк. Это само по себе было управленческой победой: не "у нас много проектов", а конкретный список с конкретной цифрой.
На этом этапе стало видно, что часть инициатив дублировалась содержательно. Ресурсы уже расходовались параллельно. Это была потеря контроля.
Шаг второй. Экономика каждого проекта
Для каждого проекта из 117 нужна была экономическая модель. Не презентация с пользой, а четыре числа:
- CAPEX: лицензии, оборудование, стоимость подрядчика если нужен
- OPEX реализации: стоимость людей через утилизацию и средний ФОТ - сколько времени разработчиков и аналитиков уйдёт и сколько это стоит в деньгах
- OPEX владения: что проект будет стоить компании каждый год после запуска - поддержка, лицензии, ресурсы на сопровождение
- Финансовый эффект - и его давал не ИТ, а сам бизнес-владелец инициативы
Последнее было принципиально. Раньше схема выглядела так: ИТ считает стоимость, бизнес называет желаемый эффект - и никто ни за что не отвечает. Теперь владелец инициативы должен был лично сформулировать финансовый эффект, дать цифру и ответить на один вопрос: "Ты готов за эту цифру отвечать?"
Не декларативно. С подписью под оценкой.
Раньше говорили: "вот это даст +2% выручки". Теперь нужно было не просто сказать цифру - нужно было участвовать в проекте и лично отвечать за эти +2%. Это другой разговор.
Как считали конкретный проект
Хочу показать механику расчёта на реальном примере. Один из проектов портфеля - замена кассового ПО. Название системы не раскрываю, но структура модели типичная для любой инфраструктурной замены.
В расчёт вошли четыре блока.
Стоимость лицензий: новое ПО на 60% дешевле текущего в пересчёте на рабочее место кассира. Это OPEX, который уходит каждый год по действующему договору.
Стоимость поддержки в год: новое решение в 4 раза дешевле. Поставщик старой системы за годы сложил хорошую для себя экономику - стоимость поддержки росла, а ценность оставалась прежней.
Замена оборудования: около 7% кассового парка требовало физического обновления. Это CAPEX, который нужно было честно учесть на входе, а не обнаружить в процессе как "непредвиденное".
Эффект от смены инструментария: старая система не давала маркетингу никаких промомеханик - всё, что можно было сделать на кассе, упиралось в ограничения платформы. Новая открывала 10+ различных механик с инструментом управления: акции, персональные предложения, бандлы, многоступенчатые программы. Маркетинг дал прогноз +10% к выручке по целевому сегменту - но не просто пообещал. Они проверили это на пилотной группе магазинов. Поэтому цифра шла не как оценка, а как подтверждённый результат, под который владелец направления взял обязательство.
Итого: не "нам нужна новая касса" - а полная экономическая модель с CAPEX первого года, дельтой OPEX и верифицированным бизнес-эффектом. Срок окупаемости вычислялся из этих чисел.
Так оценивали каждый проект из 117.
Фильтр, который из этого получился, простой:
- Есть владелец эффекта.
- Есть CAPEX первого года.
- Есть OPEX реализации.
- Есть OPEX владения.
- Есть финансовый эффект или понятная цена стратегического решения.
- Есть человек, готовый защищать проект перед CEO.
Если хотя бы одного элемента нет - это не проект. Это заявка на обсуждение.
Шаг третий. Отдельный подход к "стратегическим"
Часть инициатив не имела прямого ROI. Они числились стратегическими или имиджевыми - отдельный класс проектов с негласной защитой от вопросов про деньги.
Для них я не пытался насильно найти ROI. Я считал другое: какую дополнительную выручку должен принести бизнес, чтобы эти расходы не ухудшили P&L. При марже около 10% это означало: чтобы покрыть 10 млн расходов, бизнесу нужно было принести около 100 млн дополнительной выручки. Готов отвечать? Почти никто не был готов.
Стратегический ярлык - это была защитная конструкция. Она снимала ответственность за деньги. Как только её убрали - проекты либо получали реальную экономику, либо закрывались.
Детально этот подход разберу отдельно - именно здесь чаще всего прячутся политические проекты и именно здесь цена ошибки самая высокая.
Шаг четвёртый. Как владельцы сами закрыли свои проекты
117 - это число после нормализации, уже без явных дублей. Из них часть отсеялась ещё до экономического анализа: инициативы без автора, записи протоколов без ответственного, "хотелки" без содержания - их закрыл я сам. Экономические модели получили те проекты, у которых был реальный владелец и хотя бы декларируемый эффект.
Каждому владельцу отправили его же цифры. Собранный CAPEX, OPEX реализации, OPEX владения, оценку финансового эффекта, предварительный срок окупаемости. И один вопрос: готов идти защищать этот проект перед CEO?
Из этого пула более 90% закрылись по инициативе самих авторов после получения их экономической модели. Без давления. Без конфликтов. Без приказов сверху.
Здесь сработал главный механизм: не я спорил с руководителем, а его собственная экономика спорила с его инициативой.
Самая сложная часть была не Excel. Самая сложная часть - сказать руководителю, что его проект не пройдёт. Но в большинстве случаев этого не пришлось делать. Числа говорили сами.
Шаг пятый. Встреча с CEO и проектный комитет
После экономического анализа я сам прошёл через портфель и сделал первую сортировку без CEO: делать / пауза / закрыть.
Из 117 проектов к запуску было готово 7. Три ушли на паузу - экономика была, но не было нужного ресурса или момента. Остальные - закрыть до того, как они снова начнут есть ресурс.
Встреча с CEO была короткой. Он изучил список и сказал одну фразу: "Где не готов лично защищать - смотреть не буду. Остальные - на проектный комитет."
Это и был нужный фильтр. Если CIO сам не готов защищать проект, он не должен приносить его на комитет.
Два других топ-менеджера защитили свои инициативы на комитете.
Итог: 9 проектов в работу. 7 от меня, 2 - прошедшие защиту.
Полемика "ИТ не делает" исчезла. Потому что разговор стал не про задачи - а про деньги и ответственность за результат.
Шаг шестой. Закрыть вход
Чистки недостаточно. Если не изменить правила инициации - через квартал снова появились бы 50 новых проектов из протоколов очередного совещания.
Ввели форму инициативы с обязательными полями: предпосылки, потребности бизнеса, цели, границы проекта, результаты с владельцами и сроками, критерии успеха в трёх уровнях - минимальный, удовлетворительный, целевой.
Без заполненной формы - проект не рассматривался. Никаких исключений для "срочных стратегических".
Раз в месяц - проектный комитет. Новые инициативы утверждались для детальной проработки или отклонялись прямо на входе. Для утверждённых: детальный расчёт расходов, точки окупаемости, сравнение с подрядчиком и без - не только по стоимости, но и по сроку ввода в эксплуатацию. Скорость иногда дороже экономии.
По активным проектам - еженедельный статус-отчёт. Одна страница, формат светофора: В целом / Ресурсы / Данные и ИТ. Плюс задачи текущей и следующей недели. CEO видел картину за три минуты.
Цена этой модели
У такого подхода есть цена - и лучше говорить о ней честно.
Во-первых, нужен мандат CEO. Без него проектный фильтр быстро превращается в очередной Excel, который все обходят. Когда первый топ-менеджер приходит с "срочным стратегическим исключением" - именно здесь проверяется, работает система или нет.
Во-вторых, CIO становится неудобным человеком. Он не просто принимает задачи в работу, а задаёт вопросы про деньги, владельца и результат. Это меняет отношения с коллегами-топами.
В-третьих, форма инициативы сама по себе ничего не решает. Если комитет начинает утверждать исключения "по срочности", через квартал портфель снова расползается. Дисциплина входа важнее красоты шаблона.
Поэтому главное было не создать реестр. Главное - удержать правило: проект без владельца, экономики и критерия результата не входит в портфель. Иначе система снова превращается в список хотелок.
Что изменилось
Высвободилось 30+ человек из ИТ. Не уволили - просто перестали делать то, что никому не нужно за деньги компании. Люди перешли на задачи, которые влияли на результат.
ROI портфеля по итогам всей работы: >300%. Это не один проект - это итог перестройки системы управления изменениями в целом.
CEO перестал быть ручным коммутатором. ИТ перестало быть "чёрным ящиком, который ничего не делает". Собственник получил портфель, который можно открыть на любой строке и объяснить её на языке денег.
Не сократить список ради порядка. А вернуть компании право выбирать, куда уходят деньги и люди.
Управленческий вывод
Портфель становится управляемым, когда у каждого проекта есть деньги, владелец и право быть закрытым.
Пока проект живёт как просьба топ-менеджера - он почти неуязвим. Как только у него появляются цифры, подтверждённый эффект и обязательство по результату - слабые проекты закрываются сами. Без конфликтов, без политики, без приказов.
ИТ-портфель - это карта распределения ресурсов компании. Собственник имеет право видеть эту карту в цифрах. А CIO обязан её собрать.