The way Ken Mapp sees it, there are two basic problems with integrating data. One is a technological problem, says Mapp, manager, special projects, with Grange Insurance Group of Seattle. How do you get data that is coded in different technological platforms to talk to each other? The other is more of a logic-coding problem. How do you get data that is coded using different schemes to talk to each other? he asks.

Mapp and others like him face those problems every day. Data is used throughout the enterprise, but its not always available in the format business users want. Data comes from within and from outside the enterprise, and that means different codes, platforms, and terminology. One of Mapps jobs involves combining data from several different platforms into one enterprise data warehouse. Just look at something simple like some systems use an alpha state code and some use a numeric state code, Mapp says. So how do you know that state 04 and state CA are the same state? Thats a relatively trivial example, but the problem gets to the level where it could take a half-hour or more to describe another example.

There is one simple answer to the problem, according to Aaron Zornes, senior vice president and research director for enterprise information integration at the consultancy META Group: The carrier can buy it all [software] from one vendorspend a lot of moneyor buy an integrated package. But insurers have legacy systems to deal with, so simple answers arent likely to happen, he says.

Particular to Insurance

Insurance has a particular situation, he continues. Many times theyve grown up with product-specific computer systems. Lines of business will have their own systems. With that comes their own data, so they each [product line] maintain their own copies of customer data. If you have multiple copies and they never get updated at the same time, no one has a consolidated view of whom the customer is.

Dealing with your business partners can be a challenge for insurers as well. You might have an agency management system on one platform that talks to a policy management system on another platform, notes Mapp. Theres a problem in getting the data between those two platforms. Sometimes we have different policy systems that are on different technological platforms, so getting them to talk to each other is not trivial.

Neither of these problems is insurmountable, but that doesnt make things go easier or quicker. You tackle it problem by problem, Mapp says. If you have a need to communicate between your agency system and your policy management system, you assign some programmers and some tech resources to that problem and they solve it. They develop programs, and they move the data, and they end up with a solution to that particular problem. You do that over and over and over again for every high-priority need that arises.

Nobody said it was simple. Mapp adds: Its not an ideal situation because you end up with repetition and partial solutions. Someone may come back a month later and say, When you did that agency management thing, you forgot this piece of data. So someone has to revisit the issue, and it takes more time.

The Solution as Problem

Sometimes, solving problems causes other problems. The e-business age has created yet another complicationgetting tasks accomplished in real time. Tony Candito, senior vice president and CIO of individual business for MetLife, believes some solutions to the problem have to examine the business process as well. Some things need to be done in real time and can be, he says. Other things, though they may want to be done in real time, dont need to be.

As an example, he points to a hypothetical request that the data files be checked to find everybody between the ages of 45 and 55 who owns an annuity but doesnt own a DI policy or a variable universal life policy. You can do that in real time, he says. But from performance and other practical aspects, you dont want to.

Zornes says getting a consolidated view of the customer has its benefits, not the least of which is it can help a carrier cut expenses. There are several steps to get to that level, he explains. Being better able to understand whom the customers are, service them, sell them. The difficulty comes from employees who dont look at their company at an enterprise level. Sometimes its difficult to get this job done in certain organizations because of the politics, says Zornes. A division or product line feels it owns certain customer data, and it doesnt want to share it with the rest of the company. Sometimes its difficult because each division of the company or each product line went off and did radically different computer systems, so they have a very difficult time talking to each other.

Whos the Boss?

When this has happened, the solution must come from the corporate level. One way is by creating a customer information file (CIF) or a master customer information file (MCIF), Zornes says. This is a corporate oversight issue. You shall share your customer data. Every business segment turns in its customer data so one master file can be created. When customers call in, theyll only have to tell us their name, address, phone number, and marital status once, Zornes says.

An MCIF is not only beneficial to the customer, who often tires of answering the same questions over and over again, but the product line people will receive the benefit of having the most current information on a client just a click away. What the business segments have to learn, though, is they are not maintaining the customer. The customer belongs to the corporation, so we [the corporate level] have this master file, Zornes explains. Carriers have not stopped at personal information for the MCIF. Information on the customers policies gets added as well, and the M in MCIF switches meanings from master to marketing.

Candito is in the process of implementing a new integration package at MetLife. The focus has been on establishing a single customer file, which he calls the Gold Copy. All the data resides inside these so-called legacy systems, he says. What were doing is extracting information out of the legacy systems and into the customer information file. He believes that redundant input of client information will be eliminated through the system and more marketing opportunities will be available.

Mapp indicates Grange is attempting to solve the integration problem through an enterprise database (EDB). Well be putting all the information from all our systems into one platform so we can do the work there without having to reinvent the wheel, he says. Grange periodically migrates data from all its systems into the EDB. Theres a lot of overhead to developing this, he says. It takes a lot of time to develop, but once its done its done for good.

Whatever a company chooses to do, though, will take time, Mapp cautions, but the results will bring about a speedier process for the users. Youre going to speed development time on any projects that require cross-platform communication, he says. Youre going to be able to develop some real-time reporting for the end users they would not have had the ability to do before. Ad hoc reports and real-time queries were not conceivable without an enterprise database.

Mapp gives an example of how it can work: Suppose somebody in underwriting says, I wonder if were getting hit by policies that are renewed for the third time without a payment. Right now, that problem would never get assigned to a programmer because there are so many tasks, so many projects in the queue already, for IT, he says. Some of these things just never get acted upon. Something like that would have to bubble up to upper management and then be forced down to IT.

Once the new data warehouse is complete, though, mid- to high-level people in underwriting, marketing, and claims will have access to all the company data and be able to perform their own queries from the desktop without bringing in anyone from IT.

Multiply the Problems

Another challenge to integration is the multiple channels insurers deal with these days. Policies are sold online, through agents, by call center reps and in storefronts such as Schwab or Fidelity. Some of these channels have been thrown together quickly in a reactionary manner. Just like some of the old product lines, these channels have their own databases and their own customer data, says Zornes. Once again, things got iffy because one channel would have information and another channel would not. Online e-business people would have certain data, and the other product lines wouldnt. From the customers viewpoint, they could get online and change some of their own information, but there was no guarantee those changes were being replicated throughout the enterprise.

E-business people support anything done in real time, but other areas of the company might not be ready for that approach. It costs a lot of money to go real time, Zornes says. We cant have everything updated in real time at all places at the same time. If a customer calls in and gives a new order, that order cant be replicated across the company in 15 different databases immediately. It might be reflected in one or two, but not all of them.

From this challenge has grown data integration software. Such software has to balance a need for integration with the ability to analyze the data, says Zornes. Most systems realize everyone has different needs, and it is important to prioritize them. When a customer name or address changes, or you get some new lifestyle or demographic info, the data gets changed in one place and gets replicated out to the other systems on an as-needed basis, Zornes says. If the real-time system is acting in real time, the e-business people get it in real time, whereas, perhaps, the batch billing system only runs once a week. Thats something that can be batched and sent over for the customer data integration [CDI] system once a week.

He points out data warehouses are more batch-like and not online because of the sheer size of all the data. The data is there, and you can get at it online, but it isnt updated in real time because it is too expensive, Zornes says. Companies also discovered they could put CDI layers on top of the data warehouse to route data updates between systems as needed.

Mapp says programs can be written that can decipher data with 99 percent accuracy. I wouldnt say we have a 100 percent solution because of all the little things that could go wrong, he says. To do that you would probably have to create some system where during the process of migrating your data, you would capture these errors and feed them back to the different user departments to actually correct them.

That extra one percent opens opportunities for the future.

Straight Through

To the Other Side

One area of integration that excites the insurance industry is straight-through processing (STP), the end-to-end processing of policy applications that integrates front- and back-office solutions. Ken Mapp, manager, special projects for Grange Insurance Group, says STP is coming, but were not at the point where an agent can take an application and it turns into a policy in a half hour.

STP began in the financial trade and has moved into insurance, says Greg Grosh, founder and vice president of marketing and strategy for solution provider Data Junction. The same data structure is used so that no matter how many systems the data touches, everyone involved in the process sees the same data. The only way to make that happen is if the people agree on the content of the data and keep it in a digital format as it touches all the entities that need to touch it, he says.

Mapp believes the industry is close to reaching that level. Our goal would be to take an application in the agents office and then have a policy printed out for the insured, he says. I believe in two or three years it may be possible. We may reach a state where 60 to 80 percent of our policies can go through like that.

Mapp doesnt think the industry wants or needs STP for every policy. There will always be a variety of exceptions that will cause the policy to take a longer processing pathlike underwriting exceptions, or incomplete information from the agent, or information returned from a motor vehicle report. There will always be exceptions that require a manual process.

One thing that is holding STP up for Grange is the fact the insurer has three different policy management systems. He believes Grange has the process down to three or four steps. Were not there yet, he says. Right now, the agent takes the application and sends it in. Its coded into a policy system and mailed back out. Internally, there might be underwriting and coding involved.

Three Things to Do

Greg Grosh, of integration solution provider Data Junction, has three recommendations for insurers looking to integrate their data.

Data quality would be first, says Grosh, a founder and vice president of strategy and marketing for the Austin, Texas, firm. Data quality is not only appropriate for the task at hand, but for all the elements. Not only do you have to be proactive, but you have to continue to practice for all new sources of data.

Having a world view is second. Imagine the world is a larger number of smaller systems and transactions, rather than a smaller number of larger systems and entities, and make appropriate planning.

The third point is to be up to date on standards. That is all the standards groups, not just ACORD, Grosh says. There are a lot of splinter groups with various XML formats for all sorts of things.

Insurers have many similarities with other members of the financial services industry, but Grosh believes there is one important characteristic that distinguishes insurance from banking and brokerages. Insurers are companies that actually make products in computer systems, he says. You create a new product by defining it differently to your computers. Its defined strictly by certain attributes in the machine over time.

With that comes what Grosh calls an explosion of data that changes over time. Terms that the industry used 10 years ago are not the same as they are today. The definition of an annuity is different today, yet the data still resides, often, in the same computing systems, some of which are 30 years old. So you have a compounding effect of the need for appropriate data integration, he says.

Another key is giving computer systems the ability to overcome language problems and to instill some human characteristics into the machines. Humans scale very well for variety, but they dont scale well for volume, Grosh says. Whereas computers are just the opposite. They scale very well for volume, but they scale much worse for variety.

Special Reports /

Talk Is Cheap (But Integration Isnt)

Related Stories

Recommended For You