RPA: The Emperor’s New Robot
Ever heard the story of the Emperor’s New Clothes? The short tale narrates the story of an emperor who commissions two weavers to stitch for him a new set of clothes more valuable than any other garment. The weavers, two con men, promise that the clothes only be visible to the wise and intelligent. The result is the emperor parading in front of his subjects with no clothes, while everyone remains silent to the display for fear of being deemed incompetent, or worse, stupid. The lesson to be taken away from this childhood tale is really very simple: if something seems too good to be true, it probably is…
Recent media coverage largely touts Robotics Process Automation (RPA) to be the greatest driver of change in the corporate world since the introduction of Microsoft. RPA is increasingly being publicised as a technology that is expected to replace up to 200,000 banking jobs over the next decade. It is not surprising then that c.70% of finance organisations have reported using or piloting Robotic Process Automation. And who can blame them? On paper, RPA represents a technology that could to address a slew of challenges in the financial services industry, ranging from reducing costs, enhance regulatory compliance and increase operational efficiency. But expensive silk and brocade, RPA may not be.
In fact, if recent reports are to be believed, almost half of RPA implementations fail. And even if the implementation is successful, organisations have often failed to generate appropriate return to justify investment in the technology. So this begs the question, is the benefit from RPA really something that warrants the kind of focus it continues to receive, or is it almost as futile as invisible clothes?
To really answer the question, one must consider some of the causes for the failure of RPA projects.
- Is it the wrong technology?
Whilst RPA is often discussed alongside AI and machine learning, it is important to consider the distinctions between these technologies. Fundamentally, RPA is good at following instructions. Unlike AI or machine learning, it is not good at learning on its own or responding to unexpected events. This tends to be a bigger roadblock than most organisations realise when deploying RPA.
RPA is almost rigid in its application, requiring underlying processes, systems and infrastructure to remain static for optimal performance. This almost leads to a bigger challenge of impeding change within an organisation. In Financial Services specifically, ongoing drivers of change such as shifts in regulatory requirements, customer experience enhancements and an emerging FinTech ecosystem requires a certain level of agility from banking processes. In such a landscape, ongoing maintenance and logic updates to ensure RPA bots are adaptable to change may end up being more costly than the expected benefit.
Consumers of RPA technologies, almost misguidedly, expect RPA solutions to work ‘out-of-the-box’ with limited customisation.
However, the truth is that RPA solutions are very consultative deployments, requiring significant professional services to deploy, onboard and maintain, making deployments highly labour and resource intensive, requiring significant manual work.
Ironically, ‘significant manual work’ is what RPA is intended to reduce.
There are some good use cases for RPA. Legacy systems with an existing retirement plan that do not have any API or interoperability capabilities can have their lives extended or the cost of ownership reduced by a tactical introduction of RPA. These systems are unlikely to undergo changes and the data sets are usually well understood. But again, this is not a simple business case. It is not simply a matter of removing a swathe of manual operators. Governance and quality management must be introduced to ensure the robotic process is achieving its objectives.
- Is it the wrong process?
RPA only works if utilised within the correct process; the technology is most suitable for tasks with limited variables, because it effectively guarantees a set of outputs based on pre-defined logic. If you find the process you’ve automated is more dynamic than you expected, then you’ve automated the wrong process.
If instead it is the environment in which the automation runs is more dynamic than expected, then the RPA tooling will require additional complexity to make sure it can continue to operate in an ever-changing environment and still produce the right outcomes. Such levels of complexity may become a nightmare to deliver both in terms of effort and cost.
If a process requires decision-making on a case-by-case basis, you still want humans closely involved. However, this does not exclude applicability of RPA to any part of the process, but the candidacy for RPA implementation must be carefully considered and evaluated. For example, a workflow automation tool can help handle the repetitive steps of a process that also requires human decision-making and skill. And the workflow automation tool and RPA can work in conjunction.
Defining a process to consider its candidacy for RPA goes a long way. No matter how small a process is, defining it with all its exceptions makes it much larger than it appears in the first instance.
Even if processes have been defined previously, it’s important to start small when initially considering automation. The more logical and easier to define the process is, the faster it is to implement and less prone to errors. In the end, even if the process ends up not being automated at all, it is now defined better, people perform it the same way, and thus it is most likely more efficient and easier to perform.
Failure to thrive?
Given these challenges, organisations should walk a tight rope before deciding to deploy RPA within their business. It really is about weighing the benefits against the costs and taking a long-term view of both i.e. the C-suite should think about the long-term investment required to maintain bots within the business, rather than just taking a short-term view of deployment costs.
It is not to say that RPA offers no value at all; on the contrary in certain instances, if deployed correctly the realisation of benefit from deployment might demonstrate improvement against a range of process metrics. However, to think about RPA alone would still be a mistake. Organisations need to think holistically about their overall plans for digitisation, with RPA being one component of this plan, and not the plan itself. RPA has the potential, as part of an intelligent automation strategy, to revolutionise organisations.
Is this the end of RPA?
Unsurprisingly, many RPA vendors are adding AI or ‘cognitive’ capabilities to their offerings. This integration has led to Cognitive Robotic Process Automation (CRPA) software bots, which can automate perceptual and judgment-based tasks through the integration of multiple cognitive capabilities including, natural language processing, machine learning, and speech recognition. CRPA aims to widen the use-case for RPA to cover a larger number of ‘human’ scenarios.
However, while the possibilities CRPA opens us may be exciting, the marriage between RPA and AI is still not fully mature. It cannot be said for certain whether AI or any other cognitive technology, in fact, will be the knight in shining armour that RPA awaits. For now, what is clear is that RPA on its own offers limited use-cases and hefty deployment and maintenance costs that challenge its mettle.