With a unified CPM platform consolidation and planning are based on the same technology foundation. This means there is more scope for the implementation staff or consultants to get a head-start when designing a planning project because they can use the experience gained during the “Phase I” Actual reporting. Not sure? Read my last blog about it.

With that out of the way, this is where you start:

• Find out the overall vision and strategy of the existing CPM application, and where this planning implementation fits in.
• Was there a planning system used before? What was the business case for moving away from that?
• If you are starting this as “Phase II” (where “Phase I” was Actual consolidation), and you were not involved in Phase I, then there is a chance that the chart of accounts and other dimensions are already in production, and designed more around Actual data. If you want to extend these dimensions for Budget and Forecast type scenarios then great, this is a great chance to have some workshops on that topic.
• However for data input it is more likely that the Budget and Forecast scenarios require *less* detail input than for Actuals. That is a challenge if, in a Onestream implementation it is only when you get to Phase II that you realise there should have been a less detailed chart of accounts for forecast input, and the actual scenario should have extended on that. With Extensible Dimensionality® you have no way to create a more summarized dimension from a detailed dimension. You can only go one other way, and that is to *increase* the detail in a dimension.
  This is the reason why, if the level of detail for forecasting is not considered right at the start before Phase I, then you may be forced to designate a dummy input account for a particular rollup. For example…

In a later part in this blog series, we re-visit the problem of how Extensible Dimensionality® needs to be able to change over time, because forecasting and budgeting models continually evolve.

• Who are the key people that will validate the design? What are their concerns, and what part of the planning cycle are they most interested in.
• Can you break the project into deliverable sub-phases? (need to do some research & design first)
• Usually there are other software applications such as a CRM system, HR system, Excel workbooks or other packages that maintain SKUs, product categories, future prices, historic sales volumes etc.
  Before you dive too deep into the driver model in OneStream, you need to understand
  • What is the value of the data that can be supplied from these external systems, how can I use it in my planning model
  • Assess the quality and consistency of the data; there may be some unexpected gaps or other nasty surprises
  • Are those systems actually ready? Maybe they are only planned to be available next year. Can you really count on using it. Make sure the dependency on that other project is clearly communicated and push for a Plan B.
  • How much work would be involved in data interfaces and transformation, to get it into the new planning model. You won’t be able to answer this fully until you have a design for the planning model of course.
• Assess any planning models that have been built by the FP&A team, as a prototype or simulation of what they are really looking for in the CPM tool. Sometimes you are lucky and someone in FP&A has built a semi-working model in Excel that you can take home and play with. Sure, the consultant’s family at home will think he or she would rather play with Excel Pacman (in their imagination) than join them for dinner, but hey you’re probably used to that by now.
  Some customers may not have had the internal resources or time to build any planning model or prototype of their ideas that you can get your hands on, and the consultant is often asked “we are looking for your advice on how do all the other customers do it”.   At this point, this may lead to use-cases of Onestream Specialty Solutions that are used for financial planning. Please don’t ever call them Specialty Planning Solutions unless they can only be used exclusively for planning, or you want to wind me up of course.
• Go through the main specialty solutions (such as People Planning, Capital Planning), and show how you feel it may be relevant to what you’ve learned so far about the customer. For example they may have an HR system that can regularly feed staff information into the People Register, or a CRM tool that can supply customer information, so you may like to suggest Thing Planning. If the business is very heavy on Capex, then maybe Capital Planning could be considered with detailed insights into capex investments with project details, an asset register with depreciation schedules, useful life etc..
  There is a good chance though that the customer doesn’t have the systems in place, or the processes in place, to be able to populate a detailed register. So you need to start with something simpler, and use only the information you’re given.
• If there is little detail (scope for Specialty Solutions and Registers), then start with a simple planning model, where a very limited selection of core drivers (customer volumes, upselling percentages, a general inflation percentage on material prices), and some average prices, are applied, so you have a very small number of actual driver calculations, but you can make up for it by building a decent way of roll-forwarding Actuals to pre-populate baseline data, and then make it as easy as possible for users to change it manually.
• Explain the value of the Origin dimension, where you can pre-populate baseline data on the Origin Import member, and form adjustments are stored separately, so you can always compare the manual forecast revisions to the original baseline data.
• Find out what the scope is of the planning implementation. It may be wise to start with the Income Statement as one phase, then move onto balance sheet and cash flow as the next phase. This usually doesn’t go down well though, because cash flow forecasting is often top on the list of priorities.
• Go through the rest of the income statement and highlight where the gaps are that have not yet been covered. Certain operating expenses like office costs are relatively consistent year after year, so you may suggest a model that rollforwards averages from prior year actuals. Tip:  Don’t put this into a formula for the forecast scenario in OneStream, because data will be copied from Actuals every time you consolidate, causing potential performance problems.
• Map the income statement to corresponding balance sheet movements (e.g. depreciation expense à movement in depreciation ), to ensure the balance sheet ties in as much as possible with activity from the income statement.
• Workflow design : Work out the different teams within FP&A who focus on particular parts of the process. For example there may be users who’s core focus is on revenue/sales planning.
  Write down on whiteboards what the workflow steps might look like for different types of users within FP&A; the steps may vary by country, vary by function. What are the pre-requisites for each workflow step? Are there dependencies, can someone only complete their part of the planning process once another person has completed their part? Build that into the workflows, but first draw it out on whiteboards. Often at this point the customer has a light-bulb moment, because not only because they can visualise the overall process, but they also realize at this point which of their colleagues would be assigned to each workflow – it sort of makes it a personal connection to the process.

These actions should get you a design that works. Next blog will be about Specialty Solutions, myths, wizards and of course: financial planning.