Tips on building out a new model
Author: Andrew Tye is a Certified Master Anaplanner and Anaplan Process Developer at Aviva.
As a new model builder one of the more daunting prospects is beginning the build of a brand new model. You’ve completed the various training courses, supported an existing build, and maybe have done some small enhancements to an existing model.
At one point you’ll be given the opportunity to commence a build from scratch. You’ll understand the best practices (PLANS, DISCO, and of course The Planual). The user stories have been gathered, ranked, and broken down into the various sprints needed. Plus, model dataflows and how end users will ultimately interact with the model that’s being built. Without this at the start, getting the sequencing right can result in what can be perceived to be important modules getting built out of step with the overall process.
To ensure a successful build and deployment, how should you go about the potentially daunting task of completing those user stories?
Option 1: Build out the lists, modules (input, system, calculations, outputs), actions (imports, exports), UX pages in line with each user story plus the appropriate DCA, selective access. This is likely to be the option you pick first for a variety of reasons.
- It gives end users visibility of what’s being built early in the project, giving them the confidence of direction and how the various elements are going to come together
- It allows you to be comfortable within the project, building each element step by step like a giant jigsaw puzzle.
However, this could lead to possible dead-ends and a web of complexity which future model builders may not thank you for.
Option 2: This is the option I think works really well. Think about each area in the round. This can be a more difficult way of building particularly from an engagement piece because for quite a while there won’t really be anything worth showing to stakeholders and end users. But it can lead to a more rounded build as you’re not needing to go back round the loop several times, potentially leading to missed or duplicated items.
This layering approach to the model build enables a clean calculation build to enable unit testing before adding on the complexity of DCA, User Roles, and Selective Access layers.
Let’s dive into option two…
Putting DISCO aside for the moment, go through all the relevant lists — be it hierarchy, numbered, flat. Identify all relevant properties for each list, potentially creating more lists. Then build out the system modules for these lists. What this will help with is the calculation and output modules as the appropriate lookup and sum references will be there ready and waiting and all the structure is there ready for you.
Then it’s back to the D of DISCO — the system generated information either summarized or transactional level. Is it coming into the model already dimensioned into the actuals version where end users input forecast numbers and switchover is being utilised or into separate modules which the calculation modules reference.
The use of switchover will reduce the amount of data being stored within your model but how the data is being brought together will only exist within the imports that are to be built which may not help from an audit-ability perspective.
There may already be a Data Hub in place within the Anaplan ecosystem and that is being leveraged, in which case all of those property mappings and hierarchies will already be in place to be utilized. As well as the question of data audit-ability. Again, don’t worry about the imports for the moment.
Move into building the appropriate App pages that support the data, property modules. Showcasing the foundations of the model will give stakeholders that view of how the metadata fits together.
From here it’s time to create the calculation modules based on the process map that’s been drawn up to support the user stories and the overall model requirement. Without this knowledge of how the modules fit together this element could end up in a muddle.
You’ll want to make sure that you’re meeting the [calc once, ref many] Planual reference and being aware of how future modules use the information within the module will inform how those initial data and user input modules are built.
As the calculation modules are put together try to minimize the use of complex IF statements, this will aid with the validation of calculations through the model. It is preferable to have all the elements separated out that way the calculation engine will be most efficient and enable a fast end user experience.
Why does this approach works well? Instead of building the most important elements per how the user personas perceive them, it’s built on a logical flow of calculations.
Does the model begin with a top-down approach and then built up based on detail or the other way around? Knowing this will help the build especially as the output stage of the build approaches.
From the user story gathering phase there’ll be a good view of how those reporting pages will work. Now that all the calculation modules have been built the task of putting together those final views and good report outputs begins.
Lean into the use Management Reports strongly — boards are great to do the analysis of what’s going on with the forecast but a crisp, concise view using this page type will really add an edge to the model that’s been built.
What’s now been built is a clean model that meets enough of the user stories to begin testing. At this point end users will want to make sure inputs + calculations = outputs. After this the work around lists having selective access, user roles having access to the right App pages and amending list contents can commence. Have found that with the UX and the ability to assign pages to user roles means that there’s little need to differentiate access at a module level across user roles. Plus by not restricting access transparency within the model is maintained.
As a final piece, if available — overlay Workflow across the model. The model will have been built in a logical order with UX pages that align to the end-to-end process and should be easy to deploy following completion of testing.
Let me know your thoughts on how you go about building out models. What top tips would you add that result in a successful delivery?
Comments
-
Thanks for sharing. I always believed that everything starts with clear master data and data.
1 -
Really curious to know more about your experience with creating App pages that support the data and property modules. It makes sense to surface to end users what the foundational data look like, but isn't something I've thought to do. Can you share an example or two of where this has added value to your builds?
1 -
amazing!
0 -
Great article @andrewtye - I think the N in PLANS is very important in planning a build and deciding what O in DISCO you need; start with what output you need to achieve and build the minimum needed to reach that. Not always possible though, sometimes building in Anaplan is a process of discovery and working out what is possible when this level of planning hasn't been done before!
0
