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.