Author: Devrath Ahuja is a Certified Master Anaplanner with over six years of experience in implementing and delivering global Anaplan solutions.
As someone starting out on their Anaplan journey, sometimes user stories and the build can feel overwhelming. Have you ever looked at a user story and wondered, “Where should I even begin?” Do I create a new module, a new list, a subset, or do I already have everything I need? Don’t worry, every seasoned Anaplanner has gone through the same questions and worries as you at some point.
So how do we overcome this challenge? Well, one of the biggest learnings in my journey came from a piece of advice I got from my senior back then which was:
“Break down the task into multiple smaller sub-tasks.”
Because when you try to build everything all at once there are chances you might end up being confused and not even know where to start.
Let’s take an example of a user story from Anaplan’s L3 certification and try to break it down:
As a Regional Sales Executive, I need to be able to add an annual percentage increase “stretch goal” to the Baseline Financial Forecast to establish the Initial Country Sales Target for each country that I manage.
The percentage increase in each country’s revenue projections should be reflected across all product families and quarters of the fiscal year. For each country that I supervise, I want to be able to see the Baseline Financial Forecast values, calculated Initial Country Sales Targets, and the difference between the two values for each product family and the total of all products.
I’ll know this is complete when I can input an annual percentage increase for a country and see the Initial Country Sales Target that results and the difference between the Baseline Financial Forecast and the Initial Country Sales Target.
How do we break this down? Start by answering these 2 simple questions:
- What is the output required?
- Initial Country Sales Target
- Difference between Baseline forecast and Initial Country Sales Target
- What are the inputs?
- Annual percentage increase
In case something is unclear at this stage, revisit the user story and seek clarification, since it’s always better and worthwhile to spend some time understanding the requirement than to directly jump into build mode to avoid re-work at later stages.
Once we have the inputs & outputs clearly defined we need to answer the question:
“How are these connected?”
Remember, only think about the process and the business at this stage. Don’t go straight into solution mode!
What usually helps here is to create a process flow diagram. It could be a rough one in your mind or drawn with a pen/paper.
Once you have an answer to the above 3 questions, the flow is clear, and you can now jump into solution mode.
Remember: You do not need to replicate an excel as-is into Anaplan! You will use your understanding of Anaplan and leverage its capabilities and functionalities to provide the best solution to meet the requirements.
Elements to be considered at this stage
- Dimensions involved — Think of lists, subsets, line-item subsets
In this user story, we know the input is required Annually (Time – Year) and by Country and the output is by Quarters (Time – Quarter) and by Product Family and Country. - Source data
The % increase is on the baseline financial forecast as well as the difference is against the baseline forecast, so that becomes 1 of our data points.
Check if you already have that data somewhere in the model and if not, create a new module to import data into it. - Build
Start creating input modules, output modules, calculation modules. Add the appropriate dimension with the right level of granularity in each of them and start connecting them.
You may notice a difference in the granularity between inputs and outputs, consider if you want to aggregate the data or disaggregate it and use either native summary or Anaplan formulas accordingly.
Refer to the Planual and Anapedia at this stage to get the most appropriate and optimal formulas for your use case. In some cases, if the user story feels too complex, break individual line items into further 5-6 line items and take it step-by-step. Once you have the output, optimize it where possible. - Validate
Always test out your build. Put yourself in the shoes of the planner and follow the process flow you made earlier. Compare the output you get with the desired output. Fix any issues you encounter on the way. Compare the output at different level of summaries to ensure the calculation works (Especially useful for calculated metrics. E.g – Selling price).
Last but not the least, if you’re still unclear, ask for help. 😄 From your project team, organization CoE, or the Anaplan community!
Note: The above example considers a simple isolated user story. Building models in real-world scenarios will be much more complex and you would also need to consider connection points (to other models, modules), the UX build (this is what the end user will interact with), Security and access setup (DCA/Selective Access/Roles and access setup) and other things. As you advanceor as an experienced model builder or a solution architect, you should also spend a considerable amount of time on the scalability of the current build. Consider if you can scale this to include different versions/dimensions if required in future. Consider if the current user story has any linkages to some other user story and hence maybe needs to already be built with different considerations in mind than it would if looked at in isolation? And, all of this, will come to you as well in due time.
For now, to summarize:
- Identify the inputs and outputs from the user story
- Create a rough process flow diagram
- Identify the dimensions involved
- Identify or Import the source data
- Build empty modules with the right level of dimensionality
- Get into the world of Anaplan formulas and logics!
Bonus: Common mistakes to avoid while building a user story
- Jumping straight into building modules without understanding user story
- Ignoring subsets
- Ignoring summary settings
- Hardcoding logic instead of using mappings
- Ignoring time ranges where entire model calendar is not required
- Not following naming conventions for modules, lists, imports
- Not making use of the notes column to capture key details about the line item
What tips would you add? Leave a comment!
