Вот неудобная правда, которую IT-директора знают, но редко говорят вслух: до 80% IT-бюджета уходит на то, чтобы просто «держать свет включённым». На развитие остаются крохи.
По данным Gartner, средняя доля расходов на Run the Business (поддержку существующих систем) в enterprise-компаниях составляет 70–75% от общего IT-бюджета. В некоторых отраслях — банках, страховании, телекоме — эта цифра доходит до 80–85%.
Что это значит на практике?
Из каждых 100 рублей IT-бюджета:
- 75 уходят на то, чтобы системы не падали
- 15 -на небольшие улучшения в текущем ландшафте
- И только 10 остаётся на настоящие изменения — новые продукты, цифровую трансформацию, конкурентные преимущества
McKinsey называет это «ловушкой технического долга». Forrester — «эффектом проедания бюджета». IDC фиксирует, что компании с высокой долей Run тратят в 2–3 раза больше на IT, но получают на 40% меньше бизнес-ценности.
И вот что самое опасное: этот разрыв только увеличивается.
Каждый год доля Run растёт. Каждый год на Change остаётся всё меньше. Компании превращаются в заложников собственной инфраструктуры — они платят всё больше просто за то, чтобы оставаться на месте.
1. Анатомия проедания: куда уходит IT-бюджет
Давайте разберём, на что конкретно уходят эти 70–80% бюджета на Run:
Поддержка legacy-систем Системы, которым 10–15–20 лет. Они работают. Они критичны. Но их поддержка требует редких специалистов, дорогих лицензий и постоянных «костылей». По оценкам Deloitte, компании тратят до 60% IT-бюджета на поддержку систем старше 10 лет.
Операционная поддержка инфраструктуры Серверы, сети, хранилища, облачные подписки. Это не разовые траты — это постоянные операционные расходы, которые растут с каждым годом. Особенно в гибридных и мультиоблачных средах.
Лицензии на ПО Enterprise-лицензии на ERP, CRM, офисное ПО, СУБД, системы безопасности. Каждый год рост на инфляцию плюс «небольшое» повышение от вендора. За 5 лет стоимость владения лицензиями может вырасти на 30–50%.
Интеграции и технический долг Каждая новая система добавляет интеграций. Каждая интеграция требует поддержки. С каждым годом сложность растёт нелинейно, а вместе с ней — и стоимость поддержки.
Инциденты и «тушение пожаров» Системы падают. Баги проявляются. Безопасность требует патчей. IT-команды тратят 40–60% времени на реактивные задачи вместо проактивного развития.
Compliance и регуляторные требования Локализация данных, суверенные облака, отраслевые стандарты, импортозамещение. Каждое новое требование — это дополнительные расходы на адаптацию существующих систем.
Результат: бюджет «проедается» на поддержание статус-кво. На то, чтобы вчерашние решения продолжали работать сегодня.
2. Почему доля Run только растёт: порочный круг технического долга
Самое страшное в ловушке Run vs Change — это самоусиливающийся эффект.
Вот как это работает:
Год 1: Компания тратит 70% на Run, 30% на Change. Запускают несколько новых систем.
Год 2: Новые системы нужно поддерживать. Старые системы никуда не делись. Доля Run вырастает до 72%. На Change остаётся 28%.
Год 3: Интеграций стало больше. Техдолг накопился. Команда тушит инциденты. Run — уже 75%. Change — 25%.
Год 4: Бизнес требует быстрых результатов. IT под давлением делают «быстрые решения» вместо правильных. Техдолг растёт ещё быстрее. Run — 78%. Change — 22%.
Год 5: Компания понимает, что застряла. Почти весь бюджет уходит на поддержку. На реальные изменения денег почти нет.
По данным McKinsey, каждый год промедления с выплатой техдолга увеличивает его стоимость на 20–30%. Чем дольше откладываешь рефакторинг и модернизацию — тем дороже они обходятся.
И вот парадокс: компании знают об этой проблеме, но ничего не делают. Потому что «некогда» — нужно тушить текущие пожары. Порочный круг замыкается.
3. Реальные примеры из практики: как компании застревают
Кейс 1: Банк, который не может запустить новый продукт
Крупный российский банк. Годовой IT-бюджет — сотни миллионов рублей. Доля Run — 82%.
Бизнес хочет запустить новый цифровой продукт для молодёжной аудитории. Быстрый, современный, mobile-first.
IT говорит: «Нужно интегрироваться с core banking системой». Интеграция займёт 8–12 месяцев. Потребует специалистов, которых почти не осталось на рынке.[AZ1]
Бизнес спрашивает: «Может, сделаем отдельно, на современном стеке?» IT отвечает: «Можем. Но тогда у вас не будет единого view клиента, синхронизации остатков, централизованного риск-менеджмента. Нужна интеграция. А для интеграции нужны изменения в core».
Проект откладывается. Бюджет на Change тратится не на новый продукт, а на попытку подружить новое со старым.
Конкурент-необанк за это время запускает три новых фичи.
Кейс 2: Ритейлер, который платит за то, что не использует
Федеральная розничная сеть. Несколько сотен магазинов. IT-ландшафт собирался 15 лет.
Анализ показал:
- 40% серверных мощностей не используются (купили «с запасом», но рост бизнеса замедлился)
- 25% SaaS-лицензий оплачиваются, но не активны (купили, внедрили, не прижилось)
- 15 интеграционных шин для разных систем — часть дублируют функции
- Три разных системы управления складом в разных регионах
Каждый год компания платит за всё это. Миллионы рублей на поддержку неэффективности.
Бизнес просит запустить omnichannel и единый личный кабинет покупателя. IT отвечает: «Нет бюджета. Всё уходит на поддержку».
Кейс 3: Производственная компания и ERP-ловушка
Промышленное предприятие. 10 лет назад внедрили западную ERP-систему. Инвестиции — огромные. Кастомизаций — тысячи.
Сегодня:
- Вендор ушёл с российского рынка
- Поддержка — через партнёров, в 2–3 раза дороже
- Обновления не приходят
- Каждая кастомизация требует ручной поддержки
60% IT-бюджета уходит на поддержку этой ERP.
Компания понимает: нужно переходить на российскую систему. Но миграция — это 2–3 года и огромный бюджет, а качественного аналога на российском рынке нет. В итоге денег на «компромиссное» новое решение выделять не рискуют, в итоге бюджет уходит на поддержку старого решения.
Кейс 4: IT-команда, которая только тушит пожары
Средняя IT-компания. Портфель продуктов — 5 SaaS-решений.
Анализ времени разработчиков показал:
- 45% времени — исправление багов и техподдержка
- 25% времени — поддержка legacy-кода
- 15% времени — «срочные» доработки по требованию продаж
- 15% времени — разработка нового функционала
Команда выгорает. Новые фичи выходят медленно. Конкуренты обгоняют.
Руководство спрашивает: «Почему так медленно?» Разработка отвечает: «Потому что 85% времени мы латаем старое, а не создаём новое».
Но изменить приоритеты не могут — клиенты требуют поддержки, баги нужно чинить, legacy никуда не исчезает.
4. Последствия: что происходит, когда Run съедает весь бюджет
Когда компания тратит 75–80% бюджета на Run, последствия неизбежны:
Потеря конкурентоспособности Конкуренты запускают новые продукты, осваивают новые технологии, экспериментируют. Вы — поддерживаете старое. Разрыв растёт.
Деморализация IT-команды Никто не хочет всю жизнь чинить чужой код и поддерживать legacy. Сильные разработчики уходят. Остаются те, кто боится рынка или привык к рутине.
Рост техдолга с ускорением Чем дольше откладываете модернизацию — тем дороже она обходится. Через 3–5 лет техдолг может стоить в 5–10 раз дороже, чем если бы его выплатили сразу.
Невозможность быстрых изменений Бизнес хочет новый канал продаж за 3 месяца. IT отвечает: «Минимум год, потому что нужно переделать 15 интеграций». Медленный time-to-market убивает конкурентоспособность.
Зависимость от вендоров и редких специалистов Legacy-системы держатся на нескольких людях, которые их понимают. Если они уйдут — катастрофа. Вендоры это знают и поднимают цены, потому что альтернативы нет.
По оценкам IDC, компании с долей Run выше 75% на 60% реже выводят новые продукты и на 40% медленнее реагируют на изменения рынка, чем компании с долей Run ниже 60%.
5. Как вырваться из ловушки: три стратегии
Компании, которым удалось изменить баланс Run vs Change, использовали одну из трёх стратегий (или их комбинацию):
Стратегия 1: Жёсткая приоритизация и отказ от неэффективного
Они провели ревизию IT-ландшафта и задали жёсткие вопросы:
- Какие системы реально критичны?
- Какие можно выключить без ущерба для бизнеса?
- Какие интеграции дублируют друг друга?
- Какие лицензии оплачиваются, но не используются?
Результат: вырезали 15–25% неэффективных трат и перебросили деньги на Change.
Пример: федеральный ритейлер выключил 12 устаревших систем, консолидировал три интеграционные шины в одну, отказался от неиспользуемых облачных подписок. Освободили 18% бюджета без потери функциональности.
Стратегия 2: Планомерная выплата техдолга
Они закрепили в бюджете отдельную статью на техдолг — 10–15% ежегодно.
Не «когда будет время», а каждый квартал, по плану:
- Рефакторинг критичных модулей
- Миграция с legacy на современные стеки
- Упрощение архитектуры и сокращение зависимостей
- Автоматизация рутинных операций
Да, это отнимает ресурсы сейчас. Но через 2–3 года освобождает 20–30% бюджета за счёт снижения стоимости поддержки.
Пример: телеком-компания выделила 12% бюджета на выплату техдолга. За три года снизили долю Run с 78% до 65% и высвободили ресурсы на запуск новых сервисов.
Стратегия 3: Вынос Run на аутсорсинг или автоматизацию
Они вынесли поддержку инфраструктуры и рутинных операций на аутсорсинг или заменили их облачными/SaaS-решениями.
Инфраструктура — в облако с управляемыми сервисами. Рутинные операции — автоматизация через IaC, CI/CD, AIOps. Первая линия поддержки — аутсорсинг с чёткими SLA.
Внутренняя команда фокусируется только на критичных системах и на развитии.
Пример: производственная компания перевела инфраструктуру в облако с managed services. Сократили команду Ops на 40%, перебросили людей в разработку. Доля Change выросла с 22% до 38%.
6. Главный принцип: управлять балансом осознанно
Баланс Run vs Change — это не разовая оптимизация. Это постоянное управленческое решение.
Нельзя один раз «исправить» и забыть. Каждый год:
- Нужно измерять долю Run и Change
- Нужно ставить целевые показатели
- Нужно отслеживать, как меняется баланс
- Нужно принимать сознательные решения о том, что вырезать, что модернизировать, что выносить
По данным Gartner, компании с целевыми показателями по балансу Run/Change достигают на 50% лучших результатов в цифровой трансформации, чем компании, которые «живут как получится».
Вывод: «проедать» бюджет — это выбор
Компании не «попадают» в ловушку Run vs Change случайно. Они выбирают её сознательно или по умолчанию.
Сознательно — когда откладывают модернизацию «на потом», потому что «некогда». По умолчанию — когда вообще не управляют балансом и не отслеживают, куда уходят деньги.
В обоих случаях результат один: бюджет проедается на поддержание вчерашних решений, а на завтрашние — не остаётся.
2026 год — это год, когда игнорировать эту проблему становится опасно. Конкуренты уже вырвались из ловушки. Они тратят 40–50% бюджета на Change и обгоняют вас.
А вы всё ещё тратите 80% на то, чтобы держать свет включённым.
Вопрос не в том, знаете ли вы об этой проблеме. Вопрос в том, когда вы начнёте её решать.
