Why you should care about robotic process automation
A look into what robotic process automation (RPA) is, why it matters, and why it’s garnered so much recent interest.
A look into what robotic process automation (RPA) is, why it matters, and why it’s garnered so much recent interest.
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.”
This is precisely the kind of problem that robotic process automation (RPA) aims to address.
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.
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.)
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 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:
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:
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.
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.
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.