CIO-100: Mergers and acquisitions

Integration during a merger and acquisition (M&A) is a different beast from your typical internal system integration effort. The CIOs who have survived an M&A talk about it with the same heart-quickening cadence an adrenaline junkie uses to describe an extreme sport. If an integration project of the sort discussed in the rest of the CIO-100 issue is the IT equivalent of surfing -- requiring a CIO to stay on top of the project's breaking waves -- then integration during an M&A is like sky surfing: It's riskier and you're traveling much faster. Integration during an M&A is not a simple IT project but part of a bigger business goal. Too often, companies engaging in mergers or acquisitions ignore the IT scalability of their new business partner or their own systems. It's not that companies should make or break business decisions based on the IT architecture of the company they plan to join or take over, but it is important to have up-front knowledge of how the IT merger is likely to go. A slow or poorly handled IT integration between merging companies can jeopardize the business goals. So once an M&A is set in motion, the CIO's role is to make sure that the IT integration happens fast and smoothly.

All successful M&As therefore come down to one thing: planning. Because of the emphasis on speed, most of the work during an M&A is done before the hands-on integration work begins. Stephen N. David, CIO and B2B officer of Cincinnati-based Procter & Gamble, a CIO-100 honoree, says that 75 percent of an integration effort during a merger or acquisition is determining which systems to keep, what data is important and how much integration is actually needed before the companies are technically joined. Once that kind of planning is complete, the actual hands-on work should be just like any other IT project --only a little more exciting.

Read on for a primer from some of our CIO-100 honorees that have led successful M&As and are willing to share lessons in integrating systems as swiftly as possible.

Know Thyself

Once your company has decided that it plans to grow via mergers or acquisitions, the first step for the CIO is to come up with a detailed map of the company's IT infrastructure and communicate to the other executives the company's readiness to do an M&A. Even before a merger or acquisition candidate is chosen, the CIO needs to have explicit knowledge of his own architecture and what the most important systems are, says David.

Good, scalable architecture makes integrating two companies possible. "Make sure that the base technology that you have in place is the technology you want to grow the company with," adds Martin J. Lippert, vice chairman and CIO of Toronto-based Royal Bank of Canada (RBC), a CIO-100 honoree.

If your company does not have a scalable architecture in place, you need to make it known to the business executives before your company starts down the M&A path. Otherwise the consequences are deadly, as they were at Waste Management, the Houston-based sanitation provider that was the product of the US$20 billion 1998 acquisition of Waste Management by USA Waste (the combined entity kept the Waste Management name). Neither company had a scalable IT architecture --just 300 or so scattered AS400 mainframes between the two --that could support the new, larger company. In 1999, says Thomas L. Smith, senior vice president of IT and CIO, "everything hit the fan." That year, the senior management team was removed and a new executive team, including Smith, was brought in to clean up the mess. In early 2000, Waste Management, a CIO-100 honoree, put in place a new architecture and for the first time developed an acquisition strategy that matched its capabilities. The company began an acquisition spree that averaged one small company per business day and stuck religiously to the absorption strategy. "We made a policy decision that anyone who comes in to our properties will always come up on our systems," says Smith.

As the Waste Management example demonstrates, it is vital that all the executives understand the impact the IT architecture will have on the M&A. And it's up to the CIO to ensure that that information is part of the business discussions and planning up front.

Do Diligence

Once an M&A is proposed, there are two separate yet equally important steps to go through: diligence and planning. The diligence phase is realistically the last chance to call off the M&A before both sides commit, and as such, a CIO should be looking for red and yellow flags that suggest the integration will be harder than expected (and budgeted for). Conversely, the CIO of the acquiring company can also be looking for positive reinforcement: systems or processes from the other company that remind everyone why the merger or acquisition seemed like a good idea in the first place.

An examination of the cultural differences between the two companies planning to blend must be part of the diligence phase. Owen Flynn, senior vice president, corporate vice president and CTO of Atlanta-based credit reporter Equifax, another CIO-100 honoree, warns that when it comes to systems integration, cultural differences can be a ticking bomb. One example is when a process-oriented company tries to merge with a creative and fluid company. "You find this often in software," says Flynn. "A company might have very creative people who write brilliant code, but it's in their head. If there is no documentation, you will have a hard time leveraging the best practices."

The classic absorption model --in which one company's systems are devoured by the other --is a way around this type of problem, but RBC's Lippert says that there are dangers to that approach as well. "Part of what you are buying is the intellectual assets, and presumably you are buying them because you like what the company has done," he says.

During his due diligence studies, Lippert has turned up many technologies that RBC has adopted, including a wireless application from a company in Houston that allows appraisers to file status reports for construction projects from onsite. Internet banking is another example. When RBC purchased Centura Bank in 2001, which has more than 225 locations in the Southeast United States, it adopted the American company's Internet banking application. The banks' combined 2.3 million online banking customers now use a common interface --a significant boon for Canadians who live part-time in the United States and need an account in each country --and share a customer service center in Moncton, New Brunswick, where employees are paid with cheaper Canadian dollars.

Once the diligence phase is complete and the two sides agree to go ahead with the merger, the planning begins. The goal of the planning phase is to break the seemingly daunting task of integrating two companies into a series of smaller IT projects. It is crucial that one of the two partners emerge as the driving force behind the integration.

London-based oil giant BP, a CIO-100 honoree, learned firsthand that the planning will go nowhere until a dominant side emerges. In August 1998, British Petroleum announced a merger with Chicago-based rival Amoco, valued at more than $48 billion. At the time it was the largest industrial merger ever and the inspiration for similar undertakings by competitors Exxon Mobil and ChevronTexaco. Although British Petroleum was slightly larger than its American counterpart, both companies agreed that they were partners and that neither company entered the merger with the upper hand. Looking back, Phiroz P. Darukhanavala, BP's vice president and CTO and the man who oversaw the integration of the two companies (upon merging, the company changed its name to BP Amoco but has since shortened it to BP), says that there is no such thing. "There was a lot of debate to gain consensus," says Darukhanavala, and it got the two sides nowhere because of significant philosophical differences.

British Petroleum outsourced everything from application development to telecom and the help desk, and had an Oracle ERP system. Amoco did everything in-house and had one of the world's largest SAP platforms. It wasn't until BP imposed its will as the larger partner that a plan was actually finished. Today the SAP platform is the only remaining Amoco system.

Execution: Doing It Quickly

Once the plan is complete, the integration work can begin in earnest. Just as there needs to be a dominant side in the planning phase, the integration work itself has to have a single person who is ultimately accountable. In the case of the $30 billion J.P. Morgan and Chase Manhattan merger, the responsibility fell on Richard J. Thompson, financial director of MIS strategic architecture at New York City-based J.P. Morgan Chase, who was a veteran of previous Chase mergers. Thompson says that having one person in charge makes it clear to everyone who should be giving the commands and who has the ultimate authority. "Because of its rapid nature and the need for integrated data, our merger model needed one authoritative guiding person to manage it," he says.

CRM was an easy decision. Chase was pretty far along on a Siebel implementation while J.P. Morgan was just looking into it. A tougher decision, however, was what to do with the general ledger. Thompson relied on his previous experience to help decide whether or not to pluck best practices from the J.P. Morgan ledger or to simply go with the complete Chase system as a suite. Thompson says that the painful Chemical Manufacturer's Hanover merger taught him that examining each application of the merging companies was time-consuming and difficult. So with the J.P. Morgan Chase merger, Thompson chose to implement the Chase systems wholesale.

The actual integration work was simply a matter of extracting the data from one system and putting in the other. Thompson's troops did the bare minimum, in order for the two companies to begin using the combined data as quickly as possible. For example, when adding the J.P. Morgan data to the Chase general ledger, Thompson transferred only the essential geographic information, noting when a customer was in Europe but leaving the individual countries for later. This way the new company could access all the customer accounts while waiting for the more precise data, which would be useful for data mining.

To successfully integrate two companies, a CIO needs to be aggressive and understand that he is working toward a business goal. But you also have to get creative, Darukhanavala says. "You go through, and you throw so much out, only keeping what you have to," he says. "Actually it's a lot like cleaning out the garage."

Integration Snapshots

BP

M&A history: The British Petroleum and Amoco merger in 1998 was the largest industrial merger in history.

Integration insight: After wasting three months struggling to agree on everything, BP --the larger of the two companies --finally decided to use its systems as the default, keeping only Amoco's SAP system.

Equifax

M&A history: Frequently acquires small credit companies.

Integration insight: CIO Owen Flynn looks for cultural differences between Equifax and the company it is acquiring, and suggests that they might be an early warning that there will be problems integrating the systems.

J.P. Morgan Chase

M&A history: A product of the 2001 merger between financial giants J.P. Morgan and Chase Manhattan.

Integration insight: There was one person in charge of the project who was able to make quick decisions to help speed along the integration. The companies ended up defaulting to the Chase systems.

Royal Bank Of Canada

M&A history: Royal Bank acquired Centura Bank in 2001.

Integration insight: CIO Martin Lippert says you aren't just acquiring a company but its intellectual assets as well, and he suggests that you pick and choose from the other company the systems that can help your business.

Waste Management

M&A history: Product of the 1998 merger between Waste USA and Waste Management.

Integration insight: Proved (the hard way) that you need to understand the relationship between a scalable architecture and successful integration. The inability to recognize that before the merger ultimately led to the removal of the entire executive team.