MetLife unified its systems to ensure that its customers are satisfied
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.”
And to define a client/party Kessler needed to keep not only the identity information but also the role that person was playing and the product relationship, as well as the mailing address. So none of this could be updated through the legacy systems that all the divisions had created.
Kessler simply created the client information file or CIF and it replaced the maintenance of party information in all product administration systems. In the end, no updating of party information could be allowed using the legacy systems and the company had to create new, strategic paths for CIF update. “The resistance internally has been an issue with each of the silos of business each thinking that they own the data. It was a major enterprise effort to deal with data cleaning and quality issues. We didn’t only have business silos, but we had silos within the silos.” (see diagram).
If he had to advise anyone else on such an installation, Kessler would say, “You need partners. There is a high skill level required to integrate customer data, and no-one can do it all. But your partners all have to share the same approach and a common vision of customer data. If anyone gives you the rainbow presentation, telling you that it will be easy and they can do it all, throw them out. It’s not easy and there are a lot of resource demands.”
“We used DWL Customer really as the core, and wrapped other stuff, like validation, around it.”
He created it on an AIX host, using IBM MQ Series and WebMethods software for enterprise integration with a Websphere application server running DB2 as a database with DWL’s Customer application.
But the outcome seems to have been worthwhile.
A BRIGHTER FUTURE
Certainly Kessler has seen that he has reduced costs through service differentiation and consolidation, and he has definitely streamlined some of his internal processes, and the new system gives his sales teams opportunities to cross sell and upsell. When asked if he can handle a new merger, he’s more confident that he can integrate their customer data too.
But the biggest benefits have come in being able to write it once and it’s done, allowing MetLife to operate a web based e-service with confidence where there are far higher customer service standards, which in turn leads to higher customer satisfaction and adherence to privacy standards.
Now the first fruits of the project are being seen, he has to complete the job. “The project competes with other projects, that’s the way of things when a business has 47,000 people. And there have had to be lots of organizational changes and process re-engineering tasks. But we are ready to move onto integrating the next system.”
To date the individual life client acquisition process is implemented with the customer hub, and existing life business is being migrated. Within the individual life segment of the business all new clients are being managed through the hub. Kessler is hoping that he can keep the momentum from the benefits to those systems and carry them over to the other lines of business.
GRID PRINCIPLES AID SECURITY
MetLife is a very large insurance business which serves all 50 US states, and other countries such as Argentina, Brazil, Chile, Mexico, Uruguay, Portugal, India, Spain, South Korea, Taiwan, Hong Kong and Indonesia.
It operates in most individual insurance businesses such as financial planning, life insurance, annuities, long term care, disability, mutual funds and securities, as well as retirement and savings. It is a big medical insurer in the US and the largest dental insurance business there. It offers accident cover, car and boat insurance and home owners insurance, asset management, mutual funds and real estate.
Currently it has 12m US people on its individual customer file and outside of the US has another 8m, but it touches up to 37m through its employee status in corporate product offerings. It is 88th in the US Fortune 100 with 2003 revenues of $8.9bn, on which it made $620m profit.
It has $331bn of assets under its management and employs over 47,000 people. It claims to be the number one US life insurer, the number one non-medical health insurer and is ranked number one in most group product areas, including life insurance, automobile and homeowner’s, and long-term care and dental.
Before implementing Customer Data Integration MetLife’s customer data was spread across three different organizations; a retail bank, a mutual funds company and a property and casualty insurer; and five different lines of business (property and casualty, banking, institutional, brokerage and mutual funds).
Customers from 30 separate back office and CRM systems needed to be unified and merged while the logic in the legacy systems continued to operate unharmed.
GRID PRINCIPLES AID SECURITY
When two major US corporations of the size of Citicorp and MetLife both buy the same package to merge their disparate customer data files, you’d be pretty sure that the software house they bought them from would be a household name. Maybe Oracle, or Microsoft, or IBM or SAP.
But tiny private Atlanta-based DWL, is the company that has been setting this new business sector on fire with its new DWL Customer and DWL Money applications.
What DWL offers is a customer data hub, a way of storing all customer knowledge for an entire enterprise, separated from the transaction logic in core legacy systems. It takes in the parties, their relationships, the products they have bought, interactions, campaigns that have affected them and helps retain a privacy wall around client data.
It must also link to business processes such as event notifications and new account openings and processing for duplicate suspects.
DWL clients not only include MetLife and Citi Cards but also JP Morgan Chase, Atlantic Blue Cross Care, Great West Life and Nationwide Insurance. DWL has strategic relationships with IBM, BEA Systems, and Sun Microsystems and integrator alliances with IBM Global Services and Accenture.
Justin Lafayette, chairman and co-founder, says that Citicorp, when it bought the Sears credit card business, was able to bid a higher price due to using DWL Customer. He said Citicorp knew it would integrate its customer data faster, and therefore get more back from the deal sooner, hence it could afford to bid more.
Lafayette talked to Rethink IT last month, talking about its big customers wins and explaining the product and introduced MetLife’s Kessler.
He said the enterprise customer hub is written in Websphere and is J2EE compliant, has a configurable rules engine running with an XML architecture and has been optimized for financial services businesses and that it is front office and back office neutral.
He also said that it has passed a scalability test deviced by Citigroup that took in 83m accounts, at 456 transactions per hour including 10,000 account openings in 30 minutes (which all use the customer hub and which were all successfully written). The product’s average response time was 134 milliseconds, averaging 165 transactions each second.
COPYRIGHT 2004 Rethink Research Associates
COPYRIGHT 2004 Gale Group
