Managing exceptions after the RPA process
By Josh Painter, Bits In Glass
This blog is the fourth and final post in a series on ways to use Blue Prism robotic process automation (RPA) software effectively for business transformation. Check out part 1 on about how to select the best processes for RPA intelligent automation here, part 2 on the Robotic Operating Model (ROM) here, and part 3 on common problems when implementing RPA automation here. This post will focus on the different types of RPA exceptions and solutions for managing them after the RPA process is completed.
Planning for exceptions
A question that should always be asked when working on RPA projects is: what do you do when digital workers aren’t able to complete a task? In RPA projects there are two main types of exceptions that need planned resolutions: system exceptions and business exceptions.
System exceptions happen when a task isn’t performed because of an issue with a system used in the process. This usually happens when an RPA process that is working through information comes across a screen or dataset that’s unique for the task. The process will not be able to continue with RPA unless it’s programmed to retry for potential success. If the retry does not work the item will be marked as an exception and the process will move to the next item. Using the ROM methodology, system exceptions should be rare in a production process because most exceptions, if not all, are worked out during the testing process.
An example of a system exception is when the RPA software is navigating through a program for a specified account and an unexpected screen or data item shows up based on the status of the account, which hasn’t been outlined in the RPA process model.
Business exceptions happen when a known business rule is created in the RPA process to stop processing the task. This usually happens if the business wants to manually review specific cases that the process would identify. The RPA process is supposed to skip over the account based on a predefined limit based on the data so a manual process can take over. Business exceptions vary from process to process and would be chosen by the business during the process discovery phase.
An example of a business exception is when the RPA software finds a transaction that is higher than a predetermined amount. The digital worker is instructed to stop processing. The business exception is then sent to the business owner to manually review and process.
Managing exceptions in RPA
So how do you manage these different exceptions in RPA? The first step is to make sure the appropriate business owner is notified, and one of the easiest ways to report these exceptions to the business owner is to put them into Excel reports that can be created after the RPA process is completed. This can be a problem since the exception reports aren’t available until after the entire process is completed and Blue Prism doesn’t track exceptions during the process execution.
The above problem is easily solved by reporting exceptions by sending an email notification or message immediately after the exception happens. This tackles the problem of not reporting the exception immediately after it’s found, but doesn’t address the ability to track the exception through to when the business owner completes the task. If needed, another RPA process could be added to run the next day to make sure all exceptions from the day before have been completed.
Managing exceptions in BPM
The other way to manage exceptions in RPA is to set up the exception in another low-code business process management (BPM) software solution that can turn the exception into a task. This exception task can then be assigned to an employee and completed by the BPM system tracking the date and person completing the task.
This exception task completion process can be customized to include approvals by managers, additional data from other sources, and documents to make the exception process even easier for the employee. Some BPM software solutions like Appian have even created complete applications to manage exceptions by pulling the exception information directly from the RPA database.
Overall, having a plan to manage exceptions after RPA processes is important to make sure business processes are completed. Having unmanaged exceptions can create unneeded tension between business owners and the RPA team. It’s best to get all parties together to make decisions on the best way to handle exceptions outside the RPA platform.
Like this content? Subscribe to our blog for all the latest updates!
About the Author
Josh is a Blue Prism Consultant and our Lead Blue Prism Developer. In his role, he’s involved in all day to day activities for Blue Prism. Throughout his career, he’s always been involved with reviewing business processes and notes how fulfilling it is to be able to help automate these business processes to make work easier. Growing up in Colorado, Josh enjoys spending his free time in the mountains and traveling to new locations with his family. Read more of Josh’s blogs here.
About Bits In Glass
Bits In Glass is an award-winning software consulting firm that helps companies transform, outpace the competition, drive rapid growth, and deliver superior customer value. We excel at solving complex technical business transformation, automation, and connectivity problems that provide maximum value and the best possible outcomes for our customers.
With hundreds of years of in-house experience, we’re the partner of choice for many business transformation projects, working with market leaders who are disrupting and driving transformation across every aspect of modern business.
Find out why leading technology companies partner with Bits In Glass, including Appian (Business Process Management), MuleSoft (API-Led Systems Integration), and Blue Prism (Robotic Process Automation).