Why you should care about robotic process automation

In a classic 1983 paper, cognitive psychologist Lisanne Bainbridge drew attention to a curious irony: so-called “automated” systems were, in practice, usually attended by one or more human operators.

The more advanced the system, she observed, “the more crucial…the contribution of the human operator.” Bainbridge believed that automation designers were in denial about this, however. As she saw it, designers approached the problem of automation as if the human factor were not, in fact, a factor. This resulted in systems that left their (inevitable) human operators “with an arbitrary collection of tasks” with respect to which “little thought may have been given to providing support.”

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

This is precisely the kind of problem that robotic process automation (RPA) aims to address.

RPA explained

To understand what RPA is, why it matters, and why it’s garnered so much interest, you have to understand the case of “Maddie.” Full disclosure: Maddie is a fictional person. She’s a composite of hundreds of thousands (perhaps even millions) of smart, industrious people who are tasked with the IT equivalent of rolling a large boulder up a hill. One of Maddie’s responsibilities—she has plenty of others—is to manipulate a mouse and click the appropriate buttons (“OK,” “Yes,” “Import”) when prompted to do so by a legacy Windows application. Once an hour, on the hour, Maddie sits in front of an old-school beige computer and clicks a mouse button several hundred times. She’s the vestigial human link in a process—insurance claims processing—that has a mostly automated workflow.

Maddie has other responsibilities that challenge her ingenuity, but it’s the drudgery of pointing-and-clicking a mouse that defines her job for her. RPA is a beacon of hope for the Maddies of the world. It enlists software “robots” to automate the rote, repetitive, or tedious tasks that bridge virtual gaps, or facilitate virtual transfers or exchanges, in and between common business processes.

Whether it’s copying and pasting text, scraping screens, pointing and clicking (or dragging and dropping) with a mouse, saving changes in one program and importing them into another, etc., software robots are able to interpret inputs, events, and gestures, and trigger responses and communicate with other systems—just as humans do. In fact, robots arguably do these things better than humans do them. Unlike humans, a software robot doesn’t get tired, bored, or distracted, especially when its performing a tedious or repetitive task. Unlike humans, a software robot performs tasks precisely the same way each and every time. Unlike humans, a software robot generates records for each and every task in a workflow. Most important, unlike humans, a robot does not have a capacity for creativity or ingenuity. Robots cannot reflect on and derive innovative solutions to hard problems. They can do only what they’re programmed to do. Core to RPA is the idea that the software robot is the perfect candidate for a range of tasks that neither tax human ingenuity nor engage human passion.

Workflow and back-office automation

Virtual automation has a long history. Prior to RPA, enterprises used several different techniques to automate workflows and back-office processes. Scripting, for example, is the ur-IT automation technology. Virtually anything can be scripted—including keyboard, mouse, and GUI actions. Speaking of mice, another automation technology—screen-scraping—dates from before the widespread use of graphical user interfaces (GUI), mice, and other even newer types of human interface devices. Even though mainframe technologies evolved—IBM’s System/360 mainframe gave way to System/370, which was superseded by System/380, and so on—the programs that ran on these systems often did not.

In the late 1960s, following the shift from punch cards to magnetic tape, enterprises used optical character recognition (OCR) technologies to digitize their punch-card archives. In the 1980s, they used screen-scraping techniques to capture data from legacy mainframe and minicomputer programs and expose it in different contexts—such as on then-new PCs and Macintoshes. Two decades later, enterprises used screen-scraping to web-enable legacy mainframe, minicomputer, and client-server applications. Speaking of client-server, the succession of paradigm shifts from host-based to client-server to cloud-based architectures helped substantively automate many common workflows and processes. Yes, automation has usually eliminated a small proportion of human jobs; at the same time, however, it has created new opportunities for those well-versed in software, databases, architecture, and operations.

But RPA is different. First, RPA automates tasks that a human being must perform in a GUI, as distinct to a text-only terminal. These are tasks that comprise gaps in the midst of critical workflows or processes; tasks that (as often as not) connect or span separate programs, systems, or networks.

Second, RPA is smart; it uses machine learning (ML) techniques that learn on the basis of human action in the visual interface. Just by manipulating the mouse and clicking a sequence of “Yes,” “OK,” etc., prompts, a user like Maddie generates a training data set for a software robot to work with and learn from. The Achilles heel of scripts, mouse macros, and other established practices is that they all depend on human prognostication. Imagine a developer writes a script that triggers an action in response to one or more events: say, for example, some combination of function calls and GUI events. For the script to work reliably, however, the developer must anticipate not only expected events (first, the script moves the cursor to the designated X,Y coordinates; second it checks to make sure the designated window is activated; only then does it simulate a mouse click) but exceptions, too—edge cases, as when a dialog box captures control of the screen and obscures the “OK” prompt. RPA technology uses ML to discover, understand, and adapt to edge cases that a human user manipulating a mouse could easily deal with—but which would bring a dumb script grinding to a halt.

Third, RPA doesn’t assume that the primary goal of automation is to replace human beings. RPA technologies automate the kinds of tasks that human beings don’t like doing. RPA targets tedious, repetitive, rote, time-consuming tasks. Proponents like to claim that RPA frees human actors (like Maddie) to focus on responsibilities and activities that engage their ingenuity and creativity.

Fourth, RPA expects program, system, and even network heterogeneity. RPA evolved to eliminate gaps in workflows or processes that span disparate GUI-based systems. A history lesson might be helpful here. In the 1990s, packaged software suites emerged to displace fit-for-purpose GUI and text-based applications. An insurance company might once have depended on a mix of custom-built and commercial systems to support key processes such as enrollment, billing, claim filing, and claim adjustment; by the late-1990s, however, packaged applications were able to replicate many (if not most) of the features and functions these systems provided. But not all of them. More important, some subset of function-specific systems just couldn’t be replaced. The upshot was that even as enterprises restructured their business processes to accommodate packaged suites, they kept some of these processes (and their supporting IT systems) intact, too. The neat thing about RPA is that its software bots run alongside the GUI-based program(s) on the existing system. RPA does not modify the code of an existing system; it doesn’t even require that someone (a developer, engineer, etc.) understand this code. Software bots on one system can also interoperate with software bots on other systems; this permits RPA to knit together disparate systems into a single (managed) process flow.

All of this helps account for keen and trending interest in RPA. In most cases, RPA is a less expensive alternative to conventional practices: to approximate its efficacy (and to account for most possible problems, hiccups, or exceptions) a developer would have to observe what a user like Maddie does over a protracted period of time.

RPA also delivers return on investment via increased employee productivity, improvements in process efficiency, built-in auditability, and superior accuracy. (Humans grow bored, get distracted, and don’t notice when they make mistakes. When a software bot makes a “mistake,” it triggers an exception.)

What should be automated?

RPA automates actions, inputs, behaviors, etc., in the user interface. It is ideal for integration projects that require human manipulation of user interface elements and involve heterogeneous systems. RPA technologies exploit standard^[1] APIs, so integrators won’t have to tinker with existing applications, workflows, processes, or system architecture. In this way, RPA can help reduce the amount of work (along with much of the risk) necessary to integrate heterogeneous applications and systems. This is one of the biggest factors driving the cost-effectiveness of RPA implementations.

RPA is not a panacea. Some tasks, even if tedious or repetitive, will require manual human oversight and control. As always, careful analysis of in-process workflows enables you to determine the best overall candidates for robotic automation.

In general, the following are good places to start with RPA:

• Rote and repetitive tasks. Pointing-and-clicking a mouse. Copying-and-pasting text.
• Testing and validation. Some visual interfaces require substantial time and effort to test prior to deployment. RPA can radically accelerate this process, improve testing, and reduce costs.
• Redundant tasks. Basic tasks that multiple users tend to perform in parallel in an organization.
• Manual tasks with limited variability and few exceptions. Tasks that are consistent, repeatable, and/or highly predictable are excellent candidates for robotic automation.
• Human-orchestrated “integrations.” A user manually copies data from one visual interface and pastes it into another, or a user manually imports the output of one program into another.
• Any tedious or time-consuming task that looks like it might be a good candidate for automation. Automating the task should free one or more humans to do more productive work.

The above benefits can lower costs, improve efficiency and quality, and can economically scale, all adding up to significant return on investment for the right RPA projects.

The following are probably not good candidates for RPA, however:

• One-off tasks. A task or process that only needs to run once is not worth an investment in RPA.
• Unpredictable tasks. Tasks involving ad hoc or context-sensitive input are not viable for RPA.
• Turing test-like tasks. Similarly, tasks that require some kind of visual confirmation—such as, for example, CAPTCHAs—are not always suitable for RPA. This isn’t to preclude all such tasks, however; for example, you could use RPA to automate a process that tests for and validates images of scanned checks. You could even use RPA to test and validate that a CAPTCHA is working. RPA rule of thumb: if it’s repeatable and predictable, it can be automated.
• Decision-laden processes. Processes that require human decision making and that involve multiple decision-making stakeholders aren’t usually viable candidates for RPA. If you aren’t comfortable automating some or all of the decisions in a process flow, RPA isn’t a good fit.
• KISS tasks. Keep it simple, stupid: if it’s something a human can do quickly, easily, and non-onerously, it doesn’t make sense to automate it. Ditto for tasks/processes that offer low ROI.

“Doing” RPA

Fundamentally, RPA is an integration and interoperability technology. There is not a one-size-fits-all blueprint for “doing” RPA. There can’t be: every company and every integration or interoperability scenario is different. However, thanks to RPA’s extensive use in the health care, insurance, oil and gas, and government verticals, would-be adopters can avail themselves of resources—e.g., case studies and ROI studies, along with industry-specific consulting and integration services—that will assist them as they plan their RPA implementations. As RPA sees widespread use across all verticals, adopters should expect to encounter complex, unpredictable, and challenging scenarios.

Experience with and analysis of the RPA space leads to a formalized list of “Do’s and Don’ts” adopters can use to troubleshoot their RPA implementation projects.

RPA Dos

• An RPA initiative must have the backing of one or more C-level executives; support from a single line of business (or from IT alone) isn’t sufficient.
• An RPA initiative must be aligned with the organization’s overall digital transformation strategy.
• Engaging experts and vendor tools can help speed RPA adoption for those new to the topic.
• Once a project is up and running, establishing an RPA center of excellence can help standardize and disseminate best practices across an organization to foster and speed adoption of RPA where appropriate.

RPA Don’ts

• Don’t pursue RPA as a silo-ed, independent, or skunkworks project; align RPA with your organization’s overall vision.
• Don’t automate a process just for the sake of automating it; RPA gives you a chance to optimize existing processes.
• Don’t rush into automating a process; plan, test, and validate to achieve success with RPA.

Teams play a very important role in the success of an RPA implementation. Two common RPA-specific job roles are RPA developer and RPA solutions architect; these specialists will augment and liaison with an internal IT team in implementing RPA.

Conclusion

Over the last two to three years, RPA has emerged as a promising technology for workflow and back-office automation. Unlike older automation technologies—such as scripting and screen-scraping—RPA is designed to automate the kinds of tasks that are performed by human users who must interact with and manipulate elements in a graphical user interface. These include custom or proprietary applications that expose basic prompts (buttons, dialog boxes, etc.) or other prompts that expect a user to perform an action of some kind (enter text or number values, left- or right-click a mouse, press a sequence of keys on a keyboard) in response to a visual prompt.

The return on investment for RPA projects can be substantial; this alone helps explain the keen interest in the topic. This interest shows no signs of abating. And with Microsoft’s announcement of a new RPA-oriented cloud offering, UI Flows, RPA seems poised for mainstream adoption. “Adoption” doesn’t necessarily equal success, however. Like any new technology, RPA’s potential rewards are offset by nontrivial risks. If you understand what RPA can and can’t do, you can make an informed decision about whether RPA is a viable option for you.