Author: Clarissa Hassfurder is a Certified Master Anaplanner and CEO at Double10 Consulting.
In many cases, when a team member departs a company, there is an ability to complete hand off with one or multiple team members. But what if your Center of Excellence (CoE) is a team of one? What if there are no other people with Anaplan technical skills to take on administrative and development activities? This article serves as a guide to support Anaplan customers in the case where there will be a gap between a sole Anaplanner leaving the company and the next Anaplanner joining. Generally, we like to say that Anaplan itself serves as the documentation. And usually it’s pretty great! But in this case where there is not a chance to pass along nuances person to person, more notes and documentation are needed than typical, and need to be stored outside the system.
Access consideration
Make sure someone remaining at the company is designated as the app owner with the full suite of access (page builder, tenant admin, and workspace admin for all models). This will make providing access to a new Anaplanner easier when they join. Also be sure this person has contact information for your Customer Success Manager at Anaplan.
Admin ownership assignment
For each use case, be sure to hand off any administrative activities for each model. This could be the person designated as the Anaplan product owner. It could be one person for each use case. While admin activities/steps should be documented already, ensure the designated person has access to the appropriate documents, modules, pages, imports, and exports in order to complete their admin activities.
Documentation
For the documentation below, be sure to store it in a location where the person designated as the app owner has access.
- The first item that every new Anaplanner packet should have is a ReadMe file. This should be housed directly in the shared folder, and should link out to every document, model, and app for your company’s use cases. If your company uses a chat tool like Slack or Teams, you may also consider adding this file to an Anaplan channel as a backup. While there is an opportunity to house this as a ReadMe Anaplan model or app, housing it in a file in a shared drive allows a new Anaplanner to more easily get started on ramping up in their new role while any Okta or Anaplan Support ticket is being resolved for Anaplan access. It also allows the individual to start building a relationship with key stakeholders associated with each use case before access is fully enabled.
- The ReadMe file should contain a section for each use case in the model. Below are items to consider adding for each use case:
- The name of each model associated to the use case, with a link to the model.
- This can help if the new Anaplanner has to reach out to support for access.
- The name of each app associated to the use case, with a link to the app, with a note about which model(s) the app is associated to.
- An indication of how models within the use case are connected (or not!) via ALM. For example, does your Sales Forecasting model have both a DEV and UAT model, while a smaller Long Range Planning model does not use ALM, but it placed in Deployed mode to prevent accidental changes? Be sure to document this nuance so the new Anaplanner isn’t wasting time hunting for a DEV model for LRP.
- The main stakeholder point of contact for the model.
- This will allow the new Anaplanner to reach out to someone to begin gaining a user-level business understanding of the use case.
- Additional stakeholders and primary users, and their role associated to the use case.
- List of key stakeholders adjacent to the use case (integration tool owners, Salesforce contacts, other system owners with background knowledge of interactions with Anaplan).
- A link to an import template packet (also stored on the shared folder) for any imports in the use case.
- Often times file formats for imports will not be set as public. For admins and the next Anaplanner, these templates will be useful if changes need to be made to an import, or if the file is infrequently imported and the template gets lost by those who own the import. Even better, make an export module in Anaplan which generates the import template. In the case where an integration tool is used, the file format storage on these tools may be sufficient.
- List of any open issues remaining at time of departure. These may be housed in JIRA, but a list of JIRA ticket links or link to the epic would help the next person.
- List of recently completed fixes with an explanation in case any subsequent issues come up. In general for stability, I recommend no major build in the last week before a sole Anaplanner departs, but from a practicality perspective sometimes this isn't achievable. Detailed documentation about updates before departure is key. It may be helpful to be more detailed in a ticketing system such as JIRA if your company uses this or other ticketing systems.
- At a minimum, a description of each app's most commonly used pages. This will help the next Anaplanner answer questions quickly as they come in from users. Many customers have a document with a full description of each app's step-by-step use which could be used for this purpose. You may also consider adding detailed step-by-step instructions directly to each Anaplan page.
- Links to any administration documents on processes or actions which need to be taken periodically
- In-model documentation should also be updated as much as possible. Leverage "Notes" areas in the models, especially for high-importance modules or areas of the model that are slightly unclear.
- Add information to the Notes in the Actions area for integration-driven actions, such as frequency or name of process in the integration tool. In the example below, I’ve added notes to a couple of actions about how they are managed, name in Boomi, and run frequency/timing.
- Add Notes in the Modules area to describe how major or obscure modules are used.
- On line items within modules, you may consider adding details about why logic is built a certain way if it break from Planual standards, descriptions of why certain Dynamic Cell Access rules were used, or an explanation of a recent change before your departure. In the screenshot below, I’ve copied the previous formula and added the date of the change and the associated JIRA ticket in case the new Anaplanner needs this information for troubleshooting in the future. One note on this use: the Notes field might not allow all characters needed. In this case, consider pulling a comparison report of recent changes, copying to Excel, then providing a Notes column there. You can also export all line items from the model to Excel.
- Detailed model rollover documentation should be included in the packet. For some models, it can be as simple as advancing the time forward one year. For others it can be a complicated process including data deletion and interactions with outside teams. Understanding the order of operations in the more complex cases can be a huge help to a new Anaplanner. Pointing them in the direction of pre and post rollover for past years can also be helpful. Another article goes into detail about
With these tips, your next Anaplanner should have a more pleasant onboarding at your company!
……………
Other articles from Clarissa:
