ИИ в планировании и бюджетировании: от ML-прогноза до агента финансовой модели в EPM

По данным Gartner, проекты внедрения ИИ для извлечения данных, автоматизации расчётов с поставщиками и покупателями и подготовки отчётов обычно приносят ожидаемый эффект через 9-10 месяцев. При этом польза ИИ для финансовой службы не ограничивается сокращением рутины: более сложные сценарии могут улучшать качество управленческих решений. Однако одним из ключевых препятствий становится недостаточная грамотность финансовых команд в работе с ИИ.

Для корпоративного планирования и управления эффективностью (EPM) это ставит практический вопрос: какие задачи поручать ИИ, какой эффект ожидать и как проверять результаты? Прогнозирование, поиск аномалий, работа с корпоративной методологией и объяснение отклонений требуют разных технологий и способов контроля. 

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

При этом практическая ценность ИИ в корпоративном управлении будет отличаться для разных ролей. К примеру, финансовому директору важна скорость получения ответов и возможность проверить источники цифр, а для FP&A и S&OP ключевыми становятся точность прогноза и скорость балансировки планов.

Ключевые роли участников бюджетного процесса и прикладные сценарии ИИ

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

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

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

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

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

Базовый статистический прогноз служит ориентиром для планирования, а не готовым бюджетом. Планировщик учитывает бизнес-предпосылки, вносит корректировки и передаёт план в EPM-контур, где прогноз соединяется с целями, ограничениями, инициативами и экспертными предпосылками, проходит маршрут согласования и становится утверждённым планом.

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

Контрольные правила EPM-системы проверяют заранее заданные условия: соблюдение лимитов, балансовых связей и заполнение обязательных данных. Статистические методы и машинное обучение дополняют эти проверки: помогают находить нетипичные значения и изменения, которые не описаны такими правилами.

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

Похожая логика реализована, к примеру, в Oracle IPM Insights: система анализирует временные ряды, выделяет аномалии и помогает пользователю перейти от общего сигнала к детальному анализу. В карточке видны период и величина отклонения, а через дополнительный анализ можно открыть данные и продолжить разбор по измерениям. 

В рамках одного из R&D-проектов по запросу клиента мы исследовали такой сценарий применительно к задачам EPM. Он хорошо показывает правильную роль ИИ: сузить область анализа и обратить внимание специалиста на нетипичное изменение, сохранив проверку причин и управленческий вывод за человеком.

При формировании бюджета и сопоставлении плана с фактом важно использовать согласованную нормативно-справочную информацию (НСИ): справочники продуктов, контрагентов, статей затрат и центров финансовой ответственности. Данные поступают из разных учётных систем, где один и тот же объект может иметь разные коды или наименования. Перед загрузкой в EPM эти записи необходимо сопоставить и привести к единой структуре. ML и языковые модели могут предлагать статью управленческих расходов для новой строки затрат, сопоставлять разные наименования одного поставщика и находить вероятные дубли в справочнике номенклатуры. Правила при этом сохраняют жёсткие проверки, а эталонная запись остаётся в MDM или другой системе - владельце данных.

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

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

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

Прогноз отвечает на вопрос «что, вероятно, произойдёт». Оптимизация решает другую задачу: «какой вариант выбрать при заданных целях и ограничениях». Например, как распределить производство между площадками, сформировать транспортную программу, сбалансировать спрос, мощности и запасы или максимизировать маржу при ограничениях по сырью, оборудованию и сервисному уровню.

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

ML может прогнозировать входные параметры оптимизации, а LLM - объяснять выбранный вариант. Но для расчёта необходимо явно задать бизнес-цель, например максимизировать выпуск продукции или минимизировать затраты. В математической модели эта цель выражается целевой функцией. Также задаются ограничения: доступность и производительность оборудования, графики ремонтов, объём сырья и требования контрактов. Результат оценивают по соблюдению этих ограничений, достижению выбранной цели, устойчивости плана и времени расчёта.

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

Ассистент с поиском по корпоративной базе знаний (RAG) сначала находит релевантные фрагменты в разрешённых документах, затем формирует ответ со ссылками на документы. 

Например, на платформе Авандок.ИИ можно создать цифрового методолога на основе документации конкретной системы. Он объясняет термины и порядок работы, помогает найти нужный раздел инструкции и явно сообщает, если ответа в источниках нет.

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

С EPM-системой можно взаимодействовать на естественном языке. Финансовый директор или руководитель бизнес-направления может спросить: «Почему снизилась маржа в базовом сценарии?», «Как изменится денежный поток при росте срока оплаты на пять дней?» или «Какие подразделения ещё не завершили ввод бюджета?» Агент переводит запрос в набор разрешённых операций, обращается к модели и возвращает результат.

Главная сложность скрыта за окном чата. Агент должен определить, к какой версии плана и какому периоду относится запрос, например к утверждённому бюджету на следующий год или последнему прогнозу на текущий квартал. Он должен работать только с доступными пользователю данными и операциями модели, обращаться к ним через контролируемый API, журналировать вызовы и показывать происхождение цифр. На первом этапе агенту разумно предоставить доступ только для чтения. Запись значений, запуск тяжёлого расчёта или изменение модели требуют отдельного подтверждения.

Одним из способов организовать такое подключение служит MCP (Model Context Protocol). Он задаёт стандартный интерфейс между агентом и внешними инструментами. Финансовая модель публикует не прямой доступ к базе и не произвольный язык запросов, а ограниченный набор понятных операций: получить показатель по заданной версии и периоду, прочитать статус процесса, запустить разрешённый расчёт или подготовить изменение к подтверждению. Для каждой операции можно проверить параметры и права пользователя, зафиксировать вызов в журнале и вернуть агенту структурированный результат вместе с контекстом. MCP сам по себе не решает вопросы безопасности. Проверку прав доступа, допустимых параметров и подтверждений для выполнения действий должен обеспечивать сервис, через который агент обращается к финансовой модели. Эти ограничения действуют независимо от того, как сформулирован запрос пользователя.

Подготовка комментариев к отчётности занимает заметную часть времени финансовых аналитиков. Здесь хорошо работает гибридная схема:

• EPM или BI рассчитывает отклонение и факторную декомпозицию по утверждённой методике. 
• LLM получает готовые цифры, контекст и допустимые источники, после чего формирует черновик комментария: какие факторы дали основной вклад, где требуется пояснение владельца и какие данные стоит проверить.

Языковая модель не должна самостоятельно извлекать цифры из случайного текста или пересчитывать финансовую логику. Каждый тезис подготовленного ИИ комментария к отчётности связывается с показателем, периодом, сценарием и срезом модели. Аналитик проверяет и утверждает текст. Такой сценарий использования ИИ сокращает рутину, не размывая ответственность.

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

Технология Text-to-Viz позволяет формировать подобную визуализацию по запросу на естественном языке. Агент обращается к семантическому слою EPM через контролируемый API или MCP-инструмент, получает проверенный набор данных и на его основе создаёт инфографику в формате HTML или PDF по заданным правилам оформления.

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

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

В публичной дискуссии под общим названием «ИИ» часто объединяют технологии с разными задачами, способами проверки и рисками. В проектах внедрения ИИ в EPM такое смешение может привести к неверному выбору технологии и критериев приёмки решения. 

Агент связывает эти компоненты в единый процесс и вызывает только разрешённые инструменты. 

В ИИ-проектах мы рекомендуем следующий подход:

1. Начать с определения бизнес-задачи и бизнес-владельца результата;
2. Подготовить данные и зафиксировать текущие показатели процесса для сравнения с результатом пилота: например, ошибку прогноза, трудозатраты аналитиков или время подготовки отчёта;
3. Выбрать подходящий класс технологии под ваши задачи; 
4. Учитывать информационную безопасность, права доступа, аудит и полную стоимость владения ИИ-решением. 

В EPM к этим требованиям добавляется ещё одно: любой вывод должен быть связан с конкретной версией финансовой или операционной модели и воспроизводим.

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

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

Для оркестрации процесса необходимы:

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

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

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

Разные сценарии требуют общей архитектурной основы. Внизу находятся корпоративные источники: ERP, CRM, WMS, TMS, HR-системы, хранилище, MDM и документы. Над ними - проверяемые вычислительные компоненты: EPM-модель, сервис прогнозирования, математический оптимизатор и корпоративная база знаний.

Следующий слой предоставляет агенту безопасные инструменты. Он описывает бизнес-объекты и допустимые операции, проверяет права, фиксирует версию и контекст запроса, ограничивает параметры и ведёт журнал. Для базы знаний используется поиск по разрешённым документам; для EPM - API или MCP-инструменты; для машинного обучения и математического оптимизатора - сервисные вызовы с зафиксированными входами и результатами.

LLM находится выше и отвечает за понимание вопроса, выбор разрешённого инструмента и объяснение результата. Она не становится источником финансовой истины. Источник истины остаётся в EPM, данных и утверждённой методологии. Пользователь видит не только ответ, но и использованный сценарий, источники, допущения и статус результата. Действия с последствиями проходят подтверждение.

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

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

Перед запуском ИИ-пилота полезно ответить на 8 вопросов

1. Какую измеримую проблему процесса мы решаем и кто владеет результатом? Нужно зафиксировать исходное состояние, ожидаемый эффект и ответственного, который сможет подтвердить результат в бизнес-процессе.
2. Нельзя ли решить задачу надёжнее - правилом, формулой, BI, программным роботом (RPA) или обычным маршрутом согласования? ИИ оправдан, если более простые средства не дают нужного качества, гибкости или экономического эффекта.
3. Где находится источник истины для данных, расчёта и методологии? Для каждого типа результата должна быть определена система-владелец: EPM-модель, корпоративное хранилище, MDM или утверждённый документ.
4. С каким базовым уровнем сравнивается решение и по какой метрике принимается результат? Новое решение нужно сравнивать с текущим способом работы по заранее выбранной метрике: ошибке прогноза, времени цикла, числу ручных операций или экономическому эффекту.
5. К каким данным имеет доступ пользователь и какие действия разрешены агенту? Следует разделить чтение, подготовку рекомендации, запуск расчёта и запись данных, а также определить, какие операции требуют подтверждения.
6. Можно ли воспроизвести ответ по версии модели, входам и источникам? Журнал должен позволять восстановить, какие данные, документы, параметры и инструменты использовались для конкретного вывода.
7. Кто проверяет и утверждает результат, а также как выполняется откат? До пилота нужно назначить владельца решения, определить обязательные точки согласования и предусмотреть возврат к предыдущей версии данных или сценария.
8. Как будут контролироваться качество, безопасность и стоимость после масштабирования? Нужны регулярные проверки качества, мониторинг ошибок и доступа, контроль изменений модели и расчёт полной стоимости эксплуатации.

Если на эти вопросы нет ответов, обсуждать выбор LLM или интерфейса пока рано.

ИИ уже приносит практическую пользу в EPM и IBP, но зрелость его технологий неоднородна.

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

• Машинное обучение формирует базовый прогноз спроса. 
• Математический оптимизатор предлагает допустимый производственный или логистический план. 
• EPM пересчитывает P&L, Cash Flow и другие показатели для выбранного сценария. 
• Корпоративный ассистент объясняет методологию и помогает разобрать результат. 
• Агент формирует по проверенным данным нужный аналитический срез и визуализацию. 
• Владелец процесса сравнивает варианты и утверждает решение.

Такой контур не зависит от обещания одной «умной» модели. Он строится на разделении ответственности, проверяемых вычислениях, качественных данных и принятии решений человеком. Именно эта архитектура превращает набор интересных функций ИИ в рабочий инструмент корпоративного управления.

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

Более 20 лет «КОРУС Консалтинг» внедряет и развивает системы финансового планирования, объединяя EPM, корпоративные данные и аналитические инструменты. Мы помогаем подобрать технологии под задачи бизнеса: от прогнозирования и оптимизации планов до ИИ-ассистентов для работы с методологией и финансовой моделью. 

Хотите определить, какие задачи финансовой службы в вашей компании можно поручить ИИ уже сегодня? 

Приходите на открытый вебинар «ИИ в EPM: как агент помогает финансовой команде» 28 октября. Покажем, как ИИ находит правила расчёта, получает данные из EPM и помогает объяснить изменения показателей с опорой на источники. Вы увидите две демонстрации — прототип и решение в корпоративном контуре.