Hi there,
Can someone please provide step by step instructions on how to develop a Model Schema per project (DISCO base).
Thanks in advance,
Siva.
Hello Siva,
As far as I'm aware, there isn't a one-size-fits-all set of instructions for developing a model schema in Anaplan. However, I’d be happy to share the steps I typically follow before starting model development, which may be useful to you.
Schedule a Meeting with Key Stakeholders
I usually begin by arranging a meeting with key users or the Product Manager. During this meeting, the goal is to create a data flow schema that represents the general structure of the project. This includes identifying inputs, outputs, and the most important calculations that need to be captured in the model.
Map Dimensions and Requirements
In this meeting, I also work to investigate the dimensions (lists) that should be included for manual inputs, data imports, calculations, and outputs. This step ensures that the model design reflects the necessary business hierarchies and reporting structures.
Align with the DISCO Methodology
Once the initial data flow schema is established, I adjust it to fit the DISCO (Data, Inputs, System, Calculations, Outputs) framework, which helps ensure the model is structured efficiently:
This approach provides a clear structure for developing the Anaplan model, ensuring that every aspect is well-thought-out and aligned with the business requirements.
Feel free to reach out if you need further clarification or assistance. Happy modeling!
Thanks, Konstantin
This article helps
OEG Best Practice: The model design process — Anaplan Community
Hi Siva
As a solution architect this is just about clarifying the high level design prior to starting build. This both helps pre-empt potential issues and provides a framework and guide for everyone involved in the build allow people to work on different elements with confidence they will join up.
It you have a good business process flow and user stories it should be straightforward
It is just a flow diagram (lucidchart and VISEO are ideal but excel also work well) showing the key modules in the model and how they are linked. Similar to the Model Map.
For each module it is useful to include the key metrics/line items and the dimensionality/granularity of the module. This is useful as a logical check on the flow of data through the model, if a receiving module has more granularity than the source there could be an issue.
I also like to include a brief description of the purpose of the module (this can be transferred to the notes against the module in anaplan for self documentation)
You can applied the disco methodology using colours and/or naming conventions
It is also helpful to show which modules receive loaded data and the source of that data
Hope this helps
Seb
Thank you everyone for jumping and providing clarification.
Now I faced below warning But I cannot find any delete action for those users I don't need anymore Can I have any action to solve this warning?
I have 2 lists used in modelling, In Input module I'm using subset of territories from Country List and subset of Regions from Flat list. But in Output module,Its reversed, I'm using subset of regions from Country list and subset of territories from flat list.How to derive the numbers from input to output module. I do have…
If anyone is aware of idea exchange ideas that are currently being evaluated by the product team, if you don't mind linking them here, would love to give them an upvote. Thanks!