Make your robot perform like a rock star: achieving the remaining 15 per cent. An article by the head of transformation at Genfour, Rita Brunk, who has been involved in hundreds of robotic process implementations
I’ve lost count of the number of times I’ve seen back-office robotics implementations that are functioning about 85 per cent as well as they should be.
Companies often get robotic process automation running perfectly in say, 7 of 9 sub-processes, but when it comes to that remaining 15 per cent, many companies are in the dark as to how to get the robot to perform like a real rock star.
From experience, I’ve learned that there are several quite clear cut reasons robots underperform: lack of process documentation, lack of “the human touch”, or simply development teams that don’t video record processes or hold them up to high enough standards.
We’ve got a generation of subpar robots on our hands, with only ourselves to blame. Read on for more information on some critical activities companies should take on to get your robots working to the extent they were originally intended.
Let me elaborate
The foundation beneath the programming of any robot in the back-office is very detailed step-by-step process documentation.
Robots are only developed to do what is in the process document, which must include every keystroke and screenshot documenting an actual human’s journey to complete the process.
For example, it the robot needed to do 10 things in an Excel spreadsheet and the process document did not indicate that the file needed to be saved, the work would be useless.
In many instances when robots do not manage to complete tasks as well as they should, or when work is not being completed, I’ve found time and time again that the gaps are in the process documentation.
Remember, we want our robots to perform like a rock stars, not like kings of karaoke. So when it comes to bridging that 15 per cent gap, the extra process documentation review may be the first place to start.
The human touch
Before we can consider the process document, also known as our “Dummies’ Guide” to RPA programming, there are two more critical activities companies need to take on board.
The first is for someone other than the original human processor to take this detailed documentation and complete the process from beginning to end via the steps detailed in the document.
Any questions asked or confusion noted results in an adjustment to the document. This is no different from a normal IT programming change but in robotics, there seems to be more rigor around this document.
The second critical activity is to record via video someone doing the task, including the impact on the enterprise resource planning and other system screens.
An additional benefit of the video is that the developer or a process expert can step back and really scrutinize if everything being done really needs to be done, whether it’s including additional activities or stopping and questioning whether a step is necessary
Remember the goal of the robot is to have it run as close to 100 per cent efficiently and effectively. If a step does not add value, why not consider eliminating it?
Stop being manipulative
Another bit of my experience I would like to impart (although you may not consider it until subsequent robots are being designed) is that companies should be considering whether the data coming from their robot needs to be manipulated before it can be used.
An example would be a file containing figures in whole dollars and cents, which actually needs to be in thousands of dollars.
If a human has to get involved to manipulate the data, then clearly the company is not expecting enough from its robots.
Implementing RPA in your organization is an opportunity to get things 100 per cent right, so forget manipulating data, and instead, consider adding the task to the activity the robot will be developed to do.
In a perfect world…
Now that you’ve got your four key ingredients for success; the process, the document, the recorded activity and the resolved data optimization requirements, it’s time to consider another step which is often not even taken in to consideration.
Step back and play the game of “in a perfect world…” In other words, in a perfect world, is there more value you want the process to yield? More information or analytics? Are there steps in the process that could possibly be done simultaneously instead of serially?
This is the most important part of my learning in the robotics field, and thus, I hope you take at least this piece of information back to any opportunities you are considering for automation.
The net out of this “in a perfect world” challenge may result in yet more changes to your process document, but they will likely be the most valuable changes you’ll make.
