AMA with Chris Weiss: What is the Center of Excellence Development Maturity Curve?
Comments
-
@ChrisWeiss Thanks to you and team for the excellent support and partnership in our Anaplan journey.
Thanks to the CoE deck, we are setting up a CoE. The CoE is a mix of both business & IT users. We hired/hiring master anaplanners on both business and IT side. We are also on-boarding implementation consulting partner. The overall guidance will be from Anaplan's summit success resources (senior architects). We are betting heavily on Anaplan and hope to see some successful projects in 2020.
1 -
Nice to e-meet you. Your question is a great one and I echo all the points @ChrisWeiss has already mentioned. Hopefully I can help provide some answers based on my experience. A little about myself first - I am a Master Anaplanner and lead the Anaplan COE team at Groupon where we have 20+ use cases across our finance function and just beginning to expand outside finance into sales and HR via incentive compensation management. Groupon was an early customer with our first implementation in 2013 and our Anaplan environment has been on explosive growth since then. I attribute our quick growth and success to 3 things: Anaplan’s powerful platform, executive leadership buy-in, and a strong internal COE team that is owned by our finance function.
A little more about my 3 COE team members. All have a finance background and most have very light previous technical or systems experience. All 3 spend 100% of their time on Anaplan model building (whether that’s model maintenance, building new cases, managing projects, training/supporting our federated/non-COE model builders, etc.).
I understand your point that professionals sitting within the IT function with many years of experience will typically check all those boxes you’ve laid out and will be better equipped for ownership over certain systems. However, in my experience, Anaplan is different. The true power in the system lies with the fact that it can be a function-owned (or business-owned) tool. I've also found that the model building learning curve in Anaplan isn't as steep as other systems.
That said, it’s not as simple as giving a bunch of finance (or insert your business function) professionals model builder licenses and expecting them to be experts in Anaplan model building, understand key project management skills, learn complicated data integrations, etc. while keeping their day job. A COE team with dedicated team members whose sole job is driving the Anaplan vision at your company forward is fundamental to your success. At Groupon, having that COE sit directly within the function as well has been extremely successful.
In my opinion, here are the top reasons we've been successful with our current structure:
- The COE team members understand finance AND the Anaplan system. They can speak the language of our “customers” (finance team members) and also have the technical expertise to drive the right solution in the tool. Very powerful combination.
- For the COE team, Anaplan is their only job. They have the time/bandwidth to learn best practices, become experts in functions, learn data integrations, etc. which allows them to ensure everything we’re doing with Anaplan at Groupon is best-in-class. It's a fundamental part of their job.
- COE team can respond to requests very quickly when needed. Sometimes with a big IT function owning a tool, the time to deliver updates/changes can be too long for a fast moving business. Our COE team has clear direction from our finance leadership on when things need to be turned around and there’s no competing for IT resources.
- We have recruited the right talent to be on the COE team. These team members do not need to have 10+ years of systems and technical experience, but they do need to show a strong desire to learn Anaplan and other tools that enable it (e.g. ETL tools). They are expected to learn the technical side, have a desire to improve processes, have an analytical mind, lead projects, and the list goes on… It’s critical to find the right people for your COE and the right person leading it.
- We have always worked with an Anaplan certified consulting partner. Groupon partners with Impetus Consulting Group and we’ve had tremendous success with them. They understand our needs, fill the technical expertise gap when there is one, help us execute faster, etc. A partner who’s “been there, done that” with other customers and already knows what to watch out for is very powerful.
Hope this helps give you an example of a success story with Anaplan owned within a function. Happy to answer any other questions you have.
--Megan
3 -
Thanks for the insights! Exciting to hear about the evolution of other CoEs as we look to grow our own.1
-
Hi @ChrisWeiss ,
Thank you very much for your reply.
In Diageo we actually have a very rich experience in terms of compliance and you are describing one of the compensating controls for Segregation of Duties.
We do manage Anaplan as an IT asset though. I believe that giving the modeler keys to business makes applications explosive from many angles.
Truth be told Anaplan SOC reports do cover a lot but it's far from all. A customer has his share of compliance to adhere to as well.
However, if need be we can actually share our experience.
Thank you
Nikita
1 -
Hi @pierre_kerkinni ,
this is great stuff on validation. This is not an IT control per se, but GAR always asks for it. And that's what we tell every our new project that if data has to flow between the systems there must validation. Data is not considered loaded until it's validated.
Absolutely agree with you, ALM is a must as it gives you the tools to operate multiple controls and you mentioned one of them that covers Separation of Dev, Test and Prod.
The latter is very interesting
We've built out an internal COE management model that leverages meta data from our planning models to provide various reports of what's happening in each model. - What exactly do you mean by meta data? How do you pull it? Via API? Especially curious on how you understand how you best practices are not followed.
Nikita
1 -
Hey Serena - I just wanted to reinforce some of the guidance Chris detailed in his response to your comment.
Our group recently went through some org changes. Although we did not have to 'resell' Anaplan to new leadership we did have to demonstrate its usefulness to someone who was not as familiar with the platform. We also needed to provide them education on what Anaplan is compared to other analytic tools.
In the areas where we deployed Anaplan, a specific ROI is challenging to quantify. What I have found to be helpful outside of providing Anaplan demonstrations and user testimonials, is showing the comparison of what a process looked like before and after Anaplan. Demonstrating the inefficiencies of an old process and how Anaplan resolves them provides concrete examples to new leadership on the platform's benefits and can spark ideas of the platform can be leveraged in other ways.
I hope this helps!
-Arjun
1 -
Thanks for those valuable inputs. Much appreciated. Having dedicated model builders with 100% focus on Anaplan related activities is a vital point. As we setup our CoE, we would like to connect with customers like you and hear success stories and get feedback/suggestions.I will message you to explore options to have a quick zoom connect with you and team.
Just curious to know. Do you guys follow all/some of the below activities?
1) Create stories for all new changes (even if it is related to a small line item formula change or dashboard chnage)
2) Are those stories prioritized, vetted for benefits vs cost
3) Create design/schema, solution approach before building
4) Plan for data flow automation, data granularity, data volumes etc
5) Expert review of design/schema
6) Review the models for best practices, performance and regression testing in DEV instance
7) Refresh TEST instance with production quality data
😎 Get UAT sign-off in TEST instance, test for period-end activities
9) Use ALM to move changes to PRD instance based on clearly established release cycles
10) Clearly defined process for user access management (both on-boarding and off-boarding)
11) Update documentation and process maps
12) Provide training to end-users
13) Track tool adoption
1 -
Hi @LokeshNandula - happy to connect further if it's helpful. Below are some quick responses to your questions.
1) Create stories for all new changes (even if it is related to a small line item formula change or dashboard change) -- we do not create user stories for every change we make in a model. For example, when we're fixing something or adding a simple new field/metric to a module. We do create user stories for projects or larger additions. An area we're always looking to improve on.
2) Are those stories prioritized, vetted for benefits vs cost
Maybe need you to clarify this question. Are you asking whether we decide to create user stories depending on the benefits vs. time it takes to create?
3) Create design/schema, solution approach before building
Yes, we think design phase is the most important and where a lot of the project time should be spent. The build is actually much easier than agreeing on design 🙂
4) Plan for data flow automation, data granularity, data volumes etc
My team owns all data integrations in and out of Anaplan. This includes making sure we have the best structure set up, including level of detail required. We use Snaplogic as our ETL tool.
5) Expert review of design/schema
Same answer as #3. I will also say this is often where we have engaged with Impetus Consulting Group to help ensure the design is ready for build.
6) Review the models for best practices, performance and regression testing in DEV instance
Yes. Model improvements is a big part of our job. We are always rolling out new versions of current models that reflect best practices.
7) Refresh TEST instance with production quality data
We have PROD and DEV models in our environment (however, we currently do not use ALM). We take new copies of our PROD environment into DEV on a regular basis.
8 Get UAT sign-off in TEST instance, test for period-end activities
All of our larger projects need to go through a UAT with end-users.
9) Use ALM to move changes to PRD instance based on clearly established release cycles
We do not use ALM today due to some limitations that make it difficult to apply to our current environment. That said, we revisit often because we do think an ALM approach is a best practice.
10) Clearly defined process for user access management (both on-boarding and off-boarding)
We do keep track of employees who have left the company and ensure access is removed (although risk is low since we use SSO). We also have a standard form and manager approval process to onboard new users. This is however somewhere that my team and I need to improve as the process can be smoother I think. On our list of things to tackle this year 🙂
11) Update documentation and process maps
This is an area where we have improved a lot last year! We leverage text on dashboards and reference modules for a lot of the model documentation. In addition, we use LucidChart to create process and data flow maps that we embed on dashboards for user and admin reference.
12) Provide training to end-users
Yes. We try to host in-person trainings a few times per year, especially for new models we've just released. We also provide model builder training for builders outside the COE team.
13) Track tool adoption
Not formally.
2 -
This AMA is now closed. Thanks for your participation! Scroll down to read the questions and answers posted during our live week-long event. Want to continue the conversation? Head over to the Centers of Excellence discussion board!
0
