• Cathal Doyle

The Anaplan Way: The Four Cornerstones

As we know, Anaplan is a flexible, scalable and collaborative platform which lends itself to very rapid build times and it is therefore, not the model build that takes the time, but rather the surrounding processes that support the build. However we need to be mindful of not deploying Anaplan in an unstructured manner similar to the way Excel is used in many organizations and it is therefore critical to ensure a project is well-grounded in the fundamentals that lead to a successful implementation. We call these fundamentals the cornerstones of The Anaplan Way. Model: The design, build and testing of the Anaplan model, Data: All the data components needed for the model, i.e. master, meta and transactional data, Process: The wider business process that the Anaplan model supports, Deployment: Ensuring that the Anaplan model and the new business process is adapted in the organization.

One of the earliest fundamentals of the Model Building phase is customer education and training, which for me underpins the entire implementation process. It provides the baseline of the implementation, and allows the project team to begin to understand the Anaplan capabilities in order to conceive how it can be used to solve their business problems. Understanding the art of the possible also immediately allows you to ground and focus the business requirements towards Anaplan delivery. I generally suggest that this initial training gets your learning roughly 60% of the way there, and subsequently the model building knowledge and experience gained through the project delivery coupled with a Business Partner will get you to the 100% mark. The process of working day in and day out in parallel with a Business Partner will allow you to shadow the experts and ultimately should get you to a position where you can maintain, update, and enhance the models when the implementation is completed.

We’re always looking to avoid a trip back to the drawing board in the case where we’ve realized late on that we’ve completely overlooked an important part of the company’s business structure or processes so naturally time spent at the front end of the model design process is time saved during the model-building process. Determining what needs to be gathered to make the model work, who will use the model, how they will use it and establishing how data flows through the model are all important considerations that must be clearly defined to avoid any unwanted surprises after the model building begins. Anaplan has coined the phrase ‘measure twice, cut once’ which essentially means double-checking your information before you get started with your design. Typically given the agile process of development, things will change and shift a throughout but it is critical that you plan your model design in advance of model build to ensure an efficient and robust solution.

When a prospective client asks me what the biggest risk to a project is, I will generally always respond with Data. Firstly, because this is the one area I have no control over as we will be at the mercy of underlying ERP, CRM systems or even worse spreadsheets. Remember, the data that comes out of Anaplan can only be as good as the data that goes into Anaplan. And despite what customers may say, in my unfavorable experience their data is very rarely ‘clean’ and will require a lot of attentive nourishment and dedication to get right. For this reason, data is one of those dirty words to get out on the table way in advance and to be actioned as a pre-requisite to kick off if possible. Understanding the nature of the underlying data sources is critical in allowing you to build sufficient contingencies and identify critical risks and dependencies during the pre-planning phase. On the bright side however, generally one of the first deliverables I will target is reconciliation of said Actual data. This is a very clear and tangible delivery point, will allow stakeholders to breathe a little easier and generally give a feeling of ‘ok this thing does actually work’.

It is always worth remembering that Anaplan should not drive the Process, the Process should drive Anaplan. Without clear understanding and alignment of the end-to-end business processes that are being addressed, it will be very difficult to collect, document and prioritize User Stories and understand the associated upstream and downstream process dependencies. As Anaplan experts, we will naturally offer guidance and provide industry related best practices, but ultimately the customer is responsible for their own processes and the process documentation should be completed well in advance of project commencement. Too often than not, the process is being brainstormed during the project delivery and will ultimately never be as succinct as it could be. Anaplan frame it as ‘building the plane while flying it’ which paints the picture.

In a typical project approach, Deployment expectedly describes a training approach for getting the end users trained and ultimately rolling that application out, however we look to the Deployment cornerstone right from the start, as we encourage the involvement of end users early and often. We’re ultimately designing a solution for the end user, so why be shy about getting them involved. If you can get their early buy-in involvement in the project you start to force joint ownership of the solution and in turn may also have time to steer the ship if things need to be adjusted on their recommendations. These champions can really help to promote Anaplan come the wider rollout and if you fail to capture the appreciation of the end user, you will lose their buy-in and ultimately lose adoption of Anaplan and the new process, effectively negating any ROI for the customer. Hence, Deployment should not be considered an afterthought, and is one to be prioritized right from the outset.

The Anaplan journey is an exciting one, and in the Anaplan Way we have a measurable and definable approach to optimizing customer success and project delivery. Enjoy the process!!