Simple, logical and efficient Anaplan models contain hierarchies which are natural, intuitive and robust. Why then do we see so many that are overextended, too long and clunky?
Hierarchies in your Anaplan modelling allow your to formalise relationships between lists and dimensions. They enable you to declare and solidify parent and child mappings between adjacent dimensions and use these structures to create far more intuitive modelling processes, data flows and end user reporting.
What have we learnt that causes FP&A leaders to loose their sh!t over their Anaplan modelling?
After more model health checks than we can remember and dozens of interviews with prospective, current and future clients these are the things that really grind their gears when it comes to their Anaplan projects.
🔸 Excessive mappings tables
🔸 Over extended core hierarchies
🔸 Lack of dimensionality
🔸 Flat reporting
🔸 Counterintuitive modelling structures
Twins are pretty rare. But we find they come in handy in our Anaplan modelling.
Twin lists or sometimes referred to as aliases or parallel lists are multiple individual lists which share a set of common properties and are therefore connected.
We have found that the most common uses for twin lists are the following…
When building your lists and hierarchies in Anaplan what types should you use - flat, ragged or balanced?
When building your lists and hierarchies in Anaplan what types should you use - flat, ragged or balanced?
All of them!
What is our favourite, most versatile Anaplan modelling feature? Line Item Subsets
What is our favourite, most versatile Anaplan modelling feature? Line item subsets...
90% of all the Anaplan modelling you will ever have to design can be accomplished with SUM, LOOKUP and IF THEN ELSE - what about the others?
If 90% of all the Anaplan modelling you will ever have to design can be accomplished with SUM, LOOKUP and IF THEN ELSE then what exotic beauties are possible if you max out using the other 10%?