Site icon mindzie

A Process Optimization View on Robotic Process Automation

Balancing Value and Efficiency when Automating Business Processes

 

Robotic process automation (RPA) is a form of business process automation (BPA) in which bots, or digital assistants, replace humans in performing low-value, high-load, and low-variance activities – I will later refer to this combination of the three dimensions as the value-load-variability trinity. RPA carries the promise that humans will only be performing value-adding and knowledge-intensive tasks (if those do not get automated too, eventually) instead of boring, repetitive, time-consuming, non-value-adding manual tasks. In fact, it is hypothesized that the sheer lack of motivation makes humans that perform these boring tasks prone to error and often leads to low-quality outcomes.
 
Disclaimer 1: In this post, I will not discuss any concerns that RPA poses to employment nor the possibility of automating knowledge processes and tasks.
 
The concept of RPA has been around for a while, but recent advances in technological solutions in the areas of process mining and process automation enabled its efficient and scalable implementation. Originally, RPA techniques would mimic a user that interacts with a User Interface (UI) and demonstrates to that UI how repetitive activities are performed. The user’s mouse clicks and typing patterns would then be recorded and executed “behind the scenes” by the RPA solution (while the human worker is busy doing other things). Recently, the concept of unassisted, AI-driven, RPA (aka RPA-AI) was proposed, with the promise being that tasks will be auto-detected as potential candidates for automation and automated with minimal (or without any) human-in-the-loop. To this end, one would need an effective way to detect good automation candidates.
 
Disclaimer 2: This blogpost is agnostic to the specific RPA technology that is chosen for the implementation (although, RPA-AI sounds like a more promising and interesting direction that would automate the process of automation, which is rather repetitive on its own).
 
Instead, we would like to explore (and later challenge the existing approaches that try to answer) the following question: how does one detect potential candidates (activities/processes) for automation? In other words, what makes some activities and processes more automation-prone than others? We argue that reducing cost, manifested as the volume and/or the repetitiveness of tasks, should not be the only factors that matter when automating processes. One must also optimize on the expected post-automation value increase (or reduction) before deciding which activities should be automated.

 

Returning to the value-load-variation trinity, one can notice that it is relatively easy to detect high-load activities: if an activity repeats many times and requires much of our resources due to long duration – it is load intensive. Moreover, low-variation processes can also be easily detected, e.g., using process mining. These processes exhibit a small number of, well, as their name implies, variants. In fact, load and variability related automation indicators are listed in an excellent paper by Wanner et al. (2019) and they include: execution frequency (how frequent the task is), execution duration (how long does the task take), and three other parameters related to the variability of the tasks at hand (including how automated the process already is – the more it is automated, the less potential we have for further automation). These Wanner indicators, as we shall refer to them later, make a lot of sense from the efficiency perspective, but they completely ignore the value aspects of task automation.

 

The most difficult part, in my view, is to attach a value to an activity or a process. In fact, the question of the value of an activity is both counterfactual and relative in nature. Why is it counterfactual? We only know the value that an activity adds when performed by a human pre-automation. Why is it relative? If the activity currently adds value, one has no guarantee that when automated, an activity will still add the same value. In fact, if value is measured by, say, the quality of the activity’s outcome, then we can imagine settings in which quality is reduced when we outsource the activity to an RPA solution.

 

If the process which we wish to automate is already “optimized”, meaning that we eliminated all non-value-adding activities, we are remained with activities that add some value to our goals and now we must decide – which of the activities are good candidates for automation. Say that these activities even have a similar Wanner score. We could rank the activities by the value that they are adding to our outcomes and try automating the bottom of that list. The problem with this approach is that even if an activity adds small value, it may still be knowledge-intensive and require human expertise to eventually produce a high-quality product. Moreover, we cannot be sure that automating these activities would retain the same value or lower it.

 

To measure the change in value related to automation, one requires to either prove that the bot can do as good of a job as a human in performing the task or prove that the loss in value is worth the savings in terms of efficiency.

 

One classical example for such a trade-off between efficiency and value is call centers in large banks and their interactive voice response (IVR) units. IVR units provide some of the customer services required by customers, thus replacing call center agents. These units are clearly not as good as a human agent (for now); however, the savings of full-time equivalents are (often) worth it. Rest assured that for VIP customers the bank’s agent will always be readily available to answer the call. Another example is the process of producing medical stitches. Clearly, it is not an activity at the top of the list in terms of value-adding tasks when a surgical process is performed. However, unless a suitable technology that would perform stitches better than a human (or at least equally well) would exist, most health providers would not choose it even if it means saving time and resources.

 

To conclude, many RPA initiatives focus on finding high-load and low-variance activities and processes, because they are easier to measure using tools like process mining. However, these solutions often neglect the value (or the loss of) associated with automating those activities. One must find a way to balance between efficiency and value, which loops back to process improvement. In short, to reveal the true value of RPA, one must first understand the business process, then uncover the cost-value trade-off that leads to process optimization, and only after going through these motions automate the various steps.

 

Arik Senderovich, PhD