OEG Best Practice: The model design process

AnaplanOEG
AnaplanOEG
edited February 2023 in Best Practices

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

This process includes the following steps:

Let’s take a closer look at each of the steps, why it is important to the overall process, and the results of completing each step.

Note: This document uses the terminology end-user experience, pages, and boards when referring to dashboards.

For more information, check out Training on the new UX.

Understand the requirements and the customer’s technical ecosystem

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

Process: When you begin a project, you gather information and requirements using tools that include:

  • SOW
    • Definition of the project scope and project objectives/high-level requirements
  • Manifesto
    • Goal of the project—big picture view of what needs to be accomplished
  • IT ecosystem map
    • 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? What other Anaplan models will this model connect with?
  • Current business process definition
    • Remember that if the current process isn’t working, then it needs to be fixed before design can start.
    • The process steps should be clearly defined for any changes to an existing process or a new process. The organization should plan communication and education programs to inform and train the end-users on the process changes.
  • Business logic definition
    • What key pieces of business logic will be included in the model?
  •  Distributed model needed?
    • High user concurrency
    • Security where the need is a separate model
    • Regional differences that are better handled by a separate model
    • Model size and end-user and roles in the process. Does the input or start of a second process rely on the output of another?
    • Do the model outputs need to be real-time? Reporting and process steps should be clearly defined.
  • Is the organization using ALM 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 who will be using the model

Results:

  • Understand the goal of the project
  • Understand:
    • The organizational structure and reporting relationships (hierarchies)
    • Where data is coming from and how much data clean-up might be needed
    • What 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
    • Which systems (including other Anaplan models) the model will either import from or export to
    • What security measures are expected
    • What time and version settings are needed

Plan the end user experience for each role

Purpose: This is an important step in the model design process. Ultimately, the information or data that the end-user needs to make a good business decision is what drives the entire structure of the model.

Process: 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 a bit 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 user experience. Verify the design with the users to ensure that you have the correct starting point for the next step.

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? You may want to create a RACI matrix to identify who is responsible, who is accountable, who needs to be consulted, and who must be kept Informed.
  • Identify the business process that will be done using Anaplan
  • Review and document the process for each role, focusing on the main steps. You can document the process in any way that works for you. Here is a step-by-step process for how to document the business process: 
  1. Gather information from the end-users. For each different role, ask these questions:
    • What is the start of the process?
    • What is the result or output of the process?
    • What are the process inputs (what data are needed) and where do they come from?
    • What are the actions the user takes? Write these using a verb and an object—for example, approve the request, enter sales amount, add new hire, etc. No need to organize during this step. Use post-it notes to capture them. Keep this discussion focused on the process as it is completed most of the time.
  2. Use this information to document the process, putting the actions in the correct order. You can use any process mapping software or PowerPoint. If there are multiple roles, use swim lanes to identify the roles.
  3.  Create a timeline to map the user roles to see if there are any overlaps or dependencies that could cause concurrency issues. These are often missed because concurrency is often thought about by role, not across the whole user base.
  4. Verify the process with the end-users and Subject Matter Experts (SME) and make any corrections.
  5. Ask the end-users to sketch out what they would like to see on their pages and boards. Many processes will require multiple pages and boards. Keep this at a high level. Some questions to guide this discussion include:
    • What data do you need to see?
    • What types of charts or graphs might help you better understand the data?
    • What actions do you need to take?
    • What decisions do you make?
    • When making decisions, is there data that you need to compare?

Results:

  • List of user roles
  • Process steps for each user role
  • Timeline mapping of user roles
  • High-level page and board designs for each user role

Use the user experience design from the previous step to determine what output modules are needed in the model.

Purpose: Think D.I.S.C.O. The Output modules are needed to support the end-user experience or export to another system. This is what should guide your design – all the Input modules and Calculation modules are added with the purpose of providing these output modules with the information needed for the pages and boards or export.

Process: 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 end-user is using pages and boards for reporting purposes, what information is required?
  • Are there modules that will serve to move data to another system? What data and what format is necessary?

Results:

  • List of outputs and desired format needed for each page or board
  • Identification of how the data should be categorized on the page or board, or what hierarchies are needed. For example, employees are organized into departments, departments into business units, etc.

Identify what data is available and needed to support the output modules. Determine the data modules the model requires.

Purpose: Identify what data the model requires and where it is held. Determine the hierarchies or structures needed in the model. 

Process: Organize the data using Data modules, using each module to hold similar types of data, for example, employee, product, or sales data.  

Results:

  • Lists needed in the model
  • Hierarchies needed in the model
  • Data and where it is coming from
  • Data modules identified

Identify what inputs from end users are needed

Purpose: Planners want to be able to see how changes will affect overall results. By entering new data, planners can try different scenarios and make decisions based on data. What if manufacturing costs go up? What effect do higher shipping costs have on the bottom line?

Process: Look at the end-user experience designs from step 2 and identify the data types that end-users will be able to add or change.

Results:

  • List of pages or boards where data input is required
  • Input modules identified. These modules should not include a lot of calculations.

Determine what calculations are needed to transform source data and inputs to the data needed for outputs. Identify the calculation and systems modules needed. 

Purpose: Transform data from the Data and Input modules to the data needed for Output modules, using business rules, logic, and formulas.

Process: Some questions to use to think through what calculations are needed:

  • What is the output?
  • How should the output data be formatted?
  • What dimensionality is needed?
  • What data is available?
  • Is the source data in the same dimensionality as the output, or is it different?
    • If the dimensionality is different, what intermediate steps are needed? What Calculation or System modules are needed?
  • Will the source data need to be converted to a different data type?

Use Anapedia to locate functions. The reverse lookup page provides a list of behaviors and descriptions in plain language of many Anaplan functions. You can also use the search function in Community.

As you are thinking about the calculations needed, pay attention to functions that are used in multiple calculations. Examples might include calculations for pulling data from the current period, the parent in a product hierarchy, or pulling data from a forecast version. These can be included in Systems modules and entered once and referenced many times. Systems modules can also hold lists and list item attributes.

Also, think about how to organize the calculations into Calculation modules. Keep in mind the different types of data (for example, Revenue, Employee, Other Costs) used in the model and keep the calculations for each type together.

Results:

  • List of Calculation and System modules
  • List of possible calculations (to be tested when model building)

Using Lucid Charts (or some other tool) to create your model schema

Purpose: Provides a graphic representation of the model design that is used for communicating with the model-building team. The model schema is required documentation for the project.  

Process: Designing your model using a schema means that you must think through all the information you have about the current situation, how it all ties together, and how the model provides what is needed to meet the needs of the end-users. Begin by sketching your ideas on a whiteboard. Whiteboards are excellent collaboration tools and model design is a collaborative process. Be sure to:

  • Identify the Input, Outputs, and Calculation modules needed for each functional area.
  • Identify the Data and Systems modules needed for each functional area
    • Show the data flow between the functional areas
    • Identify time and versions where appropriate
    • Transfer the final version to an electronic format

Results:

  • 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 the current state to what is needed to support the end-user experience that was identified in step two. 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.

Final design check

Purpose: A final check of your model to ensure that it is well-designed. We recommend that you have a peer check over your model and provide feedback. It is easy to fall into using the functions you are familiar with, which may or may not be the best solution. 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 the design with a peer. This check-in is included as part of The Anaplan Way process.

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

  • You have used DISCO to organize your modules and each module has a defined purpose. Your schema has been kept 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
    • “Simple is better than complex.” –Tim Peters
  • The model aligns with the manifesto
  • The business process has been defined and works well within the model

Author Pam Polizzi.

Tagged:

Comments

  • Alessio_Pagliano
    Alessio_Pagliano

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

  • KayneSchwarz
    KayneSchwarz

    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.

  • Alessio_Pagliano
    Alessio_Pagliano

    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.

    Thanks,

    Alessio

  • Joshua.Huilar
    Joshua.Huilar

    Hi @pam_pervenanze, I'm reading through "The Anaplan Way" document and on Page 54 it states to use the "Model Design Check-in Checklist". Where can I find a copy of this?

     

    Thank you!

  • pam_pervenanze
    pam_pervenanze

    Hi Joshua,

     

    We are in the process of updating the Anaplan Way content.  Try this link:

     

     

    https://anaplan.box.com/s/qauhgibi8wcosj9xdbqn6wx28e2z59hw

     

    Best,

     

    Pam

  • EricMed
    EricMed

    It's been more than 2 years and there hasn't been an update regarding @JaredDolich comment above. The intended use of this link for "Level 3 Model Building: Schema Design - Part 1" is to help the model builder read through this page correct?

    I'm glad this content is available for additional support in learning the design structure

  • pam_pervenanze
    pam_pervenanze

    Thank you, Eric. This issue has been corrected and the link now brings you to the top of the page.

Categories