There is a great deal of buzz surrounding the rapid adoption of Robotic Process Automation (RPA) technology. According to a Gartner study, by 2020 90% of large and midsize organizations will have at least one process supported by RPA. Gartner also estimates, however, that 1 in 5 of organizations that try RPA will have replaced it with another technology during that time frame. How can the same technology be both adopted and abandoned so quickly?
The answer is revealed when examining the inherent benefits and drawbacks of RPA technology. As a form of automation, it holds the potential to boost productivity that yields the equivalent of additional 24/7 workers at a fraction of the cost of human resources. Several fundamental flaws in the approach, however, may prevent organizations from ever realizing those gains, and could even make some situations worse.
How RPA works
RPA software allows non-technical users to automate tasks by creating simple “bots” that can log in to systems, retrieve information, and perform basic tasks. So long as the tasks are clearly defined, highly repeatable, and primarily rule-based, RPA bots can be trained to do that work.
In the article Robotic Process Automation: What’s All the Hype? Russ Gould, Senior Director of Product Marketing with Kofax Advisors, compares this type of digital evolution with the impact automation had on the manufacturing industry. “At a high level, office work today operates much like the manufacturing industry did before automation. For decades, people performed tedious production work on the manufacturing floor until robots replaced them. In the office, workers still perform manual tasks every day like copying and pasting data between applications or logging into portals to input or retrieve information. This is the work that software robots are now automating across the board in terms of industries and job functions, whether customer-facing or back office.”
Limited applications with seemingly large potential payoffs
RPAs are not designed to replace complex decision-making processes (something, generally, humans are very good at). Instead, they can automate much of the busywork that swamps the daily life of an office worker. For example, retrieving information from one system, and then cutting and pasting it into another. Those kinds of tasks, although only a small part of a worker’s job can, through repetition, consume an outsized portion of their time. Eliminating that type of work should boost productivity and improve the bottom line.
Yet many who restrict their application of RPAs to this subset of mundane tasks are often frustrated with results. The McKinsey & Company article Burned by the bots: Why robotic automation is stumbling points out that, “Installing thousands of bots has taken a lot longer and is more complex and costly than most organizations have hoped it would be.” In terms of the upside, the authors note, “The economic outcomes often aren’t as rosy as originally projected. While it may be possible to automate 30% of tasks for the majority of occupations, that doesn’t neatly translate into a 30% cost reduction. People do many different things, and bots may only address some of them.”
RPAs meet reality
A major contributor to the discrepancy between expectations and results stems from the limited nature of RPA bots. While the tasks they are designed for are highly repeatable and follow unyielding logic, the real-world tasks for which they are applied to rarely fit that bill. As noted in an InformationWeek article, “It is rare that a software robot will automate 100% of even a very standardized process. As soon as any level of human judgment is required to complete a task, a ‘Robot Manager’ needs to get involved.”
If robots require human oversight to manage even the most standardized processes, the benefits derived from automation can quickly be outpaced by the management process. Compounding this cost is the additional IT layer bots create. The McKinsey authors state, “Installing thousands of bots introduces an additional architecture layer into the system requiring more bespoke governance and oversight by the IT organization, which is often already burdened with maintaining legacy systems.”
Starting with the wrong question
The question behind every RPA project is “How can we automate this process?” This question, however, ignores more fundamental concerns. Is this process furthering our objectives? Is it even necessary? This desire to understand the current process and consider what it should become is central to effective process redesign.
Unfortunately, “many companies don’t do that,” as a Harvard Business Review (HBR) article notes. “Their RPA implementations support the ‘as-is’ process, with no improvement or examination of the current process steps that are automated. As a result, they may achieve modest savings, but in many cases they will miss out on opportunities to dramatically improve process outcomes, quality, costs, and cycle times.”
The challenges of fragile technology
While RPAs’ avoidance of process redesign contributes to an upper limit on how successful these projects can be, the nature of the bots themselves may pose a greater concern. RPAs work on the interface level, interacting with the system as if it was a human using the software. The interface, however, may be the part of the application most likely to get updated or changed.
“The platforms on which the bots interact (or handshake) often change, and the necessary flexibility isn’t always configured into the bot,” the McKinsey article notes. This can lead to delays and the complete reprogramming of bots for minor changes to the system. New forms, revamped cosmetic changes, or simplified menus can effectively scratch months of work on a bot. The highly-specific nature of bot programming leads to a fragile technology that can fail to adapt to changes in a sustainable way.
A different approach
Flexible systems, such as Origami Risk, rely on a different set of tools to achieve a wider range of benefits from automation. First, instead of working with the volatile interface level, Origami Risk focuses on the much more stable data level. Accessed via data feeds or APIs, moving data directly from one system into a single repository eliminates the need for a system-hopping RPA.
RPA technology, as the HBR article points out “is sometimes described as supporting ‘swivel chair’ processes involving a lot of back-and-forth access to multiple information systems. In many cases, however, the process could extract all the necessary information at once from a system — that is, with less swiveling.” Data feeds and API access removes the need to swivel and creates a unified single source, despite the use of multiple systems across the enterprise.
The benefits of a wider view
Instead of focusing on how to automate steps, flexible data-driven events are a more reliable way to address the question “What should our process look like?” Exploring how to redesign a process can lead to business improvements that no RPA project could expect to achieve. Importantly, it allows the organization to determine which parts of a process can be automated, and which still require human intervention.
When data arrives in the form of a new claim submission, a completed audit or investigation, or any other type of submittal, the system can be instructed to carry out follow-up activities. If the details fall within expected ranges, it can be added to an administrative queue. Alternatively, it can be escalated for review if any anomalies are spotted, and sent (via email or text) with accompanying backup details to expedite the review process. Each step can be time stamped to monitor efficiency and identify any bottlenecks. Status updates can also be automated through the use of email templates that keep users, management, and any required third parties fully abreast of progress without taking any staff resources to do so.
Next level automation
Any type of automation can lead to spikes in activity (by speeding up how quickly new data flows into queues). Just as a burst of activity can overwhelm digital networks, automated processes can potentially overwhelm administrative staff by ignoring existing workloads when creating new assignments. Origami Risks borrows the concept of load balancing from the IT realm and applies it to automating task assignment. This allows you to avoid the problems of overloading some resources (while others are underutilized), yet still delivers the benefits from using automated data-driven processes.
Next level automation considers the varying reporting needs of a range of stakeholders. Some users may want custom dashboards and in-system alerts to keep an eye on day-to-day activities. Others may want simple PDFs delivered to their email inboxes either on a regular basis, or as-needed whenever conditions warrant. Executive team members may need information to be prepared in a “meeting ready” format, such as a PowerPoint template.
Origami Risk provides your organization with the flexible reporting options that allow each unit to tailor the reports and updates that stakeholders demand in the format and frequency they prefer. This means visibility of data isn’t locked down to only those using the system on a regular basis, or those willing to pour through a parade of spreadsheets.
Assessing RPA development in your organization
RPAs sound great. For some situations they might work well. But they are fragile, and not well adapted to a rapidly changing environment. Automation efforts require flexibility as a foundation, and the concentration should be on how to get as much as possible in one system (avoiding the swivel chair). This puts an emphasis on strong integrations and API-based solutions.
Origami lets you get all the benefits of RPAs, without the rigid limitations. This creates a sustainable process, where changes and updates can be made easily and without IT support. Best of all, it allows you to focus on strategic objectives rather than blindly automating steps.
Discover more ways your organization can automate processes and explore the potential for innovation in other areas by clicking the button below.