What is stopping you from starting an automation program?
I recently wrote for Disruption on the benefits of Robotic Process Automation (RPA) and Artificial Intelligence (AI). In that piece I described what these technologies are, and how they work well individually, but also how they complement each other extremely well. The RPA ‘robots’ (essentially software agents that carry out business processes usually carried out by human beings) are perfect for rules-based activities, but struggle when they have unstructured data inputs (such as customer emails) or have to make complex decisions (such as whether to approve a loan application). AI can step in here and convert the unstructured data into something structured that the robots can process, and can deal with the ‘fuzziness’ of having to make decisions based on lots of different inputs.
The benefits of automating processes in this way are many. Cost savings are achieved through the arbitrage of replacing humans with robots but also through the increased accuracy and consistency that robots can deliver: once trained, the robots will carry out the process exactly the same every single time. The AI opens up the possibility of automating many more processes, freed of the usual constraints of RPA regarding unstructured data and complex decision making.
Artificial Intelligence can also do much more than ‘just’ supporting RPA processes. It can understand speech, identify objects in images, find groups of similar-minded customers in mountains of data, make predictions and solve complex problems. So, with all of this value to be gained from RPA and AI, what is stopping organisations jumping headlong into a full-scale automation program?
There is, of course, some natural nervousness about becoming dependent on machines, rather than humans, in carrying out business processes. And there is also usually a little bit of fear – this is not because people are scared that robots will take over the world (they won’t) but more a fear of the unknown (these are new and powerful technologies, after all). But the biggest thing stopping people embarking on an automation program is, in fact, not knowing where to start.
Let’s take a look at some of the key aspects to consider when embarking on an automation journey and, in particular, the main building blocks of an Automation Strategy based on my experiences advising businesses in this area.
Creating an Automation Strategy
In my mind, this is one of the most important stages in the automation journey. Before any consideration is made of the types of technologies or the processes to be automated, it is crucial to understand how the Automation Strategy will align with the overall business strategy, and what the potential end point might be.
Aligning with the Business Strategy obviously means having a good grasp of what that is and what it is trying to achieve. Typically, businesses might be looking to reduce their cost base by a certain amount, they may be looking to improve customer experience through increased CSAT scores or they could be looking to reduce their exposure to risk through better reporting and compliance (plus many other options and combinations). Automation will be able to address some, but not necessarily all, of these objectives – the trick is to match the automation activities with each of the addressable objectives. But how do you know what the automation activities are?
This is where some useful methodologies and tools come into play. None are unique to the automation space, but each has been adapted from established technology strategy approaches. All have been tested and applied in the front-line of business.
The first aspect of the Automation Strategy to consider is the automation maturity of the organisation. This is akin to the CMM maturity models used for software development, and results in an Automation Maturity Matrix. Businesses usually start by assessing each department or function that is in scope, at whatever granularity is appropriate, based on a scale of zero (completely manual processes) to five (end-to-end strategic automation). Against this base-line, each department can then agree what level of maturity they think is appropriate to aim for – the gap between the ‘as is’ and the ‘to be’ provides the initial levels of ambition for the automation strategy.
Next is to understand what automation opportunities there might be. This is done (usually with external experts) by investigating each of the candidate areas and by identifying where the different automation technologies (RPA and all the different flavours of AI) could bring value. The end result is a ‘heat map’, presented as a matrix of functional areas and automation technologies. Each of the automation opportunities can be mapped against the types of benefits that will be delivered, which should ideally align with the overall business strategy. Those opportunities with the greatest alignment, the higher potential value, the most common technology or the biggest concentration in one functional areas should thus be prioritised. The Automation Strategy is now starting to take shape.
Now it is time to start looking in more detail at the value that the prioritised opportunities can deliver. An Automation Business Case doesn’t look much different from a traditional IT Business Case, but some aspects can be more challenging to pull together. RPA is the easier to assess, as the majority of the benefits will likely be from arbitrage, but the other benefits of reduced errors, less rework, increased compliance, higher responsiveness, etc., shouldn’t be forgotten. With AI, it’s a little trickier as the benefits are more focused on improved customer experience or enhanced decision making, but a little thought, and maybe some outside help, can create a decent-looking business case.
The final building block in the Automation Strategy is the Roadmap.
There are two major approaches to automation journeys – ‘think-then-do’ and ‘do-then-think’. Spoiler alert: the usual approach is a combination of both of these.
With the think-then-do approach, the strategy is built up fully across all areas before any technology is implemented. This has the advantage of being able to target specifically where the automation will have the greatest benefit, and allows all of the potential benefits and costs to be assessed. The challenge though is that this can take quite a bit of time, and cost, to complete, and stakeholders usually like to see something more tangible for their money. Which is where the do-then-think approach comes into play.
In this alternative approach, initial momentum is built up through a prototype or proof-of-concept so that tangible results can be demonstrated quickly . The risks are that the wrong process and/or technology is selected – a failed implementation at this stage can spell doom for the whole program. Therefore, a more typical approach is for an initial high-level review to be carried out (including the Maturity Matrix and Heat Map) and then a prototype selected from there, with more detailed work on the Business case and Roadmap continuing concurrently.
The other aspect to consider for the Roadmap is how to group the different automation opportunities into meaningful projects. These might be grouped by function or technology, but will usually be themed around specific objectives, such as ‘Customer Experience Improvement’, ‘Paperless Office’ or ‘Risk Reduction Project’.
The Automation Strategy then, built up from the Maturity Matrix, Heat Map, Business Case and Roadmap, comes full circle back to the Business Strategy: ‘these particular automation projects (made up of a series of automation opportunities) will address these particular business objectives in these timescales and will deliver these benefits’.
Whether the prototype build is carried out during the strategy development or afterwards, there are a few things to consider here as well. I have used the word ‘prototype’ as a general term, but there are a number of different approaches that can be taken to that first automation build.
Firstly, the decision needs to be made as to whether it will be an RPA or AI build. It’s generally not a good idea to try both at once (unless there is a very specific requirement) and RPA is usually the simpler of the two so is the more popular choice. If the main focus of the Automation Strategy is around AI though, it may make more sense to develop this first, especially if the benefits can be suitably impressive.
If the decision is to build up RPA first, then it is usually a choice between a proof-of-concept (PoC) or a pilot. With a PoC only the ‘happy path’ (the core process with no exceptions or escalations) is automated, usually using dummy data and usually not in a live environment. Once the concept has been proven, this build will be discarded. This means a PoC is usually quick and simple to do – it builds momentum, but the costs of doing it are not recoverable. A pilot, on the other hand, automates a live process, using production data and including as many of the exception and escalation routes as possible. It certainly takes longer and will cost more, but, if successful, the benefits can be realised immediately.
The processes selected for an RPA pilot or PoC should be relatively simple. Ideally they will be contained within a single department or function and have a low business risk but a large benefit associated with them. A pilot process that currently uses temporary resources is a good choice as the benefits can be realised almost immediately.
For an AI first build, there are a number of additional challenges to overcome. There is not enough space here to go into these in any detail, but the main consideration is the data that will be used. In most cases AI feeds off data, and, by its nature, requires large amounts of it before it can deliver meaningful insights. Any initial build will need to think carefully about whether a full data set is required just to ensure the results are robust, or whether a sub-set of the data will be adequate. Getting hold of clean, meaningful data is one of the biggest challenges of implementing AI, and this is therefore magnified during the initial build stage.
So, in my experience, a little methodology and a little knowledge can go a long way to help start an automation journey. Business executives need to look beyond the hype and focus on what RPA and AI mean for them, building a meaningful Automation Strategy that will provide the foundation for creating new sources of value within their business. Most importantly, I urge people not to wait around – this technology is available today and is being used in anger by many different companies. The fist step on the journey is always the most difficult, but will reap huge rewards if done properly.
Andrew Burgess is a management consultant, author and speaker with over 25 years’ experience, Andrew is considered an authority on innovative and disruptive technology, artificial intelligence, robotic process automation and impact sourcing. He is a former CTO who has run sourcing advisory firms and built automation practices. Andrew is also the author of the book The Executive Guide to Artificial Intelligence which will be published by Palgrave MacMillan in November