Более восьми лет я специализируюсь на внедрении CPM и BI-систем различных вендоров. Несмотря на то, что во многом их функционал пересекается, мне хорошо понятно, какие задачи решаются лучше, а какие решаются только одним из этих двух классов систем.
Написать данную статью меня сподвигли несколько повторяющихся случаев путаницы при выборе системы для определенного пула задач. В моей практике произошло меньшей мере 4 случая, когда финансовые службы различных компаний на полном серьезе рассматривали внедрение BI-системы в качестве основной системы планирования и прогнозирования. Также, вспоминается случай во время моей работы в Большой четверке, когда партнер попросил меня провести встречу с заказчиком, чтобы объяснить, зачем им нужны наши услуги по внедрению CPM, когда у них уже есть работающая BI-система.
Кстати, встречаются и обратные ситуации. Не так давно один из CIO интересовался о возможности и целесообразности построения BI системы для всей компании на базе встроенного функционала визуализации одного из известных CPM решений.
Допускаю, моим коллегам, профессионалам в этой области, подобные идеи могут показаться нонсенсом. И во многом я с ними соглашусь. Но, во-первых, мне известен ряд неплохих решений, которые, после применения несколько довольно существенных настроек над BI, позиционируют себя как системы планирования (стесняясь, однако, называть себя как CPM). Во-вторых, я видел работающие (хоть и с ограничениями) решения на базе CPM платформ, собирающих множественные наборы данных из других ИТ-систем компании, и представляющих их далее в виде аналитических BI-отчетов для пользователей.
Поэтому у меня возникла идея поделиться важными особенностями систем обоих классов, которые часто ускользают при принятии решении о выборе целевой системы. Вендоры обычно стараются не заострять на них внимание, а некоторые из критериев никогда не попадают в оценочные списки сравнения, при этом являясь существенными, а иногда и вовсе критическими, при автоматизации процессов планирования и прогнозирования.
Причины путаницы
Я осознанно решил не давать определения каждому классу систем по нескольким причинам.
Во-первых, ни CPM ни BI – это, де-факто, не какой то четкий стандарт, а попытка классифицировать определенные виды бизнес-платформ. В жесткой конкурентной борьбе вендоры, развивая и совершенствуя свои продукты, «обвешивают» их функциональностью смежных технологий или расширяют / специализируют существующую базу и, таким образом, выводят свои продукты за рамки стандартизированных определений.
Консалтинговые компании пытаются отслеживать и систематизировать такие тренды. Вот, например, как Gartner менял с ходом времени классификацию CPM-систем в своих Magic Quadrant: начав с просто “CPM Suites”, с ростом популярности он добавил к ним термин “Cloud”, одновременно разделив на финансовые (FCPM) и стратегические (SCPM), позже поделив их на функциональные категории, выделив, в частности, решения для автоматизации финансов (FP&A), продаж (S&OP), и логистики.
Во-вторых, нечеткие определения, по-моему убеждению, как раз и являются одной из причин возникновения путаницы между CPM и BI, и об этом я расскажу далее. Дать лаконичное, но четкое определение довольно непросто: мало того, что системы уже обросли огромным количеством разнообразного функционала, которым теперь можно решать задачи из смежных направлений, так и сами платформы ведущих вендоров могут сильно отличаться друг от друга по охвату и возможностям.
Отмечу лишь, что авторы статей “CPM vs. BI..”. очень любят давать определения от Gartner.
Вот, например, определение CPM, которое я нахожу достаточно удачным. А здесь, например, неплохо представлены основные ключевые возможности классических BI систем. А вот пример определения Business Intelligence Services от того же Garner, которое, по-моему мнению, вообще не дает представления о том, что такое BI сервисы, так как под это определение можно подвести огромное количество различных классов систем, не обязательно BI или CPM. Кроме того, в данном разделе глоссария упоминается, что “Системы [Business Intelligence] включают такие области, как CPM и аналитика”, что является и спорным и путающим утверждением.
Здесь мы плавно подошли к первой причине путаницы по применению CPM и BI систем. Готовя данную статью, я прочитал много работ на схожую тему. Иногда это были предвзятые или маркетинговые статьи от вендоров (особенно, предлагающих на рынке только один из классов систем), с которыми сложно согласиться. В других случаях это был всего достаточно поверхностный анализ, с минимумом сутевой информации. Например, часто в сравнениях употреблялись такие “преимущества”, как “Decision-making”, “Performance analysis”, “Analytics”, “ Data exploration”, “ Reporting”, причем кто-то относил эти понятия только из одному классов систем, другие утверждали, что они относятся к обоим классам, упоминая при этом «разный подход». После прочтения подобных материалов действительно может сложится впечатление, что в целом, классы систем очень близки и взаимозаменяемы.
Второй причиной путаницы является то, что оба класса систем действительно имеют «функцию визуализации информации на интерактивных дэшбордах». Рекламируя свой продукт, что BI, что CPM, вендоры обязательно показывают примеры красивых дашбордов и отчетов, потому что это «отлично продается». Разнообразие графиков в рекламных промо-материалах создает у конечных пользователей ложное впечатление, что обе системы выполняют похожие функции. Несколько раз я сам был свидетелем, когда финансовые директоры совершенно разных по профилю компаний, рассуждали о том, что они хотят выстроить процесс бюджетирования на базе Power BI, потому что продемонстрированные возможности «визуализации данных и дрилл-дауна до источника» полностью закрывают их потребности в подготовке бюджетной отчетности. К сожалению, увлекаясь красивыми представлениями, они на какой-то момент забывали, что планирование и бюджетирование — это далеко не только отчетность. Я точно знаю, что некоторые такие проекты даже начались и «неожиданные открытия» случились уже в ходе реализации проекта.
Немного истории OLAP
Существует довольно распространенное мнение, что направление BI развилось из технологии Online Analytical Processing (OLAP), получившей наибольшую популярность в конце 90-х - начале 2000-х годов. Первые BI-системы действительно использовали OLAP-технологию для анализа многомерных данных, обеспечивая возможности сложных вычислений, анализа трендов и построения сложных моделей.
Более поздние BI-системы дополнялись более интерактивными и интуитивно-понятными функциями, постепенно сворачивая от традиционных OLAP-технологий в сторону вычисления данных в оперативной памяти (in-memory calculations) и колоночных баз данных, увеличивая скорость подготовки отчетов и совершенствуя пользовательский опыт. Современные BI-системы, это не просто «аналитические отчеты», с динамическими фильтрами и drill-through возможностями, но инструменты с функциями интеллектуального анализа данных, определения трендов, кластеризации данных, story telling-а и даже AI.
Первые системы планирования и бюджетирования крупные вендоры вначале пытались реализовать в рамках EPR-систем (например SAP, Oracle). Со временем стало понятно, что архитектурные особенности транзакционных систем не позволяют достичь желаемой гибкости, и не соответствуют возрастающим требованиям к производительности в вычислениях для сложных финансовых моделей с несколькими сценариями, версиям и динамическим горизонтом планирования. Поэтому функции «планирования, прогнозирования, бюджетирования» стали выделятся в отдельные «движки». Так у SAP сначала появился APO (Advanced Planner and Optimizer) который позволил применить более изощренный и адаптивный подход к прогнозированию и позже, в 2007, BPC (Business Planning and Consolidation), дополненный такими возможностями, как сценарное планирование, скользящий прогноз и, также, глубокими аналитическими возможностями, отсутствующими в более ранних версиях.
Когда был анонсирован SAP HANA, BPC получил возможность использования возможности оптимизационных вычислений в оперативной памяти и предиктивную аналитику. При этом, хотя BPC и обладает возможностями OLAP, особенно в части представления иерархий и измерений, его обычно не рассматривают как классический OLAP продукт.
Похожий путь прошел и другой крупный вендор – Oracle. Ранние версии бюджетного процесса были реализованы на базе модуля General Ledger. Затем, отвечая возрастающим потребностям в более развитых инструментов бюджетирования и прогнозирования, Oracle выпустил Oracle Financial Analyzer (OFA) и Oracle Sales Analyzer (OSA). Эти инструменты позволили пользователям проводить анализ и прогнозирование многомерных данных с использованием Oracle Express OLAP Server, который превосходил по удобству и производительности традиционную реляционную СУБД, используемую для OEBS. И, наконец, идя на встречу все более возрастающим требованиям рынка, в 2007 году Oracle заявил о приобретении Hyperion Solutions Corporation, и одноименный продукт Hyperion Planning до сих пор является одним из лидеров CPM систем. Hyperion Planning использует OLAP-сервер Essbase для хранения и расчёта многомерных данных.
Про следующих двух лидеров CPM в настоящем разделе изложу кратко, потому что буду довольно много раскрывать их особенности далее в статье.
Anaplan – появился гораздо позже своих предшественников, никогда не являлся классической OLAP технологией, которую в настоящий момент многие считают устаревшей. Anaplan использует проприетарный движок и называет его “Hyperblock”. Этот движок сочетает архитектуру реляционной, вертикальной и OLAP баз данных, обеспечивая многомерный анализ, сценарное планирование и построение сложных моделей.
IBM Planning Analytics (ранее – TM1) – первые версии появились очень давно. Современные версии программного обеспечения используют in-memory OLAP-архитектуру. Модели основаны на кубах, т.е. имеют многомерную природу, подобную классическому OLAP.
Таким образом, хотя многие современные BI и CPM либо действительно используют движки OLAP, либо обладают некоторыми свойствами OLAP, я бы не ставил равенство между BI и OLAP или CPM и OLAP, как иногда упрощают некоторые эксперты.
Что под капотом?
Теперь я расскажу про особенности сравнении CPM и BI с немного необычного ракурса. Я не буду использовать стандартные критерии сравнения (вернее использую только некоторые из них), зато добавлю отличительные свойства, которые часто несправедливо обходят вниманием при сравнениях, что в результате иногда приводит к недоразумениям при выборе целевой системы.
Интеграция данных: connectors
Хорошая BI-система должна иметь out-of-box интеграцию с максимальным количеством систем в IT-инфраструктуре компании, включая облачные решения. Например, данные для KPI могут собираться из корпоративного DWH, организованного на базе современного on-premise или cloud хранилища, или из отдельных систем – ERP, CRM, HRM, CPM, EDM и так далее.
Бюджеты, выделяемые на построение BI-отчетности обычно существенно ниже, чем, например, на реализацию полномасштабного внедрения ERP, и написание интерфейсов интеграции с многочисленными системами из которых надо будет забирать данные (если нет централизованного DWH), может превысить по трудозатратам реализацию основного проекта.
Как следствие, вендоры BI решений уделяют много внимания коннекторам с популярными платформами. Например PowerBI, Qlik Sense, Tableau имеют десятки, если не сотни, встроенных коннекторов.
А что у CPM систем? IBM Planning Analytics, которая недавно справило свое сорокалетие до сих пор обходится 4мя типами интерфейса с «внешним миром» - текстовые файлы, ODBC, ODBO и REST API. Для других видов интеграции придется покупать лицензии IBM Cognos Integration Server или использовать другие внешние коннекторы. Anaplan – текстовые файлы, Salesforce коннектор, REST API. Oracle Hyperion – встроенные коннекторы к другим продуктам Oracle и все те же текстовые файлы.
Почему так происходит? Полагаю, ответ заключается в том, что чаще всего CPM приходится интегрировать именно с ERP-системами, а все современные ERP умеют, как минимум, выгружать данные в текстовом формате и обмениваться данными через интерфейсы REST API. CPM-вендоры реализуют такие способы в первую очередь, закрывая, таким образом подавляющее большинство потребностей в обмене данных.
Подготовка данных, ETL
ETL, то есть “extract, transform, load” – это 3-ступенчатый процесс извлечения, подготовки и загрузки данных в принимающую систему. Фазы “Extract” я уже коснулся в предыдущем разделе, Фаза “Load” присуща любой системе, умеющей загружать данные из внешних источников, поэтому в настоящем разделе я хотел бы детальнее остановиться на фазе “Transformation”.
В проектной реальности редко бывает так, что извлечённые из другого хранилища данные можно использовать в целевой системе без трансформаций, чему есть множество причин. Рассмотрим некоторые из них:
Фильтрация данных. Часто бывает так, что нужны не все запрошенные у внешней системы данные, и не всегда можно отфильтровать данные с заданным заранее статическим фильтром – иногда требуется динамическая фильтрация и сопоставление с уже загруженными в целевую систему данными.
Валидация данных. Обнаружение и исправление (или удаление) некорректных записей: не заполнены или некорректно заполнены обязательные поля, отсутствуют обязательные элементы для связанного объекта и так далее.
Очистка данных. Например, удаление замыкающих или задвоенных пробельных символов, очистка от недопустимых символов в названиях и так далее.
Агрегация данных. Часто нам не нужны данные с уровнем детальности исходных систем (например, уровень транзакций в ERP или биллинговой системе), и перед загрузкой данных мы делаем агрегации, тем самым значительно уменьшая объем хранимых и обрабатываемых далее данных.
Объединение множества гомогенных и гетерогенных источников в единый контейнер (например таблицу) в соответствии со структурой целевого набора данных.
Мэппинг данных целевой и исходной системы. Например, наполнение дополнительных атрибутов справочников.
Удаление дубликатов. Очень распространенная трансформация из-за разности в агрегационных ключах в системе источнике и системе получателе или просто из-за отсутствия контроля дубликатов в исходной системе.
Удаление временных или вспомогательных колонок исходного datasets, используемых, например для фильтрации или промежуточных вычислениях в процессе трансформации данных.
Приведение данных к форматам хранения целевого набора данных (конвертация типов данных, единые единицы измерения, различные ограничения, определенные для того или иного типа данных.
Это далеко не полный список конвертаций и трансформаций, с которыми приходится иметь дело при загрузке данных из внешних систем. Эти системы могут поставлять данные в совершенно различных форматах и с использованием разных прикладных программных интерфейсов.
Как уже было упомянуто, современные BI-системы обычно разрабатываются так, чтобы иметь возможность забирать данные из совершенно различных источников. Внутри самой BI-системы загруженные наборы данных должны быть приведены к единым форматам хранения и структуре данных. Поэтому для BI довольно критично иметь развитой инструмент загрузки трансформации данных. У Power BI, например, это функциональный язык Power Query, у Qlik Sense это Qlik Sense Scripts.
С другой стороны, для CPM-систем умение загружать и трансформировать данные не менее важно. Проекты по автоматизации бюджетирования и бизнес-планирования в моей практике редко обходятся без загрузки факта, который нужен для анализа эффективности исполнения планов и часто служит базой для составления планов на следующие периоды. IBM Planning Analytics для целей используется встроенный “Turbo Integrator” (который, не смотря на свое название, давно используется далеко не только как средство интеграции). А вот Anaplan или Oracle Hyperion используют графические интерфейсы, с помощью которых можно настроить мэппинг на поля источника, но которые не годятся для глубокой трансформации данных. Справедливости ради, не могу не отметить, что Tableau, один ил лидеров BI систем, также не имеет полнофункционального ETL-инструмента.
Анализируя ETL-инструментарий различных систем, я пришел к выводу, что они скорее характеризуют фокус вендора на развитии и позиционировании своего продукта, но не являются специфической особенностью конкретного класса систем.
Внесение данных и writeback
Хотя это кажется естественным, но именно из-за того, что данное функционально требование лежит прямо на поверхности, зачастую о нем просто не вспоминают при выборе платформы для планирования. Как я писал в начале, в моем опыте было несколько кейсов, когда ответственные за выбор системы планирования, сравнивая платформы по безусловно важным критериям, не включали очевидный критерий по… возможности ввода данных пользователем.
При сравнении платформ всегда много внимания уделяется их калькуляционным возможностям, поддерживаемым интерфейсам интеграции с внешними системами. Однако трудно себе представить бюджетную модель, в которой план формируется исключительно на базе загружаемых из внешних источников данных и драйверов.
Даже при идеально проработанных алгоритмах, какие-нибудь показатели приходится бы заносить в систему вручную. Например,Top-down сценариев скользящего планирования, разработанных для получения автоматизированного расчета прогнозов, менеджеры все равно не обходятся без ручных корректировок, например, чтобы сбалансировать достижение целевых показателей.
Ввод данных в систему планирования осуществляется через так называемые формы ввода. Такие формы могут целиком состоять из заводимых вручную показателей, или включать частично расчетные, а частично вводимые показатели. В случае, когда форма НЕ содержит ни одного показателя, вводимого вручную, а все показатели расчетные или заполняются через ссылки на другие формы, можно говорить о том, что это уже отчет.
Теперь вернемся к особенностям CPM и BI систем. Как уже было показано выше, если первые не могут обходиться без развитого функционала ввода данных, то вторые, являясь собственно системами отчетности и анализа вполне могут им пожертвовать. Я не утверждаю, что в BI-системах вообще нет возможности ввода данных. Она есть, но обычно либо весьма ограниченная (например, рудиментарный ввод данных через встроенный редактор таблиц, требующий привилегий моделлера), либо с использованием сторонних плагинов, writeback-надстройки в Excel и так далее. Иногда такие решения неплохо подходят для большого объема ручного ввода, но при этом они стоят дополнительных денег.
В то же время, CPM-системы изначально спроектированы так, чтобы ввод данных был максимально удобным для конечных пользователей. Обычно, CPM вендоры предлагают несколько способов реализации форм ввода – например, специальные визуалы, загружаемые в веб-браузер, и/или формы реализуемые через add-ins для Excel и реализующие самые искушенные варианты представления данных.
Визуализация
CPM-системы все больше обрастают традиционными для BI-средствами визуализации (различные виды графиков, дэшбордов и т.п.), но пока еще довольно сильно уступают лидерам BI-систем. Внимание вендоров к UI/UX не удивительно, потому что «привлекательные пользовательские интерфейсы», подкупают визуальным восприятием, а «удачный пользовательский опыт» способствует естественному желанию пользователей чаще возвращаться в систему.
В целом функционал «визуализации» у современных CPM очень гармонично надстраивается над уже имеющимися обязательными компонентами этих систем, такие как проприетарный движок процессинга данных (агрегации, предрасчеты [pre-computation], сжатие [compression], кэширование [caching], индексирование [indexing] и т.д.) и формы ввода (что в базе своей уже является «табличным» или «матричным» визуалом). Таким образом, вендору остается расширить набор визуальных представлений, что не является самой сложной задачей учитывая вариативность уже готовых платных и коммерческих библиотек построения графиков и диаграмм. Наблюдая за скоростью включения в CPM различных вендоров все новых способов визуализации, можно предположить, что через несколько лет лидеры данного класса систем догонят возможности ведущих BI-платформ.
Поддержка финансовых процессов
Существует несчетное количество разновидностей проектов, каждый со своими особенностями. Так же и FP&A проекты. CPM-системы, для которых FP&A-проекты являются одним из основных направлений, разрабатываются с поддержкой особенностей целевых финансовых процессов так, чтобы минимизировать затраты на их настройку и дальнейшее поддержание. Рассмотрим несколько из таких процессов и покажем уровень их поддержки в рассматриваемых классах систем.
Прогнозирование. Прогнозирование – это процесс предсказания будущего на основе прошлых и сегодняшних данных и анализа трендов. Средства прогнозирования есть и в CPM и в BI, вопреки распространённому мнению, что в последнем они отсутствуют. В той или иной мере все ведущие вендоры BI уже имплементировали прогнозирование в свои системы, но принципы их работы отличаются от CPM.
Во-первых, BI обычно ничего не знает о том, как была получена расчетная величина. Например, данные, рассчитанные в CPM по формуле Выручка = Количество * Цена в BI, будут загружены просто как набор значений выручки, количества и цены. Соответственно, CPM для прогнозирования Выручки будет использовать метод, основанный на драйверах (т.е. учитывать изменения Количества и Цены),а BI – один из статистических методов. При простой корреляции исходную зависимость найти весьма просто, а вот для сложных, составных драйверов, BI скорее всего предложит какую-нибудь полиномную функцию, но она будет отличаться от исходной драйверной функции.
Второй важной особенностью является то, что прогнозные данные BI так и останутся «динамическим расчетом» и не смогут стать частью утвержденного плана компании (в формате данных, записанных в собственное хранилище системы). Соответственно, прогнозные данные BI лимитированы для дальнейшего использования в других формах и отчетах; они не могут быть скорректированы вручную, скопированы в другой сценарий моделирования, то есть полноценный финансовый процесс прогнозирования в BI не поддерживается.
Бюджетирование на основе деятельности (Activity-Based Budgeting (ABB)). ABB – это метод бюджетирования, при котором затратная операция записывается, анализируется и относится (или аллоцируется) на продукт или услугу. Затраты относятся на те продукты или услуги, которые формируются в процессе их возникновения.
Драйвер затрат – это параметр, характеризующий причинно-следственную связь потребленных ресурсов с объектом калькуляции (например, производимой продукцией). Затраты при использовании ABB не просто аллоцируются на стоимость труда или материалов, как в традиционном бюджетировании, но относятся на активности, приводящие к возникновению этих затрат.
CPM-системы, как правило имеют функционал, позволяющий реализовать ABB. Этот функционал позволяет пользователям создавать виды активностей, привязывать их к драйверам затрат и распределять затраты на основании потребления этих драйверов.
Теоретически, ABB можно настроить и во многих BI-системах. На практике при настройке такого подхода в BI сталкиваешься, что они не очень пригодны для этого подхода по множеству аспектов. Например, не совсем удобна комплексная настройка множества разнородных показателей (драйверов) или затруднено применение сложных алгоритмов аллокации расходов. Эти особенности больше заметны моделлерам, чем конечным пользователям.
Рефоркаст. По моему опыту практически всегда составление плана во время бюджетной компания подразумевает не только составление «Бюджета» на следующий год, но и Прогноза на остаток текущего периода. Бюджетная компания в крупных компаниях, с которыми мне приходилось работать, обычно длится несколько месяцев (например, с июля по декабрь), в течение которых происходит уточнение KPI компании на следующий год. Одновременно продолжается обычная операционная деятельность компании, осуществляется постоянный сбор новых фактических данных, период «прогнозирования» до конца года сокращается, исходные данные для планирования на следующие периоды уточняются.
Если бюджетная кампания на следующий год начинается, например в июле, и первый Бюджет на следующий год собран за базе «Прогноз 6 + 6», а финальный бюджет собирается уже в ноябре, то он формируется уже на базе уточненной версии «Прогноз 10 + 2». Поэтому финальная версия бюджета может существенно отличаться от первой версии в том числе из-за отклонений в исполнении факта в период с июль по октябрь.
За этот период компания создает несколько версий бюджетов, что отнимает немало времени и ресурсов, поэтому в финансовых процессах планирования весьма эффективен механизм рефоркаста через «переключение» модели на следующий период (rolling forward) – т.е. постоянный «сдвиг» текущего периода по временной шкале с автоматизированным копированием фактических данных на новые версии и/или на новые периоды, а также сокращение и пересчет прогнозных периодов на базе дозагруженных данных.
Anaplan, один из ведущих в настоящий момент вендоров CPM-систем, предлагает механизм switchover, реализующий не только описанный выше процесс периодического планирования, но и задачи скользящего планирования. BI-системы не реализуют поддержку такого специализированного процесса, поскольку базово не являются настоящими системами планирования и бюджетирования.
Финансовая консолидация. Финансовая консолидация представляет собой процесс агрегации финансовых показателей компаний, входящих в единую группу, для подготовки отчетности, отражающей их общее состояние. Это сложный процесс, включающий, не только агрегацию финансовых показателей, но и элиминацию внутригрупповых оборотов и остатков, поправки для приведения к единой групповой учетной политике, трансляцию в единую валюту, расчет долей меньшинства и много других специфических преобразований и расчетов, требующих от систем специализированной функциональности.
Не все, но многие CPM предоставляют по меньшей мере часть такой функциональности «из коробки». Например, среди известных мне это SAP Business Planning and Consolidation или CCH Tagetik. В Anaplan также реализовано специализированное коробочное решение для финансовой консолидации в соответствии с принципами IFRS.
BI-вендоры не встраивают механизмы финансовой консолидации в свои продукты. Как и в случае с Activity-Based Budgeting, в развитых BI-системах можно реализовать многие из перечисленных выше аспектов, но на практике это сложно выполнить технически.
Audit Trail
И BI и CPM обычно имеют встроенные логгеры, но работают они по разному. Логгирование в BI-системах обычно регистрирует информацию по активности пользователей, изменение прав доступа пользователей к отчетам и прочие действия по администрированию и серверным активностям.
В тоже время, CPM-системы, заточенные под ввод данных, отслеживают и записывают изменения, относящиеся к пользовательским данным модели. Это важная отличительная особенность систем CPM по сравнению с системами отчетности, про которую нельзя забывать при выборе системы для целей планирования и бюджетирования.
Workflow
Бюджетная кампания – итерационный процесс, состоящий из нескольких стадий. Например: Формирование макроэкономических предпосылок планирования -> Прогноз и актуализация стратегической модели -> Формирование Top-Down целей компании -> Подготовка и защита нескольких промежуточных версий Bottom-Up Бюджета -> Формирование окончательной версии Бюджета.
Стадии бюджетирования в свою очередь состоят из сессий бюджетных комитетов, на которых центры финансовой ответсвенности формируют и защищают свои локальные бюджеты. Часть бюджетов формируются независимо друг от друга, часть бюджетов зависит от планов других департаментов, и поэтому исходные бюджеты должны быть «заморожены» на время проведения таких сессий.
В крупных компаниях подобные процессы запутаны и сложны за счет множества взаимозависимостей, и вопрос о целостности и сопоставимости данных бюджетов становится одной из первоочередных задач бюджетной компании.
Как следствие, все полноценные системы, включая рассматриваемые в настоящей системе CPM системы – Anaplan, IBM Planning Analytics, Oracle Hyperion имеют функционал для реализации процессов согласования бюджетов(workflow).
В тоже время, Power BI, Qlik Sense, Tableau, являясь собственно системами отчетности и анализа, не имеют встроенных возможностей реализации процессов согласования. Логическую сопоставимость данных для отчетов должны обеспечивать системы-источники, а на межсистемном уровне – правильно выстроенные организационные процессы и архитектура ИТ-систем.
Отсутствие в BI-системах механизма реализации процессов также является важным фактором, который необходимо учитывать при выборе системы бюджетирования.
Показатели
Ключевым элементом любого отчета или финансовой модели является измерение данных через специальные сущности – показатели. В системах планирования и бюджетирования показатели могут служить для ввода данных, хранения формул и расчетов. «Количество», «Цена», «Стоимость», «Отклонение стоимости», «Задолженность на начало/конец периода», «Срок погашения задолженности», «Ставка по кредиту» и даже иногда статьи BS/PL/CF – все это примеры показателей модели .
Большие и сложные модели часто состоят из тысяч расчетных, взаимосвязанных показателей. Поэтому CPM-система должна обеспечивать гибкий, но в то же время простой механизм настройки их расчетов.
И ведущие CPM вендоры предлагают такие механизмы. Например, в Anaplan – это Line Items, с примитивным или ссылочным типом данных, хранящие многомерные формулы, способы агрегации и даже специфическую размерность метрики. В IBM Planning Analytics, являющемся, как было упомянуто, классическим OLAP, для организации метрик обычно используется последнее измерение в кубе – очень похожее на остальные справочники куба, но все же со своими особенностями. Таким образом, в Правилах модели ссылка на измерение мер очень часто содержит имя конкретного элемента, что означает специфический расчет именно для данного показателя.
BI, как системы анализа и отчётности, также имеют средства расчета показателей (метрики/индикаторы) отчетности. Но работают они немного иначе. Например, меры Power BI, создаваемые с использованием DAX (Data Analysis Expressions) по умолчанию очень «контекстно-зависимые». Разработка мер, например, для множества строк отчета о прибылях и убытках (или одной условной меры для всех статей) – гораздо более хитрая задача, чем реализация в известных мне CPM.
Qlik Sense взаимоувязывает наборы данных с применением ассоциативных ключей. Это дает возможность интерактивного анализа данных, но, как и в Power BI, эта технология оптимизирована для анализа данных, а не финансового моделирования, как в CPM-системах.
В заключении не могу не добавить, что данный пункт является весьма дискуссионным, то есть он не такой очевидный, как, например, в случае с аудиторским следом или процессами согласования. Многие профессионалы в области BI, могут со мной не согласиться, потому что они «регулярно формируют финансовую отчетность» в рамках своих BI-проектов.
Но я и не утверждаю, что это невозможно. Я сам делал отчет о прибылях и убытках на Power BI по данным из Anaplan в ситуации, когда специфические требования к динамическим представлениям отчета не позволяли его реализовать в исходной системе простым способом. Я лишь склоняюсь к тому, что условно-статичные финансовые отчеты с множеством разнородных расчетных показателей целесообразнее делать в CPM.
Неровные иерархии
Неровные или неравномерные иерархии — это структуры, в которых ветви иерархии имеют разную глубину раскрытия. Другими словами, некоторые ветви древовидной структуры могут иметь больше уровней, чем другие. Например, в организационной структуре отдел продаж может иметь множество подотделов и уровней, тогда как отдел кадров может иметь всего несколько подразделений.
По опыту создания множества финансовых моделей, я бы сказал, что, например, в проектах по финансовому планированию (FP&A) большинство иерархий в измерениях являются неровными. Например: организационная структура, статьи отчета о прибылях и убытках, капитальных затрат и движения денежных средств, центры возникновения затрат, справочники номенклатуры и многие другие справочники скорее всего буду неровными. Примерами ровных иерархий являются измерения времени, валют и, скорее всего, контрагентов.
Все CPM-системы, с которыми мне приходилось работать (IBM Planning Analytics, и Oracle Hyperion с их многомерными движками, или Anaplan с его Hyperblock engine, нативно работают с неровными иерархиями, без необходимости писать дополнительный код. Но я не могу сказать то же самое про BI-системы. Например, Power BI или Qlik Sense, хотя и позволяют создавать иерархии через пользовательские панели, в то же время требуют написания определенного кода на DAX (в случае Power BI) или скриптов загрузки данных (в случае Qlik Sense) для визуального отображения неровных иерархий. Похожие ограничения при работе с неровными иерархиями имеются у Tableau.
Я не нашел для себя внятного объяснения, почему для BI-систем, созданных на движках с разными парадигмами, часто затруднена работа с неровными иерархиями, хотя, казалась бы, визуализация таких измерений в отчетах одинаково важна и для BI и для CPM. Возможно, другие популярные BI-платформы отлично работают с неровными иерархиями и мне просто не посчастливилось поработать с ними. Буду рад вашим комментариям здесь.
Заключение
Несмотря на схожесть по многим пунктам BI и CPM, они остаются специализированными системами и решают пересекающийся, но отнюдь не одинаковый круг задач.
Обещание некоторых лукавых продавцов «автоматизировать процессы бюджетирования на базе одной из BI» может скрывать за собой неприятные сюрпризы, с которыми вы непременно столкнетесь, когда начнется внедрение. Если по каким-то причинам такое решение все-таки принято, обратите внимание на специализированные решения, с «надстройками над BI». Не думаю, что разрабатывать такие надстройки собственными силами окажется экономически целесообразным – как видно из настоящей статьи, существует много функциональных отличий между классами систем, и все они довольно существенны.
Верно и обратное. Оцените целесообразность использования CPM в качестве «универсальной системы визуализации, отчетности и анализа данных». Во-первых, вам придется дополнительно нагрузить систему планирования, которая и без того сильно нагружена, постоянными пересчетом огромного количества данных, не имеющих отношения ни планированию ни к прогнозированию.
Во-вторых, даже выделив для этих данных отдельную системную модель с независимыми вычислительными мощностями, скорее всего вы заплатите значительно больше денег за лицензии CPM, которые обычно дороже BI, получив в результате более ограниченную функциональность визуализации и подготовки отчетов.
