As companies begin the journey into Intelligent Automation (IA), they often start with a Robotics Process Automation (RPA) pilot. An RPA pilot provides a test case for automation of a process and is governed more easily than an enterprise-wide program. As a pilot, the limited processes (often one process) have little impact on the entire company, and longer-term operational decisions about RPA do not have to be resolved. However, as RPA implementations expand within your organization, you will need to answer more complex governance questions regarding workforce management, vendor selection, infrastructure, robot maintenance, RPA orchestration across departments, and robot development standards. An enterprise-wide RPA governance model will eventually be required to efficiently manage numerous robots performing tasks that touch multiple business units, functions, and/or internal/external customers.
As mentioned in our previous white paper, “Plan a Sustainable, Enterprise-wide RPA Model,” ScottMadden recommends a four-step approach to create an enterprise-wide RPA program. In this report, we will take a deeper dive into establishing an RPA program (see Figure 1) and what it takes to govern an enterprise-wide program.
Figure 1: Enterprise-wide RPA Program Four-Step Approach
Three primary models of governance have emerged to oversee established RPA programs (see Figure 2). While these models typically originate with RPA programs, they may also be expanded to govern other IA deployments (e.g., virtual agent and artificial intelligence applications). The best model for an organization is highly dependent on its culture and how your company wants to make technology-related decisions. Evaluating approaches provides an opportunity to test new governance models and ensure effective decision-making for future technology decisions.
Figure 2: Governance Models
Centralized Model
Some companies thrive under more regimented, enterprise-wide technology decision-making. In a centralized model, a holistic approach ensures that technology solutions are implemented considering the impact to all business units and functions. These implementations typically avoid inadvertent impacts to other business units or functions and reduce the likelihood of redundant spending across the company. These one-size-fits-all models often create bottlenecks that slow delivery for business units or functions and result in sub-optimal solutions to specific business problems.
Hybrid Model
A hybrid model governs some decisions at an enterprise level but allows business units or functions to oversee decisions that address more immediate business needs. Unclear handoffs and ownership of decisions may result in this complex governance structure. In addition, it may not adequately scale to other lines of business or functions. The success of the hybrid governance model requires confusion on handoffs or “grey areas” of responsibility to be continually identified and actively managed.
Decentralized Model
Many companies have successfully operated with a decentralized model that allows business units and functions to make individual decisions related to their technology. These technology implementations may move faster, because less enterprise-wide consensus is required. However, technology decisions often result in solutions to very specific business problems. This model opens the door to replicated technology (and costs) across business units and functions. Decentralized models can also yield solutions that inadvertently impact other business units or functions; for example, a solution in human resources may inadvertently impact processes in finance and payroll.
How Can a Center of Expertise Support a RPA Program?
A Center of Expertise (COE) is comprised of a small group of experts that define and monitor standards and develop programs across the enterprise. Many companies use COEs to govern higher-value functions in finance, HR, supply chain, and IT, creating a more agile decision-making environment in a particular area of expertise.
An RPA COE, or expanded “IA COE,” allows the organization to strike a balance between strictly decentralized or centralized decision-making models. A COE’s focus on the coordination of operations, instead of on the execution of day-to-day activities, ensures that the appropriate stakeholders are involved in any solution. The RPA COE and its thought leaders can mitigate strategic and operational risks, while ensuring automation projects are controlled and managed and economies of scale are achieved.
Any organization that has transitioned an RPA pilot into a live production environment has faced critical questions: Who pays for the next group of licenses? Who will maintain the robots? Who will select the next process? Can we buy from a different RPA vendor next time? Who will develop the next robot? Who will monitor the development quality? Who will orchestrate to ensure robots do not inadvertently interfere with one another? While answers to these questions are easy during a pilot, they become more complex when implementing an enterprise-wide RPA program. These decisions should fall to a handful of groups: 1) the RPA COE, 2) the process owner (e.g., finance, HR, business unit), or 3) the IT department.
RPA decision categories, including a practical example of potential ownership, is presented in Figure 3. Note that this model enables flexing toward a more regimented or more autonomous design to fit the organization. Based on RPA objectives and your company’s culture, answers should be evaluated for each category.
Figure 3: RPA Decision Categories
Unless intentionally created as part of an RPA implementation, these models often evolve based on historical approaches to technology decisions. The degree of central decision-making can be tailored to your specific RPA or IA objectives and business needs. As the types of decisions are evaluated independently, you can test model variations and adjust over time until you settle into the RPA COE model that works best for your company.
Getting Started With a COE to Solidify Your RPA Journey
While multiple approaches to create an RPA COE exist, success rates are noticeably higher when organizations follow the basic guiding principles described below.
1. Put a “Head on the Horse”
Select an RPA COE leader and empower the individual to design the COE. This design entails agreeing on and documenting the specific decisions that will be made by the COE and the function or business unit. The COE leader will need strong facilitation and negotiation skills. Moreover, he or she will need the authority to mandate specific approaches and decisions, because it is unlikely that the COE will be immediately popular or its role fully clear. Once the boundaries have been established, the COE leader can focus on the additional resources needed to run the COE. Despite the level and degree of centralization, a COE should not be a large organization.
2. Build the COE Framework (see Figure 4)
Beyond RPA-oriented decision-making authority, several roles are needed to design, implement, and administer robots. These roles may be included in the scope of the COE or simply governed by it. Developing and running an enterprise-wide RPA program will require a:
- Controller – a role to monitor or determine how robot migration to production is orchestrated. Organizational visibility and awareness is essential as robots begin executing processes at a rapid pace. Any adverse or unexpected impacts will need to be addressed immediately.
- Designer – a role to determine guidelines and standards that will ensure the highest-impact processes are automated using robots. A centralized role in the COE will include designers who prioritize processes and determine where robots will be applied. In a more decentralized environment, the COE may advise business units on leading practices to identify processes.
- Developer – an expert role in the configuration of robots. Like complex Excel spreadsheets, robots can be configured using intricate scripting. This scripting is nearly impossible to explain or transition to an untrained resource. A centralized role will place the responsibility of building robots on the COE and require multiple developers. In a more decentralized environment, the COE may provide guidelines, standards, and quality assurance for business unit developers.
- Administrator – a role to monitor existing licenses or purchase new licenses from RPA vendors. A centralized role in a COE might determine the single enterprise vendor from whom licenses can be purchased and manage this relationship. In a more decentralized environment, the COE may simply monitor and report license and vendor usage. This role is often needed to calculate the enterprise-wide ROI or impact of an RPA program.
- IT Infrastructure Lead – a role to ensure that servers, laptops, test beds, and test data are adequately secured. This role is also responsible for approving production moves and developing internal procedures associated with production migrations. A centralized role in the COE would include IT resources dedicated to this function. In a more decentralized environment, the COE would allow the IT department to assume this role like any other system installation or upgrade production migration.
Figure 4: COE Framework
3. Support Organizational Changes
Employees are more likely to embrace and contribute to the initiatives if they understand the connection between the RPA strategy and the overall corporate strategy. RPA programs are sometimes perceived as a threat to jobs. The term “robots” can trigger employee anxiety, underscore rumors, or even garner attention from bargaining units. A smooth transition to RPA requires thoughtful strategies and plans to address employee concerns. Awareness and involvement from the HR department is essential. Many companies take the stance that they are attempting to “take the robot out of human work,” therefore allowing employees more time for strategic and analytical activities. Other companies target the cost savings generated by large reductions in transactional workforces. Regardless of strategy, it is important that communication is well planned and consistent throughout the organization. In addition, it is critical that risk mitigation plans are well documented and ready for deployment.
4. Track Benefits and Results Achieved
Keep tabs on milestones and benefits achieved by RPA solutions. Even if no ROI targets are expected, it is important to articulate the benefits RPA delivers to the organization. Like any project, RPA development will compete with other projects in the organization. If benefits are not clear and documented, RPA efforts may be replaced by other initiatives. Qualitative benefits derived from RPA solutions, such as supporting business continuity, enhancing information security, and improving customer satisfaction, are harder to measure but should also be considered in the overall case for change.
For more information about RPA, visit our website (https://www.scottmadden.com) or reach out directly to any of our authors below.
Additional Contributing Author: Rodrigo Adissi
