Blog article
See all stories »

Does RPA fit into your processes?

I’ve had an epiphany. Sadly, it’s about IT stuff – but I thought I would share it anyway! 

More specifically, it’s about Robotic Process Automation (RPA) and when to use it. As you will see below, scenarios which appear to be good candidates for RPA could turn into very costly mistakes. 

Anyone who’s spent time in contact centres or shared-service centres will be familiar with the range and complexity of processes their work entails. I’ve spent a lot of time in these environments over the course of my career and without exception have found them to be filled with hard-working individuals who do a great job, despite not always having the best tools. 

A helpful way of thinking about these processes is to see them as a mix of ‘exploratory’ and ‘programmatic’ tasks; this is something that MWD Advisors recently highlighted in their report on Desktop Integration. Exploratory processes are those that are fundamentally human-centric, while conventional wisdom says that ‘programmatic’ processes are the ones in which automation services (e.g. RPA, workflow or BPM) can be used to remove tedium and accelerate task completion.  

My ‘moment’ came when I met an organisation who had recently reviewed their back-office programmatic processes. They had concluded that even though the process flow was repeatable, the need to interpret and act upon unstructured data sources from 3rd parties would make an RPA solution too fragile. Their view was that day-1 of using an RPA solution would be fine, but beyond that they would be faced with a never-ending maintenance nightmare.  

One potential solution for this organisation, would have been to drive the adoption of self-service (or APIs) into the third-parties and/or agree a data exchange standard. That’s great if you are a market leader in your field and can mandate change. What if you are not OR you don’t have a business case that would cover the costs and effort of this approach? 

UX integration (and the various industry standards that support it) are making it possible to simplify the user experience for exploratory and programmatic processes while keeping the user fully in control. Existing UIs can be composed and then augmented with new agent-assist components that gather data from suitable data sources before prompting the user to review and make amendments. All of this is seamlessly integrated into an optimised user experience that blends just the right amount of automation with human-override. The process that I witnessed had 5 enterprise applications, 6 files and 75+ copy/paste operations. Ideal for RPA? Think again. 

10930

Comments: (2)

A Finextra member
A Finextra member 04 August, 2018, 19:22Be the first to give this comment the thumbs up 0 likes

Hi James

I have worked with BPMS in the banking industry. Used it for process automation and for operational risk management. I refer to the last 2 lines of your article. Are you stating that standardisation of the operating model is a pre-requisite for RPA? If my understanding is correct, I would state that it might make sense to take one more step back and ensure that an enterprise BPM is implemented only after an institution (bank) has standardised its products/services and the resuling business delivery processes. Since, I have come across banks not getting the ROI from BPM investments because of non-standardisation, would I be correct to state that RPA could increase the risk profile of non-standard operating environments? I have not implemented RPA and wish to get your inputs.

the link below might give you an idea where I am coming up..

https://globalriskcommunity.com/video/process-based-operational-risk-management

 

James Wooster
James Wooster - Glue42 - London 24 August, 2018, 11:27Be the first to give this comment the thumbs up 0 likes

Kanan, my apologies for not responding sooner. First, I would like to explain what I mean BPM before I address your question.  To me, BPM is about the automation of processes and/or human interactions as it spans multiple applications; if you like, the “inter-application process logic”. When done well, it will use services exposed by the backend to abstract the details of the process and keep it resilient to change. Likewise, at the front-end, BPM should only involve a user when the process paths are easily modelled and known ahead of time. To the extent that these services and rules are in effect standards, then you are right, having these defined will result in more robust solution.

 

The problem with many RPA solutions is they operate as a synthetic end-user and hence they either cannot or do-not directly leverage the back-end services. This means that changes to the UI (which are largely ungoverned) have the potential to break the ‘robot’. Furthermore, RPA’s promise of not requiring any changes to the applications makes it impossible to augment the user journey to allow additional steps for intervention and review. Sure, the lack of standards here is an issue – but the bigger problem is trying to use RPA for exploratory processes. Once an organisation has exhausted the pool or fixed/repeatable processes, then another approach is required.

James

 

James Wooster

James Wooster

COO

Glue42

Member since

16 Jul 2018

Location

London

Blog posts

5

Comments

1

This post is from a series of posts in the group:

Digital Insurance Trends

Customer acquisition, onboarding and engagement, underwriting and risk management, billing and claims – all these areas are being changed by the digital innovations. Digital Insurance Trends is a group for professionals who are interested in Insurance Technology, Fintechs, and Solutions Providers - as well as Global Industry Intelligence.


See all

Now hiring