Why I distinguish between robots (RPA) and automation
In recent months, a new craze has swept through the IT departments of many large companies: a new wave of so-called robots (or "Robotic Process Automation" software, to be precise) promises to streamline enterprise processes at very competitive costs without having to make any changes to legacy systems.
Of course, the software is not as magical as it seems and the marketing and ensuing hype should be taken with a pinch of salt. As a matter of fact, my own heartfelt conviction is that there are almost always better solutions to the problems at hand than resorting to ‘silver bullets’.
The robots I am writing about are "software tools that replicate the actions of a human being interacting with the user interface of a computer system" (as per the Wikipedia definition). Obviously, because they operate on the screen designed for employees, they have minimal impact on the underlying applications. However, I would have concerns that, by adding an extra architecture layer, such tools would tend to make the IT systems more complex, more coupled and thus more fragile, whereas the most important objective of all IT departments (and mine) should always be to achieve maximum simplification.
We all know that this challenge is immense and I see at least one major benefit from the current trend with robots: evaluating their value holistically provides us with a perfect opportunity to catalogue and assess all our IT processes and identify those that are in critical need of modernization. On this point, I see two options. My preference would be for a future-proofing approach, which involves addressing the root of the problemand, for example, building a framework to evaluate functionalities through APIs (towards a well-defined value proposition, which is the ideal scenario), in order to achieve full, flexible automation. If this ultimately proves impossible, then the robot may be considered as a temporary fix.
At this stage, I can imagine many readers are thinking that, although this line of reasoning is quite straightforward, it could not survive in the real world. Surely electing to go the reasonable and sustainable route is generally too costly, too difficult and too time-consuming to be practical? I would argue, however, that in most cases, the robot would end up being very expensive for the company and produce few overall benefits, and that, having carefully and objectively examined the complete use case, its appeal would evaporate. Even designing a tactical API approach on a system that would end up being retired often makes more sense.
Today's hype around software robots appears very convincing on the surface but CIOs and CDOs should treat carefully before committing to an unconditional roll-out. While there may be a place for such tools in many enterprise contexts, we should keep in mind that our priority is to prepare our IT for an unknown and changing future. More generally, all solutions to a problem should be assessed first to identify the one that works best, no matter how difficult to implement it looks. Sometimes, this process can be made easier through careful analysis. In other cases, the task will need to be split into multiple steps to become feasible. Only when all these possibilities have been evaluated can less-than-ideal solutions be considered.
In this post, I have focused on standard Robotic Process Automation (RPA). In a future one, I will write about the potential in process automation thanks to machine learning and Artificial Intelligence technologies.