When you embark on the Anaplan journey, you will need to focus on more than the Anaplan model build. The Anaplan platform cannot be successfully deployed in an unstructured manner. Like other mission-critical applications and processes, an Anaplan implementation and deployment needs to be planned carefully to be executed well. The keys are in the pre-planning, (requirements, team building, etc.), team collaboration and the fast iterative execution using Agile implementation methodology. Once these components are in place, ground the customer in the fundamentals that lead to a successful implementation. We call these fundamentals the cornerstones of The Anaplan Way. Why? Cornerstones provide the foundation for the corners of a building. The Anaplan Way cornerstones provide the foundation for an implementation of the Anaplan platform. These cornerstones must be planned, executed, and tracked during each phase. They are: Process: The wider business process that the Anaplan model supports. Data: All the data components needed for the model: master, meta, and transactional data. Model: The design, build, and testing of the Anaplan model. Deployment: A plan to ensure the Anaplan model and business process is adopted in the organization. Anaplan is specifically designed so that you can build models quickly. It is not the model build that takes the most time, but rather the surrounding processes that support the build that require the most time. This graphic shows the approximate percentage of time you should spend on each cornerstone. Cornerstone % Time of the Release Process 35% Data 35% Model 17% Deployment 13% Process and data cornerstones present the biggest challenges, and require the most project time. Keep the phases focused on process and data simple to start; build upon the first release in subsequent releases.
Process is arguably the most important Anaplan Way cornerstone. If the customer does not have the desired processes agreed on and documented, it significantly impacts the success of the project. Establish the process flowing through the model before the project work begins. This vital step is not something that can be done during the project; that’s like building the plane while flying it. Without clear understanding and alignment of the end-to-end business process being addressed, it will be very difficult to collect, document, and prioritize user stories. You may also risk misunderstanding associated upstream and downstream process dependencies. Customers almost always use Anaplan to fix a broken process or system – sometimes both. Therefore, the actual process must be either fixed or optimized before the Anaplan implementation.
Anaplan’s role is not that of a business process expert; our expertise is in the product, not in process re-engineering. Anaplan can offer guidance and provide industry best practices; customers must own their processes. Quite often, customers require specialist support when it comes to process. This can involve third party consulting organizations who specialize in planning and analytics process change.
During an initial scoping session, the team workshops processes and identifies the areas Anaplan will address. This honest, transparent discussion helps to identify processes that are broken or need to be changed. During the workshop, discuss Anaplan’s approach and how it quickly addresses process changes in small release cycles. Anaplan’s approach allows the project to focus on one small piece of the problem at a time. The customer must think in the one small piece at a time mindset in order to successfully move forward. All parties should come to the workshop with a basic understanding of how the customer intends to use Anaplan. Typically, this first, quick win demonstrates significant value, a glaring pain point, or utmost strategic importance. The workshop begins from this shared knowledge and moves through these steps: Begin by white boarding the entire process work-flow Anaplan will address, start to finish. Next, identify which area(s) of the process work-flow Anaplan will handle. Many times the customer wants to do it all in Anaplan. That’s fantastic! Before making that ambition a part of a plan, remember: Anaplan implementations fare best when they focus on one or two areas at a time. Plan other process areas for future releases. Keep it simple: achieve success in a small, specific area, and build on it. Once focus areas are defined, discuss other (non-Anaplan) areas and gain agreement on how they will be handled: In other software In other systems Completed manually Clearly define process touchpoints and integration points. Identify and document the processes scoped for future Anaplan releases, building an Anaplan roadmap beyond the first release. Once the Anaplan pieces are agreed upon, discuss and align on: Shared dimensions Data inputs and outputs flow charts, including data sources and destinations Calculations needed Expected end user experience (what people need to see) Who should be invited? Business Process owners who understand the end-to-end process End users who are responsible for their individual in-scope process components Data specialists who understand the data inputs, calculations, and data outputs Core project team This workshop will likely take a full day. Larger projects or complex processes can take much longer to work out so make sure to account for the time when setting customer expectations. The end result of this workshop session is documentation outlining the customer ecosystem and Anaplan’s role in it. It will take you a day or two to put this together. The next step is to share the documentation with the team. Be sure to follow up with the team to confirm your understanding.
Data, like the other four cornerstones, can make a project run smoothly when handled well. If the customer fails to plan properly or staff correctly, data can stop a project in its tracks. Make no assumptions about data. Data typically needs a significant time investment on an initial Anaplan implementation. Optimize your data time investment and minimize risk with good planning, dedicated data resources, and careful foresight. As with any change, data changes often expose underlying assumptions or gaps in a customer’s data. Project teams must think critically about and candidly discuss the dataset that moves in and out of Anaplan. Involve data specialists as well as end users early on in data discussions. Help stakeholders understand that end users will see incomplete, inaccurate, or unintuitive data as a software failure, not a symptom of low data quality. Data readiness best practices include: Start the data discussion with key customer stakeholders before the project begins. Clearly identify data sources and data components (lists, properties, hierarchies, subsets, and transactional data) in the statement of work. Assign your customer homework: have the customer’s team ensure production-quality data is ready and available at the start of the project. Gain early insight into data completeness, quality, and integrity. Build contingencies and identify critical risks and dependencies during the planning phase. Think of yourself as a ‘data detective’ who needs to check your facts with multiple witnesses. Align all customer stakeholders so they agree on the source, quality, and availability of data. Since functions tend to silo in a business, especially a larger enterprise, it is not uncommon for an IT team to be unaware of data quality issues, while a business analyst realizes the need for manual massaging and manipulation of data to make it useable. Validating assumptions across IT and business functions will help build a complete, accurate picture of the data.
As you prepare for moving data in and out of Anaplan, understand the primary data input and output methods: Manual upload/download In the Anaplan platform, simply pick a text or comma-separated-value (csv) file from your desktop (or other location) and import it into the Anaplan model. There are multiple export options to make it easy for other systems to receive Anaplan data. Semi-Automated Using Anaplan Connect Anaplan offers a way to automate the import and export of data using a proprietary tool called Anaplan Connect. Anaplan Connect is a small-footprint model that can control the importing and exporting of data from the Anaplan platform. Fully Automated Using Anaplan Connect & API Anaplan offers a way to automate the entire process of importing and exporting data using a cloud API which can also extend to other cloud APIs compliant with Java, ODBC, or JDBC. ETL Vendor Integration Anaplan offers several integration points with ETL vendors such as: Anaplan Connector for SnapLogic Anaplan Connector for Dell Boomi Anaplan Connector for MuleSoft Anaplan Connector for Informatica Third-party Data Integration Anaplan also connects with third-party services, either directly or through an Integration Platform as a Service (iPaas). Anaplan Connector for Boomi Anaplan Connector for Informatica Anaplan Connector for MuleSoft Anaplan SnapLogic Integration Visit the Integrations area on Anapedia for instructions on how to use these tools for importing/exporting.
Consider how Anaplan defines data: Data is simply numbers and text; the content of a cell in Excel. For example, a cell might contain the number $1,250,000. Metadata describes the data in context. If you see the figure $1,250,000 in a cell, it is just that – a figure in a cell. On its own, it lacks meaning and context. You need to know what that number represents for it to be useful. For example, it may be that $1,250,000 represents the value of cases sold of ACME Red Vodka 750ml, in the month of June of the current year, in London. The description and context (measure of product sold, time, location) for the dollar amount is the metadata. Without the right metadata to provide context, data is meaningless.
How does data go from simple to complex? How does data become hours upon hours of work? Anaplan has identified two key challenges: As organizations grow, so do their systems - mainly in silos: one for managing the customer relationship (CRM), one for managing the workforce (HRIS), one for accounting (ERP), one for projects, and so on. Over time, these systems contain different data -- but usually, they contain the same metadata, which becomes disconnected. Customers are a great example of how shared metadata disconnects across company systems. A customer called “Acme” in one system is called “Acme Co.” in another system, and “Acme Company” in yet another. Data for Acme exists in the ERP system; opportunity data exists for Acme in the CRM system, and marketing data for Acme exists in the marketing system. Systematically it’s difficult to match up systems, as the link between the data has been disconnected. Anaplan’s platform can help solve this problem. Anaplan models bring these items together to give a complete view of the business so the company can analyze and plan ahead. When embarking on an Anaplan implementation, forewarned is forearmed. Decide where you are right from the start and take necessary steps to fix issues. Data challenges may not be resolved overnight, but the right level of transparency allows the customer to put the right plan and the right people in place to make data preparation a priority.
There are many ways to get data in and out of Anaplan; some more involved than others. In our experience, starting simple is always the best approach, unless the customer has a large, dedicated data team. In addition, as previously mentioned, if the data needs cleaning in some way, recommend to the customer that it is best to start the data effort right from the beginning, or even before the project gets started. Suggest that the customer bring in expert help if that makes sense. Many organizations rely on external expertise to supplement the core team and many also bring in special data cleansing tools that help reconcile differences between systems. Here are some guidelines to keep in mind as you evaluate the steps you will take to manage and prepare the data for the integration process: Assign overall accountability of the data work stream to a member of the customer team; ensure the customer holds the data work stream owner accountable throughout the implementation. Start small (if you have to) and focus on data quality. Automate later. It is best to begin with manual uploads. The fact that data and metadata loads are not automated will not stop the project. Poor data can. Add data tasks as user stories in the Agile Implementation – The Anaplan Way app. Pay as much attention to data as you do to building the model. When you uncover data issues, document them clearly and socialize them broadly. It is important that the entire project team, including executive sponsor, understands the issues with upstream data. It is much better for people to have a clear understanding of the precise and specific data issues, than to say "the data is terrible, so the model won't work".
Customer model building knowledge is critical to the implementation process. Customers should complete Launchpad training before requirements gathering begins. Track training progress and completion through all phases of the project in order to: Provide a baseline: Everyone on the team should understand Anaplan’s capabilities and how the platform can be used to solve business problems. Drive efficient requirements gathering: Understanding the art-of-the-possible (what can be achieved through model building) helps ground users in Anaplan’s functionality, which in turn helps them understand how business requirements might best be realized in a model. Provide context that leads to increased stakeholder involvement: When stakeholders understand Anaplan’s capabilities and functionality, it is easier for them to make educated decisions about issues that arise, instead of avoiding or delegating decision-making. Anaplan recommends all project teams have two or more trained model builders on staff at all times in order to assist with the model build, help create knowledge transfer to end users, and effectively maintain Anaplan models one they are generally available.
Anaplan project teams should structure their model building team around Anaplan certified resources (including certified partners), and leverage the entire team’s expertise, especially in initial releases. Customers must ensure their model building resources have adequate knowledge and experience, and are authorized to build on the Anaplan platform.
Successful model builds rely on strong model design. Measure twice, cut once is something you’ve probably heard before. In this instance, it means the model has been designed as an integral part of the business process where it resides instead of as a stand-alone solution.
When you think of deployment for a typical project, it involves a plan to roll the application out to the end users and will inevitably include a training approach for getting the end users trained. Deployment is a cornerstone because it is so much more than this. Deployment must be considered right from the start, by designing a solution for the end user. 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. Involve end users in the Anaplan implementation project at the onset -- at the latest, during the second sprint. Customers should identify champions who can help promote the Anaplan model when it becomes generally available. Many times, end users may be used in early ‘sneak-peeks” at the application and the User Acceptance Testing (UAT). Getting early buy-in to the design is always a good idea for a successful deployment. In addition, work with your customer to ensure the most influential people in the user population are involved in the process early on. Encourage the customer to let these influential people own some of the decisions and participate in the design. This is a great way to get early buy-in and these people will then act as advocates to the wider user population once the application is in UAT and during the go live phase. Deployment, and the run up to deployment, is effectively a sales and PR job. Keep in mind that your customer is selling the application to their end users. Remember that it is almost impossible to over-communicate that a process change and new tool are being implemented. Work with your customer to involve business subject matter experts (SME’s), who are well respected by the business in the early stages, preferably in the requirements phase. Then, around the middle of Sprint two, once you have the model at about 90% built (model only, no dashboards), start to get them involved in evaluating the solution. What this means is three-fold: You get their early buy-in involvement in the project You start to force joint ownership of the solution You have time to steer the ship if things need to be adjusted While this buy-in and evaluation of the solution is happening and tweaks are being made, you need to prepare for how you will introduce the business to the new solution and how people will be trained. The next section is customer-focused. Work with the customer to make recommendations regarding how to effectively sell the Anaplan solution to the business. Remember that an effective deployment often leads to expands within an organization. A deployment that does not get off the ground leaves the customer wondering why they invested in Anaplan. Positioning Anaplan to the Business Provide an early introductory on-demand video for end users to view that answers these questions: What and who is Anaplan? What process are we changing? Why are we changing? How does it work (demo)? What is the timeline for completion? Provide a software simulation for users to see what it will be like to perform the process. Create a web site where anyone can browse topics and documents. Conduct regular webinars or lunch-and-learns for users to attend and ask questions; openly discuss the impact of the new process on the business and their jobs. Conduct on-site evaluations and feedback sessions in which users get to see a presentation from the project team, share comments, and generate ideas. Put yourself in the place of an end user and answer: Why are you changing the way I am doing this process? How will it change the way I do things in the future? What was wrong with the old way? How will this make me do my job better or make me more efficient? When does the project start? How will I be involved? What if I get stuck or do not know what to do? Create a Change Communication Plan During project planning, create a plan to introduce the business to the Anaplan model and process. Adjust this plan throughout the release phases. Create a training plan for end users. Include why the change is important to the end user, what the change includes, how their work may change due to the change, and where they can go for more information or assistance. Use documentation to create job aids on process flows or changes. Evaluate how many end users need to be trained; how many resources are needed to reach them all effectively. Identify two or three key success measures: how will you know end users are effectively adopting the model and process? Deployment is change management – a critical promotional role. Anaplan teams must sell the greater business on the Anaplan model in order for the business to adopt both the Anaplan model and resulting process changes. Plan layers of communication as part of the deployment plan. Over-communicate that a process change and new tool are being implemented. Find ways to effectively position the Anaplan model to the business. An effective deployment often leads to additional Anaplan implementations.