sap epm что это

SAP EPM

Решение SAP EPM (Enterprise Performance Management) является многофункциональным интегрированным бизнес-приложением, позволяющим повысить эффективность управления предприятием на всех уровнях.

SAP EPM позволяет решает ряд вопросов, связанных с комплексным управлением компании:

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

SAP Strategy Management.Управление стратегией предприятия. Позволяет сократить разрыв между стратегией и исполнением планов путем выявления несоответствий и правильного перераспределения ключевых ресурсов. В работе может быть задействована вся команда – от руководителей до линейных работников, каждый имеет доступ к инструментам для совместной работы и информации по оценке результатов деятельности компании.

SAP Business Planning and Consolidation. Бизнес-планирование и консолидация. Решение направлено на автоматизацию процессов планирования, бюджетирования и финансовой отчетности с целью повышения их эффективности. Помогает повысить точность анализа текущей ситуации на предприятии и уменьшить затраты на финансовое закрытие жизненных циклов всех процессов.

SAP Financial Consolidation. Финансовая консолидация. Решение предназначено для создания консолидированной финансовой отчетности, помогает ориентироваться пользователям в нескольких валютах, включать в анализ процессы слияний и поглощений, учитывать новые стандарты бухгалтерского учета и нормативной базы, например, соотнесение МСФО с национальными стандартами бухгалтерского учета.

SAP Financial Information Management. Управление финансовой информацией. Решение помогает оптимизировать загрузку финансовых данных из всех источников, исключая ручной повторный ввод данных, и способствует повышению качества обрабатываемой информации.

SAP Supply Chain Performance Management. Управление цепочками поставок. Решение оперирует максимально прозрачными показателями производительности всей цепочки поставок, помогает эффективно сокращать количество узких мест и объемы рисков, выявлять новые возможности и повышать оборотный капитал компании за счет оптимизации процессов.

SAP Asset Analytics. Анализ активов. Решение способствует повышению эффективности использования активов путем отслеживания их производительности и обеспечения соблюдения согласованных стратегий внутри компании.

SAP Sales and Operations Planning. Планирование продаж и операций. Решение предназначено для преобразования процессов традиционных продаж и планирования операций (S&OP) в интегрированную комплексную систему реализации стратегии продаж.

SAP Mobile Solutions for Enterprise Performance Management. Управление стратегией с помощью мобильного приложения. Решение предлагает простой и эффективный способ оставаться активными пользователями системы в любое удобное время, в любом месте. С помощью решения можно значительно расширить возможности использования системы для «мобильных» пользователей.

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

Источник

SAP Enterprise Performance Management OnDemand (SAP EPM OnDemand)

Решение SAP Enterprise Performance Management OnDemand построено на облачной платформе с использованием мобильных технологий и вычислений в оперативной памяти. Это решение позволяет бизнес-пользователям повысить эффективность управления предприятием и добиться отличных результатов.

Использование мобильных приложений на базе облачной платформы SAP HANA позволит бизнес-пользователям получать рабочую статистику в реальном времени и принимать эффективные решения. Решение было представлено на конференции пользователей систем ASUG SAP BusinessObjects, с 10 по 13 сентября 2012 года в Орландо (Флорида), во время вступительной речи Санджая Пунена, президента подразделения глобальных решений и руководителя подразделения мобильных решений SAP AG.

Решение SAP EPM OnDemand позволяет:

Инструменты прогнозирования будут регулярно обновляться, а их возможности — расширяться. SAP EPM OnDemand дополнит существующие решения SAP для управления эффективностью работы предприятий (EPM), в том числе SAP Business Planning and Consolidation. Новый пользовательский интерфейс поддерживает работу с мобильными устройствами, такими как iPad, и обеспечивает доступ к корпоративным ресурсам для большего числа сотрудников компании. Кроме того, дополнение EPM для Microsoft Office можно использовать не только с решением SAP EPM OnDemand, но и с решением SAP EPM версии 10.0. Такое сочетание функций расширяет возможности аналитики и обеспечивает единый интерфейс для всех пользователей — как в облачных, так и в локальных приложениях.

«Я постоянно общаюсь с сотрудниками финансового отдела и отдела ИТ. Занимаясь глобальными проектами, они вынуждены решать и текущие проблемы бизнеса. Приложения, доступные по запросу, позволяют решать такие вопросы быстро и экономически эффективно, — утверждает Джошуа Гринбаум, руководитель департамента консалтинга в сфере корпоративных приложений. — Новое решение SAP EPM OnDemand соответствует всем этим требованиям. Кроме того, использование единого удобного интерфейса при работе с мобильными устройствами и локальными приложениями позволяет снизить расходы на обучение пользователей при развертывании».

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

Источник

SAP BI, SAP EPM

Пакет решений SAP BI (Business Intelligence) обеспечивает возможность быстрого доступа к разнородным данным, их обработку и наглядную визуализацию для поддержки принятия решений в процессе управления организацией. В компании RBC Group представлен решениями BO/BI и BW.
Пакет решений SAP EPM (Enterprise Performance Management) обеспечивает поддержку процессов планирования и управления финансово-хозяйственной деятельностью. В компании RBC Group представлен решениями BPC и PCM.

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

SAP BO/BI

Использование решения SAP BusinessObjects Business Intelligence (Bl) Suite дает компаниям, использующим его в своей работе, значительное преимущество перед конкурентами. Топ-менеджеры компаний-пользователей SAP BO/Bl могут принимать эффективные решения, основанные на реальных данных и быстро реагировать на критичные для бизнеса ситуации.

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

Функциональность и основные возможности SAP BO/BI

SAP BW

SAP BW (Business Warehouse) в целом является классическим хранилищем данных, поскольку предоставляет инструментарий для хранения и анализа огромного массива данных. Вместе с тем SAP BW ориентирован прежде всего на решение бизнес-задач и с точки зрения пользователя не требует знаний о структуре базы данных.

Функциональность и основные возможности SAP BW:

SAP BW поставляется с продуктом SAP BEx (Business Explorer) для целей формирования гибко настраиваемых аналитических отчетов, дополненных использованием графики и различных элементов дизайна (кнопки, комбо-боксы и др.). Несмотря на то, что в целом визуальные возможности продуктов SAP BO/BI значительно шире, в ряде случаев использование SAP BEx может быть предпочтительнее в силу его тесной интеграции с офисным приложением Excel.

SAP BPC

Решение SAP Business Planning and Consolidation (BPC), используя рациональное и грамотное планирование, бюджетирование и прогнозирование, дает возможность компании повысить эффективность своей деятельности.

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

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

Функциональность и основные возможности SAP BPC

SAP PCM

Решение SAP Profitability and Cost Management (PCM) разработано специально для выявления факторов и причин, влияющих на рентабельность бизнеса, в том числе для анализа затрат компании с использованием самых современных методик. Позволяет определить причины недостаточной эффективности, просчитать влияние будущих возможных изменений и вовремя минимизировать затраты и увеличить прибыльность бизнеса, повысить уровень обслуживания клиентов и выйти на новые каналы сбыта.

Источник

Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (BI / ERP / EPM)

О чем статья?

Это обобщенная статья о том, что такое «автоматизация бюджетирования», из каких проблем состоит эта сфера и какие IT-инструменты в ней используются.

Если вы хотите понять, как связаны между собой BI, хранилища данных (DWH), системы автоматизации бюджетирования (Cognos, Anaplan, 1С: Управление холдингом, Бит.Финанс) и чем они отличаются от других корпоративных информационных систем – вам сюда.

Если вы технический архитектор, который никогда не работал с предметной областью бизнес-планирования – статья тоже для вас.

Сразу предупреждаю, что я постарался писать статью максимально простым языком, чтобы она была понятна для всех.

Почему я решил ее написать?

Сейчас практически отсутствует краткое систематизированное описание этой области, которое давало бы понятные ответы на вопросы:

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

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

Поэтому буду очень благодарен, если специалисты смогут поправить меня (если я допустил неточности) и дополнить статью информацией по известным вам продуктам в следующих аспектах:

ПРОБЛЕМЫ И ПРИНЦИПЫ ИХ РЕШЕНИЯ

Понятие «Управленческий учет» можно рассматривать в двух вариантах: 1) многоуровневая система фактического учета 2) многоуровневая система фактического учета и планирования. При этом управленческий учет ведется и в финансовом, и в нефинансовом выражении (на низших уровнях чаще используются натуральные показатели, а финансовые показатели – важны на верхних). Бюджетами же обычно называют верхнеуровневые финансовые планы.

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

В бюджетирование входит два основных вида деятельности:

Архитектурные отличия между учетом и планированием заключаются в том, что данные учета идут «снизу вверх». Чтобы получить качественную отчетность, нужно организовать запись как можно более детальных фактов. Тогда любую сводную информацию (важную для руководителей) можно будет получить простой агрегацией.

Поэтому в учете оптимально работает схема Документ –> Таблица (Регистр) –> Отчет (которая использовалась задолго до автоматизации, еще в средневековом бухучете).

Рис. 1. Учетная схема «Документ –> Регистр –> Отчет»

Планы же изначально – укрупненные. Поэтому вводить их удобно именно «сверху» (то есть, в таких же формах, в которых формируются отчеты).

Поэтому при попытке построить автоматизацию бюджетирования по аналогии с обычным учетом (рис. 3), перед компаниями сразу встают три ключевые проблемы.

Рис. 3

Проблема 1: Администрирование правил. Администрировать правила трансформации данных (из низших уровней учета – в формат бюджетирования), прописанные в коде отчетов – очень неудобно и трудозатратно.

Проблема 2: Скорость «сбора факта». Планы выводятся в отчеты очень быстро (поскольку хранятся в уже укрупненном виде), а фактические данные – агрегируются очень медленно.

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

Третья проблема – специфическая проблема планирования. Которая, собственно, является одной из важных проблем ERP-систем как реал-таймовых инструментов (предназначенных не только для «посмертного» учета произошедших событий, а для планирования и оперативного контроля бизнеса).

Теперь рассмотрим каждую проблему подробнее.

Проблема 1: Администрирование правил трансформации

На рис. 1-3 все правила трансформации фактических данных (от низшего уровня учета до верхних уровней отчетности) прописаны прямо в коде отчета.

Сложность правил трансформации

Здесь очень важно учитывать, что правила трансформации действительно могут быть достаточно сложными. Далеко не всегда трансформация представляет простое укрупнение данных (от дня к месяцу; от подразделения – к организации; от склада – к региону; от номенклатуры товара – к статье и т.д.). Особенно явно это встречается в СНГ, где управленческий учет часто ведется на основе бухгалтерского. Тогда из самых разных комбинаций разных реквизитов бухучета могут определяться разные значения для управленческого учета.

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

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

Решение проблемы 1: mapping

Для решения этой задачи mapping – соответствия между полями разных уровней и/или видов учета и отчетности – можно вынести из отчетов, создать как отдельный объект, настраивать и хранить отдельно, и затем обращаться к ним при необходимости.

Рис. 4

Это дает сразу два преимущества:

Но разработать инструмент для удобного маппинга больших объемов справочников – непросто.

Проблема 2: Скорость трансформации фактических данных

Решение проблемы 2: хранение трансформированных данных

Чтобы не вычислять данные отчетов «на лету», их можно хранить уже в укрупненном и трансформированном виде.

Для этого, помимо исходных таблиц (которые все равно понадобятся в компании), нужно создать таблицы для хранения агрегированных фактических данных. Это могут быть и отдельные таблицы, и общая таблица и для «плана», и для агрегированного «факта».

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

Рис. 5

С этой проблемой связана сфера Хранилищ данных (DWH).

Грубо говоря, DWH – это и есть место (таблица или, на практике, множество связанных таблиц) для хранения промежуточно вычисленных (агрегированных или еще как-то трансформированных) данных.

ETL-процессы

ETL можно называть любой процесс, в котором данные берутся откуда-то, изменяются и затем куда-то загружаются. Это общепринятое сокращение от Extract (получить), Transform (преобразовать), Load (загрузить).

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

У такого подхода есть плюсы:

Проблема 3: Форма ввода бюджетов

Дело в том, что в классическом виде отчеты в программных продуктах – это средство вывода данных. Но вводить данные в них нельзя.

Поскольку фактический учет идет «снизу вверх» (от фактов к суммам), в нем это не является проблемой, и потребности вводить укрупненную информацию вручную обычно нет.

То есть, если мы выстроили детальный учет по товарам (как показано в документе на рис. 2), обычно нет ни потребности, ни смысла вводить фактические данные в таком укрупненном виде, как они выглядят в отчете на том же рис. 2.

Таким образом, форма ввода сильно отличается от формы вывода.

А вот для бюджетирования классическая схема «Форма ввода» (документ) –> внутренние таблицы –> Форма вывода (отчет)» не подходит.

Например, в свое время мы разработали помесячный отчет по закупкам (как на рис. 2), а теперь начинаем вести планирование, и финансовый директор хочет вводить бюджет закупок в такой же форме.

Что остается делать? Можно создать форму для ввода планов, которая будет очень, очень похожа на этот отчет (что и было показано на рис. 3).

Первое. Нам придется разработать два технически разных объекта (отчет по закупкам и форма для планирования закупок), которые внешне должны быть идентичны.

И нам придется их поддерживать. То есть, если форма бюджета закупок должна измениться, скорее всего она изменится и для «плана», и для «факта», и нам придется вносить изменения в обе эти формы.

Второе. При вводе плана хочется видеть факт. А если формы отчета и ввода — разные объекты, делать это неудобно.

Решение проблемы 3: интерактивные формы ввода-вывода

Решение тоже очевидно: вместо привычных «документов» и «отчетов», нужно создать объект, который позволит одновременно и читать, и вводить данные.

Еще лучше, если в этом объекте можно будет еще и выполнять расчеты между вводимыми и/или читаемыми данными – то есть, работать наподобие того, как позволяет работать Excel.

При этом планы после ввода можно «складывать» в то же самое хранилище данных, где лежат фактические данные (см. рисунок).

Рис. 6

Но реализовать такие формы значительно сложнее, чем обычные отчеты или документы в учетных системах.

Степень интерактивности может быть разной: проще реализовать заранее настроенные формы, сложнее – динамические (где заранее неизвестно количество колонок/строк, но заранее заданы их типы). Еще сложнее – позволять в пользовательском режиме «вращать» данные, строить новые формы и задавать произвольные формулы расчета, меняя структуру отчетов.

Решение проблемы 4: кубы

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

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

Куб, OLAP-куб, OLAP-таблица, многомерная база данных, аналитическая база данных, столбцовая база данных – это названия способов хранения данных, позволяющих хранить их сразу на пересечении множества разрезов. Из таких таблиц проще получать различные срезы, а также они быстрее проводят разные расчеты(например, распределение затрат в различных измерениях). Поэтому они подходят для анализа «Что-если» — позволяют моделировать разные сценарии бизнеса и тут же получать ответ, как при изменении одних показателей изменятся другие.

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

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

ВИДЫ ПРОГРАММНЫХ ПРОДУКТОВ В БЮДЖЕТИРОВАНИИ

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

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

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

Если потребность в какой-либо специфической функции в компании максимально развита, желательно добавлять в контур IT-ландшафта компании (покупать или разрабатывать) отдельную систему, специализирующуюся на данной функции.

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

Карта видов ПО в бюджетировании

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

Рис. 7

Теперь рассмотрим, какую архитектуру бюджетирования предлагают некоторые популярные программные продукты.

БЮДЖЕТИРОВАНИЕ В ERP-СИСТЕМАХ

Понятие ERP со временем меняется, и в ERP-системы включаются все новые возможности.

На мой взгляд, «классический» функционал ERP включает учетную систему; конструкторы отчетов; функции оперативного контроля планов и, конечно же, базовые возможности их ввода.

Не включает: возможность сбора данных из множества распределенных источников; построение кубов и гибкой интерактивной аналитики.

Есть основания полагать, что понятие EPM (как и BI) задумывалось как нечто, выходящее за рамки ERP. Но сейчас границы стираются, и EPM-функции или даже целые продукты могут включаться в качестве модулей в ERP-системы.

А теперь рассмотрим бюджетирование в конкретных ERP-системах.

1C: УПП

В УПП реализована следующая схема, но внутри одной базы.

Рис. 8. Архитектура бюджетирования в 1С: УПП

Плюсы бюджетирования в УПП:

Недостатки бюджетирования в УПП:

1C:ERP

Насколько помню, изначально ERP предусматривала только «онлайновую» модель сбора отчетности. И на сегодняшний день во многих компаниях основной сценарий работы именно такой. Тем не менее, сейчас программа позволяет промежуточно хранить вычисленные значения.

Рис. 9. Архитектура бюджетирования в 1С:ERP

Плюсы бюджетирования в 1С:ERP:

1C: КА

«Комплексная автоматизация» представляет собой урезанную версию 1С:ERP, поэтому ее развитие проходит по тому же пути, и собственной методологии бюджетирования здесь нет.

MS Axapta / MS Dynamics AX

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

Рис. 10. Архитектура бюджетирования в MS Dynamics

И плюс, и минус системы – ее «заточенность» на собственные учетные модули Dynamics и их готовую структуру.

SAP S4 HANA

Основной продукт SAP, пришедший на смену ERP-системе SAP R/3.

Для бюджетирования сейчас используется отдельный EPM-продукт, который в десктопной версии (SAP BPC) еще можно было считать отдельной EPM-системой «поверх» ERP, но в облачной версии (SAP Analytics Cloud) уже окончательно встроен в ERP-систему (в SAP S4 HANA Cloud). Подробнее о SAP BPC будет ниже.

Про саму S/4 HANA важно сказать другое: SAP переводит всю работу ERP-системы с реляционной базы данных на комбинированную (смесь реляционной, колоночной и многомерной). Такой комбинированной базой данных выступает собственная технология SAP HANA (не путать с S/4 HANA), которая в зависимости от действий пользователя работает то как транзакционная (учетная система), то как аналитическая система (куб).

Таким образом, SAP переходит к архитектуре, противоположной той, что сегодня хорошо известна в «обычной» практике. В нем аналитическая база данных строится не «над» храналищем (SAP BW), а реализована «под» ERP-системой. При этом хранилище данных (SAP BW), когда пользователь работает с его данными из EPM-системы, передает данные для вычислений обратно в эту исходную комбинированную базу HANA.

Фактически, тот же эффект, ради которого задумывались технологии IN-Memory OLAP, SAP достигает противоположным способом: максимальным вынесением калькуляций из оперативной памяти.

Oracle Cloud ERP

Oracle также пошла по пути встраивания EPM-системы внутрь ERP.

Компания активно переводит свои продукты на облачную версию (возможно, даже активнее, чем это делает SAP). Поэтому для своего главного EPM-решения, Oracle Hyperion (о котором мы тоже поговорим ниже), компания продвигает альтернативу в виде облачного Oracle EPM Cloud, который включается в состав облачной Oracle Cloud ERP.

BI-СИСТЕМЫ

BI-системы (Business Intellegence) в «чистом» виде – это средство вывода данных. То есть, BI – это конструкторы отчетов и дашбордов, которые обычно также содержат базовые функции реструктуризации и анализа данных (например, позволяют соединять таблицы, находить усредненные тренды и пр.).

EPM-СИСТЕМЫ

EPM – сокращенно Enterprise Performance Management (управление эффективностью предприятия). Также встречаются термины Corporate performance management (CPM) и реже Business performance management (BPM).

Довольно широкий термин, который может подразумевать и смежные функции, однако чаще всего такие системы можно рассматривать как конструкторы интерактивных «План-факт» форм. Понятие EPM еще не стало общеприименимым на русскоязычном рынке, но такие решения, как IBM Planning analytics, Oracle Hyperion, Anaplan, которые иногда рассматривают в контексте BI, корректнее называть именно EPM-системами.

Иногда EPM-системы создаются для более широких целей (например, SAP EPM или 1С: Управление холдингом), которые выходят за рамки сводной отчетности, калькуляций и планирования. Но мы будем рассматривать EPM именно в части систем для автоматизации бюджетирования. Поэтому, например, мы будем называть продукт SAP Business Planning & Consolidation (SAP BPC) – EPM-системой, несмотря на то, что сам SAP называет ею более крупный продукт SAP EPM, в который включается SAP BPC.

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

Бит.Финанс

Бит.Финанс основан на методологии бюджетирования УПП, однако, в отличие от него, во-первых, поддерживается и развивается, а во-вторых, реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из внешних источников).

Рис. 11. Архитектура бюджетирования в Бит.Финанс

Плюсы автоматизации бюджетирования в Бит.Финанс:

Получение фактических данных работает в трех вариантах:

Anaplan

Флагманский продукт, недавно набравший большую популярность на мировом рынке. Предлагается только в облачной версии.

В отличие от остальных популярных решений (в т.ч. Hyperion и Planning Analytics), имеет немного специфическую специализацию: он лучше всего работает как калькуляционный сервис, который позволяет быстро автоматически пересчитывать объемные бюджетные модели с большим количеством зависимостей.

Рис. 12. Архитектура бюджетирования в Anaplan (популярный сценарий автоматизации)

И плюсом, и минусом Anaplan является его относительно четкая специализация и то, что он не покушается на IT-экосистему компании. Плюс — в том, что продукт четко определился со своим функциональным назначением, и направления его развития достаточно предсказуемы. Он представляет собой сервис для проведения анализа «Что-Если», расчета и утверждения планов (бюджетов), и планировать архитектуру заказчика нужно исходя из этого. Минус – в том, что продукт не может заменить полноценное корпоративное хранилище данных, не может заменить все возможности BI, на нем не строят сложную корпоративную ETL-инфраструктуру, да и всю систему корпоративных вычислений. Все это не было бы проблемой, если бы продукт не предлагался только в облачной версии.

В отличие от Oracle и SAP (которые как раз претендуют на экосистемность), Anaplan не делает упор на возможность легко «перегонять» данные и инструменты между облаком и серверами компании. Таким образом, в его случае недостатки облачного продукта (особенно с учетом того, что тарификация строится в зависимости от объема используемых на сервере данных) проявляются наиболее заметно.

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

Рис. 13. Архитектура бюджетирования в Anaplan (альтернативный сценарий автоматизации)

В целом, использование одновременно EPM и BI-систем является нормальной практикой.

Oracle Hyperion

Поставляется минимум в двух версиях: Oracle Hyperion Planning и Oracle Hyperion Financial Management.
Сейчас активно замещается новым продуктом Oracle EPM Cloud.

Из-за экосистемности, архитектуры могут приобретать самые разные виды, но типовая выглядит примерно так.

Рис. 14. Архитектура бюджетирования в Hyperion (возможный вариант)

На рисунке я привел BI-систему в качестве примера, поскольку аналитическая база данных Oracle Essbase является отличной базой для аналитики больших массивов данных в BI-инструментах.

В качестве ETL-решения предлагается Oracle Data Integrator, который выступает как универсальный механизм интеграции данных в экосистеме Oracle.

Плюсы автоматизации бюджетирования в Oracle Hyperion:

IBM Planning Analytics

В основном предназначенная для крупного бизнеса, не слишком простая в развертке и администрировании, но весьма функциональная EPM-система. Сейчас IBM Planning analytics строится на базе технологий TM1 (лежащих в основе Cognos’а).

Для ETL-процессов IBM предлагает использовать отдельный продукт IBM DataStage (ранее применялся Cognos DataManager), Turbo Integrator, Cognos Integration Server или внешний ETL-инструмент.

Типичная архитектура очень похожа на Hyperion.

Рис. 15. Архитектура бюджетирования в Planning Analytics (возможный вариант)

Сильные стороны IBM Planning Analytics:

SAP BPC

В целом, отличительные особенности SAP – экосистемность, сложность архитектуры и инфраструктуры решений.

Как я уже говорил, SAP в разное время поддерживал и поддерживает различные варианты архитектуры; по наиболее свежей информации, флагманская версия архитектуры, рекомендуемая вендором на сегодняшний день, выглядит так:

Рис. 15. Архитектура бюджетирования в SAP Business Planning & Consoldation (пример)

Преимущества бюджетирования на базе SAP BPC:

ETL-ИНСТРУМЕНТЫ

Для построения ETL-процессов используют известные ETL-инструменты, среди которых множество продуктов тех же вендоров, что выпускают BI/EPM решения:

Источник