Chris’ blog #1 CPM project phasing: consolidation versus planning
Posted on , updated on

What are your project phases?

As a OneStream customer or consultant, you are probably familiar with the implementation of OneStream projects in phases. Phase I usually starts with consolidation with a focus on Actual data loads from ERP systems. In such a Phase I implementation, Budgets and Forecasts would typically be prepared offline and then loaded through Excel templates into OneStream.

So far, the majority of our customers have first implemented Actual reporting as Phase I and then moved onto driver-based planning as “Phase II/III”. Some start using OneStream as an IFRS16 (Lease Accounting) solution, then look into financial reporting & consolidation later.

However there are some advantages to starting with financial Planning as Phase I, most notably that if an application is not yet being used for Actual reporting during its development & testing, then you have less auditor scrutiny for a while, allowing changes to be made regardless of the statutory reporting cycles. That is, until you start using OneStream for Actual reporting. In fact we wrote a separate blog on this topic a couple of years ago (where to start in Onestream, Actual Consolidation or Planning?)

For the purposes of this document I will assume that you’ve started OneStream with Phase I being more consolidation & reporting of Actuals. After the experience of consolidations, GAAP and IFRS adjustments, loading and mapping Trial Balances out of ERP systems, you often come onto the topic driver-based planning, and that involves completely different way of thinking.

Transition of the Mindset from Actual Reporting to FP&A

With any CPM/EPM product, there is a shift in the way of thinking which fundamentally change how you design calculations, data forms (cube views), and how calculations are triggered.

Actual Reporting

All calculations, translations and eliminations are done as part of one button “Process Cube”. The user doesn’t care about all the intermediate steps, they just want to report the output and be able to explain it.

Work mostly with YTD amounts

Focus is on one reporting period each cycle, so for management reporting this is typically monthly.

The core consolidation model doesn’t really change over time; accounts are added, more detail is added, new entities are added, ownerships change, but it’s more data changes than model changes.

Underlying detail is added to help explain the numbers that were loaded from the trial balance, rather than generate the numbers.

Dimensionality is designed around the needs of statutory and management reporting, and then subsequently you load summarized budget data into a ‘consolidation model’.

Closing Balances usually loaded, then you enrich it with movement detail afterwards.

Driver-based Planning

Most of the time, calculations need to be run immediately when you save a form, so for performance reasons only the amounts directly affected by this form should be calculated, instead of calculating the entire cube.

Work mostly with Periodic data (volumes, prices etc).

Focus is forward looking, up to a horizon. For example a long-term plan may span 5-7 years. But a mid-year forecast may look forward 18 months, or only the rest of the financial year. So if you have just implemented a consolidation system and assumed in your calculations that everything rolls forward from “Month 12 last year”, or you assume periods are always monthly frequency then you might be in for a shock.

The Planning model continually evolves over time.

Underlying detail is used to generate and explain the planned activity in the financial reports.

Dimensionality may vary by different cubes and is optimised for the underlying drivers being collected. For example sales forecasting is likely to require different dimensionality than for production costs.

Closing balances are derived from movement activity, within OneStream.

If ‘Phase I Actual’ reporting has already been implemented in a CPM tool, in a way that makes it difficult to later incorporate the items on the right side of the table above. Then you may have to spend-time re-engineering your Phase I. 

These are just some examples on the challenges you may face when moving from using a CPM system primarily as a consolidation system, to a unified platform that incorporates driver-based planning. 

In the next blogs, we discuss the effects on how a unified CPM platform affects the consultants themselves, and how to approach a new design for a planning solution on an existing CPM application.

About the author

Chris Loran works in the EPM field for over 13 years. From working with Hyperion at Hyperion Solutions, Oracle, Partake and EY to working with OneStream and Oracle HFM at Agium EPM.

Within his Lead Consultant function at Agium EPM he worked on the OneStream implementation at Guardian Industries. They have one of the most extensively used OneStream platforms in which they consolidate, budget and perform advanced driver-based planning.

Disclaimer: These blogs are meant purely for educational use and discussion. The purpose is to raise awareness of the strengths of the Onestream platform and how it could be made even better, as well as approaches to application design and building, and stimulate discussion. Experiences mentioned in these blogs are those specifically of the author and may not be the experience of other CPM consultants. The views expressed are those of the author, and does not necessarily represent the views of any CPM or EPM software vendor, nor their consulting partners.
Back to blog