Setting up an
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.
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:
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:
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:
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:
Common Standards (Team)
A well-organized automation program should have a centralized, shared repository of:
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:
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:
The Bot Maintenance team can be either centralized or decentralized depending on the company’s context and needs.
Summary
Acronotics has developed a comprehensive CoE framework based on extensive hands-on experience of what works and what doesn’t. We recommend the following:
.png)
