Is Robotic Process Automation a Magic Pill?

By Shashank Singh

A couple of weeks back, I was interacting with few operations executives from health insurance, auto insurance and specialty insurance companies. It was a nice cozy evening and the discussion topic was the new buzzword in town “Robotic Process Automation” aka RPA. People have different names to it also – Intelligent Automation, Bot Automation and probably few less known ones.

The general perception was that it’s a magic pill – some godly programmed software which can eradicate all the pain problems of the operations floor – mundane repetitive tasks, boring processes, cross-department bottlenecks, longer turnaround time, high operations cost. After chewing this magic pill, all will look extremely good from the KPI perspective.

Before we jump to assess whether it’s a magic pill or not; let’s understand what is RPA?

One definition says “RPA is a sophisticated compilation of software programs which are intelligently written to capture and interpret existing applications for processing a transaction, manipulating data and triggering responses.”

I think, it’s drawing too long a bow to compare RPA with Robotics as there is limited resemblance with no artificial intelligence (AI), neural networks or deep learning capabilities embedded. A better descriptor would be Intelligent Process Automation (IPA) or Sophisticated Macros (SM) as the set of programs that intelligently mimic human interaction (not behaviour) for managing a specific process and runs in a controlled environment for best results.

A few years back, there was similar excitement about Business Process Management (BPM) tools promising better ROI on operational dollars invested, but these had their own limitations. In today’s world, RPA tools are much leaner, meaner, intelligent and optimally priced to give next level of process automation.

It’s not well-understood that to take the RPA ride, you must meet specific minimum requirements – a basic rule of thumb is to focus on repetitive tasks where programs can be configured to mimic.  This can safely cover processes around finance ops, procurement, customer on-boarding, operations, supply chain management, accounting, customer service, infrastructure monitoring, and much more.

Is it a Magic Pill?

The simple answer is NO. This is not a magic pill where software will be installed for the operations floor and all the amber/red lights will turn green and management dashboard starts to look great. This is a journey.

Let me iterate by giving example in the Insurance industry. Insurers face multiple challenges – namely, manual data entry from multiple data sources, inter-department process handshakes are fairly manual, back-end legacy platforms and ever-increasing need for tighter regulations. Insurers play a balancing act of moving their investments into the digital journey (customer experience), compliance with regulatory frameworks and persistency management. In this scenario, process automation may not be a top priority.  

The reason I describe it as a journey is because it is the RPA tool may help to automate repetitive long-drawn processes, but in parallel, processes must be optimised to achieve better RPA results. The RPA tool will not optimise the process – it just automates. If certain process takes few hours manually, RPA tool can bring down to minutes, but it will not streamline the process or process dependency.

Within the Insurance operations realm, RPA is classic fit around customer on-boarding (new business), where tons of data entry happens, proposal tagging, OCR checks, policy service (address update, etc), letter generation, claims assessment, claims processing, complaints tagging, automated email response and operations reporting,  

In conclusion, RPA may not be a magic pill but it definitely offers a welcome change to the arduous and manual operations department. For a soft- landing it is essential to have a pre-RPA stage, where individual and inter-linked processes are reviewed in detail and are optimised to remove insufficient grids, sub-processes or tasks or data points. For example, if a certain operation report has 20 data elements which are pulled from 5 different data sources, can the report be further optimised (Minimal Viable Outcome) so that it has 10 data elements pulled from 2 different sources. This way, when the RPA program is configured to pull the data – it’s giving optimised result in a shorter time frame.

Executives should be aware that process automation requires process optimisation, both are two great ingredients of a magic pill. The overall objective can’t be achieved if we don’t use both the ingredients. We have to do our bit before software can do it's own.

Shashank Singh is a Singapore-based Digital Consultant specialising in Technology and Transformation Management.