Best Of

1. Abstract

Initialization process is a common topic on many projects. In its most common definition is the pre-population of a Scenario/Version with reference data so the planning/analysis can be quicker.

This process can easily become challenging since it often deviates from a simple copy and includes also recalculations based on business logics.

The purpose of this document would be to describe the best way to set it up and give common best practices where applicable.

2. Context

During the setup of an initialization process, there are different ways to define it and developers should decide based on the pros and cons of each method.

This is a really crucial decision because it will affect the entire data model and define assumptions upon which most of the application will be based on.

3. Content

3.1 Initialize Vs 0-based

One of the first decisions to take is whether implement an initialization process or not. Depending on the maturity of the customer organization this can be already decided by the Process owners or open to discussion.

Where feasible/applicable it is best practice to always start the planning process with an initialization. This will prepopulate the planning data and speed-up the entire planning process.

From a technical point of view, it will also allow to use at its best our “Split&Splat” functionality and unlock top-down planning as well as the usual bottom up.

The opposite option to running an initialization process is to work 0-based. A common practice in the FP&A applications is for example called “0-based-budgeting” . This is the tendency to have the most important planning exercise, i.e. the budget, to be performed only with a bottom-up approach without prepopulating the data with any initialization logic. This option can coexist with an initialization process by initializing the less critical planning exercises (for example the classical 3+9,6+6, etc Forecasts) while leaving 0-based the Budget.

In most cases, the initialization process is always applied to each planning exercise on a versioning entity called Scenario/Version. We further discuss this dimension's definition and its use in the paragraphs below.

3.2 Scenario/Version Entity Definition

3.2.1 Use 1 or 2 dimensions?

It is best practice to use only one dimension to define each planning exercise; if the process is divieded into several Scenarios (forecasts and budget) and each of these can have different Versions , it is advised to create only entity and keep the elements of this entity to minimum; this suggestion comes from the fact that most of times Versions are used but not all Versions for all Scenarios, so it is suboptimal to use 2 Entities for this feature.

3.2.2 Which elements should it contain?

It is best practice to add this dimension as few elements as possible to avoid side effects on performances; for this reason the most common definition is to add include all the relevent Scenarios and add 2-3 versions only for the most important ones; here below an example:

• FCS1+11
• FCS2+10
• FCS3+9
• FCS4+8
• FCS5+7
• FCS6+6 v1
• FCS6+6 v2
• FCS7+5
• …
• BDG v1
• BDG v2
• BDG v3

3.3 Scenario/Version Entity in the data model

Now that the entity Scenario/Version has been defined , the next choice is how to use it into the data model.

The first best practice to apply is to be homogeneous, meaning that whatever approach we apply we need to be consistent across the datamodel in the way the Scenario/Version is used. In other words, avoid that this entity is used only in certain areas of the datamodel and not in other, unless it is a specific functional requirement.

That said, here below we describe the most common approaches to this very important design choice.

3.3.1 Approach 1: Working plan + Snapshots

This first approach consists into having a set of dedicated cubes without scenario/version which are used for planning and contain what can be called the “Working Plan”. When this plan is finalized, it is then copied into the dedicated reporting cubes which are instead by Scenario/version.

This approach offers the following pros/cons:

• PRO - Best approach from a technical point of view: simpler cubes for planning because they will contain less dimensions; less data redundancy because we will not store into the planning cubes several versions of the same plan;
• PRO - Not strictly necessary startup/initialization process : since the “Working plan” is not versioned the users can just resume working from a previous plan and quickly complete the new planning exercise;
• CON - One Scenario/version active per time : since the planning cubes are not by version we cannot allow to have multiple Scenario/Version open at the same time; there are some levels of flexibility in this, since we could allow having different scenario/versions open for different business entities ( for example different scenario/version active by Company);
• CON - Identify a business milestone/date when generating the snapshots: the snapshot generation requires a process to be executed; for this reason, especially for large organizations, it requires that a business milestone is identified and commonly agreed throughout the organization;
• CON - Snapshots are for reporting purposes and cannot be reworked: once a “Working Plan” has been finalized, copied into a scenario/version and the planning has moved on to the next scenario, changes cannot be made anymore; any changes will have to be made in the following Scenario/Version;
• CON - Real-time Reporting for the working version, however snapshot reporting updated based on the business milestone;
• CON - this approach requires a number of separate cubes by Scenario/Versions. This set of cubes can become quite big if we want to version not only the final result of the planning, but also all the intermediate stages that lead to the result.

This is the suggested approach because of the simplifications that allows to the planning data model and because in most of the business applications is more than sufficient to cover the versioning/simulation requirements. Moreover, having cubes structured in this way will facilitate the creation of the required planning screens, reports and flow of data.

3.3.2 Approach 2: Planning by Scenario-Version

An alternative to the previous approach is to include the Scenario-Version entity also in the planning cubes, so have it in all the planning and reporting structures. This option makes the data model more complex and it is justified in the following cases:

• There is a specific requirement for multiple scenarios/versions active at the same time for the same business entity (i.e. Company A requires to have Budget and Forecast 10+2 active at the same time);
• Need for real time simulation in reporting and there is no business milestone to execute the "snapshot" as explained above.

This approach gives more flexibility and allows to answer the above complex requirements. Moreover, it has the following advantages:

• PRO - Reporting is easier to configure from a user standpoint because it involves less cubes; i.e. reporting is done directly on the “planning cubes” which are already by Scenario/Version
• PRO - It can be more easily adapted if the customer process becomes more complex and, for example, in the future they want to plan on different scenarios at the same time
• PRO - Users can look back at the conditions and drivers that produced the final result, because the entire process is stored.

However, when opting for this approach we must consider the following side effects:

• CON - More complex and slow planning cubes, this is because we increase the dimensionality of these structures;
• CON - Initialization always necessary and more complex because all data resides in the same cube(s);
• CON - Reporting layer and Planning layer share the same structures which is riskier in case of errors and data loss;
• CON - More difficult to archive historical data.

3.4 Initialization process

This last paragraph is about the initialization process itself. As described above this process is the start-up of a Scenario/version with relevant data. Every initialization process can be fundamentally different from each other, so there are not so many common best practices to provide . However, you can find here below some best practices when setting up the process:

• Scenario version from/to: very often the starting point of a new planning exercise is a previous one in combination with Actual past data; it is best practice to always log the action executed, so that is very clear how the process was executed and which are the basic assumptions of the data presented to end users;
• Use of temporary cubes: technically the procedures temporary cubes are very suited for this kind of processes which are mostly about copying data from one cube to another and applying specific transformation rules;
• Driver-based and simulations: most of the time the initialization executes also simulations; this is done by applying new parameters and setups to the reference dataset to obtain the new planning scenario/version; the best practice here is to always make it a step by step and show to the user the driver/parameters used to initialize the new value; this allows to clearly show to the user how the dataset has been generated.