Currently, I’m working on the early stages of a project to implement Robotic Process Automation (RPA) in a client’s business. The client is looking to deploy RPA to handle routine tasks – freeing up valuable resources to focus on delivering more important and highly valued services for people across the business. The other day, the client took me aside and asked a very interesting question: “What’s next after RPA?”
When you’re still in the process of implementing something, it might seem strange to already be thinking ahead about what’s next. But he’s absolutely right to do so. The IT landscape – especially in a business as dynamic and critical as human services – evolves so quickly that building with a view to what might replace the current tooling is key to maintaining flexibility for the future.
In asking about what would come next, the client wasn’t just referring to things like combining artificial intelligence (AI) with RPA (which we’re already doing for his business). He was genuinely looking beyond RPA to the next horizon of opportunity in terms of service delivery for people across the business. And he had a particular concern in mind: how will his organisation avoid ending up depending on a mass of robot processes, which in turn are sensitive to changes in the underlying systems?
He called this risk the “technical debt” – and with good reason, as it aligns closely with the programming concept of Technical Debt, which is the backlog of work that arises when quick wins are applied in place of the best overall solution. Part of the answer is therefore to build RPA like we should build all systems: as modular components based on strong build standards and applying user-centred design to ensure the needs of the user are taken fully into account. With this in mind, most of our work for this client in the RPA space has been focused on establishing a strong and agile “DevOps” platform for RPA development and operations, with all RPA processes and licences orchestrated centrally in a Robotics Operation Centre.
Once you have built RPA in this way, the questions of if, when and how you will replace the robots actually becomes quite straightforward – so long as you understand what RPA actually is.
So, what is the “robot” component in RPA? It is a convenient way of bundling a number of different services under a single licence – services that perform integrated and/or related functions for automating various tasks. For the client in question, these services include things like Optical Character Recognition (OCR), application programming interfaces (APIs), HTML Document Object Model integration, web drivers, workflow management, rule-based decision-making capabilities, and many more.
Against this background, moving beyond robots or addressing the “technical debt” my client referred to is really about unbundling the licensed services where there is a cost or strategic justification for doing so. Examples might include a situation where the costs of unbundling the services and then running them on an unbundled basis are less than the licence cost of the RPA product.
In approaching such decisions, the precise cost/benefit pivot point will clearly depend on the volume of transactions involved, and therefore the number of RPA licences required. Given that an annual licence for the UiPath automation platform costs about the same as 10 days of development work, most custom build or integration options will be relatively more expensive than just buying more RPA licences.
However, there’s also another part of addressing the technical debt. It’s about moving screen-based actions to integration at the API level – a step that can improve the isolation and reuse of components, as well as mitigating the risk that rework will be needed due to changes in the underlying systems. The solution used to do this may still be RPA software, acting as the orchestration tool invoking each API in a process. But the fact that this change reduces the reliance on graphical user interfaces (GUIs) means there’s less susceptibility to underlying system changes, as well as providing significantly faster processing speed and simplifying error handling.
In my view, all of this points to a need to have two key elements to support and enable the evolution beyond RPA. The first is having a strong API strategy, including things like versioning, resilience, and access models. The second is strict adherence to proven user-centred approaches and build practices, especially modularisation. Working with my client, we have put both of these in place for his business.
The graphic below illustrates how an existing RPA process can be transitioned over time to an API-based solution. You’ll see that at the interim stage – shown in the middle layer of “boxes” – there’s still a legacy system in the mix. At this point in the transition, some element of RPA must remain in the process, or alternatively a screen-scraper/GUI data input tool may be used. The solution can only become fully based on an APIs-plus-services approach once the underlying systems can support it.
So, to answer my client’s original question: this is what’s next after RPA.
My question to you as readers: How can you leverage RPA in your business?