Как управлять ИТ-портфелем, когда бюджеты сокращаются, а задач становится больше

  Автор статьи: Владимир Белозеров, заместитель коммерческого директора в KODE

Российский бизнес оказался в противоречивой ситуации. Компании сокращают инвестиции, но одновременно требуют от ИТ больше скорости, автоматизации и устойчивости.

По данным исследований, на которые ссылается РБК, около 29% российских компаний сократили бюджеты на ИТ. В отдельных отраслях снижение составило от 10 до 40%. Среди причин — падение спроса, ограниченный доступ к финансированию и общий дефицит ликвидности.

При этом роль технологий в бизнесе продолжает расти. По оценкам, которые приводят «Ведомости», ИТ-сектор уже формирует более 2,2% ВВП России, или около 4 трлн рублей.

Получается простой конфликт: денег становится меньше, а задач — нет.

Бизнес по-прежнему ждет от ИТ:

1. более быстрого вывода продуктов на рынок;
2. автоматизации процессов;
3. сокращения операционных затрат;
4. надежной инфраструктуры;
5. внедрения AI;
6. снижения time-to-market.

На практике многие компании пытаются решить проблему самым очевидным способом: сокращают количество проектов или одинаково урезают бюджеты по всем направлениям.

Но равномерное сокращение расходов редко означает равномерное сокращение потерь.

Чаще всего под давление попадают те статьи, эффект от которых сложно показать в ближайшем квартальном отчете:

1. архитектура;
2. платформенные решения;
3. инфраструктура;
4. работа с техническим долгом;
5. внутренние инженерные компетенции.

На короткой дистанции это действительно помогает снизить затраты.

Но уже через 12–18 месяцев последствия начинают проявляться в других бюджетах: растет стоимость изменений, замедляется разработка, увеличиваются расходы на поддержку, усиливается зависимость от legacy, а запуск новых продуктов становится сложнее.

Поэтому проблема сегодня не только в нехватке денег. Гораздо важнее другое: умеет ли компания быстро перераспределять ресурсы внутри ИТ-портфеля.

ИТ-портфель должен отражать текущие задачи бизнеса, а не историю компании

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

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

В условиях, когда до 70–80% ИТ-бюджета может уходить на поддержку существующей инфраструктуры, свободного ресурса для новых задач остается совсем немного.

Постепенно портфель превращается не в инструмент развития, а в список обязательств.

Проекты продолжают финансироваться потому, что:

1. уже запущены;
2. на них согласован бюджет;
3. за ними стоит сильный внутренний заказчик;
4. они включены в долгосрочные планы;
5. в них уже вложено слишком много денег, чтобы остановить.

Но ни один из этих аргументов не отвечает на главный вопрос: насколько эта инициатива полезна бизнесу сейчас.

Почему успешный проект еще не означает успешный ИТ-портфель

Проектное управление и управление портфелем решают разные задачи.

Проектное управление отвечает на вопрос:

Как реализовать конкретную инициативу в срок, бюджет и с нужным качеством?

Портфельное — на другой:

Какие инициативы компании вообще нужно финансировать сейчас?

Разница принципиальная.

Можно идеально реализовать десятки проектов, но вложить деньги не туда, куда требуется бизнесу в текущий момент.

Несколько лет назад многие компании активно инвестировали в:

1. mobile-first;
2. новые цифровые витрины;
3. экспериментальные каналы продаж;
4. клиентские приложения;
5. продуктовые гипотезы.

Сегодня у многих на первый план вышли другие задачи:

1. импортозамещение;
2. информационная безопасность;
3. надежность инфраструктуры;
4. автоматизация внутренних процессов;
5. AI;
6. сокращение стоимости операций;
7. модернизация legacy.

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

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

Российский рынок хорошо показывает, насколько по-разному компании реагируют на сокращение расходов. Ритейл, финтех и АПК могут продолжать наращивать отдельные цифровые направления, тогда как другие отрасли вынуждены концентрироваться на устойчивости и сокращении затрат.

Поэтому универсального «правильного» портфеля не существует.

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

Главный показатель зрелости здесь не количество проектов и не общий размер ИТ-бюджета, а способность быстро менять приоритеты.

Почему одинаковое сокращение всех проектов обычно не работает

При сокращении бюджетов компании часто выбирают наиболее политически удобный сценарий: каждое направление должно сэкономить условные 10–20%.

Такой подход кажется справедливым, потому что нагрузка распределяется между всеми.

Но с точки зрения бизнеса он редко оптимален.

У проектов разная ценность.

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

Если сократить каждый проект на одинаковый процент, компания одновременно:

1. недофинансирует критичные инициативы;
2. продолжает содержать слабые;
3. растягивает сроки;
4. создает дополнительный технический долг;
5. усложняет работу команд.

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

Но для этого портфель нужно оценивать не по принципу «всем понемногу», а по бизнес-ценности.

Занятая команда — не всегда эффективная команда

Еще одна распространенная ошибка — оценивать ИТ через загрузку сотрудников.

Логика понятна: если все специалисты заняты на 100%, значит ресурс используется эффективно.

На практике высокая утилизация может говорить о том, что проектов слишком много.

Когда один специалист работает сразу на нескольких инициативах, а команда постоянно переключается между приоритетами, растут издержки на коммуникацию и снижается реальная скорость разработки.

В результате компания видит полную загрузку, но получает более долгие сроки.

Поэтому в условиях ограниченного бюджета полезнее задавать другой вопрос:

какую конкретную ценность создает каждая инициатива?

При этом ценность не обязательно выражается только в выручке.

Для бизнеса результатом могут быть:

1. сокращение операционных расходов;
2. уменьшение стоимости поддержки;
3. снижение time-to-market;
4. повышение надежности систем;
5. автоматизация ручных операций;
6. снижение зависимости от legacy;
7. уменьшение регуляторных рисков;
8. повышение уровня информационной безопасности.

Если проект не помогает ни по одному из этих направлений, его место в портфеле стоит пересмотреть.

С чего начать пересборку ИТ-портфеля

В кризисной ситуации компании редко могут позволить себе несколько месяцев на создание идеальной системы управления инвестициями.

Нужен более практичный подход: быстро получить прозрачную картину и на ее основе принять решения.

Шаг 1. Собрать все инициативы

Пересборка начинается не с сокращения расходов, а с инвентаризации.

Для крупной компании уже этот этап может оказаться непростым.

Параллельно внутри организации могут существовать:

1. продуктовые проекты;
2. инфраструктурные инициативы;
3. регуляторные задачи;
4. локальные доработки для подразделений;
5. программы импортозамещения;
6. модернизация legacy;
7. внутренние платформы;
8. пилоты;
9. исследовательские проекты.

Часть инициатив живет в разных бюджетах, часть управляется разными подразделениями, а часть вообще может не попадать в общую картину.

По каждой инициативе нужно получить хотя бы базовую информацию:

1. цель;
2. бюджет;
3. состав команды;
4. текущий статус;
5. ожидаемый бизнес-эффект;
6. зависимости от других проектов;
7. риски остановки;
8. стоимость дальнейшего развития.

Первый результат такой работы — не экономия, а прозрачность.

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

Шаг 2. Выделить обязательные расходы

Не все ИТ-инициативы можно сравнивать исключительно по ROI.

Есть проекты, которые бизнес обязан реализовывать независимо от прямой финансовой отдачи.

Это может быть:

1. выполнение требований регуляторов;
2. информационная безопасность;
3. поддержка критичных систем;
4. обязательное импортозамещение;
5. устранение рисков, способных остановить бизнес;
6. требования к непрерывности работы.

Такую часть портфеля сначала нужно отделить от проектов развития.

И только после этого сравнивать между собой остальные инициативы.

Шаг 3. Проверить эффект проектов развития

Для каждого проекта должна существовать понятная причина, почему бизнес продолжает в него инвестировать.

Причем объяснение «проект уже запущен» таким аргументом не является.

Стоит смотреть, что конкретно изменится после реализации:

1. вырастет ли выручка;
2. снизятся ли расходы;
3. сократится ли время операции;
4. станет ли дешевле поддержка;
5. уменьшатся ли риски;
6. повысится ли скорость запуска новых функций.

Если измеримого результата нет, проект не обязательно сразу закрывать.

Можно:

1. уменьшить scope;
2. провести пилот;
3. объединить его с другой инициативой;
4. отложить вторичные функции;
5. перейти на готовое решение;
6. перенести запуск.

Задача — не остановить максимум проектов, а высвободить ресурс там, где потеря для бизнеса будет минимальной.

Шаг 4. Не учитывать уже потраченные деньги как аргумент

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

Возникает естественное желание «довести до конца, раз уж столько потратили».

Но деньги, потраченные год назад, не делают проект более полезным сегодня.

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

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

Самая опасная часть оптимизации — сокращение команд

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

При этом гораздо меньше внимания получает инженерная экспертиза.

Это может быть дорогой ошибкой.

ИТ-портфель — не только набор инициатив. Это также знания, накопленные внутри компании:

1. понимание архитектуры;
2. знание legacy-систем;
3. история интеграций;
4. понимание бизнес-доменов;
5. инженерные практики;
6. опыт работы с внутренними платформами.

Если проект закрывается, это еще не означает, что вместе с ним нужно автоматически сокращать людей.

Почему вместе с человеком можно потерять гораздо больше его зарплаты

В enterprise-компаниях системы редко существуют изолированно.

Инженер может формально числиться в одной команде, но одновременно быть носителем знаний о:

1. старой архитектуре;
2. интеграциях;
3. внутренних сервисах;
4. ограничениях платформы;
5. критичных бизнес-процессах.

Причем значительная часть этой информации часто нигде полностью не описана.

Если специалист уходит, компания может потерять знания, которые потом придется восстанавливать месяцами.

В краткосрочной перспективе сокращение действительно уменьшит payroll.

Но затем экономия может исчезнуть из-за:

1. роста числа инцидентов;
2. замедления разработки;
3. более дорогой поддержки;
4. необходимости заново исследовать системы;
5. привлечения внешних специалистов;
6. сложностей при модернизации legacy.

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

Закрытие проекта и сокращение команды — не одно и то же решение.

Почему хаотичная смена приоритетов демотивирует сильнее сокращений

Есть и организационный риск.

Если компания каждые несколько месяцев объявляет новую стратегическую инициативу, а затем так же быстро ее закрывает, сотрудники начинают воспринимать любой проект как временный.

У команды возникает логичный вопрос: зачем инвестировать силы в долгосрочные решения, если через полгода направление снова потеряет поддержку?

Постепенно это влияет на поведение:

1. сотрудники меньше проявляют инициативу;
2. инженеры выбирают более краткосрочные решения;
3. команды не хотят брать ответственность за большие изменения;
4. снижается доверие к руководству;
5. сложнее удерживать сильных специалистов.

Особенно сильно это бьет по продуктовой и инженерной культуре.

Поэтому антикризисное управление требует максимально понятной коммуникации.

Команды должны знать:

1. почему портфель меняется;
2. по каким критериям оцениваются проекты;
3. какие направления становятся приоритетными;
4. какие инициативы закрываются и почему;
5. что произойдет с командами после закрытия проектов.

Неопределенность обычно разрушает доверие сильнее, чем сами изменения.

Что особенно опасно сокращать без оценки последствий

При ограниченном бюджете под давление часто попадают инициативы с отложенным эффектом.

Это нормально, если решение принимается осознанно.

Но есть несколько направлений, где экономия требует особой осторожности.

Технический долг

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

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

В результате экономия превращается в постоянное снижение скорости разработки.

Инфраструктура

Инфраструктурные проекты редко дают красивый рост выручки в презентации.

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

Информационная безопасность

В этой области стоимость потенциального инцидента может существенно превышать сумму сокращенного бюджета.

Архитектурная экспертиза

Senior-инженеры и архитекторы обходятся дорого.

Но потеря их знаний может сделать еще дороже развитие и поддержку сложных систем.

Внутренние платформы

У платформенных решений не всегда есть собственный очевидный ROI, потому что эффект распределяется между несколькими продуктами и командами.

Если оценивать их только как отдельный проект, они могут казаться малоэффективными.

Но их закрытие способно увеличить расходы сразу в нескольких направлениях.

Хороший ИТ-портфель не обязательно должен стать маленьким

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

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

Для одной компании это может означать закрытие трети проектов.

Для другой — сокращение scope практически всех инициатив.

Для третьей — временную остановку новых продуктов и инвестиции в модернизацию инфраструктуры.

А иногда главный источник затрат вообще находится не в проектах развития, а в слишком дорогой поддержке старых систем.

Поэтому у портфеля нет универсального оптимального размера.

Важнее понимать по каждому крупному блоку:

1. какую ценность он создает;
2. сколько ресурсов требует;
3. какой риск возникает при остановке;
4. какие зависимости формирует;
5. насколько легко решение можно будет изменить позже.

Кризис заканчивается, а потерянные компетенции возвращаются долго

Одна из основных ошибок при сокращении бюджета — смотреть только на ближайший финансовый период.

Допустим, компания действительно снизила ИТ-расходы на 20%.

Но если одновременно она:

1. потеряла сильных инженеров;
2. остановила работу с техническим долгом;
3. разрушила платформенные команды;
4. стала еще сильнее зависеть от legacy;
5. заморозила модернизацию инфраструктуры,

то после восстановления рынка просто вернуть бюджет будет недостаточно.

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

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

Это означает сохранить:

1. критичные инженерные компетенции;
2. управляемую архитектуру;
3. устойчивость основных систем;
4. способность перераспределять команды;
5. возможность быстро запускать новые инициативы, когда изменится ситуация.

Эффективность ИТ-портфеля важнее его размера

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

Более устойчивыми оказываются организации, которые умеют быстро отвечать на несколько вопросов:

1. что действительно важно для бизнеса сейчас;
2. какие проекты перестали создавать ценность;
3. какие расходы являются обязательными;
4. где нужно сохранить экспертизу;
5. куда перенаправить освободившиеся ресурсы.

Фактически ИТ-портфель все больше становится инвестиционным портфелем.

У компании есть ограниченный капитал, и каждое направление должно конкурировать за него с другими инициативами.

Поэтому зрелое управление сегодня — это не способность один раз составить трехлетний roadmap и следовать ему независимо от обстоятельств.

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