Expect the Unexpected: RPA Flexibility
How flexibly can you expect RPA to deal with «unexpected» scenarios? Discover the trade-off between business case and robot flexibility, and find out how to conceive the right exception handling strategy.
One key advantage of robotic process automation (RPA) is that it enables you to implement automation solutions with a relatively short time to market compared with the alternatives. A small robot can usually be up and running within a couple of hours. Equally attractive is the cost structure of RPA, which only requires small upfront investments.
However, the downside of fast implementation comes in terms of stability: to deal with scenarios that deviate from the «happy path», you have to build certain exception handling capabilities into the RPA solution.
Our experience shows that the optimal amount of exception handling should primarily be determined by the complexity and added benefits of a handled exception, as opposed to purely technical considerations. Too often, companies strive for a higher automation rate rather than considering the overall business case.
Need for flexibility
RPA solutions, especially unattended ones, need the flexibility to deal with both expected and unexpected scenarios. This added stability ensures that work is performed within the designed process and thus contributes to the business case. Deviating scenarios can occur because of system and business issues, for example systems that are offline, fluctuating response time, an unexpected error message («password expired» is a common example), or a malformed process input. Real-life problems affect robots as they do normal workers. In layman’s terms, the exceptions a robot can face fall into two groups:
- System exceptions, for example when a system like SAP is not available for IT reasons
- Business exceptions, in other words issues around the business process, such as missing customer information on the application form, that block the robot from processing data.
The price of flexibility
With only finite resources available, exception handling must be prioritized based on an in-depth process analysis done beforehand. The more stability you want, the more process variations you have to analyze, and the greater the development and testing requirements involved. As scenarios become more unlikely, the expected return on this investment falls – whereas implementation costs do not.
Three common exceptions illustrate the implications and difficulties in decisionmaking: (1) system timeouts; (2) data validation of client input; and (3) name checks to identify customers.
Balanced, business-driven approach
The likelihood of an exception occurring and the complexity of implementation are key factors influencing the return on your investment in exception handling. The marginal value of each added exception becomes smaller as it becomes less likely to occur. Remote exceptions are also more difficult to test, which makes development more expensive and complex. Nevertheless, some unlikely exceptions have to be built in, as otherwise, «unattended» processing would not be possible anymore. As you can see, there is no clear black or white.
In our example, system timeouts or bad data quality are both unavoidable and likely events. For the former, an application restart is enough, whereas for the latter data validation can be programmed and tested with reasonable confidence. These exceptions have to be included in development whatever the case (see (1) and (2) in the graph below).
Conversely, name matching (see (3) below) only occurs when the customer can’t be identified by other means, such as a customer ID. This scenario is less likely than the other two exceptions (if it isn’t, you should question whether this process is a good candidate for automation in the first place).
The complexity and success rate of name matching is questionable at best – as typos or spelling cannot be accounted for. Given the low likelihood and high complexity, this exception should be left off the development agenda and handed over directly to a human worker to avoid the heavy impact on the RPA business case.
Good exception handling is not defined by the absolute percentage of scenarios covered, but rather by the ratio of how much it contributes to the automation rate without negatively affecting the business case. While the absence of exception handling seemingly benefits development time, it only places the burden back on human co-workers after the go-live. Conversely, an excessive focus on improbable exception-handling scenarios inflates development lead time and costs while contributing only marginally towards an increased automation rate and the overall business case.
Robots and humans are not mutually exclusive; they should focus on what they do best. A balanced exception handling strategy draws on the strengths of both to generate value out of RPA.