У большинства компаний проблема с IT-бюджетом выглядит не драматично, а буднично. Есть несколько Excel-файлов. Где-то ведётся CAPEX, где-то OPEX. ФОТ живёт отдельно. Руководители отправляют заявки в чаты, финансовый блок собирает цифры вручную, а в конце месяца выясняется, что фактические расходы уже давно ушли от плана.
На словах всё вроде бы под контролем. На деле никто не может быстро ответить на три базовых вопроса: сколько уже потратили, на что именно потратили и где мы рискуем выйти за рамки бюджета в ближайшие месяцы.
С чего началась задача
К нам пришла команда, у которой IT-функция уже выросла, а контур управления деньгами остался на уровне "пока работает, не трогаем". Бюджет вёлся по нескольким файлам. Заявки на закупки шли в свободной форме. ФОТ считали отдельно от бюджета подразделения. План/факт собирали в конце периода, когда на решение уже поздно влиять.
Проблема была не в отсутствии отчёта. Проблема была в отсутствии единой модели данных и нормального процесса.
Если разобрать это по слоям, картина выглядела так:
- нет общей структуры статей расходов;
- каждый руководитель описывает заявки по-своему;
- расходы по людям не связаны с бюджетом команды;
- нельзя быстро проверить, хватает ли лимита до согласования;
- прогноз расходов строится интуитивно.
В такой конфигурации любая аналитика запаздывает. Она не помогает управлять, а лишь фиксирует последствия.
Почему мы не начали с красивого дашборда
Это частая ошибка в подобных проектах. Компания понимает, что не видит цифры, и первым делом хочет BI. Но если на входе хаотичные данные и неструктурированные заявки, красивый дашборд лишь аккуратно визуализирует беспорядок.
Поэтому мы начали не с отчёта, а с вопроса: как должен жить бюджетный процесс от планирования до оплаты.
Нам нужно было собрать систему, которая закрывает четыре сценария:
- Планирование бюджета по понятной модели.
- Работа с заявками на расходы внутри одного workflow.
- Привязка ФОТ и обязательных расходов к бюджетным статьям.
- Прогнозирование отклонений до того, как перерасход случился.
Что вошло в решение
Мы спроектировали Budget Manager как рабочий контур, а не как "ещё один кабинет с цифрами".
1. Бюджетная модель
Сначала мы договорились о структуре бюджета. Это звучит скучно, но без этого проект обычно разваливается. Мы собрали дерево категорий, договорились, что считается инвестициями, что операционными расходами, как вести лицензии, подрядчиков, оборудование, сервисы, обучение и ФОТ.
Важно было не сделать модель слишком умной. Если бюджетный справочник удобен только финансовому директору, операционные команды всё равно будут обходить систему стороной.
2. Workflow заявок
Следующим слоем стал процесс заявки. Пользователь больше не писал в чат "нужно купить". Он выбирал тип расхода, подразделение, статью бюджета, сроки и прикладывал обоснование.
Это сразу решило несколько проблем:
- исчезла потеря заявок в переписке;
- стало видно, кто инициатор и кто согласующий;
- стало возможно проверять лимит до оплаты;
- руководители начали видеть загрузку и очередь запросов.
3. ФОТ как часть бюджета, а не отдельная реальность
Во многих компаниях зарплаты, бонусы, налоги и внешние специалисты учитываются отдельно, хотя именно они формируют существенную часть IT-расходов. Мы связали ФОТ с бюджетом подразделения, чтобы руководитель видел реальную картину, а не только закупки и лицензии.
Это был один из самых полезных эффектов проекта: бюджет перестал быть абстрактной таблицей и стал управленческим инструментом.
4. Прогнозирование
AI-прогнозы в этом проекте не были маркетинговым украшением. Они понадобились в очень приземлённом сценарии: заранее понимать, где фактическое потребление начинает отходить от плана.
Мы использовали исторические данные, сезонность и типы расходов, чтобы показывать вероятные отклонения по категориям. Это не заменяет решение руководителя, но даёт ему ранний сигнал, а значит — время на действие.
Что дало основной эффект
Если упростить, то эффект пришёл не от одной большой функции, а от того, что система заставила процесс стать дисциплинированным.
До внедрения компания жила в логике "сначала потратим, потом поймём, что произошло". После внедрения управление стало выглядеть иначе:
- бюджет формируется по единой модели;
- заявки проходят через прозрачный маршрут;
- руководитель видит лимиты до согласования;
- ФОТ и проектные расходы оказываются в одном поле зрения;
- прогнозы помогают замечать отклонения заранее.
Именно такая комбинация обычно даёт реальный управленческий эффект. Не "AI сам всё посчитал", а "бизнес стал принимать решения на нормальных данных".
Какие результаты получили
По итогам внедрения команда зафиксировала несколько измеримых изменений:
- сократился перерасход по ряду категорий примерно на четверть;
- ушло значительное количество ручной работы на сбор отчётности;
- руководство перестало ждать конца месяца, чтобы увидеть план/факт;
- согласование расходов стало менее конфликтным, потому что решения начали опираться на цифры, а не на ощущения.
Отдельно стоит отметить нематериальный эффект. Когда у IT-руководителя появляется нормальный бюджетный инструмент, разговор с бизнесом меняется. IT перестаёт звучать как "центр затрат, который всё время что-то просит", и начинает выглядеть как управляемая функция.
Где такие системы действительно нужны
Не каждой компании нужен отдельный Budget Manager. Если бюджет небольшой, команд мало, а расходы почти не меняются, иногда достаточно аккуратной финансовой модели и дисциплины.
Но отдельная система оправдана, если у вас совпадают хотя бы несколько признаков:
- много статей расходов и руководителей, которые инициируют затраты;
- ФОТ нужно учитывать вместе с проектными и операционными затратами;
- заявки ходят по почте, мессенджерам и устным договорённостям;
- план/факт собирается вручную;
- руководство хочет не только видеть цифры, но и управлять ими.
Что важно учесть до старта
Самая частая причина проблем в таких проектах — желание автоматизировать хаос без договорённостей о правилах. Поэтому до разработки нужно ответить на простые вопросы:
- кто владеет бюджетной моделью;
- кто имеет право создавать и согласовывать заявки;
- как считается лимит;
- как учитывать ФОТ и внешних подрядчиков;
- какие данные нужны для прогноза.
Если на эти вопросы нет ответов, система получится красивой, но слабой в эксплуатации.
Вывод
Этот проект был не про "табличку в вебе". Он был про управляемость. Когда бюджет, заявки, ФОТ и аналитика собираются в одну логику, компания получает не просто удобство, а возможность раньше видеть риски и спокойнее принимать решения.
Если у вас IT-расходы уже не помещаются в одну таблицу и вы понимаете, что спорите о цифрах чаще, чем управляете ими, начинать стоит не с ещё одного отчёта, а с пересборки самого процесса.
Читайте также: