Over the past 5 or 6 years, I've learnt a lot about how RPA can play a key part in operational improvement and wider business transformation and how it can be implemented successfully. In particular, what the technologies can achieve in real life operations, how they fit into and change end-customer journeys, and what really matters when running a successful automation programme. I’ve distilled these hard-won learnings here – hope you find them helpful:

1. Just because you can, doesn’t mean you should

In the rush to get on with things, quite often there isn’t enough thought put into what purpose an automated approach serves. This is also where transformation pragmatism not dogmatism wins out – not everything being done should be being done.

And just because an RPA tool might work, doesn’t mean alternative means of integration or access should be ignored. If you have APIs, use them.

Consider particularly what an end-customer’s reaction to an automated solution might be. Trust wins out over novelty here. Every single response has to be considered in light of user experience. 

2. Be conscious of practical ceilings 

RPA tools provide a cheap, quick and ‘light-integration’ way of accessing systems that don’t have APIs or other integrations readily available. 

They’re great for stable leaned-out environments with scale volume and limited simple rules. However, a ceiling is hit when processes become more conditionally complex. By this we mean that when process maps start branching significantly, based on lots of business rules, it becomes more challenging to develop, maintain and build these processes in automation tools (particularly in industries where regulation and checks and balances have accreted over years).

3. Do with, not to

This is borne out in every transformation programme I've ever been part of. Having folks come in and tell operations what to do doesn’t typically sit well with people who have been experts in doing their jobs for years! With regard to RPA, the opportunities are usually best spotted by the people who know the processes best. By working with the business and embedding automation within the culture of the operation, success grows organically.

For one of Capita's clients, over the course of five years, automation has delivered a net benefit of >450FTE in the back office, while simultaneously improving the experience for its customers at the front-end, and allowing for substantial customer growth. Create a cult of automation with a few fervent believers within the operation and empower them to get on with things.

4. Avoid vanity metrics

The number of bots quoted in screaming press headlines is often just the number of licences bought. Bots deployed in operations is more relevant. More relevant still is the % of overall work being undertaken, and more relevant still is the impact on FTE and customer experience – those are metrics that count.

You also don’t need hordes of developers and consultants to do substantial things. The Capita operation I mentioned above has only three developers, who have delivered huge benefits through a systematic, well-governed programme of automation.

5. Get moving – and bring people with you

Conventional wisdom says to lean out and analyse processes, and then build the associated automations. That can give a clear roadmap and identify where you can afford the upfront investment that’s appropriate.

However, even by automating sub-standard processes as they stand, you can deliver benefits sooner and fund future process improvement. It can provide valuable collateral to persuade doubters of the practical potential of the technologies. An obvious note of caution though – this still needs to be well governed and controlled.

So my key message is ‘digital pragmatism beats analysis paralysis’. Start off with a pilot – look for activities that could – and should – be automated now. And I’ve found that pretty much every organisation that’s had a successful pilot has jumped at the opportunity to do more. The benefits are easily measured and hard to ignore.