Robotic Process Automation: Less Than Meets the Eye

Donna Wilczek
Donna Wilczek
Senior Vice President, Strategy and Innovation, Coupa Software

She is an executive sponsor of the Coupa Executive Advisory Board and an inventor with multiple software patents.

Read time: 12 mins
Computer Code

Computer CodeA couple of years ago, I went to a conference on accounts payable automation, and I saw something I hadn’t seen before: A lot of booths touting robots, robots, robots. I thought, wow, how cool is this? Will my next new colleague in AP be C3PO in a green eyeshade?

The answer is no.

Despite surging interest in robotic process automation (RPA) over the past couple few years, and a whole lot of ink being spilled on the topic in the trade press, there’s less here than meets the eye.

I’m not sure who coined this term, but it’s a little grandiose. These aren’t robots in the physical sense, and they’re really nothing new. Before the term robot became so fashionable, we used to call them scripts, or remote process calls. The user interfaces have gotten more sophisticated, but we’re really talking about the same thing: Software that resides on a computer to execute a very specific and detailed set of instructions to automate a repetitive, routine task such as populating data from one system to another, assigning codes to invoices or purchase requisitions, copying files or processing orders.

Proponents say that RPA “takes the robot out of the human,” because it can do these kinds of tasks faster, more accurately and tirelessly than humans, freeing them to do other tasks that require intelligence, judgement and person-to-person interaction. That’s true.

They point out that RPA is faster and cheaper to deploy than a full-blown technology implementation, and requires a lot less IT involvement. Also true, but there are some caveats. You’re really getting into the software business yourself, with all that implies: Using industry standard code, paying attention to version control, running QA processes, and generally using the same kind of production and maintenance processes as you would for any enterprise software application. This becomes part of your technology stack, and you have to manage it that way. And, as business needs change, or government regulations change, your RPA also needs to change.

IT should definitely be involved, because these robots interact with other applications. Any time IT needs to roll out a patch, enhancement or upgrade, you have to consider how the change will impact any dependent RPA. As Chris DeBrusk, writing in the MIT Sloan Management Review points out, that can make innovation slower and more difficult. Perhaps this is why data from Deloitte indicates that only three percent of organizations have managed to scale RPA to a level of 50 or more robots.

Finally, a lot of people are making it sound like it is RPA is part and parcel of something bigger around machine learning or intelligent automation. That is simply not true, and I think that’s the most dangerous aspect of the hype surrounding RPA—that it is going to help transform finance. As DeBrusk also writes, some organizations are using RPA to free up budget and resources for large scale transformations. Others, he says, “are simply using the tools to give themselves a bit of breathing room to figure out where to go next with their core platforms.”

I’d put it another way: A lot of the use cases I've seen are just bandaids for bigger problems. They’ll keep you going, but you should really get to the doctor and get to the root cause of the problem.

What you should not do is look at this as a cure, because RPA is really just piecemeal automation. It might plug some holes in a process, or bridge some gaps between systems, but it’s a very rigid approach. It’s not intelligent, and it’s not going to get any more intelligent over time. You can’t add any data to it, an it’s not going to yield usable data for analytics or machine learning initiatives. It’s just going to sit there churning out its task while the world changes around it. It's a closed door. It doesn't lead anywhere else.

Before organizations jump on the RPA bandwagon, they are a few questions they need to ask themselves:

  • Is This the Right Technology for the Job? It’s tempting to want to solve your own problem in the fastest and easiest way possible, but most business processes are interconnected, so look at the bigger process the problem is part of. Why does this problem exist? Are there ways to reengineer the process upstream or downstream from the problem? Would an integration be better than a robot?
  • Is There Software Out There That Does This? Chances are that if your company has a process where you have people doing the same thing over and over and over again, other companies have that same problem too. There are so many SaaS tools on the market now that you should first look to see if someone is already solving your same problem. A SaaS solution will provide you much more flexibility than RPA. You’ll get data and reporting, and the provider will have the responsibility for the care and feeding of the software.
  • Does Software You Already Own Have Any of This Functionality? RPA is sometimes used to bridge gaps in automated systems. However, your system might already have some or all of the functionality you’re looking for. When was the last time you read through the documentation? Studied the updates? Talked to the vendor about the problem you’re having. If this is a common problem, it might be solvable within your current technology.
  • Could it Have This Functionality? SaaS providers have the ability to iterate faster than ever, and with subscription business models, there’s a big incentive for companies to solve as many of the customer’s problems as they can. Customer feature requests weigh heavily in prioritizing development, so don’t be afraid to ask. At Coupa, for example, when we learned that a few of our customers were looking at RPA to solve the problem of tax coding, we realized that this was a problem we could solve at scale for all of our customers with a series of configurations, instead of having people create their own RPA process and run it on top of the platform.

RPA is a relatively small technology investment, and its proponents are touting some pretty big ROI numbers, but you have to look at the bigger picture, because it is still a technology investment, with all that implies, including change management.

If you're thinking to use RPA solve a really narrow problem where you already have some technology in place to facilitate a process, that should be a red flag to dig deeper. Maybe you’re not looking at the problem the right way. Or, maybe something is lacking in the technology you’re using. Or, maybe it’s not deployed or configured properly, and you should have a conversation with the technology vendor.

Just don’t get snared thinking, wow, I can deploy robots to do all these different things. It sounds magical and modern, like it is a key piece of the digital transformation that everyone in finance is buzzing about. Really, it’s something old with a few more bells and whistles and a new name.

Donna Wilczek is Vice President, Strategy at Coupa.