CoE Operational Structures
Objective: Now that we know what a Center of Excellence is and the benefits one can provide, we’ll explore the common operating structures of a CoE and their pros and cons.
Deciding to create a CoE without planning its operating structure is like asking an architect to design your new house without giving them any details. You’ll get something, but it might not be exactly what you want or need. If you already have a CoE in place, consider whether the structure you have right now is meeting your needs and how it may need to evolve. If you don’t have a CoE yet, think through the best structure for your team right now.
There are many important questions in planning your CoE:
- How should it be structured?
- What are the pros and cons of different governance models?
- Which governance model fits our needs for today, and what governance model will fit our needs three years from now?
- How many departmental teams may be interested in building on our RPA platform?
- Do we have teams of people who want to contribute or only individuals?
We recommend that most teams start with a Centralized CoE when you first begin your RPA practice. After a central team has established best practices, it’s much easier to effectively scale RPA to more teams and expand to a more scalable operating structure. Typically, teams will progress from a centralized model, to partially federated, and finally to fully federated. Mature RPA teams may consider a hybrid model as well.
Let’s take a look at a some of the most common CoE operational structures to understand the benefits and challenges for each, so that you can structure your CoE in a way that adds the greatest value to your Robotic Process Automation practice.
Note: We’ll use the terms governance structure, operational structure, and governance model interchangeably since they all refer to the operational structure of your Center of Excellence.
The centralized governance structure is where most organizations should and do start. In a centralized governance structure, most RPA development, installation, documentation, IT testing, and delivery is all handled by a single, central team. While this doesn’t scale well, it’s helpful early on as your company and team get up and running with the Automation Anywhere platform. This central team can develop and design repeatable structures and processes to be followed later when more teams get involved in RPA.
This phase is no easy task as there is quite a bit to define while you’re still learning a new platform and technology. It is also critically important. If you skip the process of defining processes as a small, central team, you may find yourself scrambling as you attempt to define standards after the flood gates are opened for federated development. Your CoE is just like a child – it will need to learn to crawl before it can walk or run.
Key processes to establish, practice, and document best practices for as a small team include:
- Roles and user access management
- How directories should be established and permissioned on the Control Room public directory
- Processes for requesting service accounts
- Documentation standards
- Engagement with the release management teams
Some teams decide to continue with a centralized governance model for a long time, and that’s OK. If you’re a smaller organization and federated development doesn’t seem like it would work, sticking to a centralized operating model is a great choice. Identify specific business units or federated teams before changing your model.
- Ensures strong adherence to governance and rules
- Easier to control since all development and delivery is handled by the CoE
- Facilitates the process of developing standards for coding best practices, reusability, documentation, and delivery
- Sets the stage for a federated or factory model in the future
- Requires incubation time for the team to determine best practices. (This learning trail will help to define as many best practices as possible, but certain processes like VM provisioning, release management, and QA testing will be specific to your organization)
- Responsibility for all development and delivery falls on one team who is also trying to get up to speed themselves
- A centralized CoE may face competing priorities from different business stakeholders
Partially Federated CoE
With a partially federated governance model, the first 1-3 federated teams (often referred to as factories) are onboarded in the initial step towards a fully federated operating model. The CoE is still doing quite a bit of heavy lifting on development and delivery. The CoE also provides guidance and enforces best practices for the newly onboarded federated teams. This includes providing for provisioned development and test machines, licensing, access to shared development resources, and the creation of new Enterprise A2019 roles. Additionally, the CoE is responsible for establishing a base bot runner VM image (likely done in conjunction with the local server management or cloud team) and setting standards for how test and production bot runner provisioning and access is handled.
If we go back to our child analogy, at this point the CoE has moved from crawling to walking. With a partially federated operating model, the organization is able to develop and deliver automation solutions more quickly than through a centralized model, and the CoE has the opportunity to be sure that its best practices around development, documentation, and delivery are meeting the needs of the federated factories.
This is likely the first time anyone outside the CoE is doing RPA development, so it’s important to reevaluate the key performance indicators (KPIs) that are being tracked for each bot to be sure that analytics and reporting meet the needs of the federated teams. (Read more about this in the Defining Success learning experience.)
After moving to a partially federated model, some companies choose to expand further to a fully federated CoE, while others find that a partially federated CoE works for them long-term. If there are a few business units with a strong need for RPA and a willingness to build their own factories, while others have less frequent RPA needs best handled by the central team, then a partially federated model is a good choice.
- Enables the federated factories access to the RPA platform to deliver bots for the functional areas they serve
- The CoE can enforce best practices, development patterns, and deployment processes
- Reusable bots and packages can be developed and shared by other teams beyond just the CoE
- Requires significant time from the CoE to train the first factories on your newly established best practices
- Federated factories take time to get up to speed on RPA and will likely ask for things or run into issues that the CoE had not planned for
- A partially federated governance model can only work if the centralized model has already proven to add value (crawl before you walk)
- The CoE’s time is now split between delivery of RPA solutions and supporting and onboarding new factories
Fully Federated CoE
In a fully federated model, the role of the CoE shifts from development and delivery to strategy and supporting factories. This is when things start seriously scaling. Business units can be responsible for their own design, development, and delivery, working within the guardrails established by the CoE. Most enterprise software takes a “my team owns this, so if you want a change on it, send us a request” approach. With a federated CoE, Enterprise A2019 should be the opposite. The stance of the CoE should be that onboarding, documentation, audit logging, reporting, testing, and delivery all have clearly defined standard operating procedures…and as long as any interested business unit agrees to adhere to those established standards, they are welcome to use the platform to automate their own use cases.
It is at this point that organizations begin to see massive ROI on RPA. Bots and packages developed by one team can be shared across federated factories so that new automation opportunities don’t require building a bot from scratch. The CoE can partner with various factories to optimize the use of bot runners across teams and explore the use of workload management to pool bot runners together.
The CoE still needs to keep tabs on all aspects of RPA. The CoE should meet with each factory on a regular basis (every two weeks or so) to touch base, let them know about any new updates coming to the platform or related applications, help them brainstorm on use case sticking points, and play the role of connector between different factories who may be pursuing complimentary automation solutions. “Oh you guys need a bot to pull CyberArk credentials? Let me connect you to Tim from the HR factory, who recently built a package that you could leverage.” In this way, the knowledge of different factories’ automations can be shared across teams, and the domain knowledge gained by the CoE during the centralized and partially federated phases can be leveraged.
The final role of the CoE in this phase is RPA evangelism and training. Be ready to provide successful case studies, demonstrations, and guidance to individuals and teams who are interested in learning about RPA. That could include showing bots in action, showing slides on how RPA has saved the organization time and money, and pointing people to Automation Anywhere University or Community Edition to start their own RPA journey. Delivering your own in-house training sessions to those that are looking to test the waters of RPA can be a powerful way to expand the impact of automation.
- Business units interested in pursuing RPA opportunities can establish their own factories
- The CoE team doesn’t need to be quite as large, as long as level 1-2 support responsibilities are handled by a dedicated support team or federated factories
- The standards established by the CoE begin paying serious dividends because every bot should use similar error handling, logging, and reporting as established by the CoE’s bot shell (see Establishing Development Standards)
- Automation efforts scale as reusable bots and packages accelerate bot development and reduce delivery times
- A significant time commitment is required to scale to a successful federated model
- Time for the CoE to develop best practices
- Time for team members to get up to speed on RPA technology
- Time to work the kinks out of the access request, machine provisioning, and factory onboarding processes
- Requires proven success in the centralized and partially federated operating models
- The CoE can be stretched thin at times if many business units want to onboard new federated factories at once
- The CoE’s value proposition shifts from direct development to supporting scaled development, so the CoE must redefine its success metrics to executives and others
Hybrid Operating Model
This is not an exhaustive list of operating structures. You may find that certain aspects of the governance structures defined above would work well for your organization, while others would not apply. That is totally fine. With a hybrid operating model, you may choose to mimic aspects of the multiple operating models. For example:
I like the benefits of scaling in the federated model, but I want to onboard teams more quickly and help get them up to speed as fast as possible.
In this scenario, you may decide that during the partially federated operating model, instead of just onboarding teams with no RPA experience on to the platform, it would be better if team members from the CoE were directly embedded in each factory to assist with bot development. As the RPA practice moves toward a fully federated operating model, you might decide that when a new factory onboards, the first 1-3 projects are done with a CoE team member embedded full time with the new factory to help get it started.
The federated model is great, but what happens to departmental teams that have some good automation opportunities but don’t have enough people to create a dedicated factory?
Nothing with these models is set in stone. Consider a model where the CoE encompasses RPA program leadership while also having some resources available to do consulting-style development and delivery for business units that don’t have the skillset or interest to establish a factory of their own. This sort of solution also serves the organization well by having trained RPA resources available that can help out with the workload of any particular factory who finds themselves overwhelmed with opportunities for automation, but short on development resources.
Final point on this: The hybrid operating model is not the same as just skipping the centralized model and going straight for federated development. There’s significant value in the CoE having the opportunity to establish best practices before worrying about onboarding and guiding others. If you choose to operate in a hybrid operating model, it should come after the CoE has proven its ability to handle the scaling and onboarding of additional factories.
- Governance structure can be customized to meet the needs of your organization
- Flexibility with the way that the organization leverages talent within the CoE or across teams
- Benefits of a federated operating model while also enjoying some of the benefits of the centralized model
- This can be a tempting solution when the CoE is asked to do too much. Be careful that your hybrid structure doesn’t take away from the CoE’s core mission of enabling the RPA practice to scale
- Veering too far from an established operating model may impact the RPA practice’s speed and scale
- This can be an exciting place to get to, but one that requires the patience, hard work, and time to mature through a centralized model into a federated model first
The CoE governance structure sets the stage for RPA success and scale. While there is room for some flexibility in the way that your CoE operates, the three established governance structures provide a progression that many organizations have found success with. Follow the path well-traveled. The governance model of the CoE should reflect the organization’s automation needs and should continue to provide thought leadership, best practices, and guidance for all individuals and teams who are interested in automating the organization’s manual tasks.