Day in the life of a Certified Master Anaplanner (Part 1): Management Consulting
Author: Joel Bangalan, Certified Master Anaplanner, Solutions Architect, and Systems Administrator in the consulting industry.
Hello Anaplan Community! This is the first of two parts of my blog on my experience as an Anaplanner. Having worked with Anaplan both as an implementation consultant and as an end user, I’m hoping I can give insights from both perspectives, how they compare to one another, and how Anaplan was instrumental in my growth.
How I started with Anaplan
Whenever I tell people about my Anaplan experience, I always start by saying that my journey began way back in October of 2013, a little over nine years ago. Anaplan was still in its beginning stages and I’m proud to have seen its growth — both as a company and as a platform. (I’d like to acknowledge another Master Anaplanner who mentored me in this journey, Mitch Max (@Mitch_Max)!) At that time, I was doing freelance consulting and I specialized in doing spreadsheet-based financial models and valuation of financial instruments. An Anaplan use case on financial reporting (income statement, balance sheet, cash flow statement) opened and I became part of the implementation team.
At that time, Anaplan training was very different from what it is now. My memory is fuzzy on the details but the ancestor of what is now the Model Builder Certification ran for about two days in a live environment — a combination of classroom and remote classes (I don’t think it was recorded, so you had to wait for the next class offering if you miss a session). Given the training limitations, back then you learned Anaplan on the fly as you went along. While I started as a model builder, I moved upwards as I gained experience. I was among the first batch of Solution Architects (the legacy certification back in 2016) and then Certified Master Anaplanner (in 2016). Below are some of the lessons learned from my experience as a management consultant; most of these are emphasized in The Anaplan Way but I can’t stress these enough for an implementation to be successful!
Day-to-day best practices as a management consultant
Know your client. At least from my experience, the most common point of entry for Anaplan in a company is through a department for a particular use case; for instance, the FP&A team for a financial reporting application. As you start building the relationship with the client, the following are possible guides on how to know the internal organization of the company: How does this team fit in the overall company structure? Is the organization part of a bigger network/conglomerate? If so, is Anaplan already implemented somewhere in that bigger framework? Who are the different types of expected users (primary end-users; view-only users; admin; etc.)? How will Anaplan fit in the overall organization? The idea is to ensure that the Anaplan implementation is not a “dead-end” product but is a starting point towards an enterprise-wide application.
Another set of factors is to know where the client fits in the economy: what are the main products or sources of revenue? What industry does the company belong to? How big is the company relative to the industry; is it a main player? Note that you may have clients that belong to the same industry and have the same use case and yet, each are unique in their own way. As tempting as it may be to do a one-size-fits-all approach, it’s a disservice to the client and to the Anaplan platform if an implementation consultant is not able to capture the nuances unique to each client and how to best play to that uniqueness. Moreover, identifying how each company differs can help in building your set of best practices that you apply to each.
The technology team is your ally. From servers to systems security to applications, the Information Technology team (IT) is a critical part of any organization. What gets overlooked is that IT has a holistic view of the enterprise architecture and hence, they come with that perspective. As an end user, the tendency is to only consider the data coming and going out from that specific use. When building the architecture for Anaplan however, data of different types or sources need to be considered, such as metadata, transactional data, and how these will eventually be integrated into the system. They are also responsible for data security and as such, will have to ensure that the appropriate data are provided. Depending on the org structure and the existing policies there may be a need to mask individual identifiers and compensation data, for example, and designate someone that is authorized to work with sensitive data. Finally, we emphasize having a workable data set as a critical path in an implementation. Partnering with the technology team may help in managing expectations and in mitigating the data risks.
Build a partnership, not just models. It’s emphasized in The Anaplan Way that the ideal setup is such that model building is a shared responsibility between the implementation team and the client. It is therefore highly recommended to the point of a hard requirement to have a dedicated person from the client side be allocated into the project for a significant amount of time (in my opinion, at least half of their working hours). The advantages are as follows:
- They are more familiar with the data and the business side of things and can help guide the architecture and the model building by being the subject matter expert should the need arises.
- They can help in doing unit testing as formulas and modules get built.
- They get to own the build which makes it easier to transition the admin and maintenance work to the client. Moreover, this is an opportunity to mentor and train new users and model builders. We become Anaplan evangelists in this manner.
Establishing that partnership tends to promote goodwill and may help enable the team to expand the use case or at the very least obtain a good reference for future work.
Conclusion
The goal for a successful implementation is to have an application that meets the client's needs. Knowing your clients, and partnering with them during the process while establishing a good relationship with the technology team are some of the ways to achieve this goal.
In part two, I'll share my perspective on best practices and day-to-day routine as a part of a Center of Excellence within a company that uses Anaplan in its operations. Stay tuned!
Comments
-
@DoctorDataFinance - ah the days of 102 / 201! There is something to be said for learning as a collective with no outside distractions.
Will read Pt.2 with interest. IMO a CoE is both the "consulting" and the BAU all wrapped up in one. Something that partners are doing more of as "managed services".
3
