Insurance & Technology is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels

09:57 AM
Connect Directly
Facebook
Google+
Twitter
RSS
E-Mail
50%
50%

Getting to One

Technology doesn't drive mergers and acquisitions, but astute technology management is indispensable for achieving successful outcomes. Insurance & Technology looks at two large and one smaller merger to examine M&A best practices.

Information technology has become increasingly important in shaping the strategic direction of business, but if one ever doubts its essentially supportive role, one only has to consider mergers and acquisitions. If the business side sees a marriage of true minds, the union will be arranged - even if the technology executives sense a significant compatibility problem between the betrothed. Whatever the difficulties, insurance M&As remain a constant. In the past two years alone, a total of 562 deals have been consummated, with an aggregate value nearing $75 billion, according to Charlottesville, Va.-based researcher SNL Financial. Already in 2005 the industry has seen MetLife's (New York, third quarter 2004 net income of $695 million) planned acquisition of Citigroup's Travelers Life and Annuity Co. and Citi International Holdings for $11.5 billion.

MetLife CEO Bob Benmosche explicitly referred to technology investment on the part of his company as a factor in the deal. But such pronouncements - and the thinking behind them - are not typical for the industry.

"Every company looks good on paper," observes Steve Kane, vice president, global financial services, Unisys (Blue Bell, Pa.). Unfortunately, surface similarities can mislead, even when the technology dimension is not simply ignored up front, he suggests.

"If you were to look back at some of the peak M&A activity over the past couple of years and ask companies to put their hands on their hearts and answer the question, 'Did you really do a good job of operations and technology integration?' I think they would admit that they didn't," Kane says. "That's going to cause some complexity as consolidation continues through the next cycle."

To avoid that trouble, companies have to give high priority to alignment of the IT and operational structure with the business structure, according to Matt Josefowicz, a New York-based analyst with Celent Communications. "If you're going to try to do more cross-sell/up-sell, shared distribution channels, shared customers, etc., then you're going to need to do more investment in integrating data, staff and systems," he states.

The St. Paul Companies/Travelers deal is a case in point. Announced in November 2003, the $16 billion merger formed the third-largest publicly traded P&C company, with a comprehensive product and geographical footprint. According to CIO Bill Bloom, from an IT perspective, the union of the two companies involved 270 separate projects, 41,000 desktops, 3,500 servers, 170 terabytes of data and 560 million images. "We merged 290 field offices, two sets of data and voice networks, two e-mail systems, and two voicemail systems," he says.

Finding Common Ground

From a business point of view, the companies meshed in terms of their complimentary products, geographic footprints and similarity of distribution models. But in terms of technology systems, "These two companies couldn't have been more different," Bloom says. "If there were two choices for anything, it would seem that each company went a different route. When we looked at e-mail, one company had chosen Lotus Notes, the other Exchange; when you took a look at strategic platforms, one company was moving down the .NET route, the other was going Java; in terms of infrastructure, one was going ITIL, the other more custom."

What the two component companies had very much in common was their dependence on an independent distribution force. That fundamental business reality gave rise to what Bloom refers to as the first tenet in approaching the merger: "Don't disrupt whatever is working in the agent's office," he says.

Flowing from that principle was a commitment to acting quickly and decisively. "Decisiveness up front in making decisions and sticking to our guns is absolutely critical, because if you start to second-guess yourself on any of the decisions, then you're setting yourself up for failure," Bloom theorizes. "That being said, if you don't listen, you're also making a terrible mistake."

A great deal of communication occurred between the announcement of the merger and its close on April 1, 2004. Within a few days of that date, e-mail and voicemail communications were working across the enterprise, and systems decision-making got going in earnest. In the interest of speed and simplicity, suites of applications were favored over best-of-breed combinations. "It would have been easy to say that the rating system in one company, put together with an underwriting system of another company and a policy processing of the other would be the best solution, but at the end of the day it wouldn't have," Bloom argues. "There's too much risk associated with cobbling together different system components that were never meant to work with each other."

This approach may have resulted in the carrier's sacrificing what some might perceive to be worthwhile short-term opportunities, Bloom allows, but he and his line-of-business counterparts were thus able to make 80 percent of the necessary platform decisions within three months.

The approach nevertheless permitted some best-of-both-worlds outcomes. For example, the carrier settled on the Travelers claims platform going forward, in large part because it processed all personal lines business - a non-existent line in the St. Paul portfolio. However, St. Paul had a very effective rules-based workflow engine built into its system, which was notable for its flexibility. "Our approach was, 'Let's finish the merger and get all of our open claims and claims history onto the Travelers system.' At the same time, we reserved a small team of legacy St. Paul and legacy Travelers people to build the workflow and rules engine into the Travelers claims system," Bloom relates.

Bloom also took a best-of-both-worlds approach with technology staff. The decision was made to select Travelers' Hartford-located small commercial platform, as it was a more mature system and was already integrated with service centers. However, on the principle of always selecting the best people - regardless of geography - St. Paul's Baltimore-based small commercial technology team was chosen to support the system. The erstwhile Travelers small commercial team will be redirected to building St. Paul Travelers' mid-market commercial platform, while also helping the Baltimore crew to get up to speed on the system. "I looked at the talent and business knowledge of the team in Baltimore, as well as how well they worked with their business partners, and decided I couldn't afford to let them leave our company," Bloom explains.

Much of the combined company's basic technology integration had been achieved by Jan. 1, 2005. Corporate systems, such as HR, general ledger, accounts payable, expense processor, purchasing and a plethora of small systems, were completed on or about that date. The lion's share of the technology infrastructure also had been completed, including major office consolidations, data consolidation, and integration of voice and data networks. And, says Bloom, "Our disaster recovery strategies are in line, desktops have been rolled out, the help desks and security platforms have been merged, and we've adopted a single way of doing field office support."

It wouldn't be far from the truth to say that "a single way of doing things" is Bloom's ruling passion as he pursues the integration of the legacy companies' systems. The temptation to conserve the unquestionable value of those systems is strong. But Bloom is enforcing a mandate to "get to one." Echoing Unisys' Kane, Bloom submits that "There's often so much clutter left over in a legacy environment because people didn't finish what they started around a merger." Bloom's aim is to finish the merger expeditiously and arrive at single platforms for all functions by the end of this year. "Whether the smallest or the biggest of our major initiatives, we're not going to sacrifice getting to one and force the company to live with multiple systems that basically do the same thing."

Success Factors

In addition to decisiveness, the speed at which the IT work for this merger was accomplished largely depended on disciplined project management and strong relationships with the business partners, according to Bloom. Across the 270 projects involved in the merger, it was inevitable that urgency would be greater than usual and that some staff would end up in unfamiliar situations. "IT wound up providing most of the project management," recalls Bloom. "Fortunately, we had really strong people and folks who were able to see where help was needed."

Those abilities would have been moot, however, had the business and leadership not been well aligned. "If my business partners didn't believe as strongly as I did, this never would have worked," Bloom asserts.

The technology leadership at AXA Financial (New York, approximately $583 billion in assets) places, if anything, an even stronger emphasis on business direction as a success factor in its $1.5 billion acquisition of MONY, which closed in July 2004. "This is really business-driven, and the business has helped us," says Bill Levine, who retired as CIO in January.

Kevin Murray, who is taking Levine's place, opines that "The IT integration is the gravy; the business considerations drive the merger, and if mergers haven't gone well, I think it's where the product and distribution integration failed rather than IT."

A successful business integration between AXA and MONY seems likely enough, based on the companies' compatible life and annuity product lines and multichannel distribution models. Despite the similarities, however, like St. Paul and Travelers, the companies had rarely chosen the same technology products.

AXA took more of a best-of-breed approach but leaned toward suites as a rule. "If there was a suite of products that did something, we kept it to keep the integration down," says Levine. Among the systems kept were AXA's PeopleSoft (Pleasanton, Calif.) for HR and finance over MONY's SAP (Waldorf, Germany) solution. From the MONY side, the carrier kept CSC's (Austin, Texas) CyberLife to leverage it further within the enterprise.

Much of the data consolidation was unavoidably a hard slog, for which AXA had to rely on the knowledge and dogged professionalism of its IT staff. But in order to get systems from both legacy organizations on the same side quickly, a solution was crafted to build middleware layers. In the cases such as the SAP/PeopleSoft conversion, AXA simply had to bite the bullet, but in many cases, says Murray, "Bridging the middleware gives you the luxury of keeping the databases separate."

AXA's tactics paid off with the completion of several IT deliverables by the end of 2004, including payroll, general ledger and common reinsurance system, among other milestones. "Their agents can sell our products, our agents can sell theirs; combined Web site/intranet-type information - that happened very early and we continue to move the ball forward," Levine comments.

The carrier also worked to meld the two legacy IT organizations together, spread over AXA's Manhattan location and MONY's Syracuse, N.Y., office. Unlike St. Paul Travelers' priority of people above location, however, AXA is distributing its newly combined IT staff based on systems affiliation. "We kept people with their systems because of knowledge and the learning curve," Levine says. "It's very hard to retire some of the old life systems, and you need the people who know those systems to work on them."

The staff at both locations will be kept busy with further merger deliverables, including implementing MONY's Callidus Software (San Jose, Calif.) field compensation system and AXA's homegrown front-end workstation for its newly combined distribution force. "The next major accomplishment will be a June merging of the broker-dealers. And of course," comments Levine wryly, "they were one clearing firm, we were on another - you never get lucky with that."

AXA did have the good fortune, however, of two highly skilled IT organizations that blended well. Beyond the need to upgrade data center capacity, the technology work was mostly "very good blocking and tackling," Levine attests. "The merger plan is predicated on IT hitting its dates, and so far we've hit them all."

Timely delivery also characterized the IT portion of the merger of the U.S. operations of Japan-based Mitsui Marine & Fire Insurance and Sumitomo Marine & Fire ($1.1 billion net 2004 income) beginning in 2002. Indispensable to reaching the Jan. 1, 2003, finish line on time was adherence to a guiding principle to "Do only what is necessary for the business to write all policies on the core system," relates Phil Lambert, Mitsui Sumitomo's U.S. CIO.

From a technology standpoint, both organizations had seen limited growth in advance of the merger. As a consequence, they tended to "throw in the kitchen sink" during the requirements process, Lambert notes. "The principle made it easy for IT to push back on the business and ask whether a requested feature was required," he recalls. As a consequence, Lambert continues, "Instead of IT being the bad guy, saying 'no' to many requests, the business monitored itself and asked for less."

Conservative Choices

Risk considerations moderated systems choices, in a similar vein to the AXA and St. Paul Travelers merger. Even when new systems were brought in, avant garde technology was generally avoided. For example, the carrier abandoned its old Token Ring/Novell networks in favor of a Microsoft/Ethernet network. "The technology was not so much 'new' as just 'newer,'" Lambert explains. "We did not adopt the then-bleeding edge Active Directory but went with the tried-and-true NT 4.0."

Prudence similarly guided the methodological procedure of the carrier's overall technology integration. Lambert describes a "first-things-first" approach based on a concept analogous to psychological theorist Abraham Maslow's "hierarchy of needs."

At the lowest level, the carrier needed to bring desktop PC equipment and productivity up to an enterprise standard. That meant overcoming some vendor management weaknesses and enforcing hardware and software compatibility. "It was pretty easy to sell the costs of keeping machines up to par, compared to the enormous cost of the merger," Lambert says. "We did spend real time throwing out obsolete hardware - there is no point in moving the trash."

Sharing and connectivity came next, involving implementation of common file formats. Users resisted the sunsetting of some applications, such as the Lotus 123 spreadsheet application, but the presence of a temporary CIO served to absorb much of the push-back, according to Lambert. The carrier was fortunate in that both organizations used Lotus Notes, which obviated the user pain associated with merging e-mail systems. Nevertheless, relates Lambert, "The technical aspects were considerable and should not be underestimated. Getting an accurate global address book was very important - and oddly vexing."

At the level of business functionality, the carrier selected best-of-breed systems and then modified them to support the volume from rejected systems, as part of a phase Lambert characterizes as complex from both a business and technical point of view. "It took a lot of smart, dedicated people to do the gap analysis, testing and then training," he comments.

Further up the hierarchy, the carrier faced inevitable questions of user behavior modification and, at the peak of the pyramid, the effective circulation of information across the enterprise. "This was the layer that left the executive business sponsors most frustrated. They wanted efficiency of business process and reports that accurately reflected the state of the business, but the reality is that these layers could not be properly addressed until after the merger," says Lambert. He explains that the inexorable necessity of the hierarchy is such that "It is not possible to properly affect process and information without the business systems being there in the first place. Furthermore, this layer does not meet the requirements of our guiding principle; we did not need information or better processes in order to move."

Anthony O'Donnell has covered technology in the insurance industry since 2000, when he joined the editorial staff of Insurance & Technology. As an editor and reporter for I&T and the InformationWeek Financial Services of TechWeb he has written on all areas of information ... View Full Bio

Register for Insurance & Technology Newsletters
Slideshows
Video