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