McKinsey: Can you start by defining robotic process automation (RPA)?
Leslie Willcocks: RPA takes the robot out of the human. The average knowledge worker employed on a back office process has a lot of repetitive, routine tasks that are dreary and uninteresting. RPA is a type of software that mimics the activity of a human being in carrying out a task within a process. It can do repetitive stuff more quickly, accurately, and tirelessly than humans, freeing them to do other tasks requiring human strengths such as emotional intelligence, reasoning, judgment, and interaction with the customer.
Stay current on your favorite topics
There are four streams of RPA. The first is a highly customized software that will work only with certain types of process in, say, accounting and finance. The more general streams I describe in terms of a three-lane motorway. The slow lane is what we call screen scraping or web scraping. A user might be collecting data, synthesizing it, and putting it into some sort of document on a desktop. You automate as much of that as possible. The second lane in terms of power is a self-development kit where a template is provided and specialist programmers design the robot. That’s usually customized for a specific organization. The fast lane is enterprise/enterprise-safe software that can be scaled and is reusable.
You can multiskill each piece of software. It’s lightweight in the sense that you don’t need a lot of IT involvement to get it up and running. Business operations people can learn quite quickly how to configure and apply the robots. It’s lightweight also in that it only addresses the presentation layer of information systems. It doesn’t have to address the business logic of the underlying system or the data access layer.
McKinsey: How is RPA different from cognitive intelligence?
Leslie Willcocks: RPA deals with simpler types of task. It takes away mainly physical tasks that don’t need knowledge, understanding, or insight—the tasks that can be done by codifying rules and instructing the computer or the software to act. With cognitive automation, you impinge upon the knowledge base that a human being has and other human attributes beyond the physical ability to do something. Cognitive automation can deal with natural language, reasoning, judgment, with establishing context, possibly with establishing the meaning of things and providing insights. So there is a big difference between the two.
In addition, whereas RPA is pretty ripe as a technology, cognitive automation isn’t. I’ve not seen a wave of powerful cognitive automation tools appear in the market and not many companies are using them yet.
McKinsey: What are the business benefits of RPA?
Leslie Willcocks: The major benefit we found in the 16 case studies we undertook is a return on investment that varies between 30 and as much as 200 percent in the first year. But it’s wrong to look just at the short-term financial gains—particularly if those are simply a result of labor savings. That approach does not do justice to the power of the software because there are multiple business benefits.
For example, companies in highly regulated industries such as insurance and banking are finding that automation is a cheap and fast way of applying superior capability to the problem of compliance. You also get better customer service because you’ve got more power in the process. A company that receives lots of customer inquiries, for example, can free staff to deal with the more complex questions.
There are benefits for employees, too. In every case we looked at, people welcomed the technology because they hated the tasks that the machines now do and it relieved them of the rising pressure of work. Every organization we have studied reports that it is dealing with bigger workloads. I think there will be an exponential amount of work to match the exponential increase in data—50 percent more each year. There is also a massive increase in audit regulation and bureaucracy. We need automation just to relieve the stress that creates in organizations. One online retailer measures the success of RPA in terms of the number of hours given back to the business. So it’s not just the shareholders, the senior managers, and the customers who benefit but also employees.
The case for digital reinvention
McKinsey: Can you describe a process where you have seen RPA in action?
Leslie Willcocks: In an insurer we studied, there was a particular process where it used to take two days to handle 500 premium advice notes. It now takes 30 minutes. It worked like this: a range of brokers would write business for clients, and there was a central repository into which the business written had to go, and a process that someone had to manage to get the premium advice note from the broker into the repository. A number of operations had to occur for that advice note to be fully populated by all the data, and the process operator might find that the data had not been completely filled out, perhaps because the advice note wasn’t structured very well. So the data had to be structured to standardize it so that it could be a common document like all the other advice notes. And if any data was missing, that person might have had to go back to the broker, or add things from the systems of record in the back office. Then, once the note was complete and signed off by the process operator, it went into the repository.
Now a lot of that sort of work can be automated. But some of it requires human intervention, human reasoning, judgment. So an RPA engineer would look at that type of process and say, “Which bit can we automate?” The answer is not everything—it can’t structure the data. There may at some stage be cognitive automation technology that could structure the data but RPA can’t, so the human being has to structure the data at the front end and create a pro forma ideal advice note. Clearly, the RPA can’t deal with exceptions either. The engineer has to intervene and look at the exceptions and create a rule to deal with them, so that gradually you educate and configure the RPA to do more and more work. Eventually it can do 90 or 95 percent of the work and very few exceptions have to be dealt with by a human.
McKinsey: What are the most important considerations for those wishing to adopt RPA?
Leslie Willcocks: The most important consideration is strategy. You can use automation tactically for cost savings. But if you use RPA as a broader strategic tool, you get a lot more out of it. That’s number one. Number two concerns the launch. You need to get the C-suite involved and appoint a really good project champion, and you have to pick the right process. It has to be stable, mature, optimized, rules-based, repetitive, and usually high-volume. Start with a controlled experiment on a visible bottleneck or pain point.
The third consideration is change management—persuading the organization to change and adopt automation. It is a key issue from the outset. And the fourth is building a mature enterprise capability for RPA. Long-term users have built centers of excellence over time, usually within business operations, and developed skills and capabilities within that center. They have people who assess the feasibility of a proposal from a business unit. They have people who configure a robot, install it, and develop it, and controllers who switch it on and off, and plan its work and how it fits with human work. They have some sort of continuous improvement capability and relationships with IT, governance, and security. Organizations signing up to RPA now should probably think about building a center of excellence immediately.
McKinsey: How do companies choose whether to implement an IT solution or RPA? And how do the two departments work together?
Leslie Willcocks: When organizations consider proof of concept for RPA, they look at the business case and compare it to an IT solution. Often that’s pretty unflattering for IT. In one organization we looked at, the return on investment for RPA was about 200 percent in the first year and they could implement it within three months. The IT solution did the same thing but with a three-year payback period and it was going to take nine months to implement.
In addition, many business operations find going through IT frustrating because it’s so busy. Often the business wants something relatively small, but the IT function has bigger fish to fry and the business has to go to the back of the queue. So if an RPA tool is usable, cheap, and doesn’t require much IT skill to implement it’s a no-brainer for the average operator in a business unit. The reason IT gets worried is that they know the disruptive, potentially disastrous effects of people playing around with IT in the organization and not understanding how it’s going to upset infrastructure, governance, security, and all the important touchpoints that IT is held responsible for. So it’s not surprising to find IT functions in denial about RPA and what it can do. It’s crucial therefore that IT is brought on board early.
McKinsey: What do you think will be the long-term impact of robotic process automation?
Leslie Willcocks: In the longer term, RPA means people will have more interesting work. For 130 years we’ve been making jobs uninteresting and deskilled. The evidence is that it’s not whole jobs that will be lost but parts of jobs, and you can reassemble work into different types of jobs. It will be disruptive but organizations should be able to absorb that level of change. The relationship between technology and people has to change in the future for the better and I think RPA is one of the great tools to enable that change.
