Pegasystems lays down the do's & don'ts of RPA

DO use RPA

DO use RPA…to automate simple tasks.

RPA typically automates simpler and mundane work. Years of business process optimisation has made it such that a lot of work that remains is not simple, repetitive work but rather complex and fragmented. This impacts RPA getting to scale. Companies switching from one unattended RPA vendor to another eventually realise it’s the complexity of the process/applications that prevent scale, not RPA itself.

Businesses should use attended RPA to automate simpler tasks within complex processes and optimise every worker rather than automating every worker. 50% automation on 1000 people is better than 100% of 20.

Also use RPA as a means to digital transformation, not the end game.

The goal of digital transformation is to transform business. RPA has a place – optimising parts of enterprise, but ultimately to digitally transform, RPA would require replacement with deeper intelligent automation technologies for many applications. Automating bad processes on old, costly-to-manage legacy apps are still bad processes on those applications.

No set-and-forget

In addition, RPA is not scalable for APIs and too breakable for IT to use as a set-and-forget. According to a recent Pega survey of 509 global decision makers on RPA, 87% of respondents experience some level of bot failures. Further, forty-one percent of respondents said that ongoing bot management is taking more time and resources than expected. RPA automations can be exposed to APIs to redesign new digital interfaces, but these RPA connections will be temporary.

There are far better technologies to automate intelligently for serious transformation than RPA and these include:

• Low-code designs which supports centralised governed rules rather than siloed macros to eliminate cumbersome spreadsheets.
• Centralised email management with natural language processing to read and respond to emails rather than RPA on outlook.
• Orchestration and low-code together to replace old, tired processes and accelerate ending the life of many legacy apps that encourage poor processes.

DON’T use RPA…

Don’t use RPA to automate complex processes.

The core of RPA is to automate screens through the user interface (UI) – to read something off the screens and do something with the data before possibly sending the data back into them. RPA doesn’t need much intelligence for this because all RPA is limited by its operating system and the ability to support the multitude of complexly compiled applications that run on it. Some intelligence is being used via optical character recognition on-screen, but in these cases, app automation is even slower and more brittle than object-based automation systems in some RPA products.

Complex processes embedded with complex applications and GUIs are a no-go – they are fragile, expensive to support and break frequently.

Also, don’t use RPA for long-term enterprise application integration (EAI) projects.

Using RPA – UI automation – for long-term EAI projects is not architecturally sound. A simple UI change down the RPA chain could seriously impact EAI – disastrous as the objective of enterprise architects is to use robust, scalable, APIs connected using proven, secure technology. However, these aren’t always available in time to fulfil short-term optimisation or digital transformation. In this case, it is fine to at least consider RPA as a stop-gap/bridge so the value can be delivered.

It will be interesting to see how RPA develops. RPA’s lack of scale is at least drawing attention to bad processes and eventually, maybe, people will start to plan to transform them instead.