Handling Errors: Can You Trust a Robot?

Even though it seems like computers rule our lives, it’s important to remember that they’re actually not very smart. Computers/programs/robots are very good at doing exactly – exactly – what we tell them to do, but once they hit a situation or an environment that is not within their pre-defined instructions, they become useless.

This represents a genuine challenge for robotic process automation (RPA) – how can you trust a computer program to do the work of a human when it can’t make snap judgment calls? With a trained human employee, you can trust that he has the ability to distinguish an unusual circumstance and keep going. RPA promises to address this challenge (with UiPath at the forefront) by creating robots that will flag exceptions for review by a human while continuing with their task.

There are two main errors that an RPA robot can encounter: business exceptions and application exceptions. A business exception is one which has to do with the nature of the process. For example, if a robot is deployed to handle supply orders for office supplies that will ship in 5 days or less, it cannot proceed with an order that will ship in two weeks. The robot recognizes a case that does not fit its defined limits. It’s important to set limits for your robot; otherwise, you’ll be expecting new office chairs by Friday when they won’t ship from the warehouse for another 10 days.

Another example of a business exception: a robot is tasked with processing checks under $1,000. When it comes across a $3,000 check, the robot should report that exception for later review and move on to the next item. You could see this as a hassle – a properly trained human would be able to decide if that check was valid or not, after all. However, just think of the hundreds or thousands of normal transactions that did not need human attention. The exceptions definitely don’t outweigh the standard use.

The second error type is an application exception. This occurs when a robot tries to connect with another program or application and is unable to do so. The robot is blocked from doing its task and should report that error.

Application exceptions provide an opportunity, though. Sometimes, they happen because the application is offline or down for maintenance, but other times, it’s just a fluke. What if, when a robot flags an application error, another robot is automatically sent to try again? A second tier like this can keep even fewer exceptions off the desk of a human, but it requires a kind of robot management system. UiPath has already begun to explore the possibilities of RPA management software. It’s hard to trust a single robot working in isolation, but a fleet of self-checking robots? Say goodbye to processing errors.

Image by Flickr user Nick Webb, used under a Creative Commons license. https://www.flickr.com/photos/nickwebb/3016498475/