How to set up the right team structure and governance model for a successful RPA journey

Bharath Natarajan
6 min readJan 2, 2021

Automation driven by RPA technology can enable operations teams in all departments within a company to scale by automating repetitive manual tasks. RPA is best suited for automating use cases where a human is performing same or similar tasks repetitively. ML/AI will be a key part of enhancing RPA capabilities by reading and understanding documents like purchase orders, invoices etc., chatbots, NLP and many other ways that we have not thought of yet.

While getting started on your RPA journey, one of the key factors for the success of the RPA program is how to structure the team in your company. You should be thinking about this while you are finishing up the POCs and selecting the right RPA tool for your company.

There are two ways to organize the RPA team structure -

1. Central COE Model — Centralize all RPA activities into one single central team

2. Federated COE Model — Certain activities like BOT funnel management, BOT development, and Support lie in the business function while the IT COE manages the overall infrastructure, development methodologies and governance across all functions.

In the Central COE model, a central RPA team in IT will handle RPA process intake, process design, development and on-going support of all processes. The advantage of this model is that it is easier to establish a common intake model and a standardized way of designing and building the bots. The big downside of this approach is the centralized intake and development process will create a bottleneck and queue for the centralized team. This will lead to a lot of unhappy departments whose bots could not be prioritized and built. It might lead to dissatisfaction towards the centralized RPA initiative and each department might eventually start their own RPA program leading to inefficiencies and risk to the systems.

In the Federated COE model, each function/department will handle the bot intake process, design, development and first level support of the bots. In this model, the IT COE will handle the central server infrastructure, relationship with the RPA vendor, licensing model, and common coding, governance and security standards. The IT COE will reside in IT and the Federated COE will reside in the various functions like finance, sales, HR, supply chain etc. The advantage of this model is the functions will be able to work on their own bots at their own pace and cost and will realize the benefits without depending on a central team to deliver their bots. The business functions understand their business processes best and they will be best equipped to build and maintain their own bots and change the bots if the business processes change. The disadvantage is that each function must build their own technical capabilities to build and maintain the bots in their own functions. This model will work well if there is tight collaboration between the IT COE and Federated COE teams and there are proper development, code review by the IT COE, security and governance standards established across the functions by the IT COE. In addition, there needs to be a committed steering committee across functions which meet regularly to manage and guide the RPA journey across the company.

For most medium to large enterprises the Federated COE model is the best way to structure the RPA team for success. This way the individual functions can move as aggressively as needed for their business and also the knowledge and responsibility get distributed across the company. If the business functions have skin in the game, they will put the required resourcing for the program to succeed over the long term. The Central COE model will work for a smaller company where the various functions do not have the resources to commit to create their own Federated COE team. Another way to go about this is even in a larger company the RPA program can begin with the Central COE model and then after a handful of successful bots in production they can move to the Federated COE model.

The below table (Figure 1) is a way to distribute the roles and responsibilities of the various teams involved in a Federated COE model. It might be slightly different setup in each company but this way of distributing work will keep all the stakeholders engaged and aligned towards the success of the RPA initiatives.

Process Owner — This is the function within a department like finance responsible for executing a process like AP Invoice Processing or PO Creation etc.

Federated COE — This is a technical team embedded within the department to help build and support RPA processes

IT COE — This team is best embedded within the corporate IT team to help with vendor relationship, license management, infrastructure and common development and governance standards definitions.

Figure 1: Federated COE Model — Roles & Responsibilities

RPA Governance Model

Once the Federated COE team structure is established, the next focus is to establish the RPA governance framework. This should include -

1. Establishing of a bot intake process

2. Development process

3. Support and maintenance processes including Business Continuity Plan (BCP)

1. Bot Intake Process

It is very important to ensure your company is working on the right processes to automate. In the federated COE model, the individual business functions decide which processes are best automated and the order of development. The below diagram (figure 2) shows how you can setup the intake process in your company.

Figure 2: RPA Governance Model — Bot Intake Process

2. Bot Development Process

Once the decision to build a bot is taken, the next step is to use the documentation provided by the process owner to start building the bot. The below diagram (Figure 3) shows the roles and the process steps for bot development. In this methodology the process owner owns the testing and running the bot (if in attended mode), the federated COE developers build the bot and the IT COE reviews the code and provides the devops support for the bot. Once the bot moves to production, the support model and Business Continuity Plan (BCP) for the bot needs to be in place.

Figure 3: RPA Governance Model — Bot Development Process

3. Support Process

The support process for the bots and identifying who is responsible for what is very critical to document even before the bot development is started. If the RPA bot is performing a business-critical process, then it’s very important that the support process is clearly understood and there is staffing to execute the model. The below diagram (Fig. 4) shows a way to organize your support process. This can be modified to fit your company’s support process.

Figure 4: RPA Governance Model — Support Process

Conclusion

RPA is not a project; it is a journey. It is very important to select the right RPA product for your company and equally important to create a well thought out team structure and governance model to ensure success of your RPA program. You can decide whether a Central COE or Federated COE model works best for your company and then use the intake, development and support model process flows shown in this article as a starting point for establishing the governance model which works best for your company.

--

--

Bharath Natarajan

Analytics and Intelligent Automation Architecture, Tools and Best Practices. https://spockanalytics.com