Денег на ИТ становится меньше. Как пересобрать портфель и не затормозить бизнес

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

Бюджеты сокращаются, задачи — нет

В 2025–2026 годах российский ИТ-рынок оказался в непростой ситуации: компаниям приходится одновременно экономить и продолжать цифровые изменения.

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

Но отказаться от ИТ бизнес при этом не может.

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

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

При этом ожидания от ИТ остаются прежними. От команд требуют: быстрее выводить продукты на рынок, сокращать операционные расходы, автоматизировать ручные процессы, поддерживать устойчивость инфраструктуры, внедрять AI.
Только ресурсов на все это становится меньше.
Самое очевидное решение в такой ситуации — этот пропорционально урезать бюджеты всех проектов. Но именно это решение часто создает больше проблем, чем решает.

Почему нельзя просто сократить каждый проект на 20%

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

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

• архитектурные улучшения;
• модернизация инфраструктуры;
• платформенные решения;
• устранение технического долга;
• развитие внутренних инженерных компетенций.

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

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

ИТ-портфель — это не список всех текущих проектов

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

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

Все эти аргументы объясняют, почему проект существует. Но не отвечают на главный вопрос: нужен ли он бизнесу сейчас.

Проект может быть успешным, а портфель — нет

Здесь важно разделить проектное и портфельное управление.
Проектное управление отвечает на вопрос: как выполнить конкретную инициативу в срок, бюджет и с нужным качеством?
Портфельное: стоит ли эту инициативу вообще продолжать и должна ли компания тратить на нее ограниченные ресурсы?
Можно очень эффективно реализовать десять проектов и все равно потерять деньги, если ни один из них не решает сегодняшние задачи бизнеса. Особенно хорошо это видно в периоды быстрых изменений.

Несколько лет назад компании активно инвестировали в mobile-first, цифровые витрины, новые каналы продаж и продуктовые эксперименты. Сегодня у многих в приоритетах: импортозамещение, ИБ, устойчивость инфраструктуры, снижение операционных затрат, автоматизация, AI, модернизация легаси. Проблема возникает, если бизнес-приоритеты поменялись, а ИТ-портфель продолжает жить по плану, утвержденному два года назад.
В итоге деньги идут на вчерашние задачи, а на сегодняшние их не хватает.

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

В кризис важна не загрузка команд, а эффект для бизнеса

Еще одна распространенная ловушка — считать эффективность ИТ по загрузке специалистов. Если разработчики заняты на 100%, аналитики расписаны на несколько месяцев вперед, а очередь задач постоянно растет, может показаться, что ресурс используется максимально эффективно. На деле полная загрузка часто говорит об обратном: проектов слишком много. Людей дробят между инициативами, приоритеты постоянно конфликтуют, специалисты переключаются между задачами, а сроки начинают разъезжаться. Поэтому при сокращении бюджета задайте вопрос: что конкретно бизнес получает от каждого проекта? При этом ценность не обязательно выражается в новой выручке.

Проект может быть важен, потому что:

• сокращает операционные затраты;
• уменьшает стоимость поддержки;
• ускоряет time-to-market;
• автоматизирует дорогой ручной процесс;
• уменьшает зависимость от legacy;
• закрывает требования регулятора;
• снижает киберриски;
• повышает отказоустойчивость критичной системы.

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

Как пересобрать ИТ-портфель

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

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

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

• инфраструктурные проекты;
• небольшие доработки для подразделений;
• импортозамещение;
• регуляторные задачи;
• модернизация legacy;
• внутренние платформы;
• исследовательские инициативы;
• пилоты и PoC.

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

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

Шаг 2. Отделить обязательное от желательного

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

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

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

Шаг 3. Проверить бизнес-эффект остальных проектов

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

Шаг 4. Не бояться останавливать уже начатое

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

Шаг 5. Перенаправить команды, а не просто сократить их

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

Почему сокращение проектов опасно превращать в сокращение компетенций

ИТ-портфель существует не только в Jira, бюджетах и презентациях. Он держится на знаниях людей. Инженеры могут годами накапливать понимание архитектуры системы, интеграций, бизнес-процессов, технических ограничений. Эти знания редко полностью описаны в документации. Поэтому специалист, которого формально можно убрать вместе с проектом, иногда оказывается одним из немногих людей, понимающих критичный фрагмент инфраструктуры. Для enterprise-систем этот риск особенно высок: они развиваются годами, обрастают зависимостями, интеграциями и нестандартными решениями.

Еще один риск — люди перестают верить в приоритеты

Если компания постоянно объявляет новые стратегические инициативы, а через несколько месяцев закрывает их без объяснений, сотрудники быстро замечают закономерность. И начинают относиться к любому новому проекту как к временному. Зачем глубоко продумывать архитектуру, если через полгода программу остановят? Зачем проявлять инициативу, если приоритет снова изменится? Зачем строить сильную команду вокруг продукта, судьба которого зависит от очередного бюджетного цикла? В итоге хаотичная оптимизация начинает снижать не только мотивацию, но и качество инженерных решений. Поэтому при пересмотре портфеля особенно важна прозрачность. Команды должны понимать, почему компания сокращает конкретные инициативы, по каким критериям принимаются решения, куда будут перераспределять людей, какие задачи бизнес считает приоритетными на ближайший год.

Что нельзя сокращать вслепую

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

Технический долг. Его можно временно принять, но нельзя годами игнорировать. Иначе все больше бюджета будет уходить просто на поддержание скорости разработки.
Инфраструктура. Сокращать ее развитие можно только после оценки нагрузки, отказоустойчивости и стоимости потенциальных простоев.
Безопасность. Здесь цена экономии может значительно превышать сам сокращенный бюджет.
Архитектурные компетенции. Архитекторов и senior-инженеров дорого содержать, но еще дороже восстанавливать их знания после ухода.
Платформенные решения. Иногда их эффект сложно отнести к конкретному продукту, хотя ими пользуется сразу несколько команд.

Хороший портфель не обязательно маленький

Компании нужен такой набор инициатив, который она действительно способна профинансировать и реализовать без постоянного разрыва между приоритетами. Иногда это означает закрыть треть портфеля. Иногда — оставить почти все, но сократить scope. А иногда проблема вообще не в количестве проектов, а в том, что значительная часть ресурсов уходит на поддержку устаревшей инфраструктуры. Поэтому универсальной формулы вроде «оставьте пять самых прибыльных инициатив» здесь нет.

Важно сохранить способность снова ускориться

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

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

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