The challenge of uptake: What’s limiting RPA’s full potential?

When a hot new business technology comes along, we see exuberant market size predictions from analysts, accompanied by heady ROI claims from vendors attempting to increase their valuation by driving customer adoption past early stages.

Despite the repeated cycle of hype, every generation sees a handful of solutions that justifiably achieve phenomenal results in the steepness of their initial adoption curve. 

Take for instance virtualization, and a few years later, containerization. Both arrived on the scene and quite abruptly proliferated through enterprises, replacing conventional servers and later, consuming VMs — while offering an initial burst of infrastructure cost reduction and utility that couldn’t be passed up.

RPA (Robotic process automation) is a more recent phenomenon in the same vein. When the first generation of RPA tools came on the scene, they gained traction by capturing human-to-system manual work as replayable automated tasks handled by bots. 

Since virtually every information worker could use a set of extra hands to offload non-value-add tasks and typing, quick ROI was easy to identify. The RPA software market took off like wildfire in the mid-2010s, as initial vendors in the space envisioned a combined digital and human workforce pulling together in every office.

When RPA expectations outpaced ROI

RPA can trace its lineage to many other categories of business process automation, testing, and task management tools used over the last decades. But with its first appearance still a recent memory, by any account RPA is considered one of the hottest tech growth markets going right now.

What could stop RPA’s unending ticker-tape parade of ever-increasing value, given such amazing early results? What could bend this exponential growth curve into a logarithmic one?

For starters, let’s look at who actually bought RPA. In most enterprises, the CIO or a similar IT executive role will lead a group making any significant technology purchasing decisions. While digital demands on the business drive annual IT budget increases, usually every dollar of that budget will already be allocated against cost controls to meet requirements with planned development, support and infrastructure costs.

Initial RPA vendors struck an impressive early vein of customers with business managers and practitioners who just wanted to take clicks off the clock and get more work done. Unlike early adopters in other spaces, these buyers did not want to think about software or coding at all. 

This first wave of RPA wasn’t discoverable as ‘rogue IT’ because it supplanted the need for IT in some regards. Vendors could circumvent the technology-led procurement process, and sell directly to end users who could start productively equipping themselves with bots, without needing engineering help. 

An individual employee could start small and buy a personal bot, a manager could expense some bots for the team and evangelize the new time-saving utility with co-workers. 

First-gen RPA generated quick wins that easily offset the initial cost of ownership, but as usage increases, license and support costs could proliferate throughout an organization for quite a while before coming to the attention of IT.

The street of broken bots and dreams

Bots almost immediately eliminated hours of valueless toil for many employees, generating an immediate one-time productivity boost and paying for themselves. 

As for what happens next, I’ve noticed a discouraging ceiling inhibiting further improvement when talking to Gen1 RPA adopters. The bots are inherently procedural in nature, especially when recorded and replayed from on-screen user steps. They become flaky and throw errors when confronted by unexpected changes or data payloads appearing on the screen.

Of course, it may be possible to go into one or more of the bot’s steps, and set alternative paths if the automation stops for some reason. This kind of error handling didn’t usually come standard, of course. One customer said as much as 25% of their RPA integration labor was devoted to coding error handling routines.

Better page the IT support desk and ask for development help — the very thing we were trying to avoid in the first place. Or, call a consultant who’d be happy to continue maintaining the RPA bots you already have at premium rates!

Even if you can afford expert support, there’s an even flakier problem at play here: scalability. Many early RPA tools were never architected to handle today’s far more complex service-based and microservices workflows that can span hundreds of unique steps, and they reach a breaking point.

Companies confronted with this problem can wait around for a patch to resolve the rework and scale issues. Or, perhaps wait for the vendor of the old on-prem RPA to push customers onto their new SaaS edition (or ‘cloud’ edition) to at least have access to the latest updated version of the software.

Many customers felt burned when the utilization of their first RPA vendor dropped, and they made ‘lateral leaps’ to similar vendors who promised better support or modernization of a feature they wanted most, for instance, integrations to their specific CRM or incident management tools. 

The next best RPA may offer more current patches and incremental improvements, but factoring in bot refactoring and switching costs, it’s not really raising the ceiling from this ever-flattening value curve.

Gen2 RPA: Extending the interaction

RPA is young, even in tech years. So how can we already be dealing with technical and process debt in this area, and what can we hope the next generation of RPA can do about it?

Stop layering on. RPA’s productivity can become limited by the scale of its own adoption. As more procedural bots are added and used, more effort is required to code adaptation and error handling into the bots. Break out of the temptation to keep adding more layers of automation to fix existing automation.

Go beyond screenware. In today’s modern, distributed application environments, while users might experience functionality at the UI layer, by far most business logic and data is dynamic and called via APIs through cloud-based services and data sources.

A next-generation RPA approach should be able to automate not just human-to-machine interaction, but the machine-to-machine applications happening behind the scenes via APIs and REST calls. Gen2 automation encodes both human and system interactions in parallel, resulting in far less brittleness to change.

Seek out higher utilization. Since a Gen2 RPA solution expresses multi-system interactions in the natural language of computer code, the resulting automations, whether captured or coded, are more easily componentized for reuse and recombination into more complex business processes in multi-tenant environments.

Track the utilization levels of RPA assets like you would any other critical assets within your repository and live application estate. Prioritize the early retirement and replacement of existing Gen1 assets with Gen2 RPA based on demand, as measured by current usage levels and service requests.

The Intellyx Take

It’s time for RPA to live up to its full potential.

Distributed organizations are leaning on their digital backbones more than ever to support every aspect of business. When RPA automation assets are brittle, it can compromise confidence in nearly every functional aspect of a business, from employee enablement to customer services.

Gen2 RPA approaches should allow the enterprise to refactor and replace rote task-oriented bots with context-sensitive automation code that is both understandable by humans, yet speaks the language of our systems.

© 2021,Intellyx, LLC. Intellyx retains editorial control over this content. At the time of publishing, Robocorp is an Intellyx client.Intellyx, LLC. Intellyx retains editorial control over this content. At the time of publishing, Robocorp is an Intellyx client.