Как не спустить IT-бюджет 2027 года: 5 вопросов,
о которых нужно задуматься

Краткий ответ: бюджет 2027 года перестанет быть «списком затрат» только в одном случае — если каждая строка в нём отвечает на конкретный вопрос о бизнес-эффекте, а не о функциональности софта. IT-директору нужно перевести разговор с собственником и CFO с языка технологий на язык денег, сроков и персональной ответственности. Пять вопросов ниже — минимальный фильтр, который отсеивает инвестиции, создающие видимость развития, от инвестиций, которые действительно двигают сквозные процессы.

Давление на IT-бюджеты растёт с двух сторон. С одной стороны, ожидания бизнеса от искусственного интеллекта и модернизации инфраструктуры высоки как никогда. С другой — терпимость к «стратегическим» расходам без измеримого возврата падает. Forrester фиксирует, что предприятия откладывают 25% запланированных расходов на ИИ до 2027 года, а CEO всё чаще передают решения о технологических инвестициях CFO, которые требуют чёткого ROI до одобрения.

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

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

Проблема: владелец бизнеса видит в бюджете названия программ. IT-директор видит технические задачи. Разрыв в языке приводит к тому, что одобрение получают проекты, которые «давно хотели попробовать», а не те, что снимают реальные узкие места.

Что делать: каждая значимая статья бюджета должна быть привязана к конкретному отрезку сквозной цепочки — от заявки до отгрузки, от лида до оплаты, от инцидента до восстановления — и к измеримому изменению в днях или рублях.
Формулировка «сокращаем путь от заявки до отгрузки с 11 до 7 дней» работает. Формулировка «станет удобнее» — нет. Причём речь не только о прямой экономии. Сокращение цикла обработки заказа высвобождает оборотный капитал, снижает риск просрочек и уменьшает ручной труд на стыках. В защите бюджета перед CFO это переводится в часы и фонд оплаты труда: «сейчас 10 сотрудников тратят неделю на консолидацию, после внедрения — 3 человека за два дня».

Практическое правило: если IT-директор не может назвать цифру до и после по конкретной цепочке, статья бюджета остаётся в зоне риска при первом же секвестре.

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

Что делать: при оценке любого решения — покупки, интеграции, замены — нужно явно очертить его границы и задать вопрос: «Что происходит в точке, где заканчивается зона ответственности этой системы и начинается зона другого отдела?» Если вендор или внутренняя команда говорит «система закрывает всё», это сигнал: о дырах между отделами не подумали.
Практический артефакт здесь — карта разрывов по одной сквозной цепочке. На ней отмечаются точки, где процесс застревает, стоимость простоя в месяц и максимальные потери. Бюджет, который чинит переходы между отделами, окупается почти всегда. Бюджет, который даёт новый софт отделу, где и так было неплохо, — почти никогда.

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

Исследования середины рынка показывают масштаб проблемы: около трети IT-руководителей считают, что более половины их облачных расходов тратится впустую из-за недостатка видимости и управления. Та же логика работает с любыми новыми системами: без явной статьи на интеграцию и поддержку стыков «хвост» расходов всплывёт через квартал-два после запуска.

Что делать: в смете на 2027 год интеграционные расходы должны быть не примечанием, а отдельной защищённой строкой.
Минимальный чек-лист:

• какие системы уже используются в этой цепочке и какие протоколы/API они поддерживают;
• кто отвечает за интеграцию — внутренняя команда или подрядчик;
• что происходит при обновлении любой из стыкуемых систем;
• какой объём данных пойдёт через интеграцию и выдержит ли её текущая инфраструктура.

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

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

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

Что делать: для каждой существенной инвестиции в бюджете 2027 года должна быть одна бизнес-метрика, один срок проверки (квартал — разумный минимум) и один человек, чья ответственность закреплена формально. Не «команда проекта», а конкретная роль: владелец процесса, руководитель направления, функциональный заказчик.

Формулировка «сокращение сроков обработки заказов с 9 до 6 дней к концу Q2, ответственный — директор по операциям» работает. «Повышение эффективности закупок» — нет, потому что через квартал невозможно проверить, наступило ли оно.

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

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

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

Инструмент, который не требует бюджета и согласований, — карта разрывов по одной сквозной цепочке. Возьмите цепочку, которая генерирует выручку или потребляет значимые ресурсы: заявка → согласование → производство/закупка → отгрузка → оплата.

Отметьте на ней:

1. Где процесс физически останавливается — не в системе, а в реальности: ждёт подписи, ждёт данных, ждёт ответа от смежного отдела.
2. Сколько каждый простой стоит в месяц — в днях задержки, в часах ручной работы, в процентах просроченных обязательств.
3. Где потери максимальны — и какая статья бюджета 2027 года адресована именно этой точке.

Бюджет, который чинит переходы между отделами, окупается почти всегда. Бюджет, который просто даёт новый софт отделу, где и так всё было неплохо, — почти никогда. Эта проверка занимает меньше времени, чем согласование одной лишней лицензии, и даёт IT-директору главное: позицию для разговора с собственником на одном языке.