With such promise, why have we not seen more large-scale deployments of RPA? I think that a big part of the problem a chasm in the roadmap that opens after the initial proof-of-concepts.
Today’s RPA prototypes pave over cow paths
There are two approaches to getting started with RPA. On the one end of the scale, we have the daunting prospect of addressing the whole back office, getting caught up in strategy, planning and ever-expanding scope creep. And at the other, the rather more seductive and enticing option of staying agile, prototypes, learning on the job and seeing how things unfold.
Is it any wonder that many organisations opt to start out with a small pilot? Add the rather attractive fact that since RPA is completely non-invasive, and therefore more to do with process and logic, and you have an amazing cornucopia of opportunities to make small scale pilots to prove a larger business case.
The prevailing advice to get started is similar to the advice you would be given running any experiment in new technology:
- start with low hanging fruit – so start with a business process that is well understood
- look for redundancy, processes with manual workarounds or duplication of effort
- measure efficiency and effectiveness of process ‘as-is’ to prove value
- find a prototype process that is cross-silo and visible to the organisation
- communicate the experiment and invite ideas and feedback for future stages
- prototype fast, learn lessons and iterate
Because there is no need to redesign your processes, you simply set of an army of software bots to tick through your existing processes field by field, workflow by workflow. But really, isn’t this just the ultimate in Tayloristic thinking? Break out the stopwatches – If we could just execute faster, think of the productivity improvements! While, yes, there are immediate returns because bots are faster than humans, this approach is bound to hit the ceiling of benefits quickly. We do a disservice when our RPA prototypes simply pave over the cow paths of our existing processes.
There are some easy-to-avoid barriers that are created by rushing into a prototype without thought for the future. Those barriers include:
- Not involving technical expertise. This often happens because RPA in non-invasive, which makes people think there is no need to involve enterprise IT. But processes tie much of our organisations together, and the number of back end systems, logic and rules you need to understand to gain true business value is enormous.
- Working in Silos. Since prototypes tend to be single department in scope, you can end up scaling inside isolated, silos. This makes it increasingly likely that you could miss the bigger picture, strategic opportunities. Scale in silos means you are recreating your org chart and broken processes in bot form. Think cross-silo for big impact.
- Missing the big picture. Organisations that continue at the level of lots of small prototypes, rather than moving to a strategic big picture, also miss out on the benefits of the orchestration layer of RPA. This is essential – it supervises and controls the bots ensuring you are working to a bigger strategy, rather than going after low hanging fruit.
- Lacking process and service knowledge. Lack of knowledge of own business processes is a major stumbling block – to be able to automate a process, it must be thoroughly understood, documented and quantified. In most organisations, many of the obvious automation candidates are undocumented and stale.
- Lacking internal capabilities. Lack of internal capabilities leads to heavy reliance on external consultants and lock-in with business process outsourcers. Ownership must sit with the business, and this requires an investment in new digital capabilities.
So, if you are contemplating an RPA project, even at the early stages, it pays to step back, and think: Is there a better way to do this?
Think big, then act small to plan for RPA scale up
We can avoid the pitfalls by stepping back and thinking strategically, before diving back in to act small.
When you start looking at RPA, you should combine your discussions about prototyping with basic planning for scale up. All too often a proof of concept becomes a permanent solution, especially if the technology has substantial license fees or the prototype took blood, sweat and tears to build and test. In addition, scale requires common environment, security, risk and quality standards, which are rarely considered or attempted during prototypes. Therefore, allowing a prototype to become a line of service bot is an immediate limiting factor.
Here are the key discussions that any organisation must have early to avoid some of the barriers:
Technology plus people. This means we need to consider both technology and people strategy before moving to scale RPA throughout the organisation. Governance, key role definition and clear process definition are amongst the basics requires to align and contribute towards strategic goals.
Service design mindset. We must consider a service blueprint for hybrid services – in RPA, robots must be considered full virtual workers to ensure that robots are continually managed and maintained, and considered in wider team decision-making. Designing for the service offered to the business, and mapping the actors (including the RPA actors) allows the organisation to continue making productivity gains. Considering the robots part of the team, and working on the interface between them and the team is crucial for engagement.
Process knowledge mastery. One of the pitfalls of total process automation is the loss of knowledge in the business. If process knowledge is lost, then only incremental improvements can be made. What is needed is to have one or two masters, with the knowledge and depth of insight to make radical innovations once the process has been automated.
Look for value & impact. Setting up a project to scale RPA, we need to look for value – any scaling project must penetrate the value-chain and make lasting impact. Since it is impossible to take anything from an existing process straight to RPA, there are important intermediate stages that can be undertaken whilst the other barriers are being addresses.
Join RPA with other digital transformation efforts. RPA is part of a bigger drive towards digital transformation – consolidating processes and team re-organisations are excellent proofing grounds for scaling RPA. Identifying these opportunities is best done as an organisation-wide dialogue – you will be surprised where the best ideas for automation of processes come from!
Overall, for successful RPA prototypes that pave the way to successful large deployments: Start small, think big and plan strategically.