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

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

Recommendations for interfaces between models, based on examples

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