Being a trained historian, I was delighted when on a recent HfS webinar on “Beyond RPA”, I got dissed by participants for a slide that I had drawn up four years back for a similar webinar, albeit for a different organization. When I say being drawn up for a webinar I really mean it, as I would never have expected that this slide would still be in use today albeit in expanded versions and some refer to it as an industry model. And to make my smile even bigger, I revisited those old slides and the title at the time was:” Beyond the Hype: Assessing the Evolution of (Robotic) Process Automation”. You can see the original slide above. As HfS is all about facilitating discussions among the industry’s stakeholders, I am truthfully delighted for all those questions and challenges. That being said, it is time to take stock where the industry is actually at!
Why are we still talking about RPA?
On the danger of sounding like a broken record, we have to stop confining discussions on service delivery to the topic of RPA. Last year I wrote a blog that summarized many of those arguments. Yet, despite a lot of noise in the industry we are getting pulled back and end up discussing RPA time and again. Granted, as nothing is defined, for many RPA is just a placeholder for what HfS would term Intelligent Automation. But beyond semantics, why are we paying lip service to broader notions of automation such as cognitive computing, AI, and self-learning as well as self-remediating engines? Service delivery is not just about business processes. If HfS’s contention about the journey toward the As-a-Service Economy and the OneOffice has any merit, we have to overcome those organizational silos and mental stovepipes. But we also urgently need to expand the set of stakeholders educating and talking about automation. While we have to give a lot kudos to the RPA providers and consultancies who singlehandedly educated the market, the reluctance of the IT juggernauts to enter those discussions is leading to distortions of the direction and dynamics in service delivery.
Revisiting the “Continuum” – and a plea for service orchestration
To go back to my academic roots I am tempted to quote the Cambridge English Dictionary which describes a continuum as “something that changes in character gradually or in very slight stages without any clear dividing points”. If truth being told, I didn’t consult the dictionary before drawing up this slide four years back. But from the beginning, the thought-process was the following.
To help overcome the blurred perception and often confusion that I have tried to call out, HfS did introduce the Continuum of Intelligent Automation to start discussions on the evolution and innovation in service delivery. It is not meant to be an answer to the ever-increasing questions. This model is by no means perfect and we have developed additional slideware that is trying to capture the evolution toward more data-centric models. In this context, I would like to call out just a couple of the points that we are trying to get across with this model:
- First and foremost, the term Intelligent Automation is a placeholder for a set is disparate innovations in process automation encompassing the concepts that you can see on the slide. Intelligent Automation is a critical building block for the As-a-Service Economy as it decouples routine service delivery from labor arbitrage thus supporting the ideals behind the As-a-Service Economy.
- Second, the main idea behind the notion of the Continuum is that all the approaches you see here listed are both overlapping and interdependent. Despite all the focus on RPA and Cognitive, we still need all the less exciting stuff like runbook and scripting, mostly in the data center. From an operations point of view of particular importance is the integration of data into process chains and workflows.
- And the third point I would like to call out is the evolution or direction travel for the broad notion of Intelligent Automation. You can see 3 dimensions here on the slide. First, probably less surprising toward unstructured data. Second, probably less obvious toward less well-defined processes. And thirdly, toward the broad notion of cognitive and artificial intelligence as they are meant to overcome the limitations of the first two dimensions. Especially from a business process perspective, AI is meant to integrate semi and unstructured data as well as allowing this data to be routed through less well-defined process chains. But it really is a broad bucket because the boundaries between cognitive, autonomics and AI are not well defined. Having said all that, we shouldn’t look at these segments as binary choices. AI is being integrated into or bundled with RPA tools and all these tools should be discussed within the notion of service orchestration. An attendee at recent conference condensed this to following pearl of wisdom: “Make sure crap doesn’t get into your production and then throw Machine Learning at it.” Although he used a slightly more lyrical language.
Having said all that, the questions and at times challenges boil down to largely three issues. First, the suggestion that there is a linear development from RPA toward notions of AI? Second, the temptation of trying to pigeonhole tool sets into any of chevrons on the Continuum. Third, having the wrong starting point for discussing service delivery. To start to answer those from the end: service delivery is about service orchestration. All the leading service providers and the mature buyers have moved in that direction. It is all about having the right tool sets for the required use cases. Whether this based on microservices, on leveraging orchestration engines or other means: RPA is just a footnote in those discussions. And just to shout from the rooftops, orchestration implies that there is no linear development. In parts, this answers also the issue on pigeonholing. On the recent webinar, Guy Kirkwood from UiPath used the analogy of a golf course with RPA tools being the putter, while AI is more a drone that drops the golf ball into a hole. While thought provoking and entertaining, this analogy implies the old pigeonholing. Moreover, automation is in the eye of the beholder and RPA is no exception. While nothing is defined, all RPA tool sets evolve toward operational analytics and the broad bucket of cognitive. And lastly, the starting point is not how do we sell RPA but how do we innovate service delivery. It all comes down to use cases and requirements. For many of those requirements, RPA is the wrong approach.
Bottom-line: RPA is dead! Long live Intelligent Automation!
Having uttered this plea many times before, I am not overly confidence that I will get more listeners this time. But we urgently need to broaden the discussions from a narrow(minded) RPA mindset. We need the service providers come to the fore and educate the broader market. We need the buyers tell the stories from the trenches. We need new models and ideas to advance the learnings from the deployment and the best practices. Perhaps we should invite stakeholders of the automation community and undergo a Design Thinking process. The goal should be to reimagine service delivery to support the journey toward the OneOffice. The secondary goal should be to get rid of the Continuum. We would love to hear from volunteers and curious minds!!