How To Train Your Robot
Now don’t get me wrong, we really do believe that robotic process automation (RPA) is as good as the hype makes it out to be. Yes, RPA is relatively fast to deploy, robots work 24 hours a day, you should see increases in productivity and a reduction in error rates when it’s implemented properly.
The problem with RPA is the hype that’s used to sell it. Here’s what some vendors are saying: “Your employees will use visual tools to graphically capture and automate repetitive activities on our designer screen (without a hint of coding)” and “RPA that’s so easy, every employee can use it – for any process, anywhere in the business.” If you buy any RPA product believing that it is really that simple to implement, let me now reset your expectations and dispel some myths. For those who have already started their RPA adventure, I’m sure the following won’t be news to you.
Your employees will use visual tools to … automate repetitive activities (without a hint of coding)…
Close your eyes and imagine your current operations staff happily training their robots by clicking the RPA software’s ‘record’ button or by drawing a flowchart of the process, then simply clicking into all the usual applications they use to carry out a process, entering data and writing emails. Their robot watches on, ever willing to learn, paying close attention as to which passwords to use to access each application, where to enter data and the like. And it’s all been set-up without anyone from IT getting involved. It’s a process automation and software deployment utopia, right?
Unfortunately, no it isn’t. The desktop is a dangerous place for robots, with screen elements being created differently (eg HTML versus java), window response times varying or lag requiring retries to be built in, menu items in browser based applications can be hidden by drop-down menus – the list is long.. That’s not to say that these issues can’t be overcome because they can. But at a minimum it takes a very technical business analyst or a coder to identify the problem and configure a solution which works reliably.
For any process, anywhere in the business…
I guess technically it can be used for any process, but there’s no ROI to be had from applying it to low volume or overly complex processes. RPA’s value comes from its ability to be rapidly deployed across high volume, relatively simple processes. Or where a process is more complex, requiring some sort of subjective intervention, a human can review a packet of work (eg approve an insurance claim) and then pass it off to a robot to complete the simpler part of the overall process.
I think the implication that RPA can be implemented with little to no involvement from BPM and IT professionals is a serious issue faced when implementing RPA. Let’s face it, from the business’s point of view, BPM and IT people slow projects down by wanting to review the quality and compliance of software installs, they want to test and document everything. That adds time and cost to a project. Yet now we’re seeing real life RPA projects where there are no coding standards in place to ensure quality and to minimize ongoing maintenance costs. Serious compliance issues are arising from issues like robot’s passwords to log into line of business systems being visible to passers-by and robots changing customers’ personal data without rigorous testing having taken place.
Ultimately RPA may change the world, but as with any disruptive technology there are mistakes being made by the early adopters. The serious mistakes can be avoided by sticking to the tried and tested BPM and IT software configuration/coding and deployment procedures. Don’t believe that Jack or Jane in the change of address processing team can train a robot without help from experienced technical staff and BPM professionals.
