Автор: Владимир Белозеров, заместитель коммерческого директора KODE
Компании сокращают ИТ-бюджеты, но требований к цифровым продуктам меньше не становится. Бизнес по-прежнему ждёт автоматизации, устойчивой инфраструктуры, быстрых релизов и внедрения AI.
Поэтому задача CIO и CTO сегодня не просто сократить расходы, а понять, какие проекты действительно нужно сохранить, от каких отказаться и как перераспределить людей так, чтобы вместе с бюджетом не потерять критические компетенции.
Бюджеты сокращаются, задачи — нет
В 2025–2026 годах российскому бизнесу приходится одновременно экономить и продолжать цифровые изменения.
По данным исследований, на которые ссылается РБК, около 29% российских компаний сократили ИТ-бюджеты. В отдельных отраслях снижение достигало 10–40%. Среди причин — падение спроса, ограничения финансирования и дефицит ликвидности.
При этом отказаться от ИТ уже невозможно. Цифровые продукты, автоматизация, информационная безопасность и инфраструктура давно перестали быть экспериментальными статьями расходов. По данным, которые приводят «Ведомости», ИТ-сектор формирует более 2,2% ВВП России, или около 4 трлн рублей.
На уровне отдельной компании всё ещё проще: если перестать развивать клиентские сервисы, обновлять инфраструктуру и автоматизировать процессы, экономия довольно быстро начнёт мешать самому бизнесу.
Поэтому идея просто урезать всем проектам бюджет, например на 20%, выглядит логично только на первый взгляд.
Почему нельзя одинаково сокращать все проекты
Разные ИТ-инициативы дают бизнесу разную ценность.
Один проект закрывает требования регулятора. Второй снижает стоимость операций. Третий поддерживает критичную систему. А четвёртый существует уже несколько лет в основном потому, что его когда-то согласовали.
Если сократить все четыре одинаково, компания сохранит слабые проекты и одновременно недофинансирует важные.
Особенно легко в такой ситуации отложить то, что сложно показать в квартальном отчёте:
- модернизацию инфраструктуры;
- архитектурные улучшения;
- устранение технического долга;
- платформенные решения;
- развитие внутренних инженерных компетенций.
На коротком горизонте это действительно экономит деньги. Но через год изменения становятся дороже, legacy забирает всё больше ресурсов, а разработка новых функций замедляется.
Поэтому вопрос должен звучать не «где урезать ещё 10%», а куда сейчас действительно стоит направить ограниченные деньги и людей.
ИТ-портфель — не список всех проектов, которые когда-то начали
Во многих компаниях портфель складывается исторически.
Одно подразделение запускает CRM, другое — приложение, третье — аналитическую платформу. Параллельно появляются инфраструктурные, регуляторные проекты, импортозамещение и внутренние инструменты.
Через несколько лет компания получает десятки инициатив, каждая со своим заказчиком, бюджетом и аргументом, почему её нельзя остановить.
При этом значительная часть денег может уходить просто на поддержку существующей инфраструктуры, и на новые задачи почти ничего не остаётся. Об этой проблеме российского рынка пишут, например, в обзоре сокращения ИТ-бюджетов.
В этот момент появляются знакомые аргументы: «Мы уже начали». «Бюджет согласован». «Это есть в стратегии». «Мы уже слишком много вложили, чтобы останавливать».
Но всё это объясняет прошлое проекта, а не отвечает на главный вопрос: нужен ли он бизнесу сейчас.
Проект может идти отлично и всё равно быть лишним
Проектное управление отвечает на вопрос: как закончить инициативу в срок и бюджет.
Портфельное управление — стоит ли вообще продолжать эту инициативу.
Можно отлично реализовать десять проектов и всё равно потратить ресурсы впустую, если они решают вчерашние задачи.
Несколько лет назад компании много инвестировали в mobile-first, новые цифровые витрины и продуктовые эксперименты. Сейчас во многих организациях выше в списке:
- информационная безопасность;
- импортозамещение;
- устойчивость инфраструктуры;
- снижение операционных расходов;
- автоматизация;
- AI;
- модернизация legacy.
Российский рынок хорошо показывает, насколько приоритеты зависят от отрасли: где-то цифровые инвестиции продолжают расти, а где-то на первый план вышли поддержка инфраструктуры и экономия. Об этом, например, пишет ComNews.
Поэтому универсального «правильного портфеля» нет. Важнее, насколько быстро компания умеет его пересматривать.
Не считайте эффективность по полной загрузке команды
Если разработчики заняты на 100%, аналитики расписаны на три месяца вперёд, а очередь задач только растёт, это может выглядеть как эффективное использование ресурсов.
Но часто это означает, что проектов просто слишком много.
Люди постоянно переключаются, приоритеты конфликтуют, сроки едут, а действительно важные инициативы движутся так же медленно, как второстепенные.
Гораздо полезнее спросить:
Что именно бизнес получает от этого проекта?
Ценность не всегда выражается в новой выручке. Проект может:
- сокращать операционные расходы;
- уменьшать стоимость поддержки;
- ускорять вывод изменений;
- автоматизировать дорогой ручной процесс;
- снижать зависимость от legacy;
- закрывать требования регулятора;
- уменьшать киберриски;
- повышать устойчивость критичных систем.
Именно эти эффекты и стоит сравнивать между собой.
Как пересобрать ИТ-портфель
Когда бюджет уже сокращён, обычно нет времени полгода строить идеальную систему оценки. Нужен достаточно простой способ увидеть картину целиком и принять несколько неприятных решений.
Шаг 1. Соберите все инициативы в одном месте
Сначала нужно понять, на что вообще уходят ресурсы.
Кроме заметных продуктовых проектов в компании могут существовать небольшие доработки подразделений, импортозамещение, инфраструктурные работы, legacy-модернизация, пилоты, PoC и внутренние платформы.
По каждой инициативе достаточно собрать базовые данные:
- зачем она нужна;
- сколько стоит;
- сколько людей занимает;
- какой эффект должна дать;
- насколько критична;
- от чего зависит;
- что произойдёт, если её остановить.
Уже на этом этапе обычно находятся проекты, цель которых никто не может нормально объяснить.
Шаг 2. Отделите обязательное от желательного
Не всё можно оценивать через прямой ROI.
Проект по безопасности или регуляторным требованиям может не приносить дополнительную выручку, но отказаться от него всё равно нельзя.
Поэтому сначала стоит выделить то, что обеспечивает работу бизнеса:
- критичные системы;
- безопасность;
- требования регуляторов;
- обязательное импортозамещение;
- устранение рисков, способных остановить операции.
А уже оставшийся ресурс распределять между инициативами развития.
Шаг 3. Проверьте эффект остальных проектов
У каждой инициативы должна быть понятная причина оставаться в портфеле.
Если команда не может объяснить, как проект влияет на деньги, скорость, риски, клиентский опыт или операционную эффективность, его приоритет стоит пересмотреть.
При этом проект необязательно сразу закрывать. Можно:
- уменьшить объём;
- перенести часть функций;
- заменить собственную разработку готовым решением;
- объединить несколько инициатив;
- провести короткий пилот вместо большого запуска.
Цель не в том, чтобы закрыть как можно больше, а в том, чтобы высвободить ресурс с минимальной потерей ценности.
Шаг 4. Не бойтесь остановить уже начатое
Это психологически одна из самых сложных частей.
Чем больше вложено, тем сильнее желание закончить. Но прошлые расходы не делают проект полезнее сегодня.
Если рынок, стратегия или экономика изменились, смотреть нужно не на то, сколько уже потрачено, а на два других вопроса:
Сколько ещё придётся вложить?
Что бизнес получит за эти деньги?
Иногда остановить проект оказывается дешевле, чем закончить его просто потому, что «жалко бросать».
Шаг 5. Перенаправляйте людей, а не автоматически сокращайте их
Закрыть проект и вместе с ним убрать команду кажется очевидным способом сэкономить.
Но здесь компания может потерять больше, чем рассчитывала.
Инженеры годами накапливают знания об архитектуре, legacy, интеграциях, внутренних платформах и особенностях бизнес-процессов. И далеко не всё это записано в документации.
Человек, который формально работал на закрытом проекте, может оказаться одним из немногих, кто понимает критичный участок системы.
Если такую экспертизу потерять, экономия быстро превратится в:
- больше инцидентов;
- более дорогую поддержку;
- медленные изменения;
- повторное изучение системы;
- найм дорогих внешних специалистов.
Поэтому закрытие проекта не обязательно должно означать исчезновение команды. Сильных специалистов сначала стоит попробовать перевести на более приоритетные направления.
Не превращайте смену приоритетов в хаос
Есть ещё один риск: сотрудники перестают верить в сами приоритеты.
Если компания постоянно объявляет стратегические проекты, а через несколько месяцев закрывает их без объяснений, люди быстро понимают, что любой новый фокус может оказаться временным.
И начинают соответствующе относиться к работе: зачем глубоко думать об архитектуре и брать ответственность, если через полгода всё отменят?
Поэтому при пересборке портфеля важно объяснять:
- почему закрывают конкретные инициативы;
- по каким критериям принимаются решения;
- какие направления остаются приоритетными;
- что будет с командами;
- на чём бизнес сосредоточится дальше.
Сами изменения обычно менее разрушительны, чем ощущение, что решения принимаются случайно.
Что опасно сокращать вслепую
Есть несколько категорий, где экономия особенно легко превращается в будущие расходы.
Технический долг. Его можно временно принять, но если игнорировать годами, всё больше ресурсов начнёт уходить просто на поддержание прежней скорости разработки.
Инфраструктура. Сокращать её развитие стоит только после оценки нагрузки, отказоустойчивости и цены возможного простоя.
Безопасность. Здесь потенциальный ущерб может быть намного больше сэкономленного бюджета.
Архитектурная экспертиза. Сильных senior-инженеров и архитекторов дорого содержать, но восстановить накопленные ими знания после ухода ещё дороже.
Платформенные решения. Их эффект часто сложно привязать к одному продукту, хотя ими пользуется сразу несколько команд.
Поэтому критерий «не приносит выручку прямо сейчас» для ИТ слишком примитивен.
Хороший портфель не обязательно маленький
Цель пересборки — не оставить пять проектов вместо двадцати.
Нужен такой набор инициатив, который компания реально способна профинансировать и довести до результата.
Иногда для этого действительно приходится закрыть треть портфеля.
Иногда достаточно уменьшить объём почти всех проектов.
А иногда выясняется, что проблема не в их количестве, а в том, что слишком много ресурсов съедает устаревшая инфраструктура.
Поэтому при оценке лучше смотреть сразу на несколько вещей:
- какую ценность создаёт проект;
- какой риск возникает без него;
- сколько ресурсов он потребляет;
- какие зависимости создаёт;
- насколько дорого будет изменить решение позже.
Главное — не потерять способность снова ускориться
Во время сокращений легко думать только о ближайшем бюджете.
Но рынок снова изменится, появятся новые продукты и возможности. И тогда окажется важным не только то, сколько компания сэкономила, но и что у неё осталось.
Если за время оптимизации она потеряла ключевых инженеров, накопила критический технический долг, разрушила платформенные команды и перестала инвестировать в архитектуру, вернуть прежний темп будет намного сложнее, чем просто вернуть бюджет.
Поэтому хороший результат пересборки ИТ-портфеля — не минимально возможные расходы.
Это ситуация, в которой компания убрала лишние обязательства, но сохранила:
- ключевые инженерные компетенции;
- управляемую архитектуру;
- устойчивость критичных систем;
- возможность быстро перераспределять людей;
- способность запускать новые изменения.
В условиях ограниченного бюджета выигрывает не тот, кто сильнее всех урезал ИТ.
А тот, кто понимает, зачем финансирует каждый крупный проект, умеет вовремя закрывать потерявшие смысл инициативы и не уничтожает вместе с расходами собственную способность развиваться.