Ever since CPM applications came to the market, discussions around the performance of the financial consolidation processes have flourished. Different vendors have often claimed their systems can run faster, complete multiple consolidations in parallel or reduce the time from hours to minutes. All of that is great since time can obviously impact the overall reporting process, but the actual functions included in the financial consolidation must be considered before making any kind of comparison.
Still, we’re often asked the same question: Will my consolidation be quicker in OneStream than it was in Hyperion Financial Management (HFM)?
Sounds like a perfectly reasonable, simple question. And the short answer is obviously YES. Otherwise, why would hundreds of companies have migrated from HFM and other legacy CPM applications to OneStream’s unified CPM software platform?
Your follow-up question, of course: ‘Okay, how much faster?’
We get this question a LOT too – but it’s not an easy one to answer. Why not? Well, despite first appearances, we’re not really comparing apples with apples. OneStream is architected as a unified CPM platform and does things differently from legacy CPM point-solutions such as HFM.
Let’s look at some of the differences.
(We promise to avoid getting overly technical!)
Despite the above promise, we do need to talk a little about systems architecture and servers in Financial Consolidation software since both play a role in performance. Even ‘in the cloud’, all our numbers are still ultimately processed on real computers – with real processors, memory, disk drives and network links. Thus, the architecture and servers matter. We must make the best use of what we’ve built and paid for (directly or indirectly).
Given that, let’s unpack the performance differences between HFM and OneStream. HFM uses multiple processors/cores to run parallel calculations by entity. OneStream does the same but for Member Formulas (rules) within the same entity.
Why the difference matters will become clear in the following example. Pretend a server has 8 processors/cores. HFM will use all 8 because it’s still simultaneously processing 8 entities. That parallelism is fine at the bottom of the consolidation, assuming the parent has at least 8 children (not always the case), but not so great at the top of the entity hierarchy where the top-level holding company is being processed by only 12.5% of the available computing power. Worse, that top-level entity probably holds the most granular data and will therefore take longer to process anyway.
Alternatively, OneStream uses all the available processing power for all the entities, bottom to top, and that makes a difference. How much of one? Well, it depends on your exact entity structure, the shape of your data, the details of your rules and a host of other variables – which means we’d be doing you a disservice to simply quote a meaningless percentage. But the difference in performance is considerably more than nothing.
The OneStream platform has also been architected to better use the available processing power. Specifically, OneStream not only has sophisticated processes to move jobs to the server with the most available capacity but also has plenty of features that allow for separating different jobs (e.g., data load, consolidation, user interface, etc.) to different server groups. That functionality ensures users don’t suffer a degraded experience during a consolidation or scheduled data load process (See Figure 1).
The level of data granularity ultimately impacts performance. Some customers, for instance, had massive entity structures in their legacy application that included both legal entities and a lower level of detail splitting the numbers by organisation – at the segment level or, in some cases, even down to cost-centre level. And the cost centre level data doesn’t exactly seem like a logical application of ‘consolidation’ accounting – that only happens at legal entity level.
So why slow things down by running a process that’s unnecessary at that level? OneStream applications can instead be designed in various ways to avoid all that unnecessary effort.
One option is to recognise that the lowest level of data granularity doesn’t even need to be in a ‘cube’. Via OneStream’s Relational Blend technology, the detailed data can be loaded into relational tables in a single OneStream application and presented through multi-dimensional hierarchies. Only the entity-level summary of that data needs to be presented in a cube, making the data set for consolidation appropriately smaller. Of course, you can still drill down to see the detailed data within the same application – but most users won’t even realise a ‘difference’ exists in the structure.
The traditional approach to financial consolidation (e.g., in HFM) involves writing all the accounting logic (for eliminations, ownership adjustments, equity pickup, etc.) in Business Rules. Those rules are simply coded logic that gets run against the data for every Entity, sometimes multiple times in the same consolidation run.
Many of our customers use a similar approach in OneStream – in which numerous detailed differences exist around how those rules are structured, how they perform or how easily their performance is tested. In fact, many of the rules aren’t even needed or are much simpler due to the many consolidation-specific built-in features of the OneStream platform.
However, an alternative approach to consolidation exists that’s simply not available in HFM: the Investment Register approach (see Figure 2). Some of our European customers with highly complex consolidation requirements particularly favour this approach, but it can be applied anywhere.
The Investment Register comprises a list of investments and key related details (e.g., acquisition date, acquisition cost, reserves and exchange rate at date of acquisition) maintained in a relational table. In a process separate from the ‘main’ data-driven consolidation, we then utilise the Reporting Compliance Marketplace solution to generate detailed consolidation adjustments as Journals. Most rule complexity is therefore eliminated, so the consolidation itself is little more than a ‘translate and aggregate’ process.
As a result, the register approach makes consolidation a whole lot faster – but better still, think about the complete close process. How often does the data you’re consolidating change during the month-end close? Quite a lot, actually. Every time another entity has submitted. Every time an entity submits late adjustments or supplementary detail. Every time an inter-company balance gets sorted out after month-end because the process isn’t in place to fix it beforehand.
Now think about how often the group ownership data changes during the close. Rarely. Thus, if already created using the Investment Register, the consolidation journals don’t need to be recalculated every time we re-run the consolidation. In fact, we can usually even get this bit of the close done before Working Day 0, altogether removing them from the busy close period.
Financial Consolidation is ultimately a business problem to be solved. For many of our largest, most complex customers, consolidation is one of the most immediately obvious ‘big picture’ performance topics.
How that problem gets solved varies depending on the system being used. But making comparisons between those systems is not always straightforward, so we can’t (and won’t) answer the ‘Okay, how much faster?’ question with a universal percentage.
Consolidation also isn’t an isolated problem amid the many other challenges facing the Finance function. And that’s why OneStream makes a difference. It’s a unified CPM platform that allows for innovative and highly performant solutions to many different business problems, within and beyond the Finance function – and the entire OneStream community is dedicated, as it is with all our customers, to ensuring the success of your implementation.
To learn more, download our whitepaper on Conquering the Complexities in the Financial Close.