The model design process

100% helpful (9/9)


NOTE: The following information is also attached as a PDF for downloading and using off-line.



The process of designing a model will help you:

  • Understand the customer’s problem more completely
  • Bring to light any incorrect assumptions you may have made, allowing for correction before building begins
  • Provide the big picture view for building. (If you were working on an assembly line building fenders, wouldn’t it be helpful to see what the entire car looked like?)



Understand the requirements and the customer’s technical ecosystem when designing a model

When you begin a project, gather information and requirements using a number of tools. These include:

  • Statement of Work (SOW): Definition of the project scope and project objectives/high level requirements
  • Project Manifesto: Goal of the project – big picture view of what needs to be accomplished
  • IT ecosystem: Which systems will provide data to the model and which systems will receive data from the model? What is the Anaplan piece of the ecosystem?
  • Current business process: If the current process isn’t working, it needs to be fixed before design can start.
  • Business logic: What key pieces of business logic will be included in the model?
  •  Is a distributed model needed?
    • High user concurrency
    • Security where the need is a separate model
    • Regional differences that are better handled by a separate model
  • Is the organization using ALM, requiring split or similar models to effectively manage development, testing, deployment, and maintenance of applications? (This functionality requires a premium subscription or above.)
  • User stories: These have been written by the client—more specifically, by the subject matter experts (SMEs) who will be using the model.


Why do this step?

To solve a problem, you must completely understand the current situation. Performing this step provides this information and the first steps toward the solution.


Results of this step:

  • Understand the goal of the project
  • Know the organizational structure and reporting relationships (hierarchies)
  • Know where data is coming from and have an idea of how much data clean-up might be needed
    • If any of the data is organized into categories (for example, product families) or what data relationships exist that need to be carried through to the model (for example, salespeople only sell certain products)
    • What lists currently exist and where are they are housed
  • Know which systems the model will either import from or export to
  • Know what security measures are expected
  • Know what time and version settings are needed


Document the user experience

Front to back design has been identified as the preferred method for model design. This approach puts the focus on the end user experience. We want that experience to align with the process so users can easily adapt to the model. During this step focus on:

  • User roles. Who are the users?
  • Identifing the business process that will be done in Anaplan.
  • Reviewing and documenting the process for each role.
  • The main steps. If available, utilize user stories to map the process. You can document this in any way that works for you. Here is a step-by-step process you can try:
  1. What are the start and end points of the process?
  2. What is the result or output of the process? What does each role need to see/do in the process?
  3. What are the process inputs and where do they come from?
  4. What are the activities the user needs to engage in? Verb/object—approve request, enter sales amount, etc. Do not organize during this step. Use post-its to capture them.
  5. Take the activities from step 4 and put them in the correct sequence.
  6. Are there different roles for any of these activities? If no, continue with step 8. If yes, assign a role to each activity.
  7. Transcribe process using PowerPoint® or Lucid charts. If there are multiple roles, use swim lanes to identify the roles.
  8. Check with SMEs to ensure accuracy.
  • Once the user process has been mapped out, do a high level design of the dashboards
    • Include: Information needed
      • What data does the user need to see?
      • What the user is expected to do or decisions that the user makes
    • Share the dashboards with the SMEs. Does the process flow align?


Why do this step? 

This is probably the most important step in the model design process. It may seem as though it is too early to think about the user experience, but ultimately the information or data that the user needs to make a good business decision is what drives the entire structure of the model.

On some projects, you may be working with a project manager or a business consultant to flesh out the business process for the user. You may have user stories, or it may be that you are working on design earlier in the process and the user stories haven’t been written. In any case, identify the user roles, the business process that will be completed in Anaplan, and create a high level design of the dashboards. Verify those dashboards with the users to ensure that you have the correct starting point for the next step.


Results of this step:

  • List of user roles
  • Process steps for each user role
  • High level dashboard design for each user role


Use the designed dashboards to determine what output modules are necessary

Here are some questions to help you think through the definition of your output modules:

  • What information (and in what format) does the user need to make a decision?
  • If the dashboard is for reporting purposes, what information is required?
  • If the module is to be used to add data, what data will be added and how will it be used?
  • Are there modules that will serve to move data to another system? What data and in what format is necessary?


Why do this step?

These modules are necessary for supporting the dashboards or exporting to another system. This is what should guide your design—all of the inputs and drivers added to the design are added with the purpose of providing these output modules with the information needed for the dashboards or export.


Results of this step:

  • List of outputs and desired format needed for each dashboard


Determine what modules are needed to transform inputs to the data needed for outputs

Typically, the data at the input stage requires some transformation. This is where business rules, logic, and/or formulas come into play:

  • Some modules will be used to translate data from the data hub. Data is imported into the data hub without properties, and modules are used to import the properties. Reconciliation of items takes place before importing the data into the spoke model.
  • These are driver modules that include business logic, rules. 


Why do this step? 

  • Your model must translate data from the input to what is needed for the output 


Results of this step:

  • Business rules/calculations needed


Create a model schema

You can whiteboard your schema, but at some point in your design process, your schema must be captured in an electronic format. It is one of the required pieces of documentation for the project and is also used during the Model Design Check-in, where a peer checks over your model and provides feedback. 

  • Identify the inputs, outputs, and drivers for each functional area
  • Identify the lists used in each functional area
  • Show the data flow between the functional areas
  • Identify time and versions where appropriate


Why do this step?  

It is required as part of The Anaplan Way process. You will build your model design skills by participating in a Model Design Check-in, which allows you to talk through the tougher parts of design with a peer.

More importantly, designing your model using a schema means that you must think through all of the information you have about the current situation, how it all ties together, and how you will get to that experience that meets the exact needs of the end user without fuss or bother. 


Result of this step:

  • Model schema that provides the big picture view of the solution. It should include imports from other systems or flat files, the modules or functional areas that are needed to take the data from current state to what is needed to support the dashboards that were identified in Step 2. Time and versions should be noted where required. Include the lists that will be used in the functional areas/modules. 
  • Your schema will be used to communicate your design to the customer, model builders, and others. While you do not need to include calculations and business logic in the schema, it is important that you understand the state of the data going into a module, the changes or calculations that are performed in the module and the state of the data leaving the module, so that you can effectively explain the schema to others.

 For more information, check out 351 Schemas.  This 10 to 15 minute course provides basic information about creating a model schema.

Verify that the schema aligns with basic design principles

When your schema is complete, give it a final check to ensure:

  • It is simple.
    • “Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.”  ― Ernst F. Schumacher
    • “Design should be easy in the sense that every step should be obviously and clearly identifiable. Simplify elements to make change simple so you can manage the technical risk.” — Kent Beck
  • The model aligns with the manifesto.
  • The business process is defined and works well within the model.
Version history
Revision #:
13 of 13
Last update:
‎02-26-2018 10:46 AM
Updated by: