How to Avoid RPA’s Disadvantages, according to Gartner

Total annual RPA revenue is expected to reach $1.3 billion in 2020, up from $98 million in 2015. How long will that last?

Why is RPA so Popular?

Robotic process automation (RPA) is everywhere. Businesses are talking about it, analysts are writing about it; RPA has appeared in articles in Forbes and McKinley and The Wall Street Journal. You can hardly mention digital transformation without hearing about RPA.

But are there downsides to using RPA?

In the middle of all the hype are several Gartner analysts who’ve been taking a critical look at RPA and explaining the risks the rest of us have overlooked.

Derek Miers is a senior director analyst overseeing Gartner’s Magic Quadrant for RPA software. Miers was at this year’s Gartner Symposium/ITxpo where he gave a talk that was surprisingly critical of RPA —and, for that reason alone, Miers’ talk was full of useful, unique insights.

• Problems with RPA

  “These are integration scripts, for moving from system one to system two,” said Miers during the Gartner Symposium. “And doing that regularly, repetitively, reliably; and there’s a lot of value to be had there but that’s not the same as, ‘I’ve got some little squirrely thing in here that’s going and doing it for me.’ It’s ultimately a script. And that’s how you should think about it.”

  Miers’ point is that RPA tools are not magical or intelligent —that, in fact, RPA tools are just like any other tool: ultimately, a collection of scripts that will clog your environment if you’re not careful.

  RPA tools aren’t intelligent robots with machine learning and artificial intelligence; RPA “bots” are scripts that can’t dynamically respond to changes.

  For example:
  

  “So there’s a bank in southeast Asia that has 2,000 RPA bots on people’s desktops,” explained Miers. “They wish they could roll back the clock and never have done that. Because they don’t know which part of the bank is going to stop working on Monday morning, if they change an application.”

  RPA scripts —”bots”— rely on an application’s user interface to scrape information, complete forms, and move data. In order to automate processes with RPA, RPA bots have to be trained to specific user interfaces. Because bot are simple scripts, they cannot adapt to user interface changes. So that as soon as an application is updated, or replaced, RPA bots no longer functions properly, resulting in failed processes or incorrect data.

  The bank from Miers’ example? They didn’t have a way to track which RPA bots were being used for which processes. The bank was unable to tell which processes would be impacted when a user interface was changed —for example, because of a minor, automatic update.

  “That’s crucial,” said Miers. “You have to track that, right now with an Excel spreadsheet that you’re going to manually fill-in and maintain.”

  Meaning, most RPA tools lack any meaningful tracking capabilities, leaving it up to IT staff to manually track thousands of RPA bots being created by employees across the organization. Of course, few organizations have done this, leading to another issue: technical debt.

  Here’s how Miers explained RPA’s dependency on UI to the audience:

  “Because you’re doing it at the user interface level, every time something like that changes, which bit of my business is going to stop working on Monday morning? Don’t know. Oh, we can react to it quickly, every vendor will tell you how quickly they can react to that change, that’s not the same as getting in front of the change and being able to predict which bit of your business is going to stop working on Monday morning. There are really only one or two vendors who have even thought about that in a meaningful way.”

• RPA’s Long-Term Technical Debt

  If a customer onboarding process requires pulling data from a dozen different sources, and you decide to use an RPA tool, data is still being pulled from a dozen different sources. Sure, the process is being completed in much less time, but the process hasn’t changed.

  That’s because RPA, for better or worse, is superficial: RPA is copy-pasting data and clicking buttons. RPA does this much faster than humans, but the problem isn’t who or what is doing the clicking, the problem is the bulky process.

  “Actually, what you’re doing is covering the organization in Band-Aids in the hope of a wellness program,” explained Miers. “You’ve got to fix the processes. So, what you’re really doing here is building like a little façade if you like, a little shop front in front of your old applications that you can reuse. That is actually quite a useful use case for RPA.

  “You won’t find that really in the vendor literature because it sort of sounds just a bit techie and is not the democratization of integration want you to talk to. There is a whole raft of inappropriate expectations….”
  

  Instead of defaulting to RPA, IT teams should look at the process they are trying to automate to see if they can find a better way to orchestrate the process or task in question. If the process is complex and cumbersome, it should be simplified, not just automated. However, RPA tools are limited in capabilities and cannot always be used to design and orchestrate automated processes.

  Miers suggests IT teams exhaust their alternatives, first:

  “Don’t get me wrong, there is a lot of value in the RPA market, as the integration method of last resort. If it has an API, use it. If you haven’t an API and you have an old system that you know you can’t get rid of, use RPA. It’s pretty simple. It’s good at that sort of thing.”
  

  Implementing RPA instead of addressing a cumbersome process is kicking the harder work down the road. It builds up technical debt that at some point will have to be addressed.

  That bank in southeast Asia? They have a different kind of technical debt. The problem they face is that their IT team has to search through thousands of bots each time an update is made to any of the applications used by the business, in order to re-program the “bots” for the updated UIs.

• Gartner’s Hype Cycle for RPA

  RPA is great for automating routine, rules-based tasks. It isn’t great for building an agile automation environment or for designing processes that can adapt to changes within the environment. This is because RPA works at the superficial UI-level, instead of at the deeper API-level.

  From Gartner’s Magic Quadrant for Robotic Process Automation Software:

  “For 40 to 50 years, businesses have funded an expensive patchwork quilt of applications. Few of these systems were ever set up to share data. Those in the business side of the organization have become increasingly frustrated by the slow pace of IT in automating connections among these systems. They find the long wait times posted by IT departments for the attention of expensive IT resources to respond to their needs incredible.”
  

  Business users are pushing the use of RPA in order to automate faster. But automating at the UI level is a precarious, unsustainable solution in the long-term. Ultimately, organizations need to be able to better integrate new tools and to automate processes faster in order to achieve the speed and flexibility demanded by business —these are goals that RPA can do little to help.

  This is part of the reason why Gartner’s 2019 hype cycle has RPA becoming obsolete in its “peak of inflated expectations”: because the problems RPA tries to Band-Aid are best solved with APIs, workload automation, and modern job schedulers.

From Gartner’s Hype Cycle for Business Process Services, 2019:

“By 2021, task-centric RPA offerings in their current form will be obsolete. The simplistic task-focused RPA deployments that focus on routine, repetitive, rule-based workflow will give way to zeal and demand for automating more complex workflow.”

“This does not mean the RPA market is going away. We foresee that remnants of the current RPA deployments will be around for the next decade or more (similar to how we still have green screen applications and mainframes). However, we predict a renaissance of the existing market offerings —a shift from task-centric to more process-level automation and eventually to process orchestration.”

Before going all-in on a new, hype-driven technology that relies on UIs to complete simple tasks, it can be far more beneficial to implement a mature technology that already offers end-to-end process automation and orchestration —since that’s where “existing market offerings” are already headed.