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?)

Table of Contents:


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?
  • Identifying 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:

  • A 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.
The content in this article has not been evaluated for all Anaplan implementations and may not be recommended for your specific situation.
Please consult your internal administrators prior to applying any of the ideas or steps in this article.

Hi Pam, not sure if I could find the PDF version of this article?

Hi @Alessio_Pagliano,

We've removed the attachment from this article as we've updated the content within. Feel free to bookmark the article or use the Options > Printer Friendly Page feature to print (save) the article as a PDF, if desired.

Thanks @KayneSchwarz , I'm going to review this at some point soon.

There are a couple of areas I'm particularly keen to focus on : 

- Business process. In my experience the customer often believes their process has already been reviewed and is working correctly. My first impression on the article, in this area, seems to implicitly accept that. I'd suggest to ensure more focus is spent to challenge/review/optimise the process, perhaps through a more formal system thinking approach. Back to front UX discussion and mapping the full E2E process (beyond Anaplan) should help highlighting opportunities - I'm glad to see this is being officially recommended as best practice.

- Creation of a model schema. Quite important, perhaps not as easy on big and complex projects (unless it's meant to be kept at contents level, not module and Line Item). I will take my time to review the provided links and maybe share further thoughts/questions, if that's ok.

Very interesting topic, glad to see you guys are reviewing it. Hopefully this is the type of content that will feature, with practical examples, in the Anaplan designer certification.