Comparing Financial Consolidation Performance Across CPM Solutions

This article first appeared on OneStreamSoftware.com by Nigel Dahl

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!)

 

Performance Gains

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.

 

Architecture

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).

Data Granularity

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.

Consolidation Approach

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.