CNET también está disponible en español.

Ir a español

Don't show this again

Tech Industry

The uncharted territory: post-merger IT

McKinsey examines how to avoid the knotty integration glitches that have plagued IT-heavy banking mergers.

The uncharted territory: post-merger IT
From the McKinsey Quarterly
Special to CNET
October 15, 2004 4:00 AM PDT

To succeed, a merger requires the smooth integration of information technology systems and services. But the task often plunges the chief financial officer, who is responsible for ensuring the savings, into uncharted territory.

Confronted by an immediate technical challenge, companies typically choose one of two questionable routes. Fearing costs and complexity, some 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, they 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 provide a better approach.

IT underlies every process a bank performs and is particularly integral to bank operations. Banks tend to have complex operational structures, often with many brands, branches, and product sets. 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.

The merger of these structures for maximal synergy and minimal customer disruption requires the transformation of the IT functions that underpin them. This process must include two sets of rational compromises:

•  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.

•  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, revenue decline, and 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. 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.

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 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.

IT underlies every process a bank performs and is particularly integral to bank operations.
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.

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.

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 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. The ultimate goal is to give them the same banking experience they had before the merger or of enhancing that experience.

Choose a system platform
The committees must next 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. 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?"

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.

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.

For more insight, go to the McKinsey Quarterly Web site.

Copyright © 1992-2004 McKinsey & Company, Inc.

Interested in more research studies like these? If so, free registration at The McKinsey Quarterly will offer you topical alerts, access to selected full-text articles, and more. Premium membership offers full access to the McKinsey Quarterly site, including archives, and the print edition.

To browse additional Quarterly articles, click on one of the following topics:

Information Technology

Computers & Technology