Think complex processes can’t be automated with RPA? Think again

Over the last eight years I’ve read through methodologies, use cases and capabilities and above all – watched robotic process automation (RPA) grow as a solution. I’ve never written anything about RPA so I thought it pertinent for my first-ever blog to write about something close to my heart: complex processes in the context of automation. I feel strongly that even the most complex processes can be automated – if they are the right processes – and I am frustrated when companies pass over prime RPA prospects because they don’t know how to recognise them.

With the advent of RPA, many businesses are evaluating opportunities to increase the efficacy of manual labour, make work more rewarding for their employees, and enable faster and better levels of service for customers through the power of digitisation.

Even with the advancement in process automation technologies and methodologies, finding the right processes to automate is still a difficult proposition. It is this challenge that is so often the first point of failure. And, it is compounded by the fact that sometimes the cost to automate far outweighs the benefit in terms of the actual value realised.

But first, what is a process in this context? I define it as a transaction that is manually completed by a human in a business function – often referred to as back office work, non-customer facing work or an administrative task. Typical examples of processes include completing a credit check for a personal loan application, reviewing documents provided in an insurance claim, sending a wire transfer to settle an account payable, generating an offer letter for shortlisted employees, making payment adjustments for employees as part of payroll, setting up a customer’s direct debit or changing customer details.

So, what is the right process to automate using RPA? In my experience a prime candidate for automation using RPA software is a process that is repetitive and rule-based, with a logical flow. It should involve the use of electronic structured data, and it should be high in volume and completed manually. I’m confident my colleagues and those working in the RPA space would agree with these fundamental criteria.

Dealing with the ‘our processes are complex’ syndrome

The issue facing many organisations trying to decide what to automate is poor documentation.  Processes are often undocumented, loosely documented and/or process maps frequently do not outline possible variations to the process – leading to an inertia called “our processes are complex.”

There are two ways to deal with finding the right processes and the syndrome of “our processes are complex”:

  1. Machine learning driven process discovery using digital fingerprints of transactions passing through user application logs with a discovery tool, such as our Agile Process Automation (APA) solution
  2. Process lifecycle mapping working with the people who do this day in day out to find automation opportunities

Map process lifecycles to determine RPA candidates

We use the process lifecycle mapping approach when we look for opportunities to automate manual processes. I’ve discovered that this approach allows us to decouple most complex processes and unearth the rule-based and logical nature of most complex processes.

What is my interpretation of a process lifecycle? It’s a series of activities in an order that human beings, systems or applications go through to complete a “process.” Although there are standard approaches for mapping, I’m sharing an approach that I have developed over the years while assessing RPA opportunities. The diagram below provides a summary of the lifecycle:

The Process Lifecycle

Click to expand

Data aggregation. Aggregation of information usually happens in two ways, and there lies an opportunity to identify the potential to automate and choose a technology that would work:

  1. Gathering structured electronic information by downloading reports, structured email notifications, online forms and structured information from websites. Such tasks are rule-based and can be automated using RPA solutions.
  2. Gathering information from scanned forms, reading through unstructured documents and comprehending content and context. Such tasks could be partially automated using intelligent optical character recognition (OCR) solutions. Otherwise, humans can continue to aggregate the information manually, then convert the data into an electronic format.

Data interpretation. Aggregated information would then be interpreted according to defined rules that help choose the next course of action.

  1. Validation or interpretation of data, if rule-based, can be automated using RPA.
  2. Validation or interpretation of data that doesn’t have finite rules often needs to be dealt with on a case-by-case basis; it may remain as a manual activity.

Decision. Based on information validation, a decision is taken to proceed to “system actions” (entering information) or stop. A stop in processing actions is often termed as an “exception” in RPA. These business rule driven exceptions are defined either by compliance, regulators, or people who design business processes within the organisation.

System actions. Once a decision is taken to proceed, the ensuing actions to complete the system actions — often termed as “keying information on applications or systems” – are usually repetitive key strokes.

Exit/close case. Depending on the actions and outcome of the steps above, the process either leads to a successful closure (expected outcome through an automated process) or unsuccessful closure (an exception).


The “process lifecycle” methodology of breaking the process into five stages helps to determine which stages of the process have optimisation, RPA or automation potential and which stages do not. Once a process is broken down into these activities, you have deconstructed what is perceived as a complex process, and a logical, rule-based process emerges. When deconstructing a process with this approach you can also identify system actions within each stage – and if they’re rule-based too, then you have a winner.

By adding volumetrics (data about the number of transactions received) and handling times (how long it takes to complete a process) to these lifecycle stages, you get closer to understanding the actual benefits that could be derived from automation – or realise that there is no opportunity.

I’m sure there are various other ways that companies might be approaching process discovery, but I’ve found the process lifecycle method to be interesting, beneficial and ultimately successful for us and our customers in discovering what complex processes can actually be automated.

We can better understand processes by breaking them apart and unpacking their complexity. I hope that you find this process lifecycle approach, which has guided me through RPA projects, is just as useful for you as you embark on your RPA journey.

Rajesh Nair is Head of RPA for DXC Consulting in Australia and New Zealand. With more than 19 years of experience in fields including business process outsourcing, Six Sigma and robotic process automation, Rajesh works to bring the right technology solutions to organisations, in order to help them optimize business operations or enhance the customer experience.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.