От 3 недель к 2 дням: как ИТ учило ИИ отвечать финансам «почему столько»

4 раза в год ИТ-директор и его 10 лидов (разработка/поддержка/инфраструктура) считали: (1) какой нужен бюджет, а (2) как в выделенный-то попасть?

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

Впервые я с этой бедой столкнулся в 202*, когда на юнит 150 с небольшим человек (а тогда мы впервые нормально посчитали куда списываются часы), у нас ушло на пресейл и бюджетное управление 142 миллиона рублей в зарплатах или 12% от выручки.

Пресейл это аналог бюджетирования – вы изучаете требования (иногда их даже пишете), декомпозируете, проектируете и оцениваете. Но выигрываете только 1 из 5 – так что будем считать, что не в ИТ-компании этот показатель был бы 25-30 млн рублей.

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

А в апреле 2026 ко мне пришел руководитель проектного офиса в ритейл-компании с запросом "может от стресса наш бизнес начал генерить даже не идеи, а вайбкоженые прототипы, в 2 раза чаще, чем раньше, и один безумнее другого, и все хотят в прод, а давай придумаем как привести процесс в сознание?"

А для тех, кто не работал в крупном бизнесе, поясню – от идеи до Икеи *зачеркнуто* её реализации – чаще 13 месяцев, чем 13 дней – изменения на структуры в 1 000 – 30 000 человек запустить гораздо сложнее, чем написать прототип.

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

12 проджектов, пара архитекторов, директор по разработке, 3 техлида и 10 аналитиков на ежедневной основе прокручивали через себя поток новых и новых требований от бизнеса.

Я и аналитик Света обошли всех-всех (ИТ, бизнес, финансы) и оказалось, что проблема для начала даже не в перегрузке, а в полном несоответствии реального процесса – формально заявленному.

1. Заявленные 3 недели на инцест-оценку никто не контролировал, мы подбили данные по Jira – целиком это занимало 2-3 итерации в течение 4-6 месяцев.

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

2. До 1/3 оценок "отфутболивалась" через ничего не значащие комментарии. Например, инициативу по изменению контроля качества фасовочного процесса срубили через некорректный обрисованный с т зр иерархии состав смежных модулей, хотя скорее отправить ее в начало процесса скорее стоило из-за отсутствия корректно сформулированного экономического эффекта.

3. Оценки имели формальную и реальную структуру:

4. Классический реестр рисков каждый раз "прикладывался" полностью к проекту, отнимая у него суть.

5. Глубина декомпозиции задачи через Ганта требовалась такая, что настоящий никто не готовил, а сделанную фантазию – никто глубоко не смотрел.

Мы упорно сидели и выписывали частотность ошибок, которые совершают участники процесса при оценке проектов:

Начали со сбора всех план-фактов за 5 лет по 2026. Причем уделили больше внимание не документам с комитетов, а xlsx, в которых реально работали, выгрузкам с Jira и портала аутсорсинга со списаниями.

Там было все – MDM и DWH, НСИ и золотая запись, доработки CRM, HRM, ATS, ЭДО и кадровое ЭДО, ЭТРН, ERP в 2 стрима, процессинг, куча микросервисов коммерции, аналитическое хранилище, маркетинговое хранилище, еще одно внешнее маркетинг хранилище на веб и мобайл на рекламу и сквозную, ЛК и мобилка, 3 BI системы, склад, портал аутсорсинга линейного персонала, что-то около 12 модулей контакт-центра, еще 2 системы для кадрового контакт-центра – данные по порядка 250 объектам НМА ПО на учёте.

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

Мы составили эталон реально действующего пайплайна оценки входящей идеи / требования – упрощенно такой (на самом деле на 26 шагов):

В основу структуры самой оценки легли драйверы численности (экранов, тестов, процессов, процедур, таблиц и др.), реестры рисков, типовые ограничения и 30 000 очищенных эталонных строк из оценок.

Ради юмора в сравнение и с несколько иными целями (потому что знаем, как такие оценки формируются) мы взяли около 15 коммерческих предложений (оценки на фичи из развития) по 2 продуктам от поставщиков. Пришлось под @ почтой заказчика позадавать вопросы коллегам по цеху, чтобы нормализовать данные.

Упаковали это RAG + векторную базу и прикрутили LLM – онпрем и облачную (на вычищенные данные). Реализовали ИИ-агента в роли "отработка тех задач, которых нет в RAG", следуя по описанному нами пайпу.

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

Через пайп за 2 месяца пилота оценилось больше 370 инициатив – и на 50, и 500, и 5 000, и 50 000 часов были требования.

Конечно, мы "не попали" – по слепым тестам на то, что команды оценивали в условные 2 390 часов, из пайплайна приходила оценка на 3 900. Разброс колебался ±12-20%. Ну ок, а что, 2 команды из людей оценят в 1-2% разброса? Нет, он может быть на по-ряд-ки.

Но как проверить чья оценка точнее – у команды или у ИИ? Только дождаться реализации. Что, встретимся в июне 2027?

Поэтому ставили в цели мы другие эффекты.

За пилот время подготовки черновой оценки (1 итерация) для одной ИТ-инициативы сократилось с 3-8 дней до 2-3 дней чистого времени команды – ушла изнуряющая подготовка документов по нотации, ушло глубокое декомпозирование.

Продолжительность почти не изменилась – встроить встречи в плотном календаре сложно, скорее поменялось содержимое встреч:

Раньше ИТ тратило время на поиск "страшилок" для самих себя, а стало расходовать его на поиск способов мотиваций.

Реальная оценка вышла из серой зоны составления на коленке – учёт реальной работы людей вернул ее в формальное поле официального бизнес-процесса компании.

Есть и не проговоренный мной результат, который очевидно касается Y/Q бюджетирования – внимательный читатель сможет сделать верный вывод сам :)

Кроме того, каждая новая оценка была новым штормингом против коллег и бизнеса (этап работы команды, когда возникает много вопросов и взаимных недовольств). Мы же добились стабилизации процесса, придав работе над оценкой формат норминга вместе с бизнесом.

Кстати, об этом хорошо написано тут (не мной):

Бюджетирование ИТ-проектов не станет мгновенным, пока решения принимают люди – и это правильно. Но черновую механическую часть работы (сопоставление требований, первичный расчёт три) — можно и нужно автоматизировать.

Мы с командой поставили себе цель – превратить этот пилот в продукт, ведь одно внедрение не = системная боль.

* ограничение: пилот будет в облаке (в контуре с инфрой беда под LLM) и не более 1 месяца продолжительностью