Software Robots to the Rescue! Or Not?!
Automation is often regarded as a mixed blessing. To some it’s the herald of impending job cuts, for others it opens up a world of efficiency — one that unleashes the potential of human ingenuity. Robotic process automation (RPA) is no different: to its boosters, it paves the way for digital transformation; for others, RPA is just the latest overhyped tech that, in the long term, promises to cause more problems than it solves. The truth is probably somewhere in the middle.
At Thoughtworks, we see our customers using Robotic Process Automation (RPA), to automate highly manual and outdated business practices — and it’s not hard to fathom why. Software is expensive. It takes learned development skills to create. IT departments have much more work on their plate than they can achieve at one time and given their current budget. Lastly, transforming legacy systems is a multi-year process and therefore customers are using RPA to mitigate challenges today that must be addressed.
There are many organizations convinced of RPA’s promise. According to analyst group Forrester Research, more than 40% of organizations will deploy some form of RPA by 2020. The new automation economy won’t just eliminate jobs though, it’ll create them too; jobs such as bot wranglers, operational employees who handle exceptions and escalations, and who manage the performance of the bots.
So while it’s easy to understand the appeal, RPA is not risk-free. We do think that RPA has a place in helping companies compete in the digital era, but we think there are some basic patterns companies need to follow, to ensure they use RPA effectively. Lastly, although RPA vendors offer robust customer stories and ROI metrics, wide use of RPA will instantiate yet another new layer of software to be managed.
The promise of RPA
IT Automation and Robots, or robotic process automation (RPA) offers the benefit of speeding up mundane, repetitive and error prone processes, while keeping costs low and freeing up your staff to focus on more meaningful and impactful work.
Every organization has a complex collection of software, some purchased from vendors, some custom built, and some acquired through business events such as mergers and acquisitions. Business processes are built on top of this diverse landscape, often requiring humans to switch between multiple applications and contexts, including green screens, different GUI tools, and browser-based interfaces. The canonical example is a call centre agent, who may need to access over a dozen different applications in order to help a customer with their queries. In many cases that agent needs to take data and context from one application and enter it into another app, effectively doing manual “swivel chair” integration between the systems.
RPA promises to speed up these kinds of business processes by assisting, or in some cases outright replacing, the human worker driving these disparate applications. Simple RPA initiated by a worker might copy a series of values out of one ‘master’ application and fill those values in another app (RPA is a little grandiose a term for this, we’d probably call it a macro). More complex RPA solutions can actually drive a GUI and understand application context, and can perform tasks that would otherwise need a human.
This promise is so captivating that many of the RPA customer metrics include an ominous one: number of bots in production. Many RPA customer stories highlight this metric, advertising “280 robots deployed” and so on. While this captures the essence of the impact bots are having on the business, therein lies the danger. These large quantities of bots promise even larger legacy transformation challenges and points of failure.
The problems that RPA creates
Despite some bold claims by RPA vendors and a general optimism in the IT industry around the promises of automation, machine learning and AI, RPA tends not to live up to the hype. A recent Forrester report noted that some organizations found their RPA solutions didn’t meet their expected ROI, because “bot maintenance costs are a big deal.” In particular, Forrester cited factors such as licensing and infrastructure costs to run the bots, as well as maintenance costs resulting from application changes.
Forbes has also chimed in on Why You Should Think Twice About Robotic Process Automation. “If anything changes with the interface, the data, or any other aspect of the legacy app, then the RPA breaks.” The brittleness of RPA bots has led many to create rules of thumb of how to avoid misusing RPA. We’ve found that bad uses of RPA include:
- Building an RPA solution that violated the ‘How to RPA’ recipe below
- RPA on IT systems subject to constant updating (due to security or OS patches)
- RPA on a business process in the midst, or constantly in danger, of outside regulatory change (regulations affect the business process and break your bot)
- RPA on IT systems in the midst of change; application upgrades and IT transformation projects (they will change and break your bot)
It is the previous item — updating your bots to track underlying application changes — that we’re most concerned about. The entire premise of RPA is that because an IT department is so overloaded and unable to keep up with changes demanded by the business, introducing a bot to string together existing applications will create efficiencies. In particular, an organization chooses to use a bot rather than updating their existing tech estate so that it functions better. Why then, is this organization updating its GUIs and breaking the bot? Could it be that in fact two separate parts of the organization are failing to collaborate and just using RPA as a band-aid?
A significant consequence of using RPA is that it’s like pouring concrete over your existing interfaces.
No matter what promises might have been made about AI-powered bots that can do screen scraping and smart textual analysis, having RPA on top of an interface makes that interface riskier to change without breaking the bot.
“We automated the business process” really means we tied together applications that currently embody the business process. This distinction is important. This is creating a “bot layer” of software.
RPA efforts also tend to expose cultural or organizational schisms. For example, if RPA successfully eliminates headcount it may create a savings in one part of the company but increase costs of IT software maintenance and infrastructure upkeep for the bots.
On top of concerns about RPA making systems harder to change, it’s important to note that the very definition of RPA is pretty muddy. Almost anything that includes some kind of automation could be considered “RPA” depending on who you ask. For example, a process that takes a CSV data file from a mainframe, splits it into records and then fires those records into a REST API might well be described as RPA, even though this is fairly simple integration between two systems, doesn’t involve driving a GUI, and has been part of enterprise architectural patterns for decades.
For the purposes of this article, we’re focusing our advice on robots that work with interfaces that were originally intended for human consumption, for example green-screen mainframe apps, desktop-based GUI apps and web apps delivered via the browser.
How to RPA - The right recipe for RPA
Whether RPA is a bad thing as part of an overall strategy is reconcilable — if we use “tactical RPA” on top of a system that’s due for replacement, we might only need RPA in place for a short time. In that time, you might realize some benefits through improved efficiency, making RPA a good choice.
Like almost every entry on the Gartner Hype Cycle, RPA is not a silver bullet. It’s a tool to be used in the right circumstances, understanding the benefits and tradeoffs that it gives you. Here are some guidelines for getting a benefit from RPA:
Recipe for the good use of RPA
- Use an underlying API if possible. When considering an application as a candidate for automation using RPA, check with the application maintenance team whether a non-GUI interface could be created, and what the cost might be. The GUI layer in most applications drives an underlying business logic layer and it might be less work than you think to expose that business logic directly. You might still use an RPA tool to orchestrate between applications, but you’d gain reliability and speed by circumventing the UI. Some organizations use RPA as a precursor to implementing an API—by interacting with an RPA-based interface, they learn the features that will be needed when the RPA is ultimately replaced by an API.
- Start small, don’t try to automate the world. Many organizations try to tackle complex, long-running processes and quickly run into trouble. Avoid this headache and build successful momentum by starting small — even a simple process handled effectively by a robot can add up to a big win over time.
- Use the “rule of fives” to look for automation opportunities in processes that aren’t evolving very quickly, that have low complexity, and where humans spend a large amount of effort but add very little value. Forrester author Craig Le Clair coined the term “rule of fives” — five or fewer applications to orchestrate, five or fewer decisions during the process, and five hundred clicks or less required.
- Scale up RPA while utilizing ‘where used’ or RPA Monitoring analytics to ensure you see which bots are using which IT application interfaces, APIs and infrastructure components so you know which bots need to change when you do update an IT component.
- Use RPA as an approach in your legacy modernization toolkit, and ensure that your strategic roadmap takes into account all of the modernization approaches you are planning. It makes little sense to use RPA to automate a process that will disappear in six months when an entirely new process or system replaces the existing one.
- Be conservative in your estimates for cost savings on a new RPA effort, especially if you’ve not previously automated a particular application or set of applications. As we pointed out earlier, many RPA implementations require more effort and ongoing support than originally estimated.
- Anticipate more testing needs for your applications. Implementing an RPA solution to drive GUI applications couples them together. Coupling isn’t necessarily bad — you need it to get anything done — but too much, or accidental coupling can be a problem. If you use RPA to drive a GUI application, make sure that the team supporting the application is aware of the new robotic user of their software, and arrange for robot testing to be part of the software release process.
- Continue business process re-engineering and use RPA as stop-gap measure to help. Digitally native experiences for both customers and employees will lead to a healthier business in the long run. If you have poor business processes, burying them underneath an RPA solution might help you sleep better at night but hasn’t solved the underlying problem. RPA doesn’t just make specific applications harder to change, it makes your whole business process harder to change.
Use our recipe for RPA to gain efficiency, especially in highly manual business processes where humans add little value. If the number of humans doing the work is large, even small amounts of automation can pay dividends. But RPA should be part of your strategy, one tool in the toolbox, to be used in conjunction with a long-term perspective and a holistic technology strategy across your business.
The bottom line
RPA can be a part of many digital transformation initiatives, as it promises to deliver cost savings without having to immediately modernize all the underlying architecture and systems. Utilizing the cost savings to pay for true modernization efforts would be a worthwhile strategy.
Modernization efforts may take years, and business cannot afford to wait for improved efficiencies. RPA can be an appropriate way to achieve short-term improvements and organizations need to remember that there is a future price to pay: RPA makes systems harder to change because it couples them directly together. Once an RPA solution is in place, you will find that evolving an RPA-connected system is more effort, often breaking a previously-working RPA-based integration.
We think that organizations need to take on RPA with “eyes open” as part of a holistic modernization strategy. Done right, RPA can provide short-term wins, as long as you avoid the long-term pitfalls.