A CIO plan for becoming a leader in Intelligent Process Automation

Intelligent Process Automation (IPA)—a set of technologies that combines process redesign, process automation, and machine learning—is rapidly reshaping the global economy, with significant gains for organizations that adopt it at scale. As an earlier McKinsey article explains, some companies across industries have already been able to automate 50 to 70 percent of tasks with return on investment generally in triple-digit percentages. While people often focus on the cost savings, IPA also provides significant other benefits, including speed, precision, and improved customer service.

But for companies to get the full value of IPA, IT will need to play a leading role. The track record of early adopters clearly demonstrates that IPA projects carried out without the active participation of IT are likely to fail. For CIOs to play a guiding role in IPA, they need to develop a core of expertise and experience developed by implementing IPA programs within IT. And it’s important to do so quickly. If CIOs don’t support automation across the company, then business executives will start building their own shadow IT organizations or working with external vendors.

However, many IT executives struggle with successfully implementing IPA processes. The most frequently stated reasons are:

• The higher complexity of IT compared to a business process
• Difficulty in understanding the economics of IPA and a lack of clarity on how to best capture the benefits
• Inconsistent and fragmented tools that make IPA hard to scale
• The misconception that IPA is an advanced lever requiring massive process re-engineering before embarking on an automation journey

How can CIOs succeed? We have found that there are four key steps on the IPA journey that need to be mastered:

Step 1: Assess the value potential at a high level

The key to developing a clear business case starts with assessing the value potential of the main IT activities by tower (Exhibit 1).

1

A closer look reveals what some of these pockets of value are¹ 1. While a large proportion of the IT budget may be spent on purchasing hardware, software, and network bandwidth, little of that can be automated. :

1. Responding to incidents and user requests. A large proportion of incidents originate through a help-desk request, resulting in the creation of a ticket with “low difficulty,” level 1. However, while many tickets are resolved in this way, a significant proportion of tickets escalate to more complex level-2 or -3 tickets and are passed on to more specialized IT teams. Most of those ticket types become “trouble tickets” and are costly for IT to address. Since this activity is so well documented, categorizing and sorting them by automation potential provides a reliable assessment of the benefits. For example, all password reset requests from the previous year and multiplying them by average handling time (AHT) provides a clear indicator of the size of the prize for this year, provided there have been no dramatic changes to IT.
2. Conducting planned activities. Planned activities vary significantly in scope and nature, ranging from simple tasks like backups or patching to more complex security audits, upgrades, etc. The effort required to perform these activities can collectively add up quickly to ~20 percent of IT spend.
3. Delivering new applications. As far as the business is concerned, these activities represent the largest source of IT value and can account for another 20 to 40 percent of IT effort. This is not just limited to application development but includes testing and hosting, demanding the efforts of both application and infrastructure groups.

Note that automation is equally effective for outsourced or subcontracted activities.

Step 2: Drill down to specifics to understand which use cases are best suited for implementing IPA

How to implement IPA can vary significantly across identified activities and often requires digging into root causes for issues, untangling complex systems, and developing a clear understanding of how to approach implementing IPA to get the value. In some cases, we’ve seen businesses use specific IPA tactics to help unlock the necessary insights.

Responding to incidents

Understanding how to go about automating incidents starts with identifying which of them are most suited to automation, which can be challenging. While incidents are well documented, they are also numerous—large IT organization can easily generate a million tickets a year—and the root cause of each is often not readily apparent. “I don’t receive emails” does not necessarily indicate an email-program issue; it may simply mean “I lost my password.” Often businesses will try to automate incident responses without being clear about the “why,” resulting in poor outcomes.

Specific text-mining tools that read ticket descriptions in detail and derive the necessary insights can address these complexities. Using this approach, we have been able to define ~50 different ticket types and divide them into IPA categories:

• Automatable
• Requires machine learning
• Highly cognitive/manual

As an example, 80 percent of “reset password” incidents can be automated (Exhibit 2).

2

The output of this analysis should be a prioritized list of incidents to automate and which IPA element to use for each.

Conducting planned activities

While most IT groups have industry-standard tools for infrastructure management, we have seen that the complexity of configurations means that IT isn’t getting as much value from them as they should. A high degree of customization, adjustments because of mergers, and specific user requirements mean that significant manual labor is required to manage the systems.

For example, despite the broad usage of application-monitoring tools (like Prometheus) and infrastructure-monitoring tools (like Zabbix), application support teams are often unable to act quickly and effectively on the logs generated because there are often too many of them, generated for a variety of reasons. The result is companies aren’t clear about how to go about implementing IPA.

In this case, a machine-learning (ML) bot can help make sense of the complexity because it can be trained to learn the reasons behind a given alert and then recommend— or even make—better decisions about what action to take (Exhibit 3).

3

Delivering new applications

However, many CIOs fall into the trap of simply focusing on reducing manual labor, which limits the full value potential of IPA. More accurate and faster application delivery requires designing a new IT operating model, with an emphasis on agile and DevOps. Reviewing the entire process to understand how to make most effective use of agile and DevOps can lead to completely different approaches and ways of working. Some of those new ways of working can be enabled by IPA. Automating testing, for example, allows teams to iterate more quickly; creating a self-serve model for automated server provisioning allows operations to be more responsive.

One major US life insurer approached this issue by developing a phased strategy for IT infrastructure automation. It started with developing a DevOps model for how infrastructure and operations teams could work together. The team then cooperated on building out a comprehensive IPA program supported by a relevant set of APIs that enabled the team to access varied sources of data. As it learned how to manage this approach, it migrated relevant parts of the infrastructure to the cloud to increase flexibility. The result of this effort was that the infrastructure organization, which originally consisted of ~1,400 full-time employees (FTEs), was reduced to ~800 FTEs, while build and implementation speeds increased significantly, even as errors were reduced.

Step 3: Execute a proof of concept

To prove the value is real and validate the business case, the next step for a CIO is to greenlight a proof of concept. A good place to focus that is on incident processing. Companies that have implemented IPA for incident processing have been able to show cost savings of up to 30 percent. Thankfully, there are many work efforts (tickets) that can quickly be automated to serve as a proof of concept, such as incidents that are essentially a front end for already-automated processes based on mature APIs and tools, (password reset, setting up access for a new employee, ordering new equipment, etc.).

Subscribe to the Shortlist

McKinsey’s new weekly newsletter, featuring must-read content on a range of topics, every Friday

Get the Shortlist in your inbox

In its simplest form, a proof of concept requires:

• Workshops with appropriate IT subject matter experts (SMEs) to understand all the steps and systems involved in a given process. This helps to identify where IPA can best be applied.
• The thoughtful selection of an IPA platform. This decision has significant implications because platform capabilities, ambitions, and service providers vary, in some cases significantly. Some IPA platforms, for example, provide better integration capabilities, such as APIs that tie into existing systems. Others offer prepackaged or customizable bots, while some platforms are moving to provide AI capabilities even as others remain focused on process automation.
• Obtaining the necessary approvals from IT (security guidelines, for example) and the business (access limitations and regulatory constraints)
• Programming the bot(s) using iterative design techniques to ensure speed, accuracy, and scalability. At least one engineer needs to be assigned to manage the extensive testing that is a core element of the iterative design to ensure that the bot learns and adjusts based on live feedback.
• Ongoing monitoring to document the results and ensure value capture

It is also useful to think of a pilot as a kickoff for internal IPA capability building, for example, by using a blend of internal and external developers to jump-start a future center of excellence (CoE). The team should become the home and engine of IPA learning.

Step 4: Build IPA capabilities to scale

Realizing the full potential of IPA in IT requires a focus on building specific skills and capabilities, as well as adapting the new culture of the organization to eventually embed IPA at the heart of the IT organization.

Typically, we see the most successful companies do three things:

1. Ramp up the success to new areas of IT

At this stage, the team is likely to move beyond basic help-desk level 0/1 incidents and pursue the automation of more advanced level-2 and level-3 tickets. The team should also expand beyond incidents and begin working on using IPA for monitoring, dashboarding, and analytics, moving from the help desk to the data center, the network, and even application-maintenance organizations. The long-term success of the automation program is contingent on how quickly the IPA bots are adopted within the IT organization. That depends on how effective leadership is in providing dedicated training and ongoing support, as well as building up a network of internal “reference cases.” The goal is to build on the successes to find new and more advanced use cases and opportunities within IT (as a precursor for generating demand across the wider organization). Providing incentives for IT employees in the form of bonus payments or recognition in competitions can be effective.

At this point, the CIO needs to invest in capabilities that support scale, such as risk management and IT infrastructure management. These are different from those capabilities needed for pilots, which focus on getting the technology right, demonstrating value, convincing nonbelievers, etc. Leaders sometimes mix up up the two and underestimate what’s most important about each.

2. Getting the word out

With a solid foundation of experience and capabilities in place, the CIO can begin to actively position him/herself as both an advisor and enabler for the rest of the business. In practice, that means reaching out to leaders across various functions to inform them about the specific benefits of IPA, understanding their priorities and how to best implement and support the technologies ,and identifying potential security issues through bots.

IPA is by its nature disruptive. A CIO should have a clear sense of when IPA technologies will augment or replace human workers and put in place a program of clear communications and activities for each outcome.

3. Exploring advanced elements of IPA

While most IT organizations have focused on simple process automation (and to a lesser extent machine learning and natural-language processing), the future belongs to artificial intelligence and cognitive learning, which have the potential to manage complex IT tasks. Although still somewhat futuristic, the solutions are already emerging, and we expect them to rapidly mature over the next several years. But it takes time to build up the skills and experience needed to use AI effectively, in part because there is still a lot of confusion about what AI actually is. The only way to overcome that confusion is to start working on AI projects. Companies that are building up expertise in this area are developing data lakes, creating meaningful tags for that data, and then dedicating engineers to build and train algorithms to act on that data.

IPA is rapidly maturing and becoming a core part of the landscape of IT organizations. CIOs who understand how to build up their IPA capabilities can become not just enablers but leaders in this shift.