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:
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.
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.
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.
Verify the process with the end-users and Subject Matter Experts (SME) and make any corrections.
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
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.
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.
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?
So glad this is part of the L3 experience. Just so you know the link in the L3 part 1.1 (designing the model schema) takes you half way down the page. I would recommend taking the student to the top of the page. In any event, very glad this content is available!
