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

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

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

В этой статье я хочу посмотреть на проблему с архитектурной точки зрения. Разберем жизненный цикл бюджетного лимита и пять типовых разрывов процесса, которые чаще всего становятся причиной возврата к 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 об этом пока не знает.

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

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