Introduction

Sort by:
Before you get started with The Anaplan Way, here's a quick overview of The Anaplan Way methodology!  
View full article
Anaplan is a unique software platform and requires a unique implementation approach. The Anaplan Way is a methodology that helps to ensure complete transparency during every phase of an implementation. Successful implementations require transparency amongst the customer, Anaplan, and engaged partners. This approach ensures strong deployment and adoption of the Anaplan platform.   The Anaplan Way is designed to be flexible and dynamic, allowing for the twists and turns that a project may take. We systematically and methodically document changes; we build rapid re-planning into Agile sprints embedded in the Anaplan Way.
View full article
Who should read The Anaplan Way? Anaplan customers, project teams, employees, and partners will find The Anaplan Way useful. The Anaplan Way ensures your team is leveraging best practices in planning, design, implementation, testing, deployment, and maintenance of the Anaplan platform.   What is included in The Anaplan Way? The Anaplan Way is an end-to-end document that covers all major phases and considerations during an Anaplan implementation. Use The Anaplan Way for the first release and any subsequent releases. While not exhaustive, The Anaplan Way is comprehensive.   Anaplan’s platform has been successful because both the platform and the Anaplan Way flex and adjust to changes that often occur during a project. The Anaplan Way continues to drive successful releases because it is grounded in four implementation cornerstones (described in detail in chapter two). All four cornerstones should be considered during each project phase: Process Data Model Deployment     Each phase of the Anaplan way is explained in its own section. The first phase, Pre-Release, includes:   Preparing a rough estimate – called a Rough Cut Running a scoping workshop to collect necessary SOW data Creating a detailed estimate used to create the Statement of Work (SOW) that is signed by the customer   You’ll learn about the types of information needed and the steps involved in putting together this important document in chapter three.   The Foundation phase (chapter four) includes:   Setting up Launchpad, our initial customer training Conducting a kick-off meeting Writing user stories   Once you have defined user stories, you’ll design the model and have the design reviewed. You’ll also work with the customer to determine the user stories’ priority and plan which stories will be built in each sprint. You’ll learn how to manage the buckets. Using the managing the buckets process, you’ll work to ensure that sprints are evenly allocated, even when new user stories are added. Missteps here will cause problems in subsequent phases.   The next phase is the Implementation phase. Chapter five includes the steps involved in building the model using an Agile Scrum methodology. In this chapter, you’ll learn: How to conduct daily Scrum meetings Handling feedback from a Sprint Review and Retrospective What to track in the Agile Implementation – The Anaplan Way App When the sprints are complete, the Testing phase begins. This phase includes: Testing usability Managing bugs Prioritizing change requests and enhancements During the Testing phase, you’ll work with your customer to determine what absolutely must be done in order to have the model generally available. Chapter six includes the steps involved in running UAT successfully.   Chapter seven continues with the Deployment phase. Remember that deployment is one of the cornerstones and needs to be considered from the start of the project. Activities in this phase include: Implementing a deployment plan Communicating about Anaplan platform and process rollout Confirming all of the documentation is in place to ensure a smooth handoff Anaplan promotes customer self-sufficiency; our Center of Excellence model is included in chapter eight.   Anaplan security is covered in chapter nine.
View full article
Before getting started, carefully consider the following ideas. All Anaplan users need to understand these key concepts: Anaplan’s pros and cons and reminders of some do’s and do not’s An Anaplan implementation is not about the destination, but rather the journey An Anaplan implementation is about fixing a broken process.
View full article
PROS CONS You can build almost anything in Anaplan! You can build almost anything in Anaplan!   It’s true: Anaplan is the most flexible modeling and planning platform in the world. You can build world-class models--and really poor models. In order to launch successful, sustainable models, follow The Anaplan Way: design and build models using only tried and true techniques and best practices.   Anaplan Dos and Do Nots   DO DO NOT Talk to other successful customers and business partners with experience in your use case & get their take on how to tackle your business problem. Be tempted to replicate a process currently done in Excel into Anaplan. It almost never works, and what’s the point anyway? Take a look at the current processes and see if it needs updating. Try to rebuild a broken process in the middle of trying to build an Anaplan solution. You will fail. Always keep it simple. Boil the ocean. Do not try to jam everything into the first release. Remember, you will quickly iterate on each release.
View full article
Anaplan is a very different kind of platform. Anaplan was designed from the ground up to be imagined, created, and modified by customers – citizen developers. Customization is simple, and in many cases, Anaplan models need not be taken off line to make changes. You can try new ideas, incorporate feedback, make improvements, or implement new methods in hours, minutes, or less.   Business goals and strategies adjust as markets shift – more frequently than ever before in a modern business landscape. Anaplan models can change and shift with the way organizations do business.   A traditional waterfall methodology promotes a practice of gathering myriad requirements in order to force them into the first release, because in many instances, organizations will not see another release for a long time (sometimes years!). Waterfall methodologies cause much worry over what might have been forgotten. In traditional implementations, teams get unfocused, bored, and lack visibility into the outcomes of the project. New priorities come into play, putting projects on the back-burner; sometimes even leaving people wondering why the company embarked on the journey in the first place.   Businesses and people think in cycles. Miss a cycle and they are onto the next thing.   The Anaplan Way takes advantage of the natural cycles that exist in business. Anaplan helps teams think in short, focused releases, with each release building on the others. Generally, a release is ready for general availability in about two to three months. Anaplan can change and shift with businesses because it helps customers: Keep their first release focused and short. Identify what they want to achieve and when they want to achieve it. Align their organization around four cornerstones and their Anaplan goal or manifesto. (More on that later!) Stay aligned with a less is more, keep it simple mentality. Follow a crawl, walk, run philosophy. Achieve and promote a quick win, focused on immediate pain versus a long process, focused on many pains. Demonstrate the value of an Anaplan investment.   By using the Anaplan Way, we help our customers stay focused on the quick win.
View full article
When customers embark on an Anaplan journey, it’s likely they are going to change an existing process that is missing functionality or broken altogether. In most cases, this requires modifying one or more process that is upstream and downstream of the changing process.   The Anaplan platform will operate as a new component in the business process landscape. The customer must be clear on all processes that impact what is going into and out of Anaplan – as well as a clear understanding of the people, time, and systems really involved. Consider the process in-depth, as well as all processes that provide input to or rely on outputs from the process. Can all upstream or downstream processes support Anaplan?   Let’s look at an example of a Territory & Quota Planning model.    This use case calculates the quota to be allocated to a field sales representative to sell goods and services on behalf of the company.    The basic inputs to the process are: Strategic targets (planned and historical data) Sales organization list with a hierarchical structure Products list with a hierarchical structure The Anaplan platform brings the targets together. Based on historical sales data, this can be easily mapped to sales staff and sales territories to calculate quota over time. Further, these quotas can also be easily allocated across the products in a multi-dimensional platform.   In order to calculate these pieces correctly, the Anaplan platform needs clean data and metadata. Often customers perform processes like this in a silo like Excel, and were not designed to take a central feed from sources that hold historical data and/or metadata. This becomes a new requirement---one that exists outside of the core Anaplan model use case. The process of cleaning data and metadata is critical to project success and needs to be aligned with the project.   Also remember that while you are an expert in how Anaplan works, you are not expected to be a process expert. When major changes to a process are needed, it is best to recommend a process expert who can work with the customer to streamline the process.
View full article
Announcements

Leading the industry means leading the change. Read more from Anaplan's Chief Planning Officer, Simon Tucker.


Share your Anaplan knowledge and be published on the Community! Get started sharing your best practices using the Community Contribution Toolkit.

Top Contributors