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

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

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

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

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

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

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

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

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

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


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


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

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


Рис. 3

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

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

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

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

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

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

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

Это плохо:

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

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

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

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


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

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

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


Рис. 4

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

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

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

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

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

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

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

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

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


Рис. 5

DWH

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

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

Какие плюсы:

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

Минусы:

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

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

ETL-процессы

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


Рис. 6

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

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

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

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

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


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

Виды программных продуктов в бюджетировании

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

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

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



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



Важно: Нужно обратить внимание, что обычно перекрытие функций не 100-процентно.

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

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

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


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

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

Поскольку он не заменяет собой универсальное хранилище, он может использоваться как калькуляционный сервис, складывающий плановые данные в собственное корпоративное хранилище, откуда для построения быстрых отчетов и дашбордов данные передаются в отдельную 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; при этом сейчас тенденция идет к тому, что компания переводит фокус с EPC на облачную версию SAP Analytics Cloud, переход на которую также требует некоторого перестроения архитектуры.
• Цена. С точки зрения полной стоимости владения, фактически оказывается одной из наиболее дорогостоящих EPM-систем в мире, на что влияют в том числе изменения в архитектуре.

Отмечу, что сейчас продукт активно замещается облачной SAP Analytics Cloud.

ETL-инструменты

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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


Рис. 3

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

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

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

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

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

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

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

Это плохо:

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

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

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

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


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

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

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


Рис. 4

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

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

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

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

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

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

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

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

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


Рис. 5

DWH

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

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

Какие плюсы:

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

Минусы:

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

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

ETL-процессы

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


Рис. 6

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

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

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

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

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


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

Виды программных продуктов в бюджетировании

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

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

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



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



Важно: Нужно обратить внимание, что обычно перекрытие функций не 100-процентно.

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

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

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


Рис. 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
• и мн. др.

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

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

Это мой первый опыт написания публичных статей, так что сорри, если что не так. Буду рад конструктивным комментариям.


Почему с не прямой монетизацией?
Потому что компании у которых монетизация прямая и достаточно хорошо вычисляется ROI могут себе позволить инвестировать в рекламный источник до предела его емкости, до тех пор пока инвестиции окупаются. А вот сайты типа досок объявлений зачастую не могут себе этого позволить. Т.к. не имеют жесткой связи с возвратом инвестиций, т.к. сами не продают товары и услуги, а работают по рекламной модели. Проще говоря: сегодня можно потратить очень много денег в контексте, но завтра от этого у classified сайта не появится больше рекламных контрактов.

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



В рамках данного эссе предположим, что нас уже есть медиаплан с бюджетом на следующий месяц и работающие рекламные аккаунты. Что дальше?

Как обычно выглядят рекламные аккаунты таких компаний?

1. Скорее всего рекламных аккаунтов будет минимум два. Яндекс Директ и Google Ads и в этом плане нам сильно повезло, потому что конкуренция всегда лучше ее отсутствия, и это прекрасное поле для здоровой оптимизации
2. Возможно рекламных аккаунтов будет еще больше, например из-за того что по разным аккаунтам разделены кампании по принципу целевого действия, проекту, команде сопровождения или по другому признаку
3. Внутри каждого рекламного аккаунта будет набор рекламных кампании (РК), допустим их названия будут указывать на некоторый способ классификации кампаний (например, по регионам, по проектам, по типам размещения, по платформе)

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



С таким большим набором РК довольно сложно назначить дневные бюджеты. Этим мы и постараемся заняться.

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

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

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

Постановка задачи
Мало ли что в этом мире бывает, но я почти 100% уверен в следующем утверждении:

Количество узлов медиаплана будет всегда меньше или равно количеству рекламных кампаний во всех аккаунтах.

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

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

Как говорил мой преподаватель по численным методам, вот и все!. Мы пришли к формулировке классической задачи о рюкзаке. В качестве объема рюкзака выступает размер бюджета, в качестве ценности камней выступают данные о стоимости конверсии. Жадный алгоритм основа решения подобных задач. Рекомендую погуглить и почитать про задачу о рюкзаке подробнее.

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

Таким образом происходит отбор самых дешевых РК на указанный бюджет в пакете. Поэтому как я указывал ранее, целевые показатели по стоимости применительно к этой задаче не важны (при этом они конечно важны в целом, но учитываются скорее при управлении ставками). Важно просто набрать максимум конверсий на указанный бюджет.

Сильные стороны подхода

• Не важно из-за чего отдельная рекламная кампания стала вести себя лучше или хуже, как там поменялись настройки, ставки или рынок. Если такой бюджетировщик проходит по аккаунтам несколько раз в неделю со временем показатели такой кампании будут взвешены относительно других кампаний в пакете и ей будет назначен справедливый дневной бюджет.
• Можно перестать думать о бюджетировании кампаний совсем и сосредоточить фокус внимания на заведении новых качественных РК и на сопровождении старых (по гайдам, креативно, с периодическим обновлением и т.п.)
• Реализуется конкуренция между кампаниями Яндекс и Google. :)

Слабые стороны подхода

• Скорость сходимости решения изо дня в день к оптимуму не мгновенная. Частично можно уменьшить этот эффект задавая вручную нужный бюджет в течении нескольких иттераций перебюджетировщика. Далее он подхватит тренд на основании накопленной статистики. Но нужно руководствоваться здравым смыслом
• Когда в пакете мало РК нет пространства для оптимизации
• Когда в пакете много РК может накапливаться перетрата, т.к. возможен эффект суммирования небольших перетрат на множестве РК, в случае если бюджет для них ограничен
• Жадный алгоритм находит локальный оптимум
• Стоимость конверсии в общем случае не является константой. Это как если бы ценность камня в задаче о рюкзаке не было бы константой.

Особенности

• бюджеты между пакетами (узлами медиаплана) не перетекают

Комментарии по реализации

1. очевидно по кампаниям должен происходить ежедневный сбор статистики из аккаунтов контекстной рекламы и из систем счетчиков, например Google Analytics или Яндекс Метрика
2. результирующий отчет должен где-то храниться, в данном случае подходит любая БД, но удобнее всего на мой вкус Google BigQuery
3. Для анализа данный и построения отчетов можно использовать Jupyter блокнот. Так же на мой вкус лучше Google Colab, т.к. легко организуется совместная работа в команде (как в Google Docs)
4. Нужен сервер, на котором будет периодически запускать перебюджетировщик и происходить сбор статистики, обычно для такой задачи достаточно почти любого стандартного облачного сервиса AWS или Google Cloud

Пока у меня все.
Спасибо за внимание.