Hands-On Example: Defining Submodels

Modeling projects in Valsight often faces the challenge of decomposing a complex logic into the right submodels for the specific usecase. In this article, we share an example and walk through the considerations of the structure and associated dimensionality.

In general, before defining the submodel strucutre, you should have a clear idea who is going to use the model and the overall usecase. A model that is only used for simulation by a single person is easier to structure than a model that is suitable for a multi-user planning process.

In this article, we will outline the model structure for a model that is suitable for multi-user usage.

Proposed Submodel Structure

Submodel Structure

The proposed submodel structure - Arrows indicate the "has submodel" relationship, hence they define data access and not data flow (data flow = opposite directection of arrows)

Let's work through this from bottom to top, starting with the data sources.

Our recommendation is to connect data sources to only one model, as it makes the management and updating much easier in the long run. Data sources can even be configured to be attached to one model, which enforces that they are not used anywhere else.

The 400 Data model now simply "pulls the data in". All information that is used should be connected to a single node in the model. Typically you do simple data cleaning tasks such as mulitply with -1 or 1000 in this model layer. The data model often contains just a few not connected nodes. This will make it easier in the long run to understand which data is used where. In an ideal world, the "400 Data" model only contains actual (or factual) data, such as the last actuals, or - if you want to use a Forecast or Plan as basis for the simulation - then this. The important distinction between all other models is, that the "400 Data" model should not contain any datapoints in the future, it mearly defines the basis for the simulation.

The 300 Premises model is the first where we may see data about the future. It contains nodes that are used as drivers in all other models, such as an inflation rate. Here it is important, that all data is only brought into the simulation through assumptions in the scenario manager. You may, however, work with multiple data scenarios to include testdata, for meaningful data previews. With the example of our inflation: You would enter a 0% inflation in the data scenario and onlyset it to 2% in the scenario manager. You can, however, add a second data scenario, where you enter the 2% directly so that simulation on the data scenario produce meaningful output in the data preview. To facitlitate the planning process later on, each node in the premises model should have at least the "business model dimension" which basically is the Org or Business model dimension by which the 200 - Layer is split up.

The 20X Models use base data from the 400 and 300 models to define business model specific logic. They typically define how base data (no info about future) and premises (info about future) are combined to create a simulated outcome. Additional drivers that are only relevant for this business model can be modeled here. It is advisable to retain the Org dimension in this model, as it eases the combination in the next layer. Alternativly the data can be pulled into the next layer with the expand single functionality.

The 100 P&L model defines the entry point for our workspaces. It creates a combined view to allow us to access all data. Depending on your specific needs, this model can be either empty, or very simple, e.g. just combining revenues and costs from all different submodels.

The names and numbers used are not mandatory and only used to make the models a) sortable and b) clearer which models are on the same layer. You may add additional layers if it helps to structure your usecase. Many prefer, for example, to use multiple models in the premises layer to differentiate between different drivers.


Summary - Submodels

Model Layer Purpose Timeframe Dimensionality (minmal)
100 P&L Combination of all specific business modells Simulation Horizon Time, Org, others
20x Business Models Define Specific business logic Simulation Horizon Time, Org, others
300 Premises Define Placeholders for generic drivers Simulation Horizon Time, Org, others
400 Data Pull Data into the model Base Year Time


Recommendations for interfaces between models, based on examples

Model Layer

Dimensionality (min) Dimensionality typical Usecase Example
100 P&L


Time, Org
Interface Revenue Cost Time, Org
Revenue [ 2018, Business Unit A, 50 ; 2019, Business Unit A, 55 ; 2020, Business Unit A, 60 ; ....]
20x Business Models


Time, Org, Business Model specific Dimensions, for example
Interface Inflation Market Growth Time, Org
Inflation [ 2018, Business Unit A, 0 ; 2019, Business Unit A, 0 ; 2020, Business Unit A, 0 ; ....]
300 Premises


Time, Org and Dimensions valid for all Business Models, such as Countries
Interface Revenue (Base) Sold Volume (Base) Time, Org
Revenue [ 2018, Business Unit A, Product X, 100]
400 Data


Time, Org, Technical Dimensions to select/filter/clean data
Data Layer Excel Files Databases Usually time and Org

(warning) We include the Org level in each data layer, because it eases the implementation of data permission on this dimension later on


Implementing the Planning Process with Workspaces and Scenario Sharing

Adding data about upcoming projects and assumptions is done in the Workspace layer. Following the submodel structure from above, we define a workspace for the premises, one for each planning entity and one for the P&L view. The following table shows the association to the models

Model Layer Workspace Access
100 P&L 100 P&L Core users
20X

One Workspace for each model, or multiple per model.

If you, for example, have only one model for the product business, but still have multiple entities that enter planning data for products, you can create multiple workspaces per model. Access can be differentiated with workspace filters & data permissions.

Planning Users
300 Premises 300 Premises, one workspace to enter assumptions about premises. Core users
Process Time (1) Start of Planning Process (2) Kickoff Data Entry in Planning Entities (3) "Doing" of Data Entry, Parallel in the organization. (4) Start of Consolidation Phase (5) Discussions
Process Step Defining Premises and Targets Handover Planning Entities Handover Consolidate Scenarios
Users Core user for planning process Core user for planning process Each Planning User (1) Each Planning User, (2) Core user for planning process Core user for planning process
Tasks
  • Lock project
  • Define assumptions about basic premises on the Workspace WS300

  • Share the Scenario in the 300 Workspace
  • Include the shared scenario in each entities workspace via "Scenario assumptions"


  • In each entities Workspace (or business model specific workspace), enter the specific assumptions for one or many scenarios.
  1. In each entities Workspace, share the scenarios that should be available to the consolidated group view.
  2. In the 100 P&L Workspace, include all shared scenarios
  • Simulate each's business units scenarios
  • Perform simple changes of all underlying assumptions by adding Simulation line items as delta

Was this helpful?

Yes | Somewhat | No