MetLife unified its systems to ensure that its customers are satisfied

Rethink IT, May, 2004

When Steve Kessler, vice president of application development at US insurance giant MetLife, agreed to produce a single unified view of all of the company's customers, he knew he was taking on a job that had killed previous managers.

But he knew that the way his business was focused, purely around insurance contract files, was not the way for it to continue into the future.

He also knew that, if he were successful, it would enable the MetLife enterprise to move from its roots, historically centered around its products, to be a financial services organization centered around its customers.

He never quite explained why he was crazy enough to take on the job, but you get the feeling that he was happy when help arrived.

DWL came in to talk to him about its enterprise hub, called DWL. Customer, and as they explained it to him he said: "I know just what you mean, we're just about to build that."

It represented a breakthrough for both him and for DWL and, three and a half years later, MetLife is well on the way to integrating all of its customer data.

Kessler sees it all as about moving to a services oriented architecture. "In an insurance company the back end processes are all built around the contracts that people have signed. They are central to what we have been doing for many years. The question how do you shift the is company's culture?"

MetLife was a mutual insurance company for 135 years, then in 2000 it demutualized and went public. The ensuing focus on profitability is perhaps part of the reason for the change of structure.

"We decided to unify the customer records one step at a time. This year we would do the life records, then look at the auto business and then the home," said Kessler.

"If you don't have a single view of your customer data in this business a lot can go wrong. You might have a customer on the phone who wants a good deal getting his son car insurance and on the information that you have on the system in front of you, you may not give him that deal. But what happens if elsewhere on another of your systems it turns out that this same man is the CEO of a major client company? Then you risk losing all that business, but your systems didn't tell you."

ALL THINGS BEING EQUAL

The key question is: "Should you treat a $5,000 customer the same way you treat a $50m customer? Well, if you don't have the right systems in place, you don't even have the choice. You need the infrastructure to make take that decision."

He continued: "And in the world of the web, when you are making systems that can interact with customers, you will often have to show a customer the data you hold on him or her. Well, that data had better be right and if the customer makes an update, like an address change, it had better update all through your systems to every piece of business that you do with that customer."

Kessler outlined the options that had faced him back then. "There are three ways of going about solving the problem. You can build a front end solution, and pull together, on the fly, the answers you need from multiple back end systems; you can build a warehouse solution where a copy of all your live transactions are kept for you to look things up; or you can build an integrated solution where all of your back end databases are integrated through common customer data."

KEEPING UP WITH CHANGES

A front end solution makes it difficult to keep up with data changes. There are data quality issues. A warehouse solution means you have to periodically make updates of a huge amount of data, like creating data marts and it's not a system of record and it's difficult to maintain the timeliness. You can't drive transactions back through it unless you create some kind of bidirectional updating.

Kessler talked about an example of where this had been tried in his company, "We got names in parts of the address line and vice-versa because we were implementing a rule that said that a product can only be bought by one owner. But some products can be shared, so when the only place to put the second name was on the first line of the address, our staff did that."

"It was fine for printing out an invoice, both names got printed in the right order, but if you then try to export the name and address file for use elsewhere, one product owner goes missing and part of the other's address is wrong.

"But in the end the right answer, for us at least, was to create an operational system of record for all client information using a customer hub."

"Over 70% of our time was spent on culture change stuff. We would have one date of birth in one back end system and another in a different system. We needed to be able to write back to both systems, not when we wrote a new life insurance policy, but when we had someone on the end of the phone at a call center saying "My date of birth is wrong in your system, can you change it."

CENTERING ON THE DATABASE

"We needed a system where it was all about the parties involved, not the contracts, and in order to do that we had to make the new database the only place that you could update or create a new party or client information."