Setting up an

RPA Centre of Excellence

Acronotics Automation CoE Framework

After successful execution of a POC/ Pilot and once the first few sprints have been successfully completed (and the first bots are in production), companies start thinking in terms of scaling up the automation program. A company might have multiple business units and functional areas spread across multiple locations. There might be multiple budget holders and decision makers. There might be multiple regional variants of the same process. And so on.

It becomes important to streamline the automation program in order to ensure that resources are being optimally utilised, capabilities are not being duplicated, bot elements (components, infrastructure, best practises) are being reused, and bots built in different parts of the organisation are able to interact. Setting up an RPA CoE becomes a necessity.

The main points that need to be considered in setting up an RPA CoE are what are the different elements of the CoE and which ones should be run centrally and which ones should be federated. The Acronotics Automation CoE Framework addresses these issues.

CoE Framework

Governance Committee

The RPA GC should comprise of the leaders from those business units and functional areas (F&A, HR, Ops & Tech etc.) that are participating in the program. Irrespective of the participating areas, the GC should include exec(s) representing the CFO & the IT organisation, the former for budgetary decisions, and the latter for infrastructure, security & deployment considerations. An overall CoE Head with the mandate to deliver the automation program across the organisation is recommended and should be part of this committee.

The GC is essentially a governance entity and its main role is to:

  • Set objectives
  • Track progress
  • Give direction
  • Resolve conflict

Business Analysis Team

These are the designated RPA champions, process experts & business analysts from each business unit/ functional area. This should be a federated team, sitting within their respective units and driving the automation program within that unit.

The BA team in each unit is responsible for:

  • RPA Evangelization
  • Process Identification
  • Feasibility Analysis
  • Complexity Analysis
  • Process Prioritization

Process expertise tends to be specific to a business/ function, hence having a central BA pool does not serve a meaningful purpose.

Core Resource Pool

These are the people who actually design, build and deploy the bots. The key roles are:

  • Delivery Managers
  • Project Managers
  • Solution Architects
  • Tech Architects
  • Bot Developers

The core resource pool should be centralized, with resources being allocated to business units for specific projects, and returning to the pool after each project is completed (for reallocation to a new project).

The skills required for bot development are not (necessarily) linked to knowledge of a particular process area. Although a developer who works on multiple projects in the same process area will undoubtedly become more productive over time, optimal resource allocation is on balance the bigger consideration here. If each process area has its own captive team of automation engineers, it simply leads to isolated pockets of underutilized resources. And these distributed resource typically fail to share knowledge and learn from each other.

A centralized pool of development resources leads to:

  • Optimal resource allocation & utilization
  • Knowledge sharing & expertise transfer between units
  • Efficient gap-identification, training & re-skilling of the resource pool

Common Standards (Team)

A well-organized automation program should have a centralized, shared repository of:

  • RPA Standards
  • Design Principles
  • Best Practices
  • Frameworks, Methodologies & Tools (FMT)

The need for maintaining such a shared library is self-evident. The standards team itself can be quite small, but it must be mandatory for each project team to utilize the common standards, as well as contribute to the repository by adding new elements and enhancing the existing ones.

Bot Factory

Bots should be designed and built in a modular fashion, since every process is just a sequence of sub-processes, and many of the sub-processes are common across many processes. The most obvious sub-process in this respect is logging into (or logging out of) a particular application. If a mini-bot is built that simply logs into an application, this component can then be reused across multiple process bots.

As the automation program scales up, having a centralized bot factory with such components can significantly improve the productivity of the automation team.

Quality Assurance

We recommend having a small, centralized team of QA leads whose job is to:

  • Enforce Standards
  • Perform Quality Control
  • Set Acceptance Criteria
  • Collect & report metrics to GC

The central QA team functions as an independent third-eye mechanism, and ensures that standards are being enforced, quality is being maintained, and metrics are being reported.

Bot Maintenance

Once bots have been put into production, there is a need for a techno-functional maintenance team in order to:

  • Provide production support for the live bots (to ensure that they run smoothly)
  • Carry out minor enhancements to the bots (for example, if some underlying application is changed)
  • Ensure that BCP & DR plans are in place and can be executed if needed

The Bot Maintenance team can be either centralized or decentralized depending on the company’s context and needs.


Acronotics has developed a comprehensive CoE framework based on extensive hands-on experience of what works and what doesn’t. We recommend the following:

  • Decentralized (federated) BA team in each business unit/ process area
  • Centralized Standards, QA team and Bot Factory
  • Centralized Core Resource Pool with allocation to business units
  • Centralized or federated Bot Maintenance team as appropriate