Our Response to Forbes Report “Why you should think twice about Robotic Process Automation”

A prospective client recently pointed us in the direction of this report which raises some really good risk points which we have responded to with how they should be mitigated.



Risk Identified by Forbes Report Mitigation
if anything changes with the interface, the data, or any other aspect of the legacy app, then the RPA breaks” No doubt about it – robots need maintenance as does most software. We typically budget 2 days a year per robot to provide any maintenance required. This would only be required for large system changes which is why IT is engaged early in our projects (to understand their systems roadmap and establish a connection with their ongoing plans).

We use multiple selectors when we’re programming our digital workers. For example, if the digital worker needs to click on a button, the automation code (the robot’s instructions) will take into account what the button looks like as an image, the text on the button and the code that sits behind this. This makes the code robust to most changes covered implied in the article as when one thing changes about the button, the code still has another two attributes to rely on. A quick proof of concept automation is built for the current state of your systems whereas an implemented pilot digital worker is built to be resilient this way.

“Changes upstream and downstream, even during bot configuration, can significantly delay bots being put into production”


We always emphasise that our approach is never to restrict our review to just the process itself but to consider the predecessors and recipients of the outputs of the process to understand how the digital worker should be built with these in mind (as with IT in the point above). We don’t simply automate what’s there but as experienced process improvement consultants we look at the context and opportunities to refine the current process before any programming takes place.
“If the API is rich enough, however, then that’s the better, more resilient approach.”


This is true if APIs are available but typically APIs are expensive to build and potentially expensive to update when systems change. If all systems are stable and no changes are anticipated in the medium to long term then APIs are a good alternative.
“Bots need constant management and maintenance over their productive life.” This is only true if they’re not built to be resilient (as in the button selector example above). A well-built robot will only require maintenance when there are wholesale system changes.
“While the possibility of using RPA with AI to address complex and sophisticated processes is exciting, it’s still in its early stages. This can result in fragmentation and higher setup times.” We only use AI and machine learning in very specific instances (for example fuzzy matching of datasets) and the digital workers for these instances are already designed and tested within our test environments. We don’t try out new exciting features on client projects which, I agree, would make for higher setup times.
“A lot of enthusiastic fumbling around that ends quickly, frequently leading to disappointment.” Our opportunity assessment methodology is built to avoid this situation so that the right, stable processes with the attributes required to get the most out of your money are considered in prioritising the processes.