Почему контроль расходов ломается после внедрения: пять разрывов жизненного цикла лимита

Привет! Я — Мария, руководитель направления автоматизации процессов управленческого учета, бюджетирования и контроля расходов.

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

Со стороны это выглядит странно: автоматизация есть, а полноценного бюджетного контроля нет.

В этой статье я хочу посмотреть на проблему с архитектурной точки зрения. Разберем жизненный цикл бюджетного лимита и пять типовых разрывов процесса, которые чаще всего становятся причиной возврата к Excel-сверкам, ручному план-факту и спорам о доступном бюджете уже после внедрения.

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

Мы автоматизировали согласование расходов. Почему бюджетный контроль так и не появился

За годы обсуждения проблем проектов внедрения бюджетирования и контроля расходов я заметила закономерность.

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

На первый взгляд всё работает: вместо множества файлов появились единые формы и регламентированные процессы согласования. Стало проще понимать, кто, что и когда должен сделать.

Но бюджетному контролёру рано или поздно становится понятно, что автоматизация есть, а полноценного бюджетного контроля нет.

Причина обычно одна и та же: автоматизировали заявку, но не автоматизировали жизненный цикл бюджетного лимита.

Заявка на исполнение расхода существует несколько дней, иногда часов, а бюджетный лимит живет месяцами, иногда годами.

До появления заявки уже существуют:

• план бюджета;

• утвержденный лимит;

• корректировки бюджета;

• обязательства по договорам;

• амортизационные начисления.

После заявки продолжают существовать:

• платежи;

• бухгалтерский факт;

• план-факт анализ;

• управленческая отчетность.

Поэтому заявка — это не объект процесса, а событие внутри него.

Настоящий объект — бюджетный лимит, именно его состояние и должно отслеживаться на протяжении всего жизненного цикла.

Жизненный цикл бюджетного лимита

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

Именно его состояние меняется на каждом этапе:

• сначала лимит формируется при планировании;

• после заключения договора возникает обязательство;

• после появления заявки часть лимита резервируется;

• лимит может корректироваться;

• после оплаты появляется факт;

• после отражения факта становится возможен план-факт анализ.

Если связность процесса теряется хотя бы в одной токе – это источник проблем и причин ручных сверок. 

Усредненно целевая схема обмена данными в сквозном процессе бюджетного контроля выглядит так:

Слева перечислены программные блоки, по столбцам – этапы бюджетного процесса.

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

Дальше покажу вам 5 основных типовых разрывов. несмотря на то, что в жизни они редко встречаются по-отдельности, чаще всего усиливают друг друга в комбинации.

Пять разрывов, которые ломают бюджетный контроль

Разрыв №1. Бюджет не знает про обязательства и договоры

Симптом

В бюджете свободно 10 миллионов рублей.
Подразделение оформляет новый договор на 8 миллионов.
С точки зрения бюджета деньги еще доступны.
С точки зрения бизнеса они уже потрачены.

В прошлом году мы заключили договор аренды и должны платить 1млн ежемесячно.
Ответственное подразделение в этом месяце еще не оформило заявку на оплату.
С точки зрения бюджета деньги еще доступны.
С точки зрения обязательств они заняты еще год назад.

Почему 

Потому что контроль начинается только на этапе заявки или платежа.
Договоры существуют отдельно, в том числе переходящие.

Что ломается

Свободный остаток бюджета становится недостоверным.
Один и тот же лимит может быть использован несколько раз.

Как должно быть

Лимиты под переходящие договоры должны резервироваться сразу при планировании, а под новые договоры – в момент заключения.
Свободный остаток должен рассчитываться с учетом обязательств, резервов и фактических расходов.

Разрыв №2. Лимит не знает корректировки 

Симптом

В январе ЦФО получило лимит 20 млн.
В июне у него забрали 5 млн.
В сентябре вернули 3 млн.
В декабре спор — доступно 18 млн или 23 млн?

Почему 

Потому что корректировки ведутся отдельными документами и не становятся частью единой модели бюджета.
На практике корректировки это не прихоть, а реальная необходимость.

Что ломается

Через несколько месяцев никто не может уверенно ответить, какая версия бюджета использовалась при согласовании конкретного расхода.
Начинаются Excel-файлы с названиями вроде: Budget_v7_final_final_new_Маша_15.xlsx

Как должно быть

Корректировка должна быть самостоятельным объектом процесса.
Лимит в конкретном периоде должен рассчитываться как цепочка с полной историей изменений.

Разрыв №3. Заявка не знает платеж

Симптом

Заявка согласована, платеж исполнен.
Но связать одно с другим невозможно.

Почему 

Потому что платеж живет в онлайн-банке, заявка живет в системе согласования.
Отсутствует сквозной идентификатор операции. Интеграция в лучшем случае ограничивается передачей реестра на оплату

Что ломается

Появляются ручные сверки:

• что оплатили;

• что не оплатили;

• что оплатили частично;

• что вернулось.

Как должно быть

Платеж должен сохранять ссылку на исходную заявку.
А заявка должна автоматически получать статус исполнения из платежной системы.

Разрыв №4. Платеж не знает бюджетную аналитику

Симптом

Платеж есть – факт есть, а аналитики бюджета нет.

Почему 

На этапе оплаты часть аналитик теряется, в онлайн-банке остаются контрагент и сумма, но теряются ЦФО, статья бюджета, проект и остальное.
Управленческие аналитики не проходят через весь жизненный цикл.

Что ломается

План-факт превращается в отдельный проект по восстановлению аналитик.

Как должно быть

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

Разрыв №5. План-факт живет отдельно от процесса расходов

Симптом

В системе контроля расходов по статье осталось 3 млн рублей свободного лимита. В отчете план-факт по той же статье отображается 1,8 млн. Оба значения формально правильные, но рассчитаны из разных источников данных. 
Существует и план-факт, и контроль расходов, но связи между ними нет.

Почему 

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

Что ломается

На совещании появляются три разные цифры по одной статье бюджета, и каждая оказывается правильной в своей системе.

Как должно быть

План-факт должен использовать тот же жизненный цикл лимита, что и процесс контроля расходов.

Компромиссы реальных проектов

По моему опыту, чаще всего встречаются первые два разрыва:

• отсутствие учета обязательств;

• отсутствие полноценной истории корректировок.

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

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

На практике проекты редко стартуют в идеальной конфигурации. Чаще всего приходится выбирать, какие элементы процесса автоматизировать сразу, а какие оставить на следующий этап.

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

7 вопросов для проверки архитектуры контроля расходов

• Где хранится бюджетный лимит?

• Как учитываются обязательства?

• Как отражаются корректировки бюджета?

• Есть ли связь заявки и платежа?

• Сохраняются ли бюджетные аналитики до факта?

• Можно ли восстановить историю лимита на любую дату?

• Можно ли пройти из любой точки план-факта до исходных документов?

Большинство проектов контроля расходов ломаются не потому, что плохо настроено согласование заявок.

Чаще причина оказывается глубже — в одном из разрывов жизненного цикла бюджетного лимита: он перестает быть единым объектом процесса и распадается на отдельные несвязанные сущности: договоры, заявки, платежи, факты и отчеты.

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

Завершаю классикой:

Хорошая новость: бюджет автоматизирован.
Плохая новость: Excel об этом пока не знает.

---

Предыдущие статьи моей команды на тему управленческой отчетности и бюджетирования:

• Настройка бюджетирования в небольшом коммерческом банке на self-service инструментарии

• Опыт быстрого старта MIS в банке

• Настройка no-code приложения ALM (Управление активами и пассивами)

• No code автоматизация бюджетирования OPEX и CAPEX