Search
Close this search box.

5 Lessons Learned from Implementing and Operating RPA

Author

Eric Liebross

https://www.linkedin.com/in/eric-liebross-2b41242/
eric.liebross@auxis.com

Senior Managing Director of Business Transformation, Auxis

Related Topics

Implementing RPA solutions has allowed many organizations to see some very powerful results.  In this blog, I will highlight some of the key “lessons learned” from implementing and operating RPA solutions. They are based on our experience in working with both our internal operations as well as with external clients.

RPA: Beyond the Hype

In part one of this blog series, I concluded that there is a lot of “hype and noise” around RPA, and that RPA is still somewhat of a work in progress.  Many organizations are still trying to figure out how to get their RPA journey off the ground.

In my second post, I provided some tips on how to get started with RPA, offering organizations an effective methodology for identifying, capturing and quantifying RPA opportunities, in order to build your “RPA roadmap.”

Putting the hype aside, the “real” reality is that there are some organizations that have successfully tested and implemented RPA solutions (including Auxis).

Here are five important lessons learned about RPA implementation.

Lesson #1. Understand the Complexity of a Process (from an RPA perspective)

Automating business processes can be a tricky exercise.  Sometimes a “simple” process, is not that simple from a robot’s point of view.

We humans make decisions every single day, based on the data presented to us, and our experience in dealing with that data.  

However, what is a simple decision for a human may be quite daunting for a robot.

A robot will be very effective dealing with well defined, rule-based processes. It will be able to determine the appropriate next steps in the transaction workflow based on these rules. But if the rules are ambiguous, or if all the possible variances or exceptions are not well defined or captured, the robot will be forced to stop processing.

Identify Every Step in the Process

Make sure when you design a robotic process that you completely and accurately capture all of the steps in a process, the business rules, the frequency and timing of activities, and any and all exceptions.

And if there is a point in the process where the robot is truly unable to handle the next step (meaning a human’s judgement is required), all is not lost.

Auxis RPA Implementation Baton Exchange

The Baton Exchange

Break down the process into the steps that can be automated and build a “hand off” to a human worker to resolve the next step(s), at which point you may be able to transition the process back to the robot to complete the transaction.

This would be considered an “assisted” process, where a robot and a human work together to complete the activities., with the robot handling the bulk of the process and the human worker steps in as needed.

All of this should be designed up front. Remember that the role of the human worker will now change, from pure “transaction processor” to what we like to call a “Robot Operator”, so training and change management considerations need to be applied.

What about AI?

What about AI, you ask, and the ability of the bot to “learn” how to resolve these judgement-based exceptions?  “In due time” is my answer.

Today’s AI has its limitations, and it will likely take several years for the technology to advance to the levels needed to handle all judgement-based activities. However, the ability to free up employees from performing all manual activities, and enable them to perform higher value work, will bring tremendous value to today’s business operations. 

Lesson #2. Timing (and volumes) are (almost) everything

In addition to the complexity of the process, make sure that you account for the timing and volumes involved in processing transactions.  

Get ready to do some math

A lot of RPA design is a “math exercise.” You are calculating the amount of time that it takes to complete a transaction, and the volume of these transactions to determine the cycle time:

processing time x volumes = cycle time

Then you evaluate how and where the robot will impact the process, and what the improvements in cycle times will be.

Calculate how many robots you need

A robot can perform one process at a time. The number of robots needed to complete all of the transactions being processed is a function of the robotic processing time and volumes, plus the timing when these transactions need to be performed.

For example, if you need all transactions completed by 11:00 am every morning, and the data is not available until 8:00 am, you have a 3 hour window to get it done. 

If you have 300 transactions that need to be processed and it takes the robot 30 secon