Newsletter Archive

A key component to achieving value from a merger requires the smooth integration of both banks' IT systems and services.  This task often plunges the responsible executive into uncharted territory.  Confronted by an immediate technical challenge or a pressure to act, banks typically choose one of two questionable paths.  Some, fearing one-time costs and complexity, maintain duplicate technologies, never fully integrating their acquisition's systems resulting in few synergies.  Others narrowly focus on the promise of synergy gains and improved performance.  Then in their haste to integrate, simply choose one system over another, alienating both customers and employees.

Banks have complex operational structures that become more so when two banks merge.  After a merger there is a need to support an expanded branch network, and overlapping product sets while moving to a consolidated operation   Amid this complexity, it is possible to structure an approach that creates synergies, maintains serve customer service levels and achieves suitable trade-offs among internal parties.

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, banks must find the middle ground between a rapid migration that captures synergies quickly and a slow one that smoothes the experience for customers.  Second, the merging banks must simultaneously balance the requirements of disparate interest groups within each company.

A QUESTION OF PACE

Rapid integration may create immediate synergies, but it also typically drives away 8 percent or more of the acquired customer base.  The customers who remain can face service disruptions, errors, lost account information and confusion.  One U.S. bank that undertook a fast-paced integration effort found itself in an even worse position. The bank saw its customers flee, its revenues decline, and its employees' morale plummet.  It discovered that its established application architecture could not support planned additional product features and functionality upgrades required by the merged institutions. This bank quickly met its projected cost synergies which evaporated as revenues dropped and additional costs were incurred.  The merger never met its targets.

Slower integration imposes less stress on customers and employees, but is also likely to be expensive and may delay the capture of synergies indefinitely.  Our calculations for one bank found that every month the integration was delayed represented an opportunity cost of up to 7 percent of the targeted annual synergies.  The real costs are not always apparent.  One large U.S. bank sought to protect its customer base and to avoid the costs of integration by keeping its own system separate from those of its numerous acquisitions.  Over time they discovered the Bank was actually spending more on technology than its competitors as they needed to maintain and upgrade many different systems. There goal to avoid impacting the customers was in fact inconveniencing the customers.  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 branches running on different systems a customer going into a “new” branch actually received a degraded service level.  The bank's acquisitions generated neither significant customer benefits nor the optimal synergies.

To manage the trade-offs, banks must manage integration with a strong focus toward the synergies they want to achieve.  In other words, they must quickly identify target products, product gaps, systems platforms, 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 roadmap of the Bank's plan 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 challenging as it is to get the timing right, sorting out the competing 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. Too often banks simply relinquish control to the technical specialists in IT.  Not surprisingly, tech specialists focus on the best solutions from an IT perspective.  Important business decisions defining the combined entity's products and services may be based on the ease or difficultly of implementing technically.  In contrast, when a business unit takes the lead, the approach may become overly protective of its customers and existing products by limiting changes that affect them or its business practices.  They may incur enormous technology costs to maintain the status quo.

In most successful integration projects, we have found that the Bank has a strong and active Steering Committee which includes key Executives from all areas.  This Steering Committee is active and directly oversees the creation of a merged Bank vision and approves the strategy to achieve this vision.  In examining successful integration projects have a single manager responsible for the overall project and reports to the Steering Committee.

At banks, we have found that product specialists are best suited to play a balanced role in leading this triangle of players - not business units or the technology staff.  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 these 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 even more beneficial for banks.

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

GOAL 1: 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. 

GOAL 2: CHOOSE A SYSTEM PLATFORM

Next, the teams must determine which system platform best supports the combined product set and planned new products. The selected platform must have technology that not only is sustainable over the long term but also is able to handle the expanded customer base a migration brings and fit into the merged bank's overall system architecture.  At the same time, the platform must not be so complex that the bank 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 and significantly increases the risks to the project.  The merged bank should choose the better of the two existing systems.

GOAL 3: IDENTIFY GAPS BETWEEN OFFERINGS AND SERVICES

The third goal is to identify, in detail, all gaps or differences between the offerings and services of the merging banks 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).

Once 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?"

GOAL 4: SELECT ROUTINES FOR DATA TRANSFER

Finally, the bank must settle on the best routines for transferring data from the source system to the chosen system. This approach defines how customers' products and services will be impacted.  This data transfer plan is as important as detailing the product gaps to be addressed.  It includes deciding whether to migrate manually or automatically, as well as, to migrate all at once (“Big Bang”) or in a phased approach.

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, takes much time and many resources.  It also introduces the possibility of human error.  An automated migration, while faster and more accurate, will require the IT staff to construct complex routines, with significant cross mapping in order to address all possible account relationship scenarios. The design, creation and testing of these automated routines can be very expensive. We typically recommend a manual migration for any product with fewer than 1,000 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 requires that any migration be broken into manageable pieces with the fewest changes visible to the customer.  For a bank that has unique sets of customers and supported largely by independent sets of systems, managing the migration offers a considerable advantage. In most cases, customers can be moved in geographic waves enabling physical branches to be easily rebranded, 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:
- Synergies are sought,
- Interconnected activities,
- Resources required, and
- Other necessary requirements 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, time-consuming and costly. By involving representatives of all the key interest groups in creating the integration strategy, executives will better meet the needs and expectations of customers while at the same time vigorously pursuing the anticipated synergies of the merger.