Insights & Publications

Article

Automating the bank’s back office

The dream of achieving rapid, large-scale process automation is becoming a reality for some banks. Competitors cannot afford to miss the opportunity to transform their own back-office processes.

July 2012 | byJoao Dias, Debasish Patnaik, Enrico Scopa, and Edwin van Bommel

Banks have enhanced many of their customer-facing, front-end operations with digital solutions. Online banking, for example, offers consumers enormous convenience, and the rise of mobile payments is slowly eliminating the need for cash. But too many processes at banks still rely on people and paper. Often, back offices have thousands of people processing customer requests.

This high degree of manual processing is costly and slow, and it can lead to inconsistent results and a high error rate. IT offers solutions that can rescue these back-office procedures from needless expense and errors.

Our research indicates that a significant opportunity exists to increase the levels of automation in back offices. By reworking their IT architecture, banks can have much smaller operational units run value-adding tasks, including complex processes, such as deal origination, and activities that require human intervention, such as financial reviews.

IT-enabling operations encompasses both automating processes (preventing customers from using paper, digitizing work flows, and automating or supporting decision making) and using IT solutions to manage residual operations that must be carried out manually (for example, using software for resource planning). By taking full advantage of this approach, banks can often generate an improvement of more than 50 percent in productivity and customer service.

Some banks are already taking steps toward harnessing the considerable potential of this opportunity. For example, one large universal bank categorized its 900-plus end-to-end processes into three ideal states: fully automated, partially automated, and “lean” manual. This bank determined that 85 percent of its operations, accounting for 80 percent of the current full-time employees (FTEs), could—theoretically—be at least partially automated. At the time of this analysis, fewer than 50 percent of these processes were automated at all. If an ideal level of automation were reached, then almost 50 percent of the FTEs in operations could be relieved of their current back-office tasks.

This scenario sounds promising, but achieving it is easier said than done. This bank then did some due diligence to determine whether there was a viable business case to automate each process within a reasonable time frame. It concluded that only half the opportunity (measured by the automation business cases completed on each manual process) could actually be captured. Several barriers led to this conclusion.

Four obstacles to change

  1. Banks have rarely taken a hard look at their procedures. Enabling growth or launching new products has traditionally been their priority, achieved by adding new layers of product features and procedural requirements. This lack of procedural rigor has yielded highly complex business processes that prove very hard to automate.

  2. Mergers and acquisitions, product launches, and regulatory changes have left many banks with a complicated IT architecture. Redesigning entrenched systems can take up to five years and cost hundreds of millions of dollars. Banks must invest substantial capital and run the risk that, should the solution miss the mark or take too long to implement, the market may have moved on before the new system goes live.

  3. IT departments may have different agendas and lack the necessary understanding of business priorities. They typically discuss IT changes in a “black box” of architectural conversation and therefore fail to grasp the full spectrum of integration options. IT architects and solution designers, for example, may be inclined to use legacy techniques or to select the most technically exciting solutions, while IT vendors and system integrators have no incentive to reduce the complexity of the integration or the effort it requires.

  4. Banks often lack the internal capabilities to introduce more automated processes. IT departments have historically been trained to use waterfall methodologies1 when developing big projects. These methodologies1 are appropriate for developing and maintaining the traditional mainframe environments in which banks still run their core banking systems, but they are not optimally suited to automating business processes rapidly.

Faced with these challenges, few banks have had the appetite for reengineering their operations-related IT systems. Given the relatively strong growth banks experienced before the recession, most did not have to change their business processes. Now, however, the new economics of banking requires much lower back-office costs. And with regulators and consumers pressuring banks for greater transparency, better credit and portfolio risk management, and heavily expedited data processing for customer accounts, bank leaders are realizing they must take a different approach.

A new way to IT-enable banking operations

Some banks are experimenting with rapid-automation approaches and achieving promising results. These trials have proved that automating end-to-end processes, which used to take 12 to 18 months or more, is doable in 6 months, and with half the investment typically required.

A European bank recently decided to automate its account-switching process. First, a team of IT, operations, and business-process experts analyzed existing processes from customer, efficiency, and risk perspectives. The analysis uncovered several issues: more than 70 percent of the applications were paper based, and of those, 30 to 40 percent contained errors and required reworking; applications often got stuck in one data-verification step for more than five days before being processed; and because of a lack of any IT integration, branch and back-office staff had to enter data manually from several systems into the work flow.

The team then defined what it wanted the process to look like, giving priority to operational and business impact (for instance, how much labor could be saved through automation) and to feasibility (such as how many new interfaces or changes to legacy systems would be required). The team focused on simplifying the process steps and procedural requirements at each stage—streamlining the information required from the customer and eliminating redundant verification steps—to reduce the complexity of the IT solution.

Using this design, the team carefully evaluated the possible integration options. It decided to use a combination of business-process-management software and electronic forms, in addition to the legacy systems, to create an automated and digitized work flow that did not significantly change existing IT systems. Daily huddles and weekly builds,2 which were immediately tested by users, ensured that the solution met the requirements and kept users engaged.

As a result, the amount of time back-office staff spent handling account changeovers fell by 70 percent; the time customers needed to adjust to the switch was reduced by more than 25 percent. The cost-benefit ratio for this project was also significantly better than it had been in previous automation efforts: the project generated a return on investment of 75 percent and payback in just 15 months.

This European bank’s experience illustrates three principles that make success more likely when automating operations:

  1. Consider business priorities to simplify the process. Automating inefficiencies or unnecessary product features embedded in historical processes is pointless. By first defining the best processes from customer, business, and risk perspectives—taking a lean approach to process design—banks can significantly reduce what actually needs to be automated, which in turn lessens the cost, risk, and implementation time. A truly cross-functional team consisting of operations, IT, and business experts, as well as strong project governance, is required to design and enforce such optimal end-to-end solutions. The involvement of top management across multiple functions—operations, retail, and IT, for instance—is also essential.

  2. Use multiple integration technologies and approaches. The right mix of integration solutions, backed by a solid evaluation of each solution’s time to market and contribution to architectural complexity, enables banks to automate most of their manual interventions without rewriting or substituting legacy architectural building blocks. For example, banks are successfully creating work flow systems by overlaying business-process-management tools that connect separate legacy systems, which in turn eliminates manual data entry and related errors across end-to-end processes. This evaluation is not straightforward, however, and requires a thorough understanding of what the market for integration solutions has to offer.

  3. Prepare the IT shop for agile-development methods. To achieve rapid development cycles and use off-the-shelf solutions successfully, IT departments must build skills beyond their traditional capabilities. In particular, they should hire or train people who can assess the software market and apply the right solutions, as well as develop systems in-house; who can run agile or iterative development projects; and who are capable of working seamlessly with business and operations counterparts.

As some banks experiment with this rapid-automation approach, and the impact of initial pilots resounds throughout the organization, IT and operations teams will feel pressured to integrate all end-to-end and back-office processes. All too often, however, efforts to scale up these initiatives are short lived. IT architecture teams, concerned that they will not master unfamiliar integration solutions, or that additional efforts will make the IT landscape even more complex, may react warily. Meanwhile, operations and business personnel push to automate everything everywhere as soon as possible, without proper planning and evaluation. These pressures spread IT teams too thin, diverting their attention from the largest areas of opportunity. Because such projects are carried out much more quickly than traditional development efforts, IT departments struggle to set up the necessary infrastructure on time, and the teams are not focused on the value or necessity of additional features.

To overcome these obstacles, banks must design and orchestrate automation-transformation programs that prioritize and sequence initiatives for maximum impact on business and operations. They also need to define a target IT architecture (both applications and infrastructure) that uses a variety of integration solutions while maintaining a system’s integrity.

Successful large-scale automation programs need much more than a few successful pilots. They require a deep understanding of where value originates when processes are IT enabled; careful design of the high-level target operating model and IT architecture; and a concrete plan of attack, supported by a business case for investment.

Another European bank launched a strategic initiative to shrink its cost base and increase competitiveness through superior customer service. Upon completion of the first successful pilots, the bank’s automation program consisted of three phases.

In phase one, the bank examined ten macro end-to-end business processes, including retail-account opening and wholesale customer service requests, to identify the automation potential and to prioritize efforts.

In phase two, the architecture was designed and a plan of attack formulated. The bank took three critical actions:

  • It decided which processes would be fully automated, partially automated, or fully manual, based on four key tests. The tests determined whether a process was too complex to automate (for example, deal origination and structuring), whether regulation required human intervention (for instance, the financial-review process), whether or not the process was self-contained (that is, dependent on multiple customer or third-party interactions), and whether manual touch points added value to the customer relationship (for example, product inquiries).

  • It designed the building blocks of the target application architecture, which consisted of legacy systems and off-the-shelf applications, as well as the IT infrastructure requirements, to provide timely and necessary computing and storage.

  • It derived a design-based holistic business case for the automation program and defined the rollout plan.

In phase three, the bank implemented the new processes in three- to six-month waves, which included a detailed diagnostic and solution design for each process, as well as the rollout of the new automated solution.

This approach helped the bank to deliver business and operational benefits rapidly and successfully. The program paid for itself by the second year and kept implementation risks under control.

Rapid process automation in banking used to be a fantasy. But in a world marked by financial and economic woes, banks need to find faster, more economical, and lower-risk approaches to reducing costs and improving customer service. Fortunately, the market for integration support solutions and alternative IT-development approaches has become more reliable over the past ten years, unlocking the key to rapid, large-scale automation of business processes. Banks cannot afford to miss the opportunity to automate now.

About the authors

Joao Dias is a principal in McKinsey’s Cologne office, Debasish Patnaik is an associate principal in the London office, Enrico Scopa is a principal in the Prague office, and Edwin van Bommel is a principal in the Amsterdam office.

Related articles

Overhauling banks IT systems
article

Overhauling banks’ IT systems

core banking systems dating from the 1970s are compromising bank performance. however, updating them is becoming less costly and risky.more

taro11_frth_Thumbnail
article

Tackling the roots of underperformance in banks’ IT

a lean approach can help it executives bring stronger operational discipline to the intensely varied, specialized environments they oversee.more

Why business needs should shape IT architecture
article

Why business needs should shape IT architecture

to get the most out of these programs, organizations must ensure that they are led by people with the right skills, connections, and attitudes.more

      • includes:
        •  

About this content

The material on this page draws on the research and experience of McKinsey consultants and other sources. To learn more about our expertise, please visit the Business Technology Practice.