AMA with Chris Weiss: What is the Center of Excellence Development Maturity Curve?
Check out the questions and answers from our latest Ask Me Anything session. Chris Weiss, who runs our global strategy for customer Centers of Excellence, along with other CoE experts, answered questions all throughout last week.
Over 200 of our customers have built an Anaplan Center of Excellence (CoE). Help to jump-start your journey to launching your own CoE by checking out the video and questions and answers in the comments.
*This AMA is now closed. 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!
https://youtu.be/ua3fCxxkSu0 Comments
-
And we’re live!! I hope you find this brief video useful in orienting yourself towards the most common steps of building an Anaplan CoE. And now I’m happy to dive into the details on any questions you have, either regarding the video, broader CoE development maturity curve, or any other topic you may want to discuss regarding your CoE. Don’t hold back Anaplan Community, Ask Me Anything!
1 -
Thank you for hosting this AMA. CoE is one of my favorite topics for sure.
From my perspective the CoE is a balancing act between effective governance and empowerment. On one hand the CoE needs to enforce standards to ensure the entire ecosystem maintains compatible models, particularly with the data hub. On the other hand, the CoE needs to empower their modelers (hopefully the business users) to innovate and solve their use-cases with a minimal amount of technical support.
How have some of the most effective CoE's made this balance and what, in your opinion, were the success factors?
The challenge for most customers, I base this off of a limited number of customers I've worked with, is that their teams are too small to have all the people necessary to implement the type of CoE you describe in your video. How can they focus on the "beginner" CoE?
2 -
Hi @JaredDolich, thanks for being such a great CoE advocate to your clients!
Great question, and you're absolutely right that the best CoEs have found a balance of removing themselves as a bottleneck to model development while ensuring consistent quality and adherence to best practices.
What I’ve learned from these customers is that working towards this goal doesn’t start by achieving 100% of both, but rather prioritizing enablement of business users (empowering modelers as you said), and working as hard as possible to support them through any errors they face or defects that are inevitably caused, as quickly as reasonable given limited resources.
When done best, success here looks like an exponential increase in the creativity of problems solved within Anaplan by outside modelers, which should be released in increasing speed over time.
Here’s an example of what this looks like in real life. One of our strongest CoE leaders told me that they knew they had achieved success here when they were conducting a model audit one day, and stumbled onto a really complex set of calculations that they didn’t understand. After investigating further, turns out that several months ago the business had used Anaplan to completely solve one of the biggest challenges the company had been facing for years, all without the CoE ever knowing. Of course to get there that particular CoE leader had spent a ton of time cleaning up peoples’ messes first, and there were still some elements of the build that had to be tweaked to come into alignment with best practices, but it was worth it for this solution that the CoE had never even thought to bring into Anaplan!
Hope that helps!
3 -
@ChrisWeiss Thanks for starting a AMA session on COE! Could you share your wisdom on how to maintain a COE structure when the executive sponsorship is affected by a company re-org?
3 -
@ChrisWeiss If Anaplan customers are limited on resources for building their COE, what's the best steps to take to get some buy-in to invest in a COE?
2 -
I have a question regarding ALM deployments. Most IT departments have rigorous change control processes to minimize the risk of users being adversely impacted by the introduction of new code to Production. A deployment checklist may include validating that the change was approved, the code reviewed and testing completed. Do you see the COE providing this governance? if so, what factors should they consider when determining how much formal process their organization needs?
4 -
What advice would you give to ensure that a CoE continues to advance their Anaplan footprint though new use cases? In the early stages of CoE I would presume there is often a slate of projects that can be tackled and a backlog of model building to take on. But what happens when the pipeline starts to dry up, is there a point at which you go fully into "maintenance mode"? Appreciate any insights you would offer.
3 -
Hi @serena.zhang, thanks for the great question, lots to dig into here!
I’ll start with some honesty, I haven’t see a a whole lot of examples of this in general. That said there are some commonalities across the few examples that I have seen, and realistically they all have to do with the actions of the members of the CoE, regardless of team size.
The first and probably most impactful way to maintain the CoE structure through leadership changes is to have a strong Anaplan technical expert (hopefully a Certified Master Anaplanner, like you Serena!) take responsibility for maintaining the day-to-day consistency of the Anaplan footprint, almost like a grassroots effort to maintain governance regardless of formal org structure. This is even more helpful if there is a visionary CoE Leader on the team to also maintain order (keep an eye out for upcoming resources to launch soon describing this in more detail), though realistically in this situation the technical expertise is more critical than the CoE Leader role.
Then it’s the job of that Master Anaplanner to roll up their sleeves and demonstrate key wins to the new executive sponsor (if one has been assigned), or to take Anaplan on a road show to ideal new exec sponsors. Things I’ve seen succeed are demonstrating ROI from previous implementations, sharing praise and comments from business users who have benefitted from Anaplan, or even just quickly building Proof Of Concept dashboards to demonstrate speed and value in the language of the new exec sponsor(s). This idea of “internally selling Anaplan” to executives is a great way to ensure you maintain control over your CoE structure (by helping your leadership appropriately understand the benefit of this team’s existence and your role in defining the best path forward), and is also a great way to accelerate your career growth as part of this hypergrowth ecosystem. Along those lines, Arjun Rai and Kyle @sakowski27 just finished describing this in more detail in our interview from a few weeks ago around the 17:10 mark, and of course I recommend checking out the whole interview.
If executed correctly by somebody like you, senior leaders should begin fighting over who gets to own the Anaplan footprint and CoE, and your job becomes picking and aligning to whomever has the best strategic vision for enabling Connected Planning at the company, leveraging your past success and role as the Anaplan SME to ensure you have a say in the matter.
The examples I’d reference are from customers who recently underwent an acquisition, where they maintained a leadership role in their CoE by having the more successful series of Anaplan implementations, and also from another Certified Master Anaplanner who moved from one region with a strong CoE to another region with no CoE, who was able to leverage his mastery of the Anaplan platform to generate the political capital necessary to receive approval to build another team in his new region (not that there should always be separate regional CoEs within one company, but that’s a story for another question).
Really great question with lots of room to elaborate further, hope this helps!
3 -
Hi @Agandhi, this is a really common question, thanks for bringing it up!
I’ll start with the fact that it’s alright for an Anaplan CoE to start small. We see very successful CoEs managing several production use cases with 2-3 full time employees. The CoE should grow and scale over time with the Anaplan footprint, so the best way of approaching your question is to pivot slightly from focusing on expanding the CoE team and towards expanding the business impact and benefit of the Anaplan footprint within the company (promise I’m not getting sales-y, I’m not talking about buying more Anaplan licenses necessarily, but more along the lines of building more use cases/models or whoever you can provide additional value to the business). This way the limited resources on your current CoE are seen as a roadblock to additional success, rather than a cost to be minimized.
In order to accomplish this, it’s critical to measure and report the key successes of the current team. We are definitely in the early stages of maturity in terms of CoEs reporting internal ROI metrics, but it’s something we’re starting to see more of, and will share out more examples in the coming months. In the meantime you can review some of the success metrics we report for our customers at anaplan.com/customers, though you may already have a good sense of the benefit you’ve provided.
And if those metrics don’t make the strongest case on their own, I’d recommend peeling away to find some time to build some quick proof of concepts to demonstrate the potential for Anaplan to solve new challenges or use cases to key executive sponsors. When leaders can see the speed and value you can bring to the business, it becomes much easier for them to invest in expanding your team, since there’s a direct benefit to the bottom line (not just the cost of expanding your team).
That said, you may not even have your 2-3 FTEs. If that’s the case, I would recommend reviewing some of the customer CoE success stories that are out there (CPX 2019 SF CoE panel, CPX 2019 London CoE panel, Anaplan Live! customer panel, etc.), or connect directly with a similar Anaplan customer as a reference, to help show your leadership team that you’re prepared to help maximize the value of the investment they’ve already made in Anaplan. Nobody wants to leave money on the table, so finding similar relatable customers who have articulated the value they received from building even a small CoE may help you get the ball rolling.
Wishing you the best of luck with your additional investment, hope that helps!
3 -
Hi @Ellen.Morley,
Thanks so much for the detailed question around deployment management, definitely a key area of focus for CoEs that want to prepare for (or currently manage) multiple use cases/departments.
Yes, especially where required by IT I definitely see the CoE as being responsible for providing an ALM deployment checklist. The CoE are likely the ones with the most experience both with ensuring successful deployments, and the internal procedures and politics around working with IT.
It’s also worth not in that we recommend that IT play a supporting role in every CoE (more details here). I mention that because in situations like these, especially where required by IT, somebody from that IT department should already be regularly engaged with the CoE and should help in co-creating this document. In typical business-run CoEs this may be the first SDLC or deployment process they have managed, whereas IT has much more expertise here, so definitely take advantage of their experience.
I’ll specifically point to an excellent CoE forum post by 2019’s Master Anaplanner of the Year @bdeaton, who described her CoE’s very detailed approach to testing and documentation before every deployment.
You make a great point around wondering how formal this process should be, and of course this will be different customer to customer based on internal policies. That said, since one of the primary goals of the CoE should be maintaining agility and providing increased speed to value, the bar really should be set at requiring as little formality as possible to ensure successful deployments while complying with IT policies.
Thanks for the great topic, hope that helps!
2 -
Hi @Tiffany.Rice,
Great question, roadmap development is directly related to the final stages of building a mature CoE.
The short answer to your question of CoEs entering “Maintenance Mode” is that while there are definitely some of those out there, I wouldn’t personally recommend that as an aspirational goal until true Connected Planning is achieved across your entire company! (How’s that for aspirational?!)
I have seen plenty of mature CoEs whose primary goals are proactively taking Anaplan out to different areas of the business, demonstrating the value of Connected Planning (or even just Better planning, for that matter), and then have responsibility for the process of scoping the work and overseeing the implementation (whether they own the actual model build or not). Some of the customers I spoke to on CPX 2019’s CoE Panels discussed how they approached this topic (Maria Milazzo in San Francisco ~8:41, and Ashley Stevens in London ~23:45). At the end of the day, the best CoEs are those who achieve Connected Planning, not just those who build and manage the best Anaplan models.
Along those lines, we recommend that all CoEs build their Connected Planning Topology/Honeycomb/Roadmap, or whatever you want to call it. We’re in the early phase of building an accelerator for CoEs to manage this, tagging in @Beauram to loop you in on the pilot group if she hasn’t already. Hopefully these tools help make it easier for CoEs to tackle the more administrative parts of this mission.
But building a roadmap isn’t just about putting a bunch of hexagons on a slide, it requires transformational leadership. For CoEs who have successfully completed their backlog and have become a well-oiled machine efficiently managing the day-to-day with spare time on their hands, you have earned the right to take on this higher level challenge. This is your opportunity to pivot to become exponentially more impactful in your work and be at the forefront of bringing the Connected Planning vision to life at your company. While you may need a Chief Planning Officer to help make the path a little easier (more resources to come there soon), if you’re in a position to chart your own course you can absolutely be the change in your organization. And along the way you may even set yourself on the path to achieving this role yourself, along with countless other career opportunities.
Thanks for getting me started on this great topic, I’m sure many of us here could rant on about it forever, hope this is helpful!
4 -
Thank you for the COE AMA! I often think of a COE being very cumbersome and complex to implement, but I appreciated how you simplified it. In your experience, what is the most common disadvantage of a COE once it's been implemented and are there actions that can be taken to overcome that disadvantage?
3 -
Hi @TaraTCG,
Great question, and thanks for the feedback that you think this video helps make CoEs a little more approachable!
I’d say that I see 4 potential disadvantages of CoEs, which I’ve seen most often in groups that unintentionally slipped into an informal “CoE” without much forethought (who then need help rectifying these issues):
Potential Challenges:
- Becoming a bottleneck or source of red tape if they become overly centralized in nature,
- Decelerating the speed to new value as they grow,
- Struggling to maintain internal investment (both time and money), and
- Pigeonholing the team as an application management/support function vs. a true transformation connected planning engine.
And here are the most effective solutions I’ve seen in combatting those challenges, in respective order:
- Building strong internal processes: As a CoE shifts from focusing on chipping away the backlog or putting out fires, they quickly need to focus their attention on creating scalable, repeatable, consistent business processes for things like managing new requests and maintaining recurring meeting cadences, including providing some documentation. This should help the team become more comfortable with the moderate level of decentralization that follows, while unlocking their productivity to keep up with the business.
- Prioritizing internal enablement: Every Anaplan customer should have at least one Certified Master Anaplanner (or somebody in the application process working towards becoming one). And as the CoE matures, the original founding members and Certified Master Anaplanners should shift their attention from focusing entirely on model building activities towards primarily focusing on internal training and enablement activities. When they become a multiplier, the CoE can focus on providing exponential new value at scale, while helping end users identify for themselves how Anaplan can be used to continue improving their business processes (and take less of your time with basic support issues).
- Identifying strong visionary leadership: As the CoE continues demonstrating the successful outcomes the Anaplan footprint has provided to the business, a Chief Planning Officer or visionary Connected Planning executive sponsor will understand that limited resources prevent realizing additional value from the current Anaplan investment, so the decision to invest in expanding the team shifts from being a net cost to a net benefit. Additionally, this executive sponsor is critical to ensure that the CoE continues focusing on connecting the company’s strategic objectives to the tactical execution planning conducted in Anaplan. In other words, they provide value by making sure model builders are prioritizing building the right things in Anaplan, which helps prevent anybody from underestimating the CoE’s value.
- Maintaining close proximity to the business: As CoEs grow and become more centralized, inevitably somebody tries to move the group to a more “logical” place in the organization. This is often a mistake (varying from customer to customer of course). The CoE must stay as close to the business as possible and maintain their role in achieving transformational Connected Planning, rather than just supporting one or two production applications. Even as CoEs expand across many LOBs, the bulk of the team should be made up of business users from each of those LOBs, which will help ensure that business outcomes are continuously prioritized and improved as capacity allows, rather than becoming a mini-IT support department for what should be a primarily business-owned platform.
I know that your team in particular has lots of great thought leadership on helping your clients avoid most of these pitfalls, so please feel free to add more details that you think other customers might benefit from. Thanks for getting this great topic started!
3 -
Hello @ChrisWeiss
Thank you for doing this AMA on CoE. A very interesting topic. I have a questions that is not purely CoE related but I thought I would ask it.
We would like to set-up an engagement model where the CoE develops all the models and does all the enhancements (and basically owns all Anaplan development related activities) but the business owners run the model maintenance. And by "model maintenance", I mean mainly:
1) Create the new versions (weekly, monthly, quarterly depending on the process). More often than not, we use a standrad list for versions
2) Bulk copy the "prior" version into the current one. That way the starting point of the new version is equal to the prior week and users onyl need to update the changes
3) Gather enhancement request from users
The problem with this set-up (in particular item 2) above) is that the business owner would need admin rights and we would like to avoid that.
Have you come accross a similar scenario? How can we manage the process differently without moving all the "model maintenance" tasks to the CoE?
Many thanks in advance for your insight.
1 -
Hi @fabien.junod,
Glad to hear about the progress you’re making with your CoE, thanks for sharing your engagement model thoughts. For what it’s worth this is a common CoE setup that is working very well for many other customers, so you’re in great company! I’ve seen this exact situation approached two different ways, and would be interested to hear from you if your group has come up with any other creative solutions here.
The first solution is of course to replicate standard Versions and Bulk Copy functionality in a custom build, so that end users can activate these business processes from a Process action published on a dashboard. I’m sure you’ve considered this, and there are lots of reasons many customers don’t take this approach based on their specific situation (and of course we recommend using standard functionality wherever possible).
The second solution that I see customers land on more often, is identifying at least one model builder in each group who would have admin rights. If your concern about providing admin rights is around access issues, it’s worth looking into ways to use Anaplan itself to help you manage what your admins are up to (think Tenant Administration, splitting models across multiple workspaces, reviewing model histories for user audits, general offline governance approaches/expectations among your team, etc.). And we’re also piloting a broader CoE solution based on how our Anaplan-on-Anaplan team manages this issue, if you aren't already involved please let us know if you’d like to be included or otherwise keep an eye out here for updates from us and @pierre_kerkinni.
Otherwise, if your concern is around the cost implication, I recommend front-loading the effort of ensuring exponential value that the group will be gaining from this investment (beyond just the ability to bulk copy). For example, while these power users within the business units are collecting enhancement requests, can they also be responsible for quickly building lower complexity items within guardrails set by the CoE, and does that increase the speed to value for that group? Can they serve in a “part-time” role on your CoE (say 20%) and act as the model builders on implementations for their business group to help prioritize the needs of their team and ensure resourcing constraints don’t slow the CoE down?
To get to your point, I fundamentally agree with you and believe that the business SHOULD own these tasks, and the job of the CoE is to remove any barriers preventing that from happening (for example cost/business justification, user audits, and/or admin enablement and expectation-setting). We all know the time invested in these activities is far more valuable than time spent owning the model maintenance tasks, even if at first they both take the same amount of time.
Hope that helps, let me know if you'd like me to go into more details on any of these ideas, and good luck with the next step of your CoE!
1 -
Hi Chris,
Should model building be with business or IT?
As organisation start using Anaplan as an enterprise planning platform, there should be expert architects and model builders to envision the larger picture, scalability and usability of functionalities developed in Anaplan. Encryption, security, access management, automation becomes the priority. Often, business users come with 2-3 years of total experience and lack application knowledge and domain/functional expertise to design a solution. What is Anaplan's guidance to customers building world class planning platform?
2 -
Hi @ChrisWeiss, How would you see the role of Partners play in a Customer's CoE? Do we provide guidance for them to setup a CoE and provide long term support?
1 -
I consider model governance the most important aspect of our Anaplan COE with the goal being to improve the reliance that people can place on all of our Anaplan models. I definitely see governance as a value add process and not an exercise in compliance, so I try to always focus on what we get out of performing a governance process before making it mandatory in our system.
A huge part of our model governance centers around making and deploying changes to existing models. I would say that our approach was to try to develop a process that would balance an appropriate level of simplicity (so as to encourage model builders to follow the process willingly) with mitigating against model risk. We definitely pulled in elements of IT change management processes, but tailored them to meet our needs. We established the process, then trained up all the model builders on it, and are regularly involved in performing the necessary steps (COE approval is required for every promotion and we are the only ones who actually run the promotion processes).
As for factors to consider: They key factor is all about risk - you need to understand what the risks are and then determine how much risk your organization is willing to take on vs mitigate. Check in with your stakeholders to ensure you understand what risks they are concerned with. Remain flexible and express that to your model builders so they will provide open and honest feedback about the processes you've put into place - they may understand the risks better than others since they are most involved with the details, so their buy-in is key. Layer in changes over time and demonstrate the value that the controls add so you can get buy-in from model builders and stakeholders. Connect with your internal audit partners. It's their training to identify risks and assess controls. Leverage that expertise and run ideas by them to help determine if they will be effective in controlling risk.
2 -
Good day @serena.zhang,
I have actually dealt with both of the issues you have highlighted below.
The first obstacle my team faced was getting executive sponsorship behind us in order to pursue a COE. As an FP&A team we saw the benefits and need for more structure and organization around administration and maintenance, but we only would pursue a functional COE if we decided to go ahead and up our contract to the enterprise license. Long story short we opted out and our COE discussions everything was put on hold.
The second obstacle the team faced was that our boss (who was working on developing and pitching a COE/new position to executive management) decided to leave. So our teams COE dream was put on hold until further notice.
What We decided to do as a team was to begin operating any Administrative/maintenance/enhancement/defect requests just as a working COE would. Collecting and prioritizing these and then having weekly meetings on timelines in order to make sure Anaplan was operating both efficiently and as user friendly as possible. This has allowed us to 1. Collect/address/adjust our model accordingly and in a timely fashion 2. Create more structure around revision tags for Audit Purposes, and 3. Provide a foundation that could easily transition over to a full time COE in case the case that executive sponsorship finally hops on board.
Hope this helps!
Best,
Kyle
1 -
Hi @UpaliKW,
Great question, as with everything in the Anaplan ecosystem we work extremely closely with our Partners to ensure the success of our customers along every step of their journey, including building and scaling a CoE.
I’ll share two of the most useful resources that I’ve seen lately when thinking about the relationship between Customer, Partner, and Anaplan in terms of CoEs. First, we’ve learned that the best time for new customers to build their CoE is during their first model implementation. Partners typically take the lead in this step of the customer journey, and we’ve identified a simple roadmap to help Partners support our customers build a CoE as part of The Anaplan Way.
During UAT, when customers begin releasing Anaplan to their end users for the first time and collect test script feedback, Partners are typically responsible for managing any defects and issues that will prevent successful go-live, but typically lots of out of scope and enhancement requests also come up. We recommend using the attached template to split responsibilities between customer and Partner, with the Partner owning the dedicated UAT activities, and the customer owning the CoE-Lite activities, as the foundation for what will become their Full CoE after deployment. This also helps the Partner focus their time and attention where they can add the most value during the sometimes chaotic time of UAT, on fixing in-scope defects that are critical to the success of the initial deployment.
Additionally, our most mature customer CoEs have developed very robust, evolving relationships with their Partners as they take on new roles with the Customer, everything from providing complex technical solution architecture across all cloud platforms and providing thought leadership on Connected Planning and how to achieve excellence in planning in specific LOBs. Our most recent customer interview panel went into some details here, especially around 5:17.
Thanks Upali, always glad to make sure the Partner perspective is included in everything we do here, great question!
0 -
Hi @LokeshNandula,
Thanks for bringing up the contrasting roles of business and IT, this something I’m asked very frequently and realistically the answer is slightly different for every customer.
I’ll start with the most common answer, that Anaplan is meant to be a business-owned planning platform, which leverages Excel-like formula syntax to shorten the learning curve as business users transition from planning in spreadsheets to Connected Planning. The benefits of the business owning Anaplan is that they are the most qualified to ensure that Anaplan directly addresses their planning needs, and can be responsible for adjustments to the system as their planning environment remains fluid and flexible. Or from another angle, most IT teams don’t want to receive a support ticket every time a business user needs to make a slight adjustment to their planning or forecasting process (which would happen weekly, if not daily in some cases!).
That said, you’re absolutely right that most business owners are not experienced in managing and architecting a scalable, enterprise-grade cloud platform. This is a new skill for many of them, which is why we are investing so heavily in providing these resources around how they should manage their CoE (and of course we know we still have a long way to go here!). The benefit to IT playing a role here is in sharing common best practices in software management that apply across all technologies, regardless of how flexible or intuitive they are to learn. In other words, most business users don’t have a decade of experience designing Software Development Lifecycles to migrate new functionalities from a development sandbox to a production environment, and we certainly don’t want to discredit the in-house expertise that the IT team already has in this area.
Every CoE should have representatives from both the business and IT in order to ensure a successful holistic Anaplan implementation. We like to recommend a “best of both” world where IT owns software-related elements that are technology-agnostic (integrations, data management, documentation, etc), where the business owns planning processes, model building, and dashboard design. There are more details about this breakdown on our Roles & Responsibilities article (3rd graphic from the top).
That said, this exact breakdown is different for every company. You may find a great deal of success having your Certified Master Anaplanners (or global solution architects) located in IT due to their expertise in developing scalable enterprise-grade solutions. Or your entire team may be located within the business, with occasional requests over to your IT team for occasional data feed updates, and learning the new skill of enterprise solution architecture to build the best Anaplan models.
The thing that is most important is that for your company, your CoE needs to maintain a strong relationship across both groups. And isn’t that the whole point of a CoE anyway? Breaking down corporate silos of traditional planning? Why not start here, breaking down the silos between IT and Business!
Hope that helps, definitely curious to hear your views and from others who are struggling with similar dilemmas!
1 -
@ChrisWeiss Thanks for detailed answer. We are defining roles, responsibilities & skillset for Anaplan COE and its always challenging when model building is owned by business. Customers look upto Anaplan for guidance and it would be helpful if the skillsets are defined for model building & architect roles.
We come across many Anaplan model builders and architects (including some master anaplanners) with only 2-3 years of overall experience. They lack below skills which are mastered with 7-10 years of project delivery experience. These skills are necessary for successfully delivering enterprise level projects. We don't find these skills in business users and experimenting with them is risky for large projects.
1) Experience running large projects at enterprise level
2) Experience in designing, developing solutions in legacy planning tools like SAP BPC, Hyperion, Cognos
3) Experience in converting business requirements into scalable technical solutions
4) Experience in MDM (Master Data Management)
5) Experience in creating dashbords or ad-hoc reports in Tableau, BOBJ etc
6) Understand the difference between meta data & transaction data
7) Experience in setting up hierarchies
😎 Experience handling sensitive and non-sensitive data
9) Functional & domain experience
10) Experience in leading requirement gathering sessions
11) Experience in documenting business process
12) Experience in articulating data requirements, data granularity, data flow
13) Experience in managing enterprise level projects (say 30+ team members, >$2 million initiatives)
14) Experience in sizing, scaling & looking at big picture (support & maintenance issues etc)
15) Experience in interviewing, selecting right candidates for model building
As always, looking for your thoughts and valuable guidance here.
1 -
Hi Chris!
Could you please share how the CARM controls and model health are addressed in CoE models that do not manage Anaplan as an IT asset?
Thank you
Nikita Gnilozub
Diageo Anaplan CoE Anaplan CoE Solution Architect
2 -
Phase 1 Implementation: Compensation System
- Due to efficiency gain: Removed 2 commission analyst HC ($200K Annually)
- Re-purposed 1 Commission analyst HC as Anaplan admin to manage the model enhancement and maintenance
Phase 2 Implementation: Segmentation and Territory Management
- $200K internal costs assumed funded by leveraging existing annual Go-To-Market spend on OBI Enhancements (6 months of consulting engagement every year). No need to manage/support OBI Rules.
- Hired 1 person to manage Segmentation and Territory Management in Anaplan for $100 k (savings of $100 K on GTM spend)
- Later the same person managed Quota Planning as well
Phase 3 Implementation: Product P&L by Finance team
- First federated CoE model
- Productivity gain from 4 weeks to 2 days
- Resource re-purposed to build other P&L modeling
- Later full time part of CoE (Federated) to help build FP&A applications
1 -
Thanks @prakash_harihar, really appreciate you sharing your experience here! And for everybody else who doesn't already know Prakash, he works at Anaplan now but is famous in the land of CoEs as the leader and creator of our first ever Customer CoE from his time at McAfee. Many of the foundations for our customer CoE strategies come from his work, so thanks Prakash for everything, and these details should be very useful as other CoEs look to find additional funding and support for their teams!
0 -
Hi @LokeshNandula,
Great points, it's very helpful that you've outlined this thorough list here!
I think you're absolutely right. If these are the required skillsets for your company in managing your Anaplan footprint, it should absolutely be heavily dependent on IT resources and/or an implementation consulting partner. We're in agreement that these skills would be very rare to find within the business, and in this case the business would still of course play a critical role in providing user stories/business requirements as well as feedback on your implementations.
That said, I think many Anaplan customers are not quite looking for that level of expertise in managing their planning applications in Anaplan, especially at first. I know you all are doing some very big and exciting things with Anaplan, so your situation is unique, but also we can point to just as many examples of finance or other business users accomplishing complex technical requirements in Anaplan on their own.
Either way, this will of course vary customer to customer, and you're absolutely doing the right thing for what your company needs, and if other companies have similar needs they will probably skew more towards IT-reliance than being entirely business-owned, I'm just not sure exactly what percentage of customers fall into your same category here.
Thanks again for putting together these exhaustive list, excellent resource to be added to the CoE resource library!
1 -
@Tiffany.Rice @ChrisWeiss @Beauram
The topic of COE's being the drivers of their organization's connected planning journey is a really interesting one. In my experience I don't often see the backlog "dry up" after a few models are in production - it is often the opposite. If the value of these models can be demonstrated across the organization, new business units and functional areas will start lining up at the opportunity to get into Anaplan. At that point it often becomes a prioritization effort in which many important factors need to be considered.
At Cervello we think about this prioritization effort in two phases. The first is a scoring exercise in which all potential use cases are scored against a series of measures (e.g. business impact, data readiness, etc). This exercise will help segregate the near-term use cases from the mid-term and long-term use cases. From there, creating the time-phased road map is dependent on additional factors such as key planning milestones and process dependencies.
3 -
Hi @Tiffany.Rice,
Passing along a direct response from Ashley Stevens, CoE Leader at Aviva, who had this to say on your excellent topic. As you can tell from the number of replies on this question, you really hit a nerve in terms of something that is very top of mind for CoEs these days!
"I don’t think you ever fully enter maintenance mode. The Anaplan transformation journey to get to a connected planning end state is ever evolving: bringing in new areas, rebuilding legacy models, adopting the NUX, etc....
The key transition for us was moving beyond a reactive approach where projects were initiated by end users (generally following a conversation with Anaplan) to shaping our own strategic roadmap. All current / pipeline activity is focused on moving us closer to a connected planning end state as well as revisiting legacy models to ensure best in class solution. Key to doing this successfully is having the right roles and responsibilities in the team to ensure we deliver end to end transformation: Data / Solution Architect owning the roadmap, Process Engineers designing the E2E solution, Model Builders, BAU Maintenance Analysts, Governance Lead - and using third parties to augment these skills where appropriate.Hope this helps.Kind regards,Ashley"1 -
Great question, managing compliance controls like Diageo's CARM or more general SOX compliance is starting to come up more often.
In complete transparency, it isn't something that I have much experience with and these usually require very strict formal approaches, but I do know we will need to provide more support here as this catches up to becoming a priority for more customer CoEs. So I can offer a few high-level customer examples, and hopefully some others from the community can chime in here as well.
First, I've seen customers lean heavily on the Model History to manage this. Some creative customers have built input modules that are structured the same as the export from the Model History, so they run a Model History export at regularly scheduled intervals, then upload the file back into an Anaplan module, and use that for compliance and audit reporting. I know that I'm oversimplifying a pretty complex process, especially for a group like Diageo who manage MANY different models, but it might inspire some ideas.
I also am aware of some customers who have tried to use Tenant Administration to manage this, though I think this provides limited usefulness at this time. But worth taking a look.
And last I would say this is definitely something worth partnering closely with IT on. Aligning to internal policies and procedures is probably your best bet here, especially in the short term (I know your group is unique here, but this should stand for most other customers with a similar question).
Hope this helps for now, knowing that this is an underdeveloped topic that definitely needs a closer look!
1 -
Hi @Nikita_S_Gnilozub ,
To elaborate a little on Chris's recommendations, we've implemented a few strategies internally at Anaplan that've allowed us to mitigate risk. We start by ensuring all data coming in from our transactional systems and data warehouse are validated. We do this through a series of checks both in our data warehouse and anaplan data hub. By knowing our data is accurate, it allows us to plan more confidently. The second thing we've done is required all business critical models to be put on ALM. This helps us properly test all changes before we deploy them to production. Lastly, 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. This includes having a way to more easily filter through various model histories, track user access, and flag instances where our best practices aren't being followed. We're actually in the process of taking features from our internal COE model to standup a template for our customers to use. Stay tuned!
2
