An Anaplan rescue mission

daniel_bad

Author: Daniel Badura is a Certified Master Anaplanner and Senior Consultant at valantic Business Analytics GmbH.

Over the years, we have worked with clients at various stages of their Anaplan adoption journey. Some were just getting started, while others had been using it for several years and use cases. 2023 brought a new challenge: a company on the verge of abandoning Anaplan and going back to Excel-based planning. Things had not worked out with their previous arrangement.

What went wrong

There were two main issues:

1. The implementation did not match the requirements. This was in part because the internal project manager had to write the user stories without sufficient guidance. To make matters worse, she was not involved in the development phase, which led to the consultants working in relative isolation. But the problems also arose from an overly complicated version setup, resulting in the use of separate models per version.
2. The model was not built according to best practices. Calculations were slow, modules were large, and hierarchy maintenance was cumbersome.

We took a good look at their model and saw that it could be salvaged. Still, it took some convincing, because the client had been let down before. To minimize their risk, we divided the project into manageable milestones. At the end of each milestone, there was an option to halt the project if they were not satisfied.

What we did differently

Aside from getting the model to work, our main objective was to restore the client’s confidence in Anaplan. We tackled this from two angles:

1. Transparency: The previous model was a kind of “black box” and contained many of the consultants’ best guesses. By now, the client team had realized that they needed to be more involved and were eager to learn the basics of Anaplan themselves. Instead of a vendor-client relationship, we assumed a shared perspective and emphasized knowledge transfer. Not only did it lead to a better understanding of roadblocks and tradeoffs on their part, but it also enabled them to maintain the model themselves after the project was over.
2. Stability: By simplifying the version setup and redesigning the model to be in line with best practices, we made errors less frequent and easier to trace and fix.

At the start of our collaboration, the client saw their model as a kind of Hydra, where fixing one flaw caused two new ones to appear. With increased transparency and stability, we overcame this challenge. In the end, we had a model that we all could be proud of, because we built it as a team. Other departments in the company have taken notice, and we are now in talks with them about further use cases.

Conclusion

Since my first Anaplan seminar, I’ve always liked the Anaplan Way of emphasizing collaboration and knowledge transfer. It seems that this structured and transparent approach can sometimes get lost in the haze and haste of real-world projects. But as our example shows, it pays off to practice these fundamentals, and to remember the importance of working together — every step of the way.

sarahputrikag

Hi @daniel_bad thank you for this article. I also experiencing the same problem regarding the complexity of the modules that has been developed by prev consultant. This complexity causes various problems both of data and calculation then causing users to doubt the effectiveness and efficiency using Anaplan compared to spreadsheet.
From reading this article, I have hope there is a way to improve users trust in Anaplan.