CPM vs BI Platforms Insights: What Is Usually Behind The Scenes
Introduction
Over the past eight years, I've been focused on implementing #CPM (Corporate Performance Management) and #BI (Business Intelligence) systems from various vendors. These system classes are closely intertwined but still not the same.
On the whole, my inspiration to prepare this text comes from several recurring cases of confusion when companies were choosing the solution. In my experience, there have been at least four examples where the finance departments of different companies seriously considered implementing a BI system as their primary planning and forecasting system. Additionally, I remember a case from my time at a Big Four Company when a Partner requested that I hold a meeting with a client to explain why they should engage our services for CPM implementation, even though they already had a functioning BI system in place.
By the way, reverse situations also crop up. Not long ago, one of the CIOs was exploring the possibility and feasibility of building a company-wide BI system using the built-in visualization functionality of a well-known CPM solution.
I admit that my colleagues, experts in these fields, might find such ideas weird. And I primarily agree with them. ?However, firstly, I'm aware of decent solutions on the market that, after some significant configuration, position themselves as planning systems (though they are somewhat reluctant to call themselves CPM). Secondly, I've seen operational scenarios (albeit with limitations) where CPM gathers data from other IT systems within the company and provides analytical BI reports for users.
In this article, I will share crucial features of both system classes that often go unnoticed when making decisions about the target system. Vendors typically do not highlight these features; some of these criteria almost never make it into comparison evaluation lists. Nevertheless, these features can be substantial and sometimes even critical, especially when planning and forecasting business processes are automated.
Disclaimer: Indeed, I do not claim to have a professional-level knowledge of all CPM and BI systems, although I have worked with many of them. It is unlikely that I can completely eliminate subjective assessment, but when making any statement, I will try to reference the capabilities of the leading representatives of their class.
Muddling Reasons
Before going further, you might expect me to provide definitions for each class of systems. However, I've intentionally chosen not to do that, and there are several reasons for this.
Firstly, neither CPM nor BI is a strict standard; rather, they are attempts to classify certain types of business platforms. Moreover, in tough competition, vendors continuously evolve and expand their products, often developing them beyond standard definitions.
Secondly, I believe that vague definitions are among the main reasons of the confusion between CPM and BI. I won't deny that providing a concise yet precise definition is quite challenging. Not only have these systems grown with a vast array of functionalities, which can now address tasks from various adjacent domains, but the platforms from leading vendors can also significantly differ in scope and capabilities.
I noted that authors of articles like "CPM vs. BI…" often like providing definitions from Gartner. Here is the definition of CPM, which I find quite fitting. And here, for example, the basic key capabilities of classical BI systems are well presented. However, when it comes to definitions like Business Intelligence Services from the same Gartner glossary, it doesn't effectively convey what BI services are. This is because this definition can be applied to a many system classes, not necessarily just BI or CPM. Furthermore, this glossary section mentions that "[Business Intelligence] solutions include areas such as corporate performance management (CPM) and analytics, which is both debatable and confusing.
This brings us to the first reason behind the confusion in using CPM and BI systems. While preparing this article, I've read numerous works on similar topics. Sometimes, these were biased articles from vendors (especially those offering only one of these system classes), and it was hard to agree with their perspectives. In other cases, it was only a shallow analysis containing a lot of marketing and fewer substantial insights. For instance, "advantages" like "Decision-making", "Performance analysis", "Analytics", "Data exploration", "Reporting" were frequently used in comparisons. Some attributed these concepts solely to a specific class of systems, while others claimed they applied to both, but with a “different approach". After reading such material, one might indeed get the impression that these system classes are very similar and even interchangeable.
The second reason for the confusion is that both sets of software solutions include graphical dashboards and interactive analytical capabilities. When promoting their products, whether BI or CPM, vendors will invariably showcase examples of beautiful dashboards and reports because they are highly marketable. The diversity of charts in promotional materials creates a false impression among end-users that both systems perform similar functions. I've seen several examples when CFOs from entirely different companies deliberated on establishing their budgeting process using Power BI because the demonstrated "data visualizations and drill-down" fully meet their reporting needs. Unfortunately, while captivated by beautiful visuals, they sometimes forget that planning and budgeting encompass far more than just reporting. I know for sure that some of these projects began, and "unexpected discoveries" emerged during project implementation.
A Bit of OLAP History
There is a common belief that Business Intelligence (#BI) evolved from the technology known as Online Analytical Processing (#OLAP), which gained popularity in the late 1990s - and early 2000s. Early BI tools leveraged OLAP engines to analyze multidimensional data, providing capabilities for complex calculations, trend analyses, and sophisticated data modeling.
Later, BI tools started incorporating more interactive and intuitive features, pivoting away from traditional OLAP engines towards in-memory processing and columnar databases, improving reports speed and user experience. ?Modern BI systems are not just about "analytical reports" with dynamic filters and drill-through capabilities but are also tools for operational insights, featuring trend identification, data clustering, storytelling, and even AI.
Large vendors initially attempted to implement planning and budgeting functionalities within Enterprise Resource Planning (ERP) systems (e.g., #SAP and #Oracle). Over time it became clear that the architectural characteristics of transactional systems couldn't deliver the desired flexibility and didn't meet the increasing demands for computational performance in complex financial models with multiple scenarios, versions, and dynamic planning horizons. As a result, the functions of "planning, forecasting, and budgeting" were separated into standalone "engines".
For instance, SAP introduced Advanced Planner and Optimizer (APO), which enabled a more sophisticated and adaptive approach to forecasting. Then, in 2007, they launched Business Planning and Consolidation (#BPC), offering features like scenario planning, rolling forecasts, and robust analytics, which were lacking in earlier solutions. ?When SAP HANA was introduced, BPC was further enhanced to leverage the in-memory computing capabilities of HANA, resulting in better performance, real-time data access, and improved predictive capabilities. Although BPC possesses OLAP-like capabilities, especially in its representation of data hierarchies and dimensions, it is not typically considered a classical OLAP product.
Oracle followed a similar path. Early versions of the budgeting process were implemented using the General Ledger module of Oracle E-Business Suite (OEBS). In response to the growing need for more advanced budgeting and forecasting tools, Oracle introduced standalone tools like Oracle Financial Analyzer (OFA) and Oracle Sales Analyzer (OSA). These tools allowed businesses to perform multidimensional analysis and forecasting using Oracle Express OLAP Server, a significant improvement over the traditional relational database used in OEBS. Recognizing the need for an even more integrated and robust solution for planning, Oracle acquired Hyperion Solutions Corporation in 2007, and the product #Hyperion Planning remains one of the leaders in CPM systems. Hyperion Planning relies on the Essbase OLAP server for its multidimensional data storage, calculation capabilities, and data retrieval.
I'll provide a brief overview of the next two CPM leaders here in the article because I'll delve deeper into their specifics later in the article.
#Anaplan: Anaplan emerged much later than its predecessors and never was a classical OLAP technology, which some now consider outdated. Anaplan uses a proprietary in-memory engine called the "Hyperblock", combining aspects of relational, vertical, and OLAP databases and computation to deliver multidimensional analysis, scenario planning, and large-scale modeling.
#IBM #Planning #Analytics (#TM1): The earliest versions of TM1 were introduced a long time ago. Modern software versions employ an in-memory, OLAP-style engine. Models are cube-based, which means they have a multidimensional nature like classical OLAP. Therefore, although many modern BI and CPM systems either truly use OLAP engines or possess some OLAP features, I wouldn't equate BI with OLAP or CPM with OLAP, as some experts sometimes oversimplify it.
What's Under the Hood?
Now, let's talk about the peculiarities of comparing CPM and BI from a slightly unusual perspective. I won't use the standard comparison criteria (or will only use some of them), but instead, I'll add distinctive points that are often unfairly overlooked in comparisons. This can sometimes lead to misunderstandings when selecting the target system.
Data Integration: Connectors
A good BI system should have out-of-the-box integration with the maximum number of systems in a company's IT infrastructure, including cloud-based software. For instance, KPI data might be collected from a corporate Data Warehouse (DWH) hosted on-premise or in cloud storage or from individual systems such as ERP, CRM, HRM, CPM, EDM, etc. Budgets allocated for building BI reports are typically much lower than, for example, the costs of a full-scale ERP implementation. Delivering integration interfaces to fetch data from multiple systems (if there is no centralized DWH) can be time-consuming and may exceed the cost of the main project.
As a result, BI solution vendors pay a lot of attention to connectors with popular platforms. For example, #PowerBI, #Qlik Sense and #Tableau have dozens, if not hundreds, of built-in connectors to various data sources.
But what about CPM systems? IBM Planning Analytics, which recently celebrated its 40th anniversary, still relies on four types of interfaces to the "outside world" - text files, ODBC, ODBO, and REST API. For other types of integration, you'll need to purchase IBM Cognos Integration Server licenses or use other intermediate tools. Anaplan supports text files, Salesforce connector, and REST API. Oracle Hyperion has native connectors for different Oracle products and relies on text files.
Why does this happen? I believe the answer lies in the fact that CPM systems are often required to be integrated with ERP systems, and most modern ERPs can, at the very least, export data in text format and exchange data via REST API interfaces. CPM vendors primarily implement these methods, thus covering most data exchange needs.
Data Preparation as Part of ETL
ETL, which stands for "extract, transform, load", is a three-phase process where data is extracted, transformed, and loaded into an output data container. I've already touched on the "Extract" phase in the Data Integration section. The "Load" phase is inherent in any system capable of loading data from external sources. That’s why I would like to focus more on the "Transformation" phase now. ?It's quite rare in a real project that data extracted from another storage can be used in the target system without transformations. There are several reasons for this. Let's explore some of them:
This is by no means an exhaustive list of conversions and transformations that need to be dealt with when loading data from external systems. These systems may deliver data in completely different formats and use various application programming interfaces.
As already mentioned, modern BI systems are usually developed to have the capability to fetch data from various sources. Within the BI system, the loaded datasets must be standardized in terms of storage formats and data structure. Therefore, having a powerful data loading and transformation tool is critical for BI. Power BI, for example, has the Power Query functional language, and Qlik Sense uses Qlik Sense Scripts.
On the other hand, the ability of CPM systems to load and transform data is equally important. Rarely does planning occur without, for example, loading fact, which is not only needed for plan execution analysis but often serves planning for the following periods. IBM Planning Analytics, for example, uses the built-in "Turbo Integrator" (which, despite its name, has long been used not only as an integration tool). Anaplan or Oracle Hyperion, on the other hand, use graphical interfaces to configure source field mappings but are unsuitable for deep data transformation. To be fair, I must also note that Tableau, one of the BI system leaders, also lacks a full-fledged ETL tool. Analyzing ETL tools in various systems, I have concluded that it's more about the vendor's focus on developing and positioning their product than a specific feature of a particular class of systems.
Data Entry/Writeback
It’s on the surface, and yet it’s often overlooked. As I mentioned earlier, in my experience, there have been several cases where the decision-makers, while comparing platforms, omitted the obvious point about data entry capability. Much attention is always directed toward the calculating system capabilities, reports and the supported interfaces for integration with external systems. However, it's difficult to imagine a budgeting model solely built on data imported from external sources, and there are no metrics manually entered into the system. Even for top-down scenarios in rolling planning, as I mentioned in this article, managers still cannot do without manual adjustments (e.g., to balance the achievement of target indicators).
We enter data into planning systems through input forms. These forms can either consist entirely of manually entered metrics or include partially calculated and partially input metrics. Only when a form does not contain manually entered metrics do we call it a Report.
领英推荐
Now, let's circle back to the characteristics of CPM and BI systems. While CPM cannot do without advanced data entry functionality, the BI, being primarily a reporting and analytical system, can do very well without it. I'm not saying that BI systems totally lack data entry capabilities. They do exist, but typically, they are either quite limited or use third-party plugins, or Excel writeback extensions, and so on. Sometimes, these add-ons are suitable for extensive data input, but usually, they come with an additional cost.
On the other hand, CPM systems are inherently designed to make data entry as user-friendly as possible. Many CPM vendors offer several ways to implement input forms. For example, they provide visuals that can be loaded into a web browser or forms realized through Excel add-ins.
Data Visualization
CPM systems are increasingly incorporating traditional BI visualization features (various types of charts, dashboards, etc.), but for the most part, they still lag behind BI leaders. The vendors attention to UI/UX is not surprising because "attractive user interfaces" appeal to visual perception, and a "successful user experience" encourages users to return to the system more often.
In general, the "visualization" functionality of modern CPM harmoniously complements the existing mandatory components of these systems, such as proprietary data processing engines (aggregation, pre-computation, compression, caching, indexing, etc.) and input forms (which are already "tabular" or "matrix" visuals by nature). Thus, the vendor's task is to expand the set of visuals, which is not the most challenging task, considering the variety of ready-made paid and open-source libraries for charts and graphs. Observing the speed of inclusion of new visuals in various CPMs, we can assume that within a few years, the leaders of this system class will catch up with the capabilities of leading BI platforms.
Financial Processes Support
There are countless variations of projects, each with its unique characteristics. So are #FP&A projects. CPM systems, for which FP&A projects are one of the focus areas, are developed to support the specific features of financial processes, minimizing the cost of customization and ongoing maintenance. Let's explore some of these processes and see the level of support in the considered system classes.
Forecasting. #Forecasting is the process of making predictions about the future based on past and present data, as well as analyzing trends. Both CPM and BI systems have forecasting capabilities, contrary to the common belief that BI lacks them. To some extent, all major BI vendors have implemented forecasting in their tools, but their approach differs from that of CPMs.
In BI, data is usually treated as datasets without knowing of how calculated values were derived. For example, data calculated in a CPM system using a formula like "Revenue = Quantity * Price" would be loaded into BI as separate datasets for Revenue, Quantity, and Price. Consequently, CPM uses driver-based methods for forecasting, while BI relies on statistical methods. While simple correlations are straightforward, searching for complex, composite drivers may be more challenging to handle. BI will likely offer some kind of polynomial function, but it will be different from the original driver-based functions.
Another critical difference is that BI's forecasted data remains "dynamic calculations" and cannot become part of the company's approved plan data (in a format written back to the system's own storage). Therefore, BI's forecasted data is limited for further use in other forms and reports; it cannot be manually adjusted or copied to another modeling scenario. In other words, BI systems do not comprehensively support the financial forecasting process.
Activity-Based Budgeting (ABB): #ABB is a budgeting method that records, analyzes, and links activities that incur costs in every business process to specific products or services. It uses drivers to allocate costs based on these activities. A cost driver is a factor that has a direct cause-effect relationship with the resources consumed. In ABB, costs are not just allocated based on direct labor or materials (like in traditional budgeting) but on the activities that drive the costs.
CPM systems typically have functionalities that can support ABB. These functionalities allow users to define various activities, link them to cost drivers, and then allocate costs based on the consumption of these drivers.
While theoretically, the activity-based approach can be set up in many BI systems, in practice, configuring such an approach in BI systems may reveal that they are not tailored to this approach in various aspects. These are working with multiple heterogeneous metrics or complex cost allocation algorithms. These limitations may be more noticeable to modelers than end-users.
Rolling Forward. Almost always, the budgeting process during the budgeting campaign implies not only the creation of the "Budget" for the next year but also the Forecast for the for the remaining current period. The budgeting campaign usually lasts several months in large companies, during which the company refines its KPIs for the next year. At the same time, the company's normal operational activities continue, new factual data is constantly being collected, the forecasting period until the end of the year is reduced, and the initial data for planning for the next periods are being clarified. If the budgeting campaign for the next year begins, for example, in July, and the first budget for the next year is compiled based on the "Forecast 6 + 6," and the final budget is assembled in November, then it is already based on the updated version of the "Forecast 10 + 2". Therefore, the final version of the budget can significantly differ from the initial version, including due to variations in performance from July to October. During this period, the company can create several budget versions, which takes a lot of time and resources.
Therefore, the rolling forward approach is highly efficient in financial planning processes. It enables consistent moving forward in time with automated copying of factual data to new versions and/or new periods, as well as the reduction and recalculation of forecasted periods. Anaplan, one of the leading CPM vendors, offers the switchover mechanism, implementing not only the periodic planning process but also rolling planning tasks.
BI systems do support for such kinds of processes, as they are fundamentally not genuine planning and budgeting systems.
Financial Consolidation. Financial consolidation is a complex process involving the aggregation of financial data from various subsidiaries and business entities within a group company to present unified financial statements. This process includes merging multiple financial data sources, eliminating intercompany transactions, adjusting for variations in accounting practices, translating foreign currencies, calculating minority interest, and many other specific transformations and calculations that require specialized functionality.
Not all, but many CPM systems offer this functionality out of the box. For example, well-known systems like SAP Business Planning and Consolidation or CCH #Tagetik support financial consolidation. Anaplan also has a stand-alone solution for financial consolidation following IFRS principles.
In contrast, BI vendors do not embed financial consolidation mechanisms into their products. While advanced BI systems can theoretically implement many of the aspects listed above, it can be technically challenging in practice.
Audit trail
Both BI and CPM systems typically have built-in logging mechanisms, but they serve different purposes. In BI, audit logs usually record information related to user activities, changes in user access rights to reports, and other administrative actions and server activities.
On the other hand, CPM systems, which are tailored for data input and writeback, track and record changes made to a model. This is an important distinguishing feature of CPM systems compared to reporting systems. When choosing a system for planning and budgeting purposes, it's crucial to consider this difference, as audit trails for data entry and modeling activities can be essential for financial transparency and accountability.
Workflow
Budgeting campaigns typically involve multiple stages, for example: Forming macroeconomic assumptions > Forecasting and updating strategic models > Setting top-down company goals > Preparing and defending several intermediate versions of bottom-up budgets > Finalizing the budget. These budgeting stages may consist of breakdown sessions where cost and profit centers create and defend their local budgets. Some budgets may be developed independently, while others depend on the plans of other departments, requiring precedent budgets to be "frozen" during such sessions.
In large companies, these workflow processes can be complex, with many interdependencies. Ensuring data integrity and consistency across budgets becomes a top priority. Therefore, comprehensive systems, including CPM systems like Anaplan, IBM Planning Analytics, and Oracle Hyperion, include workflow capabilities as part of their platform.
In contrast, Power BI, Qlik Sense and Tableau, being primarily reporting and analysis systems, do not have traditional workflow capabilities built-in. Logical data consistency for reports must be ensured by source systems, structured processes and IT architecture. The absence of workflow mechanisms in BI systems is an important factor to consider when choosing a budgeting system.
Metrics
Metrics are a key element of any report or financial model. In planning and budgeting systems, metrics can be used for data input, formula storage, and calculations. "Quantity", "Price", "Variance" ,"Opening/Closing Balance", "Debt repayment period", "Loan rate" and even sometimes BS/PL/CF items are all examples of metrics in the model. Large and complex models often consist of thousands of interconnected metrics, so CPM systems must provide a flexible yet straightforward mechanism for configuring metric calculations.
Leading CPM vendors offer such mechanisms. For example, in Anaplan, these are Line Items, with primitive or reference data types, store cross-dimensional formulas, aggregation methods, and specific metric dimensions. In IBM Planning Analytics, a classic OLAP system, the last dimension in the cube (measures dimension) is typically used to store metrics. This dimension is similar to other dimensions in the cube but has its own features. Therefore, the model rules often contain the names of the specific elements, which means specific calculations for the metrics.
As analysis and reporting tools, BI systems also have means for calculating metrics or measures. However, they operate somewhat differently. For instance, measures in Power BI, created using #DAX (Data Analysis Expressions), are very "context-aware" ?(they respond and recalculate based on user interactions with the report). Developing measures, especially for multiple P&L items (or one measure for all items), can be more challenging in BI compared to CPM systems. Qlik sense links data sets using associative keys. This allows for very interactive analysis, but, like Power BI, it's optimized for analytics rather than the granular financial modeling of CPM tools.
In conclusion, I cannot but add that this point is debatable, as it is not as straightforward as Audit Trail or Workflow. Many BI professionals, experts in their field, may disagree with me because they "regularly set up financial reports within their BI projects". However, I am not claiming that it is "impossible”. I have personally built P&L reports in Power BI based on data from Anaplan when specific requirements for dynamic report views could not be achieved in the original system using a simple approach. I am only inclined that static financial reports with multiple heterogeneous calculated metrics are more efficiently to do in CPMs.
Rugged Hierarchies
Rugged or uneven hierarchies are hierarchical structures where branches of the hierarchy have different depths. In other words, some branches of the tree structure may go deeper (have more levels) than others. For instance, the sales department might have many sub-departments and levels in an organizational structure, whereas the HR department might just have a few.
In the context of financial modeling and #FP&A projects, many hierarchies in dimensions are likely to be uneven. These may include divisions and departments, P&L/CAPEX/CF items, cost centers, inventory items, and many other structures. Typically, dimensions like time, currency, and contractors have relatively even hierarchies.
Most CPM systems I have worked with (including IBM Planning Analytics, Oracle Hyperion with their multidimensional engines, and Anaplan with its HyperBlock engine), natively work with rugged hierarchies without additional code. However, the same cannot be said for BI systems.
For example, Power BI and Qlik Sense, while allowing users to create hierarchies through user panels, often require the writing of specific code in DAX (Power BI) or a data load script (Qlik Sense) to visually display uneven hierarchies. Tableau faces similar limitations.
I have not found a plausible explanation for why BI systems, built on engines with different paradigms, often struggle with uneven hierarchies although that visualization is equally important for both BI and CPM. Perhaps other popular BI platforms work great with uneven hierarchies, and I just wasn't lucky enough to work with them. I will be glad to hear your comments here.
Conclusion
Despite many similarities between BI and CPM, they remain specialized systems designed to address overlapping but not identical sets of tasks. Promises from some crafty sellers to "automate budgeting processes using a BI solution" can lead to "unpleasant surprises" when such implementations begin. If, for some reason, this decision is made, consider specialized add-ons for the platform. Developing such add-ons in-house may not be practical regarding the time and human resources required, especially given the significant gaps outlined in this article.
Conversely, evaluate the feasibility of using CPM as a "universal system for visualization, reporting, and data analytics”. First, you would need to put additional strain on your planning system, which is already heavily loaded with constant recalculation of a vast amount of data. This data would have no relevance to planning or forecasting. Second, even if you create a separate system model for this data with independent CPU and memory resources, you will likely to pay significantly more for licenses (CPM licenses are typically more expensive than BI licenses) for a more limited set of visualization and reporting functionalities.