5 Best practices for Anaplan sustainability
This article covers material I presented during an Anaplan User Group session in 2021. The module snapshots are from prior to my transition to the Anaplan UX for visualization outputs.
As someone who started off as an Anaplan implementation consultant and then moved on to manage a tenured Anaplan deployment within a corporation, the perspective and priorities are different for each role when it comes to sustainability.
As a consultant, you’re typically building out an Anaplan use case from scratch and have a clear go-live date detailed in the statement of work. Once the project is finished, you move on to the next project.
After shifting to an internal manager of Anaplan, those clear goal posts go away and it becomes harder to track progress and milestones. While it’s possible to get all users trained and processes documented at a given point in time, the likelihood is that many users will churn and processes will also change.
For these reasons, building a model with sustainability in mind requires a different mindset and a higher standard of delivery to promote the transparency and transferability of your work. Below are recommendations for internal Anaplan managers to help promote the long-term sustainability of your Anaplan deployment.
1. Development tags
If you poke around a tenured Anaplan deployment, even ones with the strictest controls, it’s common to see line items with the “DEV_” or “TEST_” prefix within the production environment. While having these in your model presents an obvious risk, there are a number of reasons why this happens:
- Convenience factor. Creating additional DEV or TEST line items is one of the easiest ways to perform scenario analysis, without ever needing to touch lists or versions. And in most cases, you’ll immediately be able to compare your new DEV line items to the current live calculations. Additionally, the prefix approach is accommodating in that you can add them to almost any component of Anaplan (line items, lists, list items, saved views, modules, subsets, import actions, etc.).
- Ability to isolate. Assuming you have an experienced Anaplanner on your team who is familiar with your model and use case, it’s not difficult to isolate the impact of these tags by adding a glaring all-caps prefix to the DEV items and making sure none of the production line items reference the new DEV items.
- Anaplan’s value proposition. Part of Anaplan’s core value proposition is being able to provide the flexibility and immediacy of Excel, while still maintaining the higher standards of an Enterprise Resource Planning tool. Assuming you have a way to manage the overall process, leveraging development tags is a way to achieve that balance.
I know some only allow development tags in a DEV or Test model separate from production. Consider allowing development tags in your model only if you manage and track them closely. You can do so with a simple list and module. 
Other items to keep in mind around development tag management:
-
Establish rules and guidelines. If you have certain modules or lists where you absolutely do not want development tags to be created, confirm these restrictions with your team. For example, you could have a very large module in terms of cell count, where the addition of “DEV_” line items would significantly increase the overall size of your model.
-
Tag owners. Ensure that each development tag has a specific owner so that you have someone to follow up with to track its progress, identify blockers, and push the final changes through to production.
-
Prioritize clean up. During a busy planning cycle, it’s very easy to overlook this step. But we all know that having extraneous “DEV_” line items in your model represents a risk to your Anaplan deployment long term, even if they are not directly impacting production line items. Make sure you track your development tags to completion and remove them from your model when done.
2. Restore points with baselines
Regardless of how experienced you are with Anaplan, at some point during your model building career you’ll run into a situation where it’s difficult to fully understand the downstream impact of a proposed change. This can come from inheriting a model from another person, working within an intense planning cycle where you don’t have significant time allocated for testing, or simply being asked to make a complex structural change to a tenured model.
Leveraging restore points with baselines is a simple way to assess the impact of changes you’ve made to the model, while also providing a safety net of an “undo button” (the restore point) if you notice unintended outcomes after your changes.
Creating a restore point interface is simple:
- Restore point input. Create an input cell for your restore point that is lengthy and contains all the context you want to capture. With a single lengthy input, it’s much easier to find that specific change in the model history if and when you need to restore the model.
- Context values. You should have the context values calculate automatically based on the restore point input, rather than having multiple cell inputs. This is done through simple text formulas.
- Baseline references. Choose references that cover all areas that could possibly be impacted by your changes. Immediately after creating the restore point, hardcode these baseline reference values.
Once you have these elements in place, it’s simple to create your restore point, snapshot your baseline values, make your proposed change, and check the interface for variances.
Two final notes about restore points:
Last resort. Performing a model restore in your production environment isn’t something you should take lightly. If you have a large number of contributors in various time zones, performing a model restore could potentially erase several hours of work from different teams. While I like having restore points easily identifiable in my change history, I view actually “restoring the model” as more of a last resort and will try all other approaches first. If you do end up in a situation where the model restore is necessary, clearly communicate the implications with your team.
DEV model. A simple way to remove the constraints of restoring your model is to create a DEV copy of your model, ideally in a DEV workspace that your regular model contributors don’t have access to. Once there, you’ll have more freedom to make changes and even restore your model without affecting the work of your model contributors.
3. Use custom versioning lists
Versions is one of the core functionalities that we learn about during our initial ramp-up process. I remember how heavily it was emphasized during my first demo of the tool. Despite its prominence as an Anaplan feature, best practice guidance has shifted away from using Anaplan’s base “versions” functionality and instead using “custom versioning lists.” Essentially, you are migrating all your versioning needs away from the built-in functionality over to a set of lists. From the perspective of sustainability, there are several reasons to do this:
- Model transparency. Most models will eventually need to leverage more than one use type of “versions” to cover the scope of the use case. In the example shown, in addition to the primary planning calculations, we also need versioning capabilities for the top-down target and forecast scenarios.
- Model relevance. When you begin the build of a model, it’s generally clear what Anaplan’s generic “versions” functionality should apply to. In the example above, it would be our primary plan. However, over time as the model grows and evolves, there is a likelihood that this default version will apply to fewer and fewer modules. For an aged model, it can be confusing to new users to see the core versions functionality only applied to a small set of modules.
- Model simplicity. I’ve lost count of the number of times I’ve seen Anaplan’s generic “versions” applied to a module that didn’t need it. Because it is so foundational to Anaplan’s functionality, newer model builders tend to overestimate its relevance and apply it to modules unnecessarily. However, by explicitly detailing the context of the versioning to your model builders, with custom versioning lists, you make your model more transparent and reduce the likelihood of this mistake. A model builder is more likely to unnecessarily apply the generic “versions” to a module versus a list titled “top-down target versions.” And by not having versioning applied to modules that don’t need it, you’ll make your model simpler and smaller in size.
- Costs of using custom versioning lists. When you leverage custom versioning lists, you are still able to “bulk copy” across the list members within them, and you do so through the standard versions menu. However, any switchover logic you were intending you’ll have to build in manually. Additionally, you lose the ability to leverage Anaplan’s built-in version formulas, such as “ISCURRENTVERSION” or “PREVIOUSVERSION.” In general, these inconveniences are minor relative to the benefits of using custom versioning lists.
4. Build a scoping matrix
The Anaplan scoping matrix is a long-term planning framework that will help you manage your Anaplan deployment as it grows. The process of creating a scoping matrix is simple. List all of your Anaplan models in a matrix with Anaplan’s key features listed across the top. Then fill in any intersections where you are using that particular feature within that model. Below is a dummy example. Note that the Anaplan features you decide to track will vary between customers and use cases.
Building and maintaining a scoping matrix will provide a number of benefits to your organization:
- Driving simplicity. Every Anaplan feature you leverage represents additional cost of ownership, in terms of both ramp and maintenance. If you see a feature that is not critical or was put in for test purposes, you should consider removing it to simplify your deployment and reduce your overall cost of ownership.
- Building expertise. On the other hand, if you have a feature that is critical to deployment (for example, custom versioning lists), consider leveraging it in more than one use case to build up expertise among model builders.
- Platform updates. As new Anaplan features are released, test and get feedback from your builders and users. Use the scoping matrix to assess their benefits and periodically re-evaluate which features you want to maintain.
- Model handoffs. Whenever you need to hand off a use case to a team member, the scoping matrix provides that person insight in terms of the expected workload and any ramp areas they may need to invest in.
Most Solution Managers will agree that simpler models are more sustainable. An active approach is required to encourage model simplicity. The Anaplan scoping matrix is a great tool to help you drive towards that simplicity.
5. Import action maintenance
Poor import action maintenance is one of the biggest issues affecting model sustainability. We know we should take an active approach in managing and updating our Anaplan actions. Any tenured model runs the risk of eventually looking like the example on the left rather than the cleaned-up example on the right.
There are a few reasons why models end up having trouble with managing import actions:
- Autosave of all imports. Anaplan saves every import action you perform, even if it’s a one-time CSV upload. Over time, after several model updates and builder handoffs, the import action list can get messy if it’s not maintained.
- Lack of a standard naming convention. You’re about to import into a list — do you prefix the action with “LIST BUILD,” “LIST APPEND,” or “LIST CREATE”? The fact that a platform-wide standard doesn’t exist can make it difficult to enforce a consistent rule set, even among your own model builders.
- Cleanup process. Deleting actions can be an intimidating process for less experienced model builders. Deleting an action could potentially break things in your model, but leaving an action in can’t directly break anything, so the tendency is to err on the side of caution and leave more actions around than needed.
Import action maintenance is probably one of the least enjoyable processes of managing an Anaplan deployment, but maintaining a rigid discipline around import actions is easier than working on a model with its action list in disrepair. Below are a handful of tips that can help you:
- Required process mapping. Set a rule with model builders that all repeatable actions must be mapped to a process. Mapping an action to a process is good for organization and prevents the action from being deleted.
- Regular action cleanup. Whether it’s a daily scrum or a weekly PMO, make sure you have action cleanup on your team’s agenda. If your entire team is aligned on making this a priority, you have a greater chance of success.
- Create a pending deletion section. If you create a pending deletion section at the bottom of your import action list, any ad hoc import will show up there. It’s a simple way to queue your action cleanup discussions.
- Use a defined naming convention. Naming conventions will vary between companies, use cases, and implementation vendors. Make sure you establish one and communicate it with model builders. Below are examples of the prefixes I’ve used:
- LIST APPEND: intended to add additional items to a list.
- LIST HIERARCHY: intended to update the parent value for list items.
- LIST SUBSET: intended to update whether or not list items are included in a subset.
- MOD DATA: general category for any import with the primary intent of feeding data into a module.
- INPUT RESET: any import intended to reset an input value to either zero, blank, or other default value.
Parting thoughts
Making your Anaplan deployment more sustainable may seem like a steep hill to climb, especially if you have a complex use case, with a long tenure and the input of several different model builders. But for those of us who’ve used the platform for a long time, we know sustainability is a requirement for Anaplan to achieve its full value proposition. Your Anaplan model should be making your life easier and simpler, and it shouldn’t feel like you’re dealing with the same problems every year. It takes hard work, discipline, and ultimately a few iterations to get things moving in the right direction. By focusing on sustainability early and often, you’ll cultivate a better Anaplan experience for model builders and end users.
What best practices would you add to this list? Leave a comment!
About the author: Matthew Kuo
Matthew Kuo is a Master Anaplanner who has used Anaplan for nine years. He has spent the majority of his Anaplan career working in the high-tech industry working on sales operations, finance, marketing, and HR use cases.
Comments
-
Great article Matthew. Best practice IMHO. I implement all your strategies and I always get a pat on the back from the next person that takes over my models.
2 -
Well precise article @matthewkuo
1 -
Very insightful, thanks @matthewkuo! #5 is my personal pet peeve, it can be so frustrating to unpack actions that have not been well maintained. As they say cleanliness is next to godliness.
1 -
Thank you for sharing another piece of quality thought leadership, @matthewkuo! Your points noting the importance of sustainability in model development and architecture are spot-on and are so relevant for all model builders to consider!
1
