Day in the life of a Certified Master Anaplanner (Part 2): CoE Administrator
Author: Joel Bangalan, Certified Master Anaplanner, Solutions Architect, and Systems Administrator in the consulting industry.
Hello Anaplanners! This article is the second of two parts on my experience as a Certified Master Anaplanner. I’ve worked as an Anaplan implementation consultant and as an end user, I’m hoping to give my insights from both perspectives, how they compare from one another, and how Anaplan was instrumental in my growth.
In this blog, I will dive into what a Master Anaplanner does as part of a Center of Excellence (CoE) within a company that uses Anaplan. For context, my Anaplan journey started as part of a consulting team that implements and builds Anaplan under different use cases and clients. I provided insights on this experience in part one. Later in my career I joined an Anaplan client as a systems administrator. Much of the difference is in the perspective. For example, in consulting, you think of your clients as the buyer of the product, while as part of the CoE administering Anaplan, you can think of the end-users as your customer. The objectives of managing expectations and keeping customers happy are still the same. However, an administrator now owns the product and has a more long-term vision for how it fits in the overall corporate structure and strategy. Whereas implementation partners come and go, product administrators are always there and have a better understanding of the culture and the personalities of the end users and the stakeholders.
Here are the insights I learned as part of this assignment. Like in the first blog, most of these are emphasized in the Anaplan Way yet it helps to remind people of these factors regularly.
Day-to-day best practices as a CoE administrator
Be flexible and adaptive. In a fast-paced and growth environment, change happens a lot. It could be the structure, the metrics, the way metrics are calculated, and the processes involved. This impacts the metadata, the hierarchies, the calculation modules, actions and processes, and the user interface. Change may happen period-by-period; hence, the need for flexibility and the ability to adapt to changes. What this means is that we are taking advantage of the agile methodology in an implementation. This approach works well since there is a quick turnaround regarding new requirements. One thing I’d like to stress is that there is the temptation to add complexities on top of the existing model. An example of this is when an exception or a new logic is defined — it's easy to add a conditional in a computation and be done with it. However, care should be taken to still follow best practices (e.g., early exit). Therefore, I recommend having a holistic view of the calculation rather than simple adding another level of a conditional. This will make the model more sustainable and avoid introducing lag times as computations become more complex. \
Document as you go. As models expand (additional modules, line items, actions), it will be easy to get lost among a sea of formulas. Over time, even original authors have difficulties remembering how or why certain formulas were built. Same with actions — these can add up easily. It takes discipline to document as you build something. Take advantage of the Notes section in modules to reference a more detailed document. One best practice I've seen is to add dates to the notes as you make them so it's easier to track progression. Another important use of the notes is for line items that are used as filters. We’ve encountered issues in the past where it’s not as easy to determine if a Boolean line item is referenced as a filter. This is for cases where filters aren't all in one place. For actions, aside from renaming it to be descriptive enough to identify what it does, the Notes column should be further used. I also recommend regularly checking which actions you remove to avoid cluttering the Actions tab. It takes time to scroll through the Imports, for example, for a model that’s been around for a few years.
Find ways to expand and enhance. This is somewhat related to the first section on flexibility. Over time, models can get more complex. The way it was built in the past was based upon prevailing information at that point in time. The model architecture and the design of the formulas were optimal back then but may not be the case now. Keep track of the changes and/or enhancements from that point on (in addition to the “document as you go” section above). As more enhancements or efficiencies are identified, it becomes a strategic decision on how to best approach these. Should there be a partial rebuild or a complete rebuild? How many resources are required? How many hours are we able to allocate to the enhancements without impacting the day-to-day operations? Do we need to bring in outside consultants? These are some of the management factors that help guide the strategy and the timeline of a planned enhancement or rebuild of the model. One possible consequence of an enhancement or a rebuild is recapturing that efficiency that may have been lost over time (complex formulas, exponential growth in model size, etc.). Freeing up more workspace size will enable the organization to also consider an expansion into another use case. A successful administration of models in one department and/or use case will make it easier to have executive support toward expansion.
Conclusion
A Center of Excellence in an organization is important for model maintenance and ensuring that the models are used appropriately on a day-to-day basis. However, it shouldn’t remain stagnant — models grow with the organization, and the CoE should be flexible in adapting to changes, strategic in its enhancements and expansion, and disciplined in drafting supporting documentation along the way. These factors aid in championing Anaplan throughout the organization.
Comments
-
@DoctorDataFinance Thanks for sharing these fantastic pieces of insight!
0 -
It would be nice to have a partial rebuild training example/webinar
0
