Back in June, we were so fortunate to have nearly 700 people attend our live session discussing ways to avoid some of the most challenging Anaplan implementation tasks. In this blog, we summarize the top 10 as well as add a few more that were brought up by you during the session.
Discover the best ways to prevent the most common implementation mistakes. Hear how avoiding these mistakes will help accelerate deployments, bring faster adoption for end-users, and facilitate faster expansion to higher value-add use cases, among other benefits.
Top 10 Challenges Implementation Mistakes
During the live event, we discussed the following challenges:
(For examples of how to avoid them, check out our video.)
· Standing up composite hierarchies in the Data Hub
· Not using smart keys when loading transactional data into Data Hub
· Production Data and SELECT vs LOOKUPS to Central module
· IFISACTUALVERSION() vs IF SYS Time < CURRENTPERIOD()
· Early Exit on Conditionals
· Improper use of IF THEN ELSE instead of leveraging a mapping module
· Not documenting the process before building into Anaplan - very few clients have their processes mapped out. It’s important to map out the process to show business stakeholders what's being built in Anaplan.
· Simply taking the process as is and blindly building it into Anaplan without asking the question of "can this be simpler or streamlined" can cause overly complex calculation logic. Example: the client has 50 allocation methodologies; are all 50 needed? What is the 80/20 here? The solution should not be to build every possible calc into Anaplan.
Mockups / Examples
· To ensure reports and certain calculations are built properly it helps to have a mockup or example provided, in excel, PowerPoint, etc. This jelps reduce the back and forth with just words in user stories. Front to back [Anaplan Way]
· A good team is made up of the following expertise: an SME familiar with the application being built, an application modeler, a data integration modeler, a SCRUM master that can implement the Anaplan Way and has a pleasant but resolute demeanor, a project sponsor willing to help with the change management, and the Anaplan business partner. Some of these roles can be made up of one person. At least one of the modelers is a solution architect.
· Getting key members of the process and stakeholders to actively participate in testing and providing feedback from the beginning of sprint 1 is paramount to a successful implementation
Training the Customer
· Involving client model builders in the build and ensuring they are developing the skillset to run, enhance, and expand the model and entire connected planning journey is as important as building the model. Things change and enhancements come up - the client is investing not only in the Anaplan tool but also their resources to help nurture the tool.
· Underestimating the importance of change management and leading with the "if we build it, they will use it" mentality can derail the project, even if the model is built perfectly.
The Top Additional Challenges We Heard From You
We had so many contributions, suggestions, and ideas from you that we wanted to share some of the most mentioned in this blog post.
Data integration expertise
This topic came up a lot most notably because the current certifications only lightly touch upon the best practices for data integration. We all learned in the Anaplan Way certification course, and it's true, that 40-50% of the effort will be data integration. There's much more involved than loading data. The same data must be cleansed, transformed, staged, audited, and synchronized with the spoke applications.
The implementation mistake is to assume the customer or the IT team will handle it. In our experience, what typically happens is that the modeling team manually loads the data successfully but doesn’t go back to cleanse it or automate it. This unfortunately leads to project delays.
Filling the bucket
Short on time? The project was negotiated as a 6-week project that probably should take 8 or 10? A typical mistake is to skip the Anaplan Way processes, particularly, the collection of the user stories and having them prioritized, and having their respective effort estimated. Sprints are your friend, they manage expectations, and they help you remove some of the misunderstandings when you get towards the end of the project.
Leveraging the Anaplan Community
The single most under-utilized resource is the Anaplan Community. In addition to the 25 Community Bosses that monitor the forums, there are nearly 50,000 other members that have probably encountered many of the same challenges you’ll face in an implementation. Also, check out the Best Practices, how-to section, and blog posts. They’re all peer-reviewed.
Rough cut portion (Anaplan Way)
The very first phase of the Anaplan Way is to create a rough estimate of the size, a general idea of the requirements and success criteria, and the approximate effort to implement the requirements. When collaborating with the customer on these points, this builds confidence with the implementation team, provides a terrific venue for managing expectations, and ensures a greater chance of adoption.
Planning for calendar rotation
We heard many examples where applications are brilliantly built but only work for the current year because no one took the time to build in the administrative tasks necessary to rotate the calendar so it can be used for the next year. Or worse, years just keep getting added to the calendar without any ability to archive or save off obsolete years. Yes, it takes time and there are some architectural considerations but it’s important for the sustainability of the application.
Long-term solution to a problem
One of the common mistakes we do during the implementation of projects is not thinking long-term about the problem. Our focus must be to provide a sustainable solution to the problem rather than a quick fix or workaround. Try to test the limits of data and length and breadth of problems and then build a solution accordingly. Both prototyping and development must be done keeping this in mind. Try to understand the business strategies and how they are to evolve with upcoming years. Keeping this in mind, prototype and develop your solution accordingly for the long-term sustainability of the system.
Overloading the model for catering exceptions
We notice this very often that business analysts and developers spend a considerable amount of time in identifying and building the exceptional scenarios in Anaplan. In the long run, this practice is not good for the overall hygiene and maintenance of the system. Before, taking the decision to build out exceptions in Anaplan, we need to consider the likelihood for that exception to occur. If the probability for that exception is quite less, it is better to handle that in downstream systems or through user trainings.
This conversation started with the question, “should I take the certifications?” This led to a lengthy discussion about how the certifications have been retooled to reflect all the learning and best practices in the last couple of years. The answer is a resounding “yes” because they address the most common mistakes made in implementations, nearly every point that has been made in this blog. Yes, many implementations were successful but now that we know more about how the Anaplan engine works, there are more optimized ways to ensure adoptions, sustainability, and performance.
This article was written by 2021 Master Anaplanners Sonal Tripathi (@SonalTripathi), Brett Francis, Daanish Soomar (@DaanishSoomar), and Jared Dolich (@JaredDolich). Have questions? Post them in the comments!