01.08.2020 11:20
Andrew-BUSINESS 5 2400 Источник


О чем статья?


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

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

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


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

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


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

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

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

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

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

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


Проблемы и принципы их решения


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

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

У сферы бюджетирования две основные функции:

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

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


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

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


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

Пример реализации

Рис. 2

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

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


Рис. 3

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

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

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

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

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

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


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

Это плохо:

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

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


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

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

При этом:

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


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

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


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


Рис. 4

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

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

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

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

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


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


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

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

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


Рис. 5

DWH


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

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

Какие плюсы:

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

Минусы:

  • Точность. На самом деле, этот минус скорее теоретический (максимальная точность обеспечивается именно когда мы берем данные из самого первичного источника информации).
    На практике
    Если в первичном учете данные ведутся качественно и хранилище выстроено качественно, то и в нем данные будут достаточно точными; если же первичный учет ведется плохо, то и без хранилищ в отчеты будут выводиться некорректные данные. То есть, потеря в доли процента в качестве данных после перехода к хранению агрегатов действительно возможна, но в большинстве случаев для компаний такие потери не являются значительными, чтобы принимать их во внимание.
  • Загрузка памяти. Соответственно, чтобы хранить агрегированные данные, мы тратим лишнее место на жестких дисках. Тоже, на самом деле, скорее теоретический минус.
  • Расшифровка. Если мы подключаем отчеты к агрегированным таблицам (в которых данные не детализированы по исходным документам), возникают проблемы с возможностями их расшифровки (drill-down).

ETL-процессы


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

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

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

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

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

  • Сложность контроля целостности загруженных данных. Выстроить процесс 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-системы.

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-системы, передает данные для вычислений обратно в эту исходную комбинированную базу.

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

Популярные 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, которые иногда рассматривают в контексте Business Intellegence, корректнее называть именно EPM-системами.

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

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

Известные EPM-системы:

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

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

Бит.Финанс


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


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

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

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

Mapping – как в УПП. На среднем уровне.

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

  • Работа через формы учетных документов. Несмотря на то, что формы документов стали гибкими (см. первый плюс), и в целом в этом аспекте сделан большой прогресс по сравнению с УПП, продукт все же не ушел от документно-ориентированной модели работы настолько далеко, насколько хотелось бы. Что, как мы сказали, для бюджетирования архитектурно неправильно и неудобно.
  • Отсутствие интерактивных форм ввода-вывода. В отличие от 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
  • и мн. др.

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