RPA Opportunities: How to address Unstable Processes

It has been quite a while since corporate corridors are abound with news of digital disruption especially Robotic Process Automation (RPA) and AI impacting every walk of life. While strategy heads and digital officers have amassed enormous amount of information on trends in Automation, one key question that we face while working is on identifying the right starting point. 

The straightforward criteria for a perfect automation / RPA use case are that the process is transactional in nature, the logic required to complete the transaction is rules based and the data required to run the automation in a structured, digital format. In short Process stability is one of the most commonly endorsed criteria to appraise RPA prospects. The older argument is that the process should not be in a state of unpredictability if we are going to pull RPA to automate it. While this is ideal and it should be considered a nice-to-have. But there are several reasons why we should not reject an RPA opportunity because of uncertainty but the most important one is that calling a process “unstable” doesn’t really mean anything. 

The term “unstable” is a generic label for complexity and reflects how frustrated individuals who manage the process are with the complexity. Classifying a process “unstable” does not help to understand why the process is unstable. Believe it or not, RPA tools can help you stabilize some of the root causes of instability. Let's label these types of processes as “seemingly multifaceted” because that term invites exploration and a better understanding of the fundamental causes. Some of the main characteristics that make a process seemingly multifaceted are incomplete data, multiple research branches, multiple resolution branches and multiple failure modes. 

A process with incomplete data forces the person performing the process to make some sort of extrapolation about what to do next using the data they have. Extrapolating your way to a solution in these situations is really the process of identifying the right research and resolution steps for that particular problem. 

For example, if you have an excellent purchase order and invoice data but your receipts are inconsistent or unreliable, an EDI matching algorithm will likely fail leaving a person to make a judgement call about how to reconcile the failed match. Many would look at a process like this and say that it’s unsuitable for automation. The problem with that assumption is that the people performing the work are constantly making judgement calls and creating rules on the fly to impose order on the problem. In other words, the team manually performing the work is creating multiple ways of researching and resolving the same root problems. The advantage of having a team manually resolve apparently complex processes is that the business has unintentionally created a laboratory to discover the ideal method of overcoming the sources of process unpredictability. The root cause stems from having multiple ways to resolve the same branch of the process which will create a cascade of failure modes in the final outputs. Ultimately, “instability” or “apparent complexity” leads to extrapolation of research steps and resolution steps which creates a flood of failure modes.

So, what to do with these types of processes? The most important fact to acknowledge first is that the laboratory is not filled with people who are equally proficient at making the right judgement calls. You have some rock stars who are better suited than others to make accurate extrapolations about incomplete data. Find them, listen to them and begin mapping a “happy path” to create an anchor in the process. Next, automate the happy path in RPA. Work to get that branch of the process working well and kick out any transaction that does not meet the happy path’s strict criteria. These non-happy path situations are called “exceptions”. After you are confident that the happy path is working well, give each exception type you identify a name and measure the volume of transactions that meet the key identifiers for that particular exception. Last, focus your attention on defining resolution steps for and automating the high-volume exceptions. As you can see, the process to tackle apparently complex processes is straightforward however, don’t underestimate the level of effort required to define the initial happy path. RPA ultimately helps you turn unstable processes into clearly defined branches that can be understood and individually assessed for automation.

--------------------------------
----------------------
------------