Арм бюджетирование что это
Как выбрать систему автоматизации бюджетирования
Система бюджетирования является инструментом, который осуществляет накопление и анализ управленческой информации, разработку планов, проведения план-факторного анализа деятельности организации. В конечном счете – это механизм управления бизнесом через управление финансами.
Сегодня на рынке представлено множество различных систем автоматизации бюджетирования. Так, из зарубежных систем широко известны Oracle Hyperion Planning (Oracle), IBM Cognos Planning (IBM), Corporate Planner (Corporate Planning), Prophix (Profix Software). Из российских разработок можно отметить «Инталев: Корпоративные финансы», «ИТАН: Управленческий баланс», «КИС: Бюджетирование», Bplan, PlanDesigner, ГМ: «Оперативный финансовый учет».
Рассмотрим российские решения с точки зрения возможности разработки гибкой системы бюджетов, консолидации бюджетов, интеграции с бухгалтерскими системами, возможности анализа данных и ценовой политики.
Программный продукт BPlan – это инструмент, позволяющий разрабатывать, анализировать и контролировать исполнение бюджетов. Работа с BPlan строится путем моделирования системы бюджетов в виде совокупности взаимосвязанных таблиц и работы с созданной моделью.
Система BРlan дает возможность быстро разрабатывать и вносить изменения в бюджетную модель и эффективно анализировать данные в бюджетах.
Возможность проектирования иерархических аналитических направлений (время, контрагенты, номенклатура и т.д.) позволяет в дальнейшем автоматически консолидировать или разносить значения статей бюджетов по уровням.
Особенностью системы является то, что можно осуществлять анализ данных по различным направлениям (статьям бюджета, номенклатуре, времени и т.д.) практически без выполнения дополнительных настроек.
В системе поддерживаются возможности план-фактного анализа, анализа «Что если», а также возможность импорта данных из внешних источников посредством Excel.
Система проста в освоении (особенно для тех, кто имеет хороший опыт работы в Excel) и ориентирована на использование в средней или небольшой компании.
Стоимость одной пользовательской лицензии BPlan c технической поддержкой на 1 год составляет 23 700 руб., без технической поддержки — 18 000 руб. 1 пользовательская лицензия с технической поддержкой на 1 год для 2-4 пользователей — 22 000 руб. При покупке от 5 лицензий — 17 000 руб.
PlanDesigner позиционируется разработчиком как система бюджетного управления и контроля, ориентированная на решение задач корпоративного управления: анализ, прогнозирование, планирование и перепланирование, контроль, организационное проектирование, управление мотивацией персонала и автоматизации корпоративных регламентов. Система не требует специальных знаний в области программирования для конструирования экономических моделей.
Система предоставляет широкие возможности формированию бюджетов, мультивариантность процедур их согласования и утверждения. Продукт позволяет регламентировать и контролировать процесс сбора и консолидации данных, согласования бюджета и т.д. Координатору предоставляется возможность увидеть текущее состояние каждого документа, используемого в процессе разработки бюджета (просрочен, согласован и т.д.).
С помощью PlanDesigner можно проводить анализ данных (в том числе «сверление» по иерархии и анализ взаимосвязи между бюджетами). Использование многомерных кубов (OLAP технологий) позволяет проводить эффективный анализ как плановых, так и фактических данных.
Следует также отметить реализованный механизм настройки модели (поддерживается механизм drag&drop). При необходимости система позволяет представить бюджетную модель и взаимосвязи бюджетов в графическом виде.
PlanDesigner предоставляет возможности импорта данных: он позволяет импортировать данные из внешних источников (систем управленческого и бухгалтерского учета, систем для управления проектами, различных ERP продуктов, Excel, xml и интернет-источников).
В системе реализован механизм платежного календаря. Кроме того, смеются возможности настройки прав доступа (вплоть до каждой ячейки отчета).
Продукт подойдет для использования в крупных и средних организациях различных направлений деятельности.
Стоимость рабочего места зависит от конфигурации и функционала и находится в пределах от 300 до 1500 евро. Также необходимо приобрести серверный компонент PlanDesigner&UPE, стоимость которого составляет 7500 евро. Клиентская часть ПО может быть установлена на любом количестве компьютеров, лицензии ограничивают лишь число пользователей, одновременно работающих с сервером.
«ГМ: Оперативный финансовый учет» (Гроссмейстер)
Программный комплекс «ГМ: Оперативный финансовый учет» предназначен для автоматизации функций планирования, анализа исполнения бюджета, а также учета платежей и договоров крупных предприятий.
При помощи конструктора бюджетов можно разрабатывать гибкую систему бюджетов с учетом любой методологии.
Модуль работы с бюджетом обеспечивает различные варианты планирования бюджетов: «сверху вниз» и «снизу вверх», планирование статистическим методом. Кроме того, модуль дает возможность разносить общие данные по филиалам, корректировать бюджеты с учетом приоритетов, с учетом фактических данных и т.д.
Система учета платежей и договоров, входящая в комплекс «ГМ: Оперативный финансовый учет», предоставляет возможность планирования бюджета «от договора» и автоматическое получение фактических данных по бюджетам.
С помощью продукта можно вести учет всех финансовых потоков, контролировать целесообразность платежей и превышение плановых значений по отдельным статьям бюджета.
Дополнительная установка Oracle Discoverer позволит получать произвольные управленческие отчеты.
В системе поддерживается возможность обмена данными посредством файлов Excel, txt, xml, а также прямой обмен данными на уровне базы данных (СУБД Oracle).
При интеграции с ПО «Прогнозирование финансовых потоков и рисков» того же разработчика позволяет проводить анализ финансовых рисков.
«ГМ: Оперативный финансовый учет» позиционируется разработчиком как продукт для крупной корпорации, имеющей разветвленную филиальную сеть, большое количество контрагентов.
«Инталев: Корпоративные финансы» («Инталев»)
«Инталев: Корпоративные финансы» – это программно-методический комплекс, который решает все задачи цикла управления финансами (бюджетное планирование, платежный календарь, управленческий учет и отчетность, консолидация и анализ).
Это ПО-конструктор. Настройка осуществляется визуально, без кодирования и доработок, но в отличие от многих решений продукт не требуется настраивать «с нуля», т.к. он содержит готовые специализированные модели бюджетирования.
Любые сделанные ранее настройки можно сохранить и внести новые. Таким образом, можно точно настроить систему бюджетирования и развивать ее вместе с ростом бизнеса, масштабируя решение в техническом и методическом плане.
Поддерживается полноценная система управленческого учета с использованием данных о стоимости отдельных функций и ресурсов. Управленческий учет можно вести на основании данных бухгалтерского и оперативного учетов, также возможен импорт из внешних источников, например, из Excel, xml.
Интеграция с автоматизированной системой бизнес-процессов и документооборота того же разработчика позволяет продукту быть не просто финансовой системой, но и описывать финансовые процессы в организации: например, автоматизировать и контролировать процесс разработки, согласования и утверждения бюджетов.
«Инталев: Корпоративные финансы» предоставляет возможность контролировать движение денежных средств при помощи платежного календаря, устанавливать лимиты на бюджетные статьи.
Решение обеспечивает высокую оперативность отчетов и достоверность информации в них за счет отсутствия повторного ввода и перегрузки первичных данных за счет интеграции с «1С». Очень удобно, что продукт позволяет «провалиться» из практически любой цифры отчетности до первичного документа. Кроме того, использование дополнительного модуля делает возможным проведение многофакторного анализа с использованием технологии OLAP.
«Инталев: Корпоративные финансы» позволяет интегрироваться с другими специализированными системами планирования для загрузки в нее операционных планов и создания на их основе финансовых. Благодаря этому системы управления проектами (ресурсами) автоматически состыковываются с системой бюджетирования.
Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (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 решения: