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 you structure it?

• 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 Automation 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 Automation practice. After a central team has established best practices, it’s much easier to scale Automation to additional teams and expand to a more scalable operating structure. Typically, teams will progress from a centralized model, to partially federated, and finally to a fully federated model. Mature Automation teams may also consider a hybrid model. Let’s look at 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.

Centralized CoE

The centralized governance structure is where most organizations should start. In a centralized governance structure, most automation development, installation, documentation, IT testing, and delivery are 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 duplicated later when more teams get involved in RPA/automation. This phase is no easy task as there is a lot 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:

• Migrations

• Roles and user access management

• How directories should be established and permissioned in 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.

Benefits:

• 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

Challenges:

• Requires incubation time for the team to determine best practices (Our Pathfinder Program 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 more heavy lifting on development and delivery. It also provides guidance and enforces best practices for the newly onboarded federated teams. This includes providing provisioned development and test machines, licensing, access to shared development resources, and the creation of new Automation 360 roles. Additionally, the CoE establishes a base bot runner VM image (likely done with the local server management or cloud team) and sets standards for how to handle test and production bot runner provisioning and access.

If we go back to our child analogy, the CoE has moved from crawling to walking. With a partially federated operating model, the organization can develop and deliver automation solutions more quickly than through a centralized model, and the CoE ensures 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 automation 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 automation and a willingness to build their own factories, while others have less frequent automation needs best handled by the central team, then a partially federated model is a good choice.

Benefits:

• Enables the federated factories access to the automation 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

Challenges:

• 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 automation/RPA and will likely ask for help or run into unforeseen issues

• 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 automation 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, Automation 360 should be the opposite of that territorial approach. 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 automation. 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 automation. They should meet with each factory regularly (roughly every two weeks) to touch base, let them know about any new updates coming to the platform or related applications, help them brainstorm on user case sticking points, and play the role of connector between different factories who may pursue 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 CoE can share the knowledge of different factories’ automations across teams, and they can leverage the domain knowledge gained by the CoE during the centralized and partially federated phases.

The final role of the CoE in this phase is automation evangelism and training. Be ready to provide successful case studies, demonstrations, and guidance to individuals and teams who are interested in learning about RPA/automation. That could include showing bots in action, showing slides on how automation has saved the organization time and money, and pointing people to Automation Anywhere University or Community Edition to start their own automation journey. Delivering your own in-house training sessions to those that are looking to test the waters of automation can be a powerful way to expand the impact of automation.

Benefits:

• Business units interested in pursuing automation opportunities can establish their own factories

• The CoE team doesn’t need to be as large, as long as level 1-2 dedicated support teams or federated factories handle responsibilities.

• 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

Challenges:

• 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 automation  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 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. This is totally fine. With a hybrid operating model, you may choose to mimic aspects of several 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 onboarding teams with no automation experience on to the platform, it would be better if you directly embedded team members from the CoE into each factory to assist with bot development. As the automation 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.

Another example: A departmental team has some good automation opportunities but doesn’t have enough people to create a dedicated factory. Keep in mind that we do not set these models in stone. You can customize a model to have the CoE encompass automation program leadership while also having some resources available for 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 automation resources available that can help out with the workload of any factory that finds themselves overwhelmed.

A 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.

Benefits:

• 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

Challenges:

• 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 automation practice to scale.)

• Veering too far from an established operating model may impact the automation 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

Summary

The CoE governance structure sets the stage for automation 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.

Resources

Videos

Tips for Scaling: Embrace the Co-Development Model

Blog Posts

Why You Need a Center of Excellence

Scaling with Citizen Developers