• Technology
  • McKinsey & Co.

Taming Postmerger IT Integration

Lessons from the IT-heavy banking sector can bring balance to this critical task.

To succeed, a merger requires the smooth integration of IT systems and services, but the task often plunges the CFO responsible for ensuring the savings into uncharted territory. Confronted by an immediate technical challenge, companies typically choose one of two questionable routes. Some, fearing costs and complexity, never fully integrate their acquisition’s systems and thus gain few synergies. Others focus on the promise of synergy gains and improved performance but, in their haste, simply choose one system over another, often alienating both customers and employees.

CFOs might consider looking to IT integration in the banking sector for guidelines that can provide a better approach in other sectors. IT, underlying every process a bank performs, is particularly integral to bank operations. Moreover, banks tend to have complex operational structures, often with many brands, branches, and product sets. (The authors worked with one acquiring bank that had accumulated more than 700 branches, nearly 400 product sets, and about 300 IT systems — and was set to buy a competitor with almost as many branches, about 250 product sets, and close to 200 IT systems.) Yet even amid that complexity, it is possible to structure an approach that taps synergies, serves customers at least as well as they were served before, and achieves suitable trade-offs among internal parties. (Scott A. Christofferson, Robert S. McNish, and Diane L. Sias, “Where Mergers Go Wrong,” The McKinsey Quarterly, 2004 Number 2, pp. 92–9.)

To merge these structures for maximal synergy and minimal customer disruption, it is necessary to transform the IT functions that underpin them. We have found that this process must include two sets of rational compromises. First, companies must find the middle ground between a rapid migration that captures synergies quickly and a slow one that focuses on a smooth experience for customers. Second, the merging companies must simultaneously balance the requirements of disparate interest groups within each company.

A Question of Pace

Rapid integration may garner immediate synergies, but it also typically drives away 8 percent or more of the acquired customer base. The customers who do stick around can face service disruptions or lost account information. One U.S. bank that undertook a fast-paced integration effort found itself in an even worse position. The company not only saw its customers flee, its revenues decline, and its employees’ morale suffer but also soon discovered that its established application architecture could not support planned additional product features and functionality upgrades. The merged company quickly met its projected cost synergies, but the benefit was fleeting. Because of the additional costs, the merger didn’t meet its targets.

Slower integration may impose less stress on customers and employees, but it can also be expensive and delay the capture of synergies indefinitely. Our calculations for one company found that every month the integration was delayed represented an opportunity cost of up to 7 percent of the targeted annual synergies. Even real costs are not always immediately apparent. One large U.S. bank, for example, sought to protect its customers and to avoid the costs of integration by keeping its own system separate from those of its numerous acquisitions. Yet it discovered that it was actually spending more on technology — to maintain and upgrade so many different systems — than its competitors were and was also inconveniencing the customers whose service it had sought to protect. Customers transferring their accounts from state to state went through the same rigmarole they would have faced in transferring to a completely new bank. With various branches still running on different systems, the bank’s acquisitions generated neither significant customer benefits nor the optimal synergies.

To manage the trade-offs, companies must manage integration with one eye on the synergies they want to realize from it. In other words, they must quickly identify target products, systems platforms, product gaps, migration routines, and specific customer sets — and then create a detailed and comprehensive migration plan for the integration team to follow meticulously. The result should be a complete overview of the way a company plans to get from today’s environment to the future one. The best plan will explain in detail how the company will realize every anticipated source of synergy (Exhibit 1).

A Question of Leadership

As difficult as it is to get the timing right, sorting out the needs of separate and powerful interest groups can be even tougher. In retailing, for example, such groups include the merchants who create promotions, the information technology staff, and the operations employees who manage the customer interface — with all of them jockeying to manage or influence the integration process. In banks, these groups include business units, product specialists, and IT, but most banks simply relinquish control to the tech specialists in IT. Not surprisingly, tech specialists tend to push for the best solutions from an IT perspective; indeed, important business decisions about the combined entity’s product offerings may be based on how easy or difficult they are to implement technologically. In contrast, a business unit that takes the lead may become overly protective of its customers by limiting any changes that might affect them or its business practices — and not worrying about the enormous technology costs it may be incurring.

At banks, we have found that product specialists, despite their inherent biases, are best suited to play a balancing role in this triangle of players — not business units or the technology staff, as others have suggested. (Bradford Brown and Vikram Malhotra, Tying the Knot: IT Systems in a Merger,” The McKinsey Quarterly, 2003 Number 4, pp. 128–38.) In most banking organizations, the product units are responsible — during business-as-usual situations — for maintaining and developing a profitable portfolio of products in line with the needs of customers. These units therefore serve as the focal point for balancing those needs (defined by the business units) with the cost of meeting them (dictated by the technology side). As concerns about the cost of merging systems yield to the benefits of customer retention and revenues, the leadership of the product units will be all the more beneficial for companies.

When the technology side claims that upgrading the IT systems will be too complex a task, for example, the product side can ask: “Exactly how complex will it be?” “What resources are required?” “What are the implications for other IT projects?” and similar questions. When the business units worry about the revenue implications of failing to provide a given product, the product specialists can demand to know its true revenue impact and profitability, get information about other, similar products that are available, and so on. Ideally, the product side mediates by taking the group, product by product, through the portfolio rather than allowing the discussion to progress only on a project-by-project basis or to become focused solely on customers.

To combine the efforts of various constituencies, companies should include representatives of all key groups — in this case, business units, product teams, and the technology team — on both the initial working committee responsible for developing a migration plan and the steering committee that implements the migration. These committees must debate every issue, every gap, and every routine to develop and implement the proposed migration. The process has four critical goals.

Confirm target product set. The first goal is to confirm the target product set for the merged banks. As much as possible, this process should be undertaken from the perspective of customers, with the ultimate goal of giving them the same banking experience they had before the merger or of enhancing that experience.

Choose a system platform. Next, the committees must decide which system platform will best support the combined product set and any planned new products. The chosen platform must have technology that not only is sustainable over the long term but also is able to handle the additional customers a migration brings and fit into the merged company’s goals for the overall system architecture. At the same time, the platform must not be so complex that the company will lack the necessary resources and skill sets to support and develop it. Risk must be minimized, and so must the impact on customers. The new platform must also take into account the views of the business units and be deliverable within the overall time lines for the merger.

Migration might seem like a good time to invest in best-practice systems and services, perhaps by replacing existing systems with more efficient or modern ones as gaps are uncovered. We disagree. Such an effort distracts management from the already demanding requirements of the merger. Instead, in the absence of strong reasons to the contrary, the merged bank should choose the better of the two existing systems.

Identify gaps between offerings and services. The third goal is to identify, in detail, all gaps between the offerings and services of the acquirer and the acquired companies and then to determine whether or not to close them. Any two banks, for example, will have a variety of different product offerings, access channels (the Internet, call centers, ATMs), payment methods and terms, and processing routines and standards (on a technological level).

If the target product set and system platform have been established properly, all of these product gaps will now be visible. One large bank discovered more than 1,000 of them when it first began the integration process. Since closing all of the gaps isn’t likely to be possible, the working committee and the steering committee should analyze each gap to determine if it must be addressed. For selecting gaps to close, a detailed decision tree can be helpful (Exhibit 2). Key questions include: “What do we lose if we don’t close this gap?” “Is there an alternative solution or work-around?” “Is this product really necessary?” “How long will it take, and at what cost?”

Select routines for data transfer. Finally, the company must settle on the best routines for transferring data from the original system to the new or chosen system. This plan is as important as detailing the product gaps to be addressed. It includes deciding whether to migrate manually or automatically.

A manual migration, which involves physically closing down a customer’s account on the old system and opening up a new one on the target system, will take much time and many resources and introduces the possibility of human error. However, an automated migration, while faster and more accurate, will require the IT staff to construct complex routines, with significant mapping in order to address all possible account relationship scenarios. Considering this trade-off, we typically recommend a manual migration for any product with fewer than 10,000 accounts and an automatic migration for any product with 10,000 or more accounts. We have, however, seen successful manual migrations of up to 50,000 accounts.

Although a product-by-product conversion may be technically appealing, the very real risk of customer confusion demands that any migration be broken into manageable pieces. For a company that has unique sets of customers and is supported largely by independent sets of systems, managing the migration offers a considerable advantage: in most cases, customers can be moved in geographic waves to allow physical branches to be rebranded easily, with customer sets created around typical transaction patterns.

Once the steering committee has worked through these four goals, it can begin to create a detailed migration blueprint that lists which synergies are sought, where activities interconnect, what resources are required, and anything else necessary to complete the migration. This blueprint — continually updated and revised — will allow the committee to understand the trade-offs and compromises it makes as it moves through the migration process.

Integrating IT systems is complex and time-consuming. But by involving representatives of all the key interest groups in mapping out an integration strategy, executives can better meet the needs and expectations of customers while at the same time vigorously pursuing the anticipated synergies of the merger.

Lisa Åberg is an associate principal in McKinsey’s Stockholm office, and Diane Sias is a principal in the New Jersey office. This article was first published in the Summer 2004 issue of McKinsey on Finance.

Discuss

Your email address will not be published. Required fields are marked *