10 Anaplan Best Practices To Optimize Your Model

As an Anaplan Model Builder, few things match the thrill as when you build your Anaplan model for planning. You already feel the itch to deploy it. But wait! Now is the time to Optimize! Optimize! Optimize!

It cannot be stressed enough - optimizing your models is a very important step as an Anaplan model builder to improve your Anaplan model performance, save on license costs, bring greater adoption of the solution and thus drive improved ROI on your Anaplan investments.

Following are a few best practices that we have compiled, based on our experience in Anaplan implementations, on how to optimize your Anaplan model for best performance and cost savings.

The first Anaplan best practice that we are going to talk about is the DISCO, which adheres to the ‘L’ or LOGICAL in Anaplan’s broader PLANS framework.

PLANS is the framework or principles around which all the Anaplan models should be built. DISCO evolves from the principle that Anaplan’s model performance is optimized if the calculations are performed over the same dimensionality. Although it may not always be possible, the model should be designed in such a way that the calculations are aligned as much as possible.

This is the essence of D.I.S.C.O. As an Anaplan model builder, you need to create groups of modules that have a sole purpose, with a common structure, thus ensuring a LOGICAL split of the information within the Anaplan model. On the contrary, by combining all of the different types of structure into the same module, you will make the model difficult to comprehend, as well as create duplication and inefficiencies within calculations.

One of the most important things to consider as an Anaplan Model Builder in your model design is the correct use of time dimension. In the model settings, you have to define the model calendar which will be the base for your planning. However, it will often happen that a few of your modules will need to use time that is outside your model calendar. In such cases, always define the time ranges within those modules instead of expanding the model time scale. Every year that is added to the model calendar considerably increases the size of the model, and will leave those cells empty where these time settings are not used. Another thing to note with time ranges is that you must update them every end of the year, since they are not dynamically updated.

Do not use formulas in a daisy chain (more on Daisy Chain will be covered in the next point). A standard principle behind using formulas in Anaplan is that they should not be repeated - (formulas should be run once, and referenced multiple times), and they should not be long. Complex IF THEN ELSE formulas should be broken up, and remember to PUT THE MOST COMMON CONDITION FIRST! Another standard best practice is to not use SUM & LOOKUP in the same line item, as it usually creates performance problems. Minimize the use of SELECT function, especially with TIME because a change will be required every year. Instead, create a dimensionless module to store TIME & other SELECT values, and use LOOKUP to reference them. Lastly, if your line items use conditional formatting, then turn SUMMARY off.

Daisy chain refers to the schema in which multiple modules are linked in a serial schema to one another. While this works if your model is simple and straightforward ( unlikely!), this schema will run into inefficiencies when the different modules reference each other often for values, calculations and inputs. A daisy chain schema will create a long dependency, and formulas will have to be calculated in sequence - thus consuming unnecessary GPUs, and slowing down your model. Rather, as an Anaplan Model Builder, you should design with this principle in mind - store or calculate once and reference many times. Make sure the downstream line items are referencing a single module which has the necessary information. This will considerably improve your model efficiency.

Subsidiary views are useful in certain situations such as to show the alternative hierarchy for a dimension, but they should be used sparingly. Using too many subsidiary views in a module defeats the PLANS standards and makes it confusing to the end-user. Moving the group of related line items to a separate module rather, makes it Logical, Auditable, Sustainable and it removes duplicity.

Anaplan allows you to define properties for lists, which function similar to a line item in a module. But it is preferable to use a line item since line items make it easier to write formulas and control the summary. List properties also add to the size of the list upon loading. If your list has properties that are not regularly used in the model, Anaplan best practice is to create a system module with those properties as line items.

Subsets increases the versatility of your lists, but adding them on large lists can create performance problems. It is Anaplan best practice to create a separate list in such cases since they will add the aggregations and to the size of the whole model. Another important thing to keep in mind for an Anaplan Model Builder is that your subsets should use proper naming conventions, otherwise it will become very confusing to locate and identify them.

Include only those dimensions in your module, where the logic or data in the module demands it. Having extra dimensions will increase the size of your module, require unneeded calculations and create additional context selectors in the model UX - thus preventing end-users from getting to their desired view.

Anaplan provides a range of options for summary - SUM, AVERAGE, MIN, MAX, OPENING/ CLOSING BALANCE, etc. These are automatically applied to your line items as you create them, and can be quite useful for planning purposes. However, it is an Anaplan best practice to turn off the summary settings from the blueprint view, for those line items where SUMMARY is not needed. This will help reduce the size of the model, as well as remove unnecessary calculations that need to be done with summary.

Audit and identify which actions are not being used, and remove them. Also, identify if there are any data sources without any associated action - if there are, then they are unnecessary and should be removed from your model.

So, go ahead and check if your Anaplan model is adhering to these 10 Anaplan best practices. By optimizing your Anaplan model build for performance and costs, you will go a long way in winning over happy users and other stakeholders.

At Polestar Solutions, we are leading Anaplan partners serving multiple fortune 500 clients on their enterprise planning needs. Our team comprises highly experienced industry veterans, a team of Anaplan model builders, architects, and motivated individuals with a knack to deliver top-notch strategy and services across the globe.