От ERP к специализированному планированию

Знакомая ИТ-директору ситуация. Финансовый отдел просит выгрузку из системы ERP (от англ. Enterprise Resource Planning — планирование ресурсов предприятия) под бюджет на следующий год. Дальше данные переходят в Excel под ручные формулы. И в итоге план не сходится с фактом. Причина в том, что учетная система не создавалась специально для планирования.

В феврале 2026 года ГК «Корус Консалтинг» провела исследование «ERP сегодня: приоритеты и барьеры». Большинство опрошенных — руководители IT-отделов и бизнес-подразделений. По результатам, только у 10,3 % система внедрена и работает полноценно, у 43,6 % — в частичном использовании, для 22,7 % в приоритете остается контроль над финансовыми потоками. В июне 2026 года компания SimpleOne совместно с партнерами представила исследование процессов управления ИТ-активами среди 100 российских компаний. По итогам, каждая пятая (20%) ведет учет активов в Excel.

Команда pickTech рассказывает, почему ERP не подходит для сценарного планирования и как эту задачу закрывает отдельный класс систем.

Почему ERP не создан для планирования

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

Отсюда первое расхождение. Регламентированный учет требует точности по факту. Управленческий учет и планирование — гибкости и скорости: пересобрать модель, переключить сценарий, развернуть аналитику в нужном разрезе. Системы автоматизации управленческого учета и системы бюджетирования сфокусированы именно на этом. Автоматизация финансового учета в ERP и автоматизация управленческого учета в системе планирования — разные задачи с разной логикой данных. Управленческий учет 1с и в других учетных системах закрывает факт, но планировать поверх него напрямую неудобно, и финансисты уходят в Excel. Каждая такая выгрузка создается через ручную операцию. Сначала формируют отчет, затем кто-то перекладывает его в нужную структуру, и при следующем пересчете цикл повторяется. Для ИТ это поток однотипных задач, для финансов — риск работать на устаревших данных.

Конфликт справочников

В ERP они детальны: сотни статей затрат, тысячи позиций номенклатуры, контрагенты и договоры. В системе планирования та же информация разделена на крупные группы: два-три десятка плановых статей, номенклатуры, центры финансовой ответственности (ЦФО). Это разная гранулярность данных. В ERP крупной компании может быть несколько сотен статей затрат. В плановой модели их осмысленно держать в пределах трех десятков. И сводить одно к другому вручную при каждом пересчете невозможно.

Перенос справочников «один в один» не работает: либо модель тонет в детализации, либо теряется связь детального и планового уровня, и факт невозможно агрегировать по плановой структуре. Нужен слой согласования — управление мастер-данными (MDM, Master Data Management), чтобы устранить дублирование информации и объединить правильные данные. Следует использовать правила мэппинга справочников, по которым детальные статьи учета сворачиваются в плановые, а у каждого элемента есть владелец. На уровне интеграции это задача ETL (от англ. Extract, Transform, Load — извлечение, преобразование, загрузка): извлечь данные из ERP, преобразовать под плановую структуру (агрегация, сопоставление аналитик) и загрузить в систему планирования. Без согласованных мастер-данных план-факт не сходится, и каждое изменение справочника в ERP ломает исторические сравнения. Отдельная сложность — изменения во времени. Компания разделила один ЦФО на два или укрупнила номенклатурные группы, и без версионирования справочников исторический факт перестает быть сопоставимым с планом.

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

Архитектура решения: планирование как отдельный слой

Если вынести планирование в отдельный слой над ERP, этот класс систем называют по-разному:

• CPM-система (Corporate Performance Management) — управление эффективностью;

• EPM-система (Enterprise Performance Management) на уровне всего предприятия;

• IBP-системы (Integrated Business Planning) — интегрированное бизнес планирование.

Что такое IBP? Это слой интегрированного бизнес планирования, который связывает финансовый план с операционными и стоит поверх учетных систем. Ушедшие SAP BPC, Oracle Hyperion и Anaplan, а также SAP IBP, занимали именно эту нишу. Теперь на их место пришли российские IBP-системы.

Технически такой слой строится на многомерной модели, в основе которой — OLAP-куб. В нем данные хранятся по измерениям (dimensions): статья, период (число, месяц, год), ЦФО, сценарий, версия. Это позволяет разворачивать аналитику в любом разрезе, держать несколько версий и сценариев одновременно и пересчитывать модель целиком. In-memory обработка данных — расчет в оперативной памяти — на порядки быстрее пересчета модели на диске: сценарий пересчитывается за секунды вместо часов. Пересчет сценария идет за секунды там, где в связанных листах Excel уходят часы.

Сценарное моделирование здесь — это техническая возможность системы. Многомерность плюс версионирование позволяют считать сценарный анализ как переключение версий одной модели вместо пересборки файлов вручную. Финансовое моделирование становится управляемым. Единый слой данных собирает кросс-функциональную модель (финансы, продажи, производство) в одном контуре. Данные обычно проходят промежуточный слой. Факт выгружается из ERP в область подготовки, там приводится к плановым справочникам и только потом попадает в куб — это и есть роль ETL и MDM в связке. Обмен с ERP идет через API-интеграцию или регламентный ETL, консолидация по группе считается там же. Версионирование решает задачу управляемости: видно, кто и когда менял план, можно сравнить версии бюджета и вернуться к утвержденной.

*Планирование как отдельный слой поверх ERP: четыре причины

Преимущества системы планирования для ИТ-директора

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

На российском рынке IBP системы и платформы бюджетирования представлены несколькими сопоставимыми решениями. Как пример, Планум-Платформа, Optimacros, Форсайт и 1С:УХ. Подходы к интеграции, многомерности и работе со справочниками у них различаются. Выбор определяется тем, как система ложится на конкретный ландшафт данных. Без согласованных мастер-данных и зрелых процессов даже сильная платформа результата не даст.