Excel epm что это

SAP BPC – Отчетность

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

SAP BPC 10.0 предоставляет различные исключительные возможности, включая интеграцию с SAP HANA через BPC 7.x для обработки среды больших данных для целей отчетности.

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

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

• Использование шаблонов по умолчанию
• EvDRE Builder
• Интерфейс перетаскивания
• Пустая рабочая тетрадь

Интерфейс надстроек SAP EPM для Excel

Вы также можете создавать отчеты в Надстройке бизнес-планирования и консолидации EPM для Excel. Интерфейс Excel в BPC широко разделен на следующие разделы –

• EPM Add-In Ribbon
• Подключение и размер
• Контекстное меню EPM
• Область отчета

Чтобы создавать отчеты в интерфейсе надстроек EPM для Excel, необходимо включить следующую опцию. Перейдите в EPM → Параметры → Параметры листа → Установите флажок «Активировать распознавание элементов».

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

Другой вариант создания отчета с использованием надстройки Excel – добавление измерений к оси строк и осям столбцов. Как только вы добавите размеры, нажмите «Обновить».

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

Версии надстроек EPM

Ниже приведены две версии надстроек EPM.

EPM Add-in .net 3.5

Поддерживает MS Office 32 бита.

Это ухудшает производительность, если вы запрашиваете использование соединения ODBO.

Он работает на платформе .net 3.5.

Он поддерживает MSP-файл.

Он не поддерживает режим большого объема BV.

Поддерживает MS Office 32 бита.

Это ухудшает производительность, если вы запрашиваете использование соединения ODBO.

Он работает на платформе .net 3.5.

Он поддерживает MSP-файл.

Он не поддерживает режим большого объема BV.

EPM Надстройка .net 4.0

Он поддерживает MS Office 32 и 64 бит.

Он поддерживает режим BV на источниках данных BW.

Он обеспечивает оптимизацию производительности, если вы запрашиваете соединение ODBO.

Он также поддерживает файл * .msp (необходимо удалить / переустановить).

Он поддерживает подключения BW для встроенной модели.

Он поддерживает MS Office 32 и 64 бит.

Он поддерживает режим BV на источниках данных BW.

Он обеспечивает оптимизацию производительности, если вы запрашиваете соединение ODBO.

Он также поддерживает файл * .msp (необходимо удалить / переустановить).

Он поддерживает подключения BW для встроенной модели.

Разработка отчетов с использованием динамических шаблонов

В наборе примеров приложений есть различные шаблоны, и вы можете выбрать любой из них и настроить их в соответствии с требованиями отчета.

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

Ниже приведены шаблоны по умолчанию в BPC.

Промежуточные итоги по счетам	Этот пользовательский отчет содержит измерение счета с промежуточными итогами в строках и любое измерение в столбцах.
отклонение	Этот пользовательский отчет содержит любое измерение в строках и сравнение категорий в столбцах. Он также имеет расчет отклонений (количество и процент). Как с YTD, так и с периодическими коробками.
Закрепление	Этот пользовательский отчет содержит любое измерение в строках и элементы типа сущности в столбцах с иерархией.
Сравнительный Х	Этот пользовательский отчет содержит любое измерение в строках и категориях сравнения в столбцах, а также извлекает данные за тот же период прошлого года. Как с YTD, так и с периодическими коробками.
Сравнение с 3-летним	Сравнение год за годом.
Тренировка на месте	Этот шаблон выполняет сверление на месте.
Вложенные	Это позволяет вложить любые два измерения в строку и третье измерение в столбец.
Сортировать по значению	Этот шаблон выполняет сортировку по общему значению.
Размер сверла	Это позволяет использовать сверло в одном измерении к другому.

Запустите EPM Office Excel Add-in, чтобы использовать шаблон. Эти шаблоны доступны в папке «Компания» и создаются с использованием надстройки BPC, а не BPC 7.x, где шаблоны создаются с помощью EvDRE.

Разработка отчетов с использованием функций EPM

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

Вы можете добавить размеры к прямой оси, как показано на следующем снимке экрана.

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

Миграция отчетов EvDRE

Все отчеты, созданные в BPC 7.5 Excel, можно перенести в BPC 10.0 с помощью надстройки EPM Excel. Функция переноса EvDRE в надстройке используется для переноса как можно большего количества функций в новую версию, но настраиваемые отчеты и шаблоны можно перенести только частично, и для полной миграции требуется некоторое ручное усилие.

Миграция отчетов EvDRE в BPC 10.0

Откройте отчеты, созданные в EvDRE.

Обновите отчет, чтобы перенести правильные размеры. Затем перейдите на ленту EPM → Дополнительно → Миграция EvDRE.

Разработка отчетов с использованием веб-клиента SAP BPC

Чтобы получить доступ к бизнес-планированию и консолидации, вы можете войти в веб-клиент. Чтобы запустить веб-клиент, откройте веб-браузер и используйте URL-адрес – http: //server.domain: порт / sap / bpc / web /

Когда вы входите в веб-клиент BPC, первый экран, который открывается, это стартовая страница и домашняя вкладка.

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

• Новое рабочее пространство
• Новый отчет
• Новая форма ввода

Перейти к новому отчету, и откроется следующий экран.

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

Вы также можете редактировать существующие отчеты. Есть возможность отложить макет отчета. Если вы выберете эту опцию, это не изменит макет отчета.

Источник

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

О чем статья?

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

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

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

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

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

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

1. В чем специфические проблемы автоматизации бюджетирования? Чем она отличается от автоматизации обычного учета?
2. Чем отличаются между собой модные программные продукты (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, Бит.Финанс, 1С: УХ) и по какому принципу они построены?
3. Почему BI – не основной инструмент автоматизации бюджетирования?

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

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

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

• Архитектура (взаимодействие с аппаратной частью и другими модулями учета и планирования)
• Функциональность
• UX: интуитивность, понятность, простота настройки
• Стоимость внедрения / владения

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

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

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

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

• Составить план
• Сопоставить план с фактом

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

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

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

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

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

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

Рис. 3

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

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

Проблема 3: Формы ввода планов . Самой удобной формой ввода планов является план-факт отчет. Но отчеты в информационных системах обычно не позволяют вводить данные.

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

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

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

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

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

• Правила нельзя администрировать без изменения кода;
• Использовать их можно только в этом отчете.

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

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

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

• если закупается номенклатура «Горюче-смазочные материалы» у поставщика «ООО Прямоугольник» и по договору «Договор №25» – это одна статья бюджета;
• если ГСМ закуплены у другого поставщика; или даже у того же поставщика, но по другому договору – это уже другая статья бюджета.

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

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

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

Рис. 4

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

• Правила проще администрировать. Их можно сделать интерактивными и настраивать без кода, а значит это зачастую могут делать даже обычные пользователи;
• Одно правило можно использовать в разных отчетах и/или других алгоритмах

Значимых минусов у такого подхода нет.

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

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

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

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

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

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

Рис. 5

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

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

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

Минусы:

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

ETL-процессы

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

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

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

• Распределение нагрузки на систему. Процесс трансформации растягивается во времени. Мы можем заполнять агрегированную таблицу постепенно (по мере изменения/добавления данных в исходных учетных системах) или по расписанию. Например, сложные вычисления можно откладывать на ночь или другое нерабочее время, когда сервер «свободнее». Это позволяет управлять нагрузкой на систему.
• Однократность трансформации. Однажды записав сводную информацию в агрегированную таблицу, мы сможем обращаться к ней из множества разных отчетов. Поэтому одни и те же трансформации не придется выполнять множество раз.

Минус же один:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6

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

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

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

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

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

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

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

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

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

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

• Системы исходных данных (системы учета, ERP-системы)
• ETL-инструменты
• Хранилища данных (обычные и OLAP-кубы)
• BI-системы
• EPM-системы
• Конечно же, Excel

У каждого вида систем есть теоретически основная функция (см. таблицу):

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

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

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

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

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

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

Рис. 7

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

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

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

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

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

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

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

1C: УПП

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

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

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

• УПП очень прозрачна и легко дорабатывается. В ней легко выверять данные и достаточно недорого разрабатывать новый функционал.

Mapping – в УПП на среднем уровне. Это не плюс и не минус. Настройка средней трудоемкости.

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

• Отсутствие интерактивных форм ввода-вывода. Создание любых данных выполняется через документы (ввод планов; получение агрегированных фактических данных; проведение калькуляций), где нет и не может быть интерактивности и возможности видеть общую картину.
• Отсутствие ETL-интерфейса. Маппинг есть, но загрузка фактических данных происходит прямо из формы документа, что неудобно.
• Старая платформа. Нельзя использовать технологию «Управляемые формы» 1С, которая дает пользователю современные возможности универсальной фильтрации/сортировки списков и отчетов. Это ухудшает аналитические возможности пользователя.

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

1C:ERP

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

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

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

• Достаточно функциональные формы ввода-вывода

Недостатки бюджетирования в 1C:ERP:

• Жесткость модели. В принципе, как и в большинстве ERP-систем, бюджетная модель не терпит частых изменений и достаточно придирчива к предварительной настройке
• Слабый mapping. Почему-то функционал мэппинга хуже, чем в УПП
• Жесткость продукта. В отличие от УПП, здесь перерабатывать каркас методологии крайне сложно и дорого. Нужно хорошо изучить существующую, и строить бюджетирование на 1С:ERP, если она действительно подходит компании
• Производительность. Интерактивные формы достаточно функциональны, но техническое устройство делает их крайне медленными на больших объемах данных

Также в 1C:ERP нет серьезного функционала по части настройки организационного процесса бюджетирования (workflow) и многопользовательской работы. Например, процессы согласования вынесены в отдельный продукт 1С: Документооборот, который обычно внедряется поверх ERP.

1C: КА

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

MS Axapta / MS Dynamics AX

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

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

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

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

Минусы:

• ETL. В целом продукт не предоставляет значимых возможностей трансформации данных
• Жесткость продукта. Здесь задана готовая, но достаточно ограниченная методология. И (как и в случае с 1C:ERP) перерабатывать ее не только сложно, но и практически бессмысленно.

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 – это конструкторы отчетов и дашбордов, которые обычно также содержат базовые функции реструктуризации и анализа данных (например, позволяют соединять таблицы, находить усредненные тренды и пр.).

• Power BI
• Tableau
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

Как правило, BI подключается к хранилищам данных (как реляционным, так и многомерным) или к исходным SQL-таблицам. Таким образом, можно обращаться к достаточно детализированным исходным данным (чтобы укрупнять их уже в BI). Однако, сложные условные трансформации (с условиями «если») – это не про «классический» функционал BI. Если перед вами стоит задача построить систему визуализации дашбордов, лучше постройте трансформацию перед тем как внедрять 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, а кроме этого реализуют возможность ввода и записи данных.

• Oracle Hyperion
• IBM Planning Analytics
• Anaplan
• SAP BPC
• Бит.Финанс
• 1C: Управление холдингом

Начнем с маленьких.

Бит.Финанс

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

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

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

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

Mapping – более развит, чем в УПП.

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

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

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

• Работа через формы документов. Несмотря на то, что формы документов стали гибкими (см. первый плюс), и в целом в этом аспекте сделан большой прогресс по сравнению с УПП, продукт все же не ушел от типичной для 1С документно-ориентированной модели работы настолько далеко, насколько хотелось бы. Что, как мы сказали, для бюджетирования неудобно.
• Отсутствие гибких интерактивных форм ввода-и-вывода. В отличие от 1C:ERP, здесь их нет.

Anaplan

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

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

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

• Калькуляция. Продукт сфокусирован на вычислениях, и хранит все данные в In-Memory OLAP, что позволяет пересчитывать все модели в режиме онлайн.
• Коллективная работа (в рамках подготовки плановых данных).
• UX и произвольное моделирование.
• ETL. Собственный и достаточно удобный ETL-инструмент.
• Требует минимальной IT-поддержки. Особенно по части моделирования.
• Стоимость. Дороговато для российского рынка, но в сравнении с международными лидерами (тем же Oracle Hyperion) полная стоимость владения выходит ниже.
• Скорость внедрения. В сравнении с Hyperion и Planning Analytics, продукт проще и в использовании, и во внедрении.

Минусы:

• Форматирование.
• Коллективная работа (в части работы с событиями: уведомления, рассылки и пр.).
• Собственный синтаксис формул. Вообще использование собственного кода – всегда недостаток с точки зрения конечных пользователей.
• Иерархии. Раньше были проблемы с использованием разной иерархии справочника для разных бюджетных моделей. Проблема не важна для многих компаний, но критична для некоторых. Возможно (я надеюсь на это), к данному моменту Anaplan уже решил эту проблему.
• Ad-hoc отчетность. Вообще это скорее специализация, чем недостаток: 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:

• Экосистемность. В случае с Oracle отмечу как плюс, поскольку Oracle – один из крупнейших поставщиков баз данных, и интеграция для компаний, кто работает на Oracle СУБД (а таких компаний много), действительно дает преимущества. В частности, удобнее распределять функционал между облаком и сервером. Кроме того, коллеги говорят о достаточно серьезных преимуществах по части безопасности в Oracle’овой архитектуре (в этом я не специалист, если здесь таковые есть — просьба поправить).
• Ad-hoc («отчетность по запросу»).

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

• Экосистемность. Отмечу и как минус, поскольку, по имеющейся информации, Hyperion выбирается в основном именно компаниями, работающими на стеке технологий Oracle, и от его использования в не-Oracle’овой среде в долгосрочной перспективе возможен меньший эффект.
• Калькуляции. Продукт в меньшей степени заточен на пересчеты моделей, чем тот же Anaplan.
• Сложность. Продукт не слишком легкий и с точки зрения инфраструктурной нагрузки, и с точки зрения UX (требует высокой квалификации и подготовленности пользователей).

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:

• Прогнозирование.
• Работа с событиями.
• Гибкость. Продукт нельзя назвать не требовательным к предварительной настройке, но он старается быть адаптированным к изменчивым моделям.
• Неэкосистемность. Что удивляет в работе с IBM – большой объем методических материалов, выпускаемых компанией, направлен на описание лучших практик взаимодействия продуктов IBM с другими решениями (в том числе, Oracle и SAP), причем в самых разных вопросах. На мой субъективный взгляд, хорошо, что в долгосрочной перспективе компания держит тренд на то, чтобы развивать интеграцию со сторонними системами (что позволяет поддерживать самые разные варианты сложившихся в компаниях архитектур), а не сокращать ее.
• Поддержка продукта.

Минусы

• Сложность. Как и в случае с Hyperion: требуется значительное обучение пользователей, не самая легкая инфраструктура.

SAP BPC

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

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

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

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

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

Недостатки бюджетирования на базе SAP BPC:

• UX и гибкость. Как и практически все продукты SAP, решение для бюджетирования требует высокой квалификации рядовых пользователей, а также очень требовательно к трудоемким предварительным настройкам.
• Инфраструктурная нагрузка. К тому же, SAP постоянно изменяет архитектуру. С одной стороны, это хорошо: разработчики ищут новые способы реализации задач. С другой стороны, для компаний это создает трудности при переходах на новые версии. Например, несколько лет назад SAP стала активно отказываться от версии своего хранилища (SAP BW) для MS SQL Server, оставляя альтернативную ей версию NetWeaver; затем стала активно продвигать BW/4 HANA как альтернативу NetWeaver; сейчас тенденция идет к тому, что компания переводит фокус с десктопной EPM-системы на облачную версию SAP Analytics Cloud, переход на которую также требует некоторого перестроения архитектуры.
• Цена. С точки зрения полной стоимости владения, фактически оказывается одной из наиболее дорогостоящих EPM-систем в мире, на что влияют в том числе изменения в архитектуре.

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

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

• IBM DataStage
• Informatica PowerCenter
• Talend
• Apatar
• SAP Data Services
• Oracle Data Integrator
• Microsoft Azure Data Factory
• и мн. др.

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

Источник