Govern Your Bots!

Leveraging robust step-by-step documentation and exception handling, bots build upon the knowledge of subject-matter experts who have carried out business processes for years to deliver pristine, audit-ready automation solutions. Yet these solutions don’t come without risk. As you begin to implement bots and develop automated processes, it’s imperative to be prepared for mishaps, both expected and unexpected.

Governance mitigates this risk. Patrick Hauck, head of RPA Practice at Novatio Solutions, says governance is about “delivering business value to stakeholders in a transparent, compliant, and sustainable manner.” Describing it as a framework for identifying, assessing, and managing risk, Hauck states governance is “essential for any digital transformation program,” particularly for a technology with a low barrier to entry like RPA. But before walking through the keys to successfully governing bots, let’s establish a baseline with a bit of RPA basics.

WHAT IS RPA?

RPA is technology that enables a robot—the digital worker or “bot”—to execute processes by emulating human interaction with computer applications. In other words, a bot mimics the clicks and keystrokes a human performs to carry out a specific task. Navigating through desktop and web-based applications simply by accessing the user interface, RPA offers a lower-risk alternative to traditional automation—with minimal to no computer coding required in many instances. Picture an Excel macro that isn’t limited to Excel but, rather, can interact with anything on your computer screen.

Most RPA software is made up of three primary components: the bots, a bot manager, and a workflow design module. The bots perform processes; the bot manager enables scheduling and allocation of developed processes; and the workflow design module is where processes are developed. It’s a common misconception that RPA developers develop bots—they don’t. They develop the processes that bots will perform, an important point that will prove most relevant when progressing along the governance journey: The governance for the developed processes will have similarities to existing IT controls, but governance for bots will parallel that of human employees.

There are two types of robots that can carry out the developed processes: attended and unattended. There are solid use cases for both. Attended robots require a human to initiate the process through some form of trigger on the computer (like clicking a button) and may require additional human interaction at varying points during the process. Generally, the user’s computer would be unavailable while the bot is performing processes on the front end of the machine and only becomes free when user input is required. For example, consider month-end close processes within the financial system that require immediate review before it’s possible to proceed to the next step.

Unattended robots run on a schedule in the background and without any human interaction at all. Because the work gets done without any human input or trigger, humans are free to perform other tasks while the bot executes the process. Use cases can range from invoice processing or setting up data records to reconciliations and financial-report generation combining multiple data sources and identifying exceptions for human review.

At the enterprise level, the overall operating model for the RPA program takes one of three different forms:

• A centralized model typically has a Robotics Operations Center (or Center of Expertise) that oversees and is responsible for RPA governance and infrastructure while leading process development for the entire company.
• A decentralized model involves a central team focused primarily on governance and infrastructure, with hubs deployed within various business teams leading implementation for their respective areas.
• A federated model places the power of governance, infrastructure, and implementation in the hands of individual teams or departments.

Decentralized or federated models can also include “citizen developers,” which are users from various business units who have other full-time responsibilities but have been given access to the RPA software to develop impactful solutions benefitting their team.

Other critical decisions to be made are whether RPA implementation will reside within a business unit, such as a finance or operational team, or within the IT group. Despite where the overall initiative resides, you also need to determine who will be allowed to develop opportunities—business professionals, IT professionals, or both?

These strategic decisions about the implementation approach will ultimately inform selection of the RPA tool, capability development plans, governance models, and ownership of controls.

BOT GOVERNANCE

There are risks to any RPA implementation. In the white paper “Internal Controls Over Financial Reporting Considerations for Developing and Implementing Bots” (September 2018, bit.ly/2LfMjeM), Deloitte identified five areas of key risks related to RPA: operational, financial, regulatory, organizational, and technology (see Table 1 for risk examples in each of these areas). The key to sustainably leveraging RPA to deliver business value while strengthening the control environment is governance.

Effective RPA governance proactively embeds robust preventative, detective, and corrective controls above and within operational processes with the intent of mitigating risks. Hauck says, “Risk management is a critical component of governance, and the strategic risks of not realizing intended benefits or the interruption of critical business processes can mean losing the competitive edge for an organization.”

So how do you govern bots? Not terribly differently from the way you govern humans. Businesses establish policies that address the broad spectrum of employee behaviors—everything from outlining the processes humans can perform and the type of system access they may be granted to detailing the business continuity procedures that should be followed in the event normal processes are impeded for reasons outside the workers’ control.

Following the premise that bots are digital workers, policies should be established specifically to govern their activities. Bots should be governed through written procedures that define how automation candidates will be selected, how data will be secured, who will carry out implementation, what standards development will be held to, and how benefits will be realized.

Five critical actions should be completed to ensure governance procedures are relevant and fit for purpose:

1. Identify key stakeholders and proactively seek their input. This includes getting feedback from and involving a number of individuals and business areas, such as:

• Program sponsor
• Senior IT leader
• RPA program lead
• Key senior business leaders
• Lead architect
• Internal control
• Internal audit
• External audit

2. Determine the RPA operating model. This includes whether it will be centralized, decentralized, or federated; whether the implementation will reside with IT developers, business developers, or both; and whether citizen development will be allowed.

3. Conduct an RPA Proof of Concept (POC) and select the RPA tool. To prove that RPA technology is a feasible and valuable solution for your organization’s processes, applications, and future developers—and to ensure you’re able to select the best RPA tool for your operating model—conduct a POC with the top RPA software candidates (see “Conducting an RPA POC”).

RPA tool selection also should be informed by the type of RPA implementation model chosen. For example, if business professionals are leading process development, you may want a tool that’s more intuitive and requires less coding. This step is critical to demonstrating the impact of RPA on your organization’s processes and the feasibility of your selected operating model.

4. Perform process discovery. It’s essential to source your RPA pipeline with viable automation opportunities. Vetting enough of these processes at an early stage in the RPA journey ensures the program won’t stall after the first few processes are deployed. Following POCs, criteria for good RPA candidates should be established that include not only technical feasibility but financial viability.

5. Prepare a business case. Everything in business must deliver value. All too often, RPA programs don’t scale because businesses fail to realize a return on the overall program investment. The business case in this instance should be informed by an aggregate of the net present value for the highest-priority processes identified during process discovery.

Ensure an experienced and independent party, such as an RPA development partner of your selected RPA software vendor, weighs in on the technical feasibility of the processes from an RPA perspective. This is critical because all candidates for automation aren’t necessarily RPA candidates. Processes that require significant judgment, interact with applications with user interfaces that change frequently, or are immature or unstable and need refinement after each execution generally aren’t good RPA candidates. In the earlier stages of the RPA journey, it will be easy to mistake an automation candidate for an RPA candidate. Without someone experienced in RPA development supporting process assessments in earlier stages, you run the risk of committing to more value than you’re able to realize.

To avoid overestimating the value of the RPA program, there are a couple of considerations to make regarding the particular processes being selected for automation. First, determine if existing applications could handle the automation, such as the company’s enterprise resource planning software. For example, if you use SAP, could you turn on certain functionality that could automate the process within that software? If so, then examine whether the business case supports automating the process through SAP or RPA.

Second, are others in the company already working on automating the process (regardless of what technology they’re using)? If so, then the process shouldn’t be automated through RPA unless they are planning to stop. Both considerations increase the importance of circulating and vetting the process pipeline with relevant subject-matter experts within the business and application owners (typically in the IT department) prior to finalization.

GOVERNANCE DOCUMENTATION

Whether your organization decides to write a detailed manual, publish a slide deck, or produce a few one-page guides, you must establish documentation that team members, cybersecurity groups, internal control staff, and external auditors can point to just as they do your existing accounting and financial procedures. This documentation should be easily accessible and reviewed by the relevant key stakeholders, including written confirmation of their support.

Engaging key stakeholders early in the process will allow you to write procedures that are the right length and level of detail for your group as well as to assess your organization’s appetite for mitigation approaches to certain risks. Regardless of company size—whether it’s three team members wanting to get started in an accounting department of 10 to a newly formed team in a finance organization of thousands—there are seven governance areas that should be reviewed with each of the key stakeholders over a few meetings or workshops:

1. Governing Bodies

Identify the governing bodies that will provide oversight of the RPA program. Oversight includes reviewing risks, ensuring adequate risk mitigation, and confirming which processes can be automated (through process assessments, including reviews of prioritization criteria, process type, and organizational area). Key questions to cover in this section are: How many governing bodies will there be? Would you like one at a higher level and one that is made up of people a bit closer to the processes or a single governing body? Who will sit on the governing bodies? What will their specific remit be? How often will you review the effectiveness of governing bodies, and how will you measure this?

2. Organizational Construct

The organizational construct includes the people accountable for operational delivery. It will be informed by the type of RPA implementation you selected (centralized, federated, or decentralized) and should be composed of a hybrid of IT and business professionals. Even if your IT group leads all development, individuals in business units will need to support the documentation of existing processes, help define requirements for the automation solution, and participate in user-acceptance testing.

Clearly define roles and responsibilities in this section for each person who owns a component of operational delivery, regardless of whether that person is a direct report to the leader of the program or a staff member sitting in another team who provides part-time support. Determine what the support model will look like after deployment, including the training and development plans for the individuals fulfilling the various program roles.

3. Operational Life Cycle

Define the stages through which ideas must progress, from ideation to deployment and benefit realization. Answer the following questions: How will automation ideas be generated and captured? What criteria will be used to assess opportunities and determine if they should be developed? Will processes be reviewed prior to their being promoted into production? Who needs to review or approve an automated process before it’s used by the business? What software development life cycle will be employed? What change management processes need to be executed before a human turns a process over to a bot? What documentation is needed? How will process maintenance or support for processes that break post-deployment be managed? What business continuity plans are needed to ensure any potential interruptions to critical processes don’t negatively impact the business?

4. Internal Controls

Following a review of existing internal control policies, consolidate risks that have been identified by key stakeholders at the program level and at the individual automation-opportunity level. Create a risk register that details how each risk is mitigated and review it at regular intervals.

The risk mitigation measures in the register should translate into controls that are embedded within the operational life cycle. This section should cover these controls and how implementation will maintain adherence to existing internal control procedures, including documentation requirements for audits. Bear in mind that some existing procedures may not be applicable to bots. The internal control team needs to agree to these exceptions, and a standard treatment for digital workers needs to be established. Specifically, the approaches to bot-naming conventions, the storage of account credentials, internal control reviews for bot processes prior to deployment, and internal audits of critical processes performed by bots should all be agreed on and documented.

5. Technology Governance

Most companies should already have existing documentation related to technology governance. Those need to be updated or expanded to incorporate RPA nuances. When engaging stakeholders, particularly in the IT and cybersecurity groups along with representatives from the selected RPA software vendor, the following topics will be important to discuss and document: application management, credential management, user management, licensing structure, version management for code packages, technology continuity in the event of outages, business process continuity, cybersecurity risks, approach to data storage, coding standards, and best practices. Also address general IT controls, including network security, audit logs, applicability of segregation of duties, user access provisioning, encryption, and use of privileged user accounts.

6. Performance Management

After defining the business case for the RPA program, an annual budget and value targets are likely to be set, and a milestone-based plan should be developed. Program-level performance management should detail who in senior leadership holds ultimate budget authority, how success against high-level targets will be tracked, and how necessary stakeholders will be informed of these metrics.

At the operational level, key performance indicators (KPIs) should be established that cover, where applicable, bot performance, environment stability, adherence of development to coding standards, robustness of exception handling, implementation timelines, and benefits realization at the process level (hours and dollars saved, value created, etc.). Document how these KPIs will be tracked (such as through a dashboard or other tool) and the frequency at which data will be made available to relevant individuals.

7. Vendor Management

There will be at least two types of vendors engaged along this journey: the RPA software company and a development partner. Be sure to follow existing procurement and delegation of authority procedures to engage these companies formally. Document who may discuss commercial terms and performance with the vendors.

Many RPA programs in existence today have failed to grow at scale because they didn’t have adequate development partners. Although RPA isn’t nearly as complex as traditional IT automation, no one will become an expert overnight. Development partners are needed to provide support to leverage best practices, develop your staff, and deliver automated processes at pace in the earlier stages of the program. Determine how the success of development partners will be measured and ensure the RPA software company supports and actively participates in regular partner evaluation.

ARE YOU READY FOR RPA?

RPA is here to stay, particularly because of its ability to integrate with other critical technologies like AI, machine learning, and data science. The overwhelming majority of organizations that have begun RPA implementation have begun with finance and accounting processes. No matter where you are in your personal or organizational RPA journey, it’s never too late to establish or reinforce RPA governance.

To govern bots, it’s important to leave no stone unturned and to avoid the pitfalls of early adopters before you. Following the blueprint provided here should strengthen your foundation and set your organization up for RPA success. Embrace your new digital teammates and leverage them for all they have to offer.

Conducting an RPA POC

Once you’ve researched the available RPA tools and identified a few candidates that appear to be a good fit for your operating model and business needs, it’s important to conduct a proof of concept (POC) with each tool to confirm RPA technology is right for your processes and, if so, to inform RPA tool selection. Here are the steps for conducting an RPA POC:

1. Identify two or three use cases (existing manual processes currently performed by employees) spanning multiple business applications and with the potential to create significant efficiencies or value if automated.
2. Have the RPA software vendors come to your organization to support development of these pilot processes. Most leading tools will support POC development for low or no initial cost.
3. Evaluate the RPA tools based on common criteria. Assign scores and weights. Allow team members from both IT and the business functions to score and consolidate the results. Common criteria for RPA tool selection include:

• Speed of development
• Complexity of development—for example, is knowledge of any programming languages required to design processes?
• Capability of built-in data-scraping activities
• Ease of capturing structured and unstructured data
• Ability to integrate with other technologies
• Ease of integration with business applications
• Other general assessment criteria not specific to POCs: ease of learning, ease of use, comfort for training material, feasibility for chosen operating model, adequacy of platform’s cybersecurity risk mitigation features, cost, licensing model, etc.

To encourage diversity of thought in evaluating the POC and to improve everyone’s understanding of what process development will entail, the POC development ideally should take place in your office (or, at a minimum, through screen-sharing sessions) and should include some of the future RPA developers, IT resources, and business subject-matter experts.

The more that team members from both IT and the business units understand what’s needed for process development, the better they’ll be at identifying which processes to use the bots for and how to use them effectively once the tool is chosen and the RPA program is implemented.