D.I.S.C.O. provides a logical structure for one to use when designing Anaplan models.
What does D.I.S.C.O stand for?
This is the starting point of data flow, which supports Inputs, Calculations and Outputs. Data modules may contain the latest chart of account data, employee roster, list of opportunities or assignments, or transactional history.
It is unlikely end-users will be viewing the data directly (unless there is a requirement for transactional analysis), so one should consider the optimum dimensional structure to hold this data. Also depending on the complexity in the model build, it is best practice to have commonly used data and structures in a data hub.
In the example below, this shows transactional history, which also has filter options. This will allow the end user to undertake transactional analysis in an efficient way.
These modules are initial interaction for end users. The modules should be designed for ease of use and flexibility of calculations, and then optimised for use on dashboards. It’s best to keep all input in these modules, and end results in separate modules.
Here is an example of the inputs of the amount, price and factory vehicles produced by region and by product:
If modules differ by dimensionality, systems modules will able to align/ map structures between one another. Best practice would be to use modules and line items in preference to list properties.
Examples of System modules are:
Create a System module for each key hierarchical list and create line items for the key attributes. These should include line items for all the parents within the list. Example below shows the parent of the car and an attribute being engine size:
These are some of the key modules that are needed to link, transform and map data between modules. SUM and LOOKUP formulas should use these modules.
In the example below, this is mapping an OPEX list to a line item subset in order to map data between modules:
Time Settings Modules
The first module you should build is a time module. Anything to do with time should reside in this module, or similar modules if there are multiple granularities of time within the model. It is very likely that within calculations you will need to know which periods are historic and which are future.
Calculation modules are very different from Input modules. Users rarely need visibility into the detail of the calculations. These modules should be optimised for calculations.
The example below is calculating the price of a vehicle based on Region & Model:
This is the last remaining part of the DISCO approach. This is for the end user to understand what the calculations result is. This could show an output of the P&L forecasting, cash forecasting or volume planning etc. In an ideal world there should be no data flows out of these modules. Output modules can also provide an export view for the end-result to connect the flow of information to external systems that require the data.
Here is an example of an output of Revenue by Region:
Stay tuned for the next article from The Bedford Coach!