Почему бухгалтерская логика ERP убивает гибкость планирования

Если изменился курс валют или уровень инфляции, такие системы, как 1С:Управление холдингом или SAP BPC не смогут спрогнозировать последствия для вашего бизнеса. Причина лежит на уровне архитектуры данных: эти системы построены на бухгалтерской метамодели. В этих ситуациях помогут сценарное моделирование, анализ «что, если» и многомерные аналитики. Разбираем, в чем структурный конфликт справочников ERP и платформ интегрированного бизнес-планирования (IBP – англ. Integrated Business Planning). И как его закрывают MDM-слой и расчеты в оперативной памяти.

Два подхода к данным: проводка против многомерного куба

ERP построена на реляционной базе и принципе двойной записи. Любая операция превращается в проводку: дебет счета и кредит счета. Управленческие аналитики жестко привязаны к плану счетов через субконто. На практике 1С:Управление холдингом упирается в потолок пяти корпоративных аналитик. Если нужно больше, начинаются проблемы с производительностью отчетов, а стоимость поддержки модели растет.

Платформа класса IBP устроена иначе. Данные хранятся в многомерном аналитическом кубе (OLAP – англ. Online Analytical Processing), расчеты выполняются по in-memory OLAP-архитектуре (в оперативной памяти на многомерном кубе). В одном кубе свободно умещаются десятки аналитик: продукт, регион, канал, ЦФО (центр финансовой ответственности – подразделение с собственным бюджетом), сценарий, версия. Версия плана – отдельное измерение, а не отдельный документ.

Разница в скорости пересчета особенно заметна на больших объемах. Реляционная база на 10 млн. строк может пересчитывать плановую модель до нескольких часов. In-memory OLAP справляется за секунды. Алкогольная Сибирская Группа в 2023 году мигрировала с SAP IBP на Optimacros через интегратора Navicon. По данным CNews от 04.04.2023, пересчет плана производства занял 4 минуты с отклонением 0,1% для более чем 600 SKU. Для ИТ-директора это конкретный показатель скорости, так как бухгалтерская метамодель такой результат структурно не выдает.

Конфликт справочников ERP и систем планирования

Это центральный архитектурный конфликт, с которым сталкиваются при попытке дополнить ERP бюджетным контуром. Управление НСИ (нормативно-справочной информацией) – точка, в которой эти два мира расходятся.

Справочник контрагентов в ERP оптимизирован под платежные и налоговые задачи: ИНН, КПП, банковские реквизиты, договорные отношения, юридические лица группы. В системе планирования контрагент – объект сегментации с другим набором атрибутов: канал продаж, ABC-категория, регион ответственности, роль в цепочке поставок, признак внутригрупповых операций (ВГО).

Прямая загрузка полного справочника из ERP в IBP, наоборот, усложнит работу. Управленческая модель оказывается перегружена техническими записями, ненужными на уровне планирования: подразделениями-плательщиками, спецсчетами, техническими юрлицами под отдельные сделки. Из-за этого у аналитика не получится собрать корректный отчет по 20 ключевым клиентам, так как в его базе окажется 4 000 контрагентов.

Решение лежит в слое управления мастер-данными (MDM – англ. Master Data Management). Полный мастер-справочник остается в ERP как источник верных данных. В IBP-систему передается релевантная часть, проходящая через правила мэппинга.

Возможны два рабочих сценария реализации.

1. В IBP заранее ведется целевой аналитический справочник, а данные из ERP при загрузке сопоставляются с ним по настроенным правилам MDM. Что не нашло пары, попадает в категорию «Прочие контрагенты».

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

Внутригрупповые контрагенты обычно выделяются отдельной веткой. Они нужны для сверки ВГО при консолидации. Ключевые внешние клиенты идут отдельной веткой, и по ним строится детализированная аналитика. Прочие сводятся в единый агрегат.

Подобная архитектура реализована в Планум-Платформе. ERP остается источником полной НСИ, а IBP использует адаптированный аналитический справочник, оптимизированный под бюджетирование, консолидацию и управленческую отчетность. Аналогичный подход к разграничению справочников применяют Optimacros и Knowledge Space.ъ

Рис. 1 – Архитектура управления мастер-данными между ERP и IBP-системой. Полный справочник ведется в ERP, в IBP передается релевантная часть через правила мэппинга.

Сценарное моделирование как водораздел

По данным Яндекс Wordstat, фразовая частотность запроса «сценарное моделирование» – 45 в месяц. Эти данные показывают реальную потребность.

На практике сценарное моделирование означает следующее. Аналитик держит в системе 5–10 версий плана одновременно: базовый, оптимистичный, пессимистичный, версия с задержкой выхода продукта, версии с курсом 110 и 130. Все они пересчитываются параллельно. Финансовый директор открывает сравнение в один клик и видит, как меняется EBITDA (прибыль до вычета расходов по процентам, уплаты налогов и начисления амортизации), OPEX (повседневные расходы: аренда, зарплата и т.п.) и денежный поток в каждом сценарии.

В 1С:УХ эта механика реализована через документ «Сценарий», привязанный к модели бюджетирования. Документ задает имя сценария, но полноценной копии куба под него не создается. Глубокий анализ what-if (сценарий ≪что если≫) затруднен, так как каждая итерация требует пересохранения и пересчета модели. Параллельное сравнение пяти версий – отдельная инженерная задача, не закрытая из коробки.

В IBP-системах сценарий – это отдельное измерение многомерного куба. Тот же фонд оплаты труда (ФОТ), тот же продукт, та же неделя, но три значения по трем сценариям, одновременно, без копирования данных. Многомерное моделирование превращает what-if-анализ в дешевую операцию пересчета.

Для понимания структурной сложности приведем пример модели из практики Планум-Платформы: в кубе «Расчет ФОТ» 18 таблиц, 28 связей и до 12 измерений. Это типичная конфигурация для среднего по размеру холдинга. На бухгалтерской метамодели такую структуру технически воспроизвести трудно. Для платформ класса FP&A (финансовое планирование и анализ) и EPM (управление эффективностью предприятия) это рабочая норма.

Рис. 2 – Пример модели с многомерной структурой и связями между объектами – то, что технически сложно реализовать на бухгалтерской метамодели.

AI-агенты и самостоятельная работа аналитика

Понятия «ИИ» и «AI» вендоры применяют к двум разным технологиям. Для CIO важно их разграничить, так как от этого зависит, какую функцию закладывать в дорожную карту.

Модели машинного обучения (ML, от англ. machine learning). Это статистический прогноз по историческим данным: регрессии, ARIMA, градиентный бустинг. Технология зрелая, есть у большинства современных IBP-систем. К большим языковым моделям отношения не имеет, хотя в презентациях часто называется «прогнозированием на основе ИИ».

AI-агенты на базе больших языковых моделей (LLM). Они понимают структуру модели данных и отвечают на вопросы на естественном языке. Например, аналитик задает запрос: «сделай прогноз для продукта prd3, если цена у него как у prd1, а объемы в два раза больше, чем у prd2». Как результат, агент возвращает таблицу с расчетом и пояснением.

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

Рис. 3 – AI-Ассистент в IBP-системе: запрос на естественном языке и сгенерированный прогноз для нового продукта.

Связанный архитектурный вопрос, может ли бизнес-аналитик самостоятельно (self-service) добавить новую аналитику в куб, поменять формулу или собрать отчет без программиста. Для CIO это вопрос распределения нагрузки. Если бизнес-аналитик работает в платформе сам, ИТ-департаменту не придется разбираться с рутинными правками модели. Например, компания Yazaki Volga самостоятельно внедрила Планум-Платформу силами финансовой команды, без участия ИТ-отдела и внешних интеграторов. Для российского рынка корпоративных платформ планирования таких публичных кейсов мало.

Рамки закона и сроки миграции

Архитектурный выбор пересекается с регуляторикой. С 1 января 2025 года Указ Президента № 166 от 30.03.2022 (с поправками 887/2023) ввел запрет на использование иностранного ПО на значимых объектах критической информационной инфраструктуры (ЗОКИИ). С 01.09.2025 действуют поправки в 187-ФЗ (58-ФЗ от 07.04.2025), которые закрепили требование о включении ПО в реестр российского. Федеральный закон № 325 от 31.07.2025, вступивший в силу 01.03.2026, ввел дополнительный национальный контроль над объектами КИИ.

На практике это означает, что SAP BPC, Oracle Hyperion, IBM Cognos, Anaplan на ЗОКИИ юридически использовать нельзя. Компаниям, подпадающим под определение значимого объекта (критическая часть энергетики, металлургии, транспорта, финансов), можно использовать только российский реестр ПО.

Корпоративная IBP-система в крупном холдинге внедряется от 9 до 18 месяцев. Если в начале 2025 года проект не стартовал, компания уже работает в режиме согласования отсрочки с регулятором.

Приведем примеры публичных кейсов миграции на отечественные платформы планирования. Компания «Росэнергоатом» перешла с SAP BPC на отечественную систему Форсайт. Бюджетирование, которая охватила 11 АЭС, центральный аппарат и 6 малых филиалов (atommedia.online, 29.01.2024). «Норникель» перевел производственное планирование на российскую систему Knowledge Space (CNews, 02.12.2025). Задачей перехода была полная перестройка всех процессов, а не просто миграция данных. Во время внедрения команда проекта и разработчики платформы решили проблему цикличности материальных потоков, которая раньше была недоступна для российских систем планирования. За этот проект компания стала лауреатом премии CIPR Digital-2025 в номинации «Промышленный масштаб».

Подведем итоги

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