The way Ken Mapp sees it, there are two basic problems withintegrating 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 technologicalplatforms to talk to each other? The other is more of alogic-coding problem. How do you get data that is coded usingdifferent schemes to talk to each other? he asks.

Mapp and others like him face those problems every day. Data isused throughout the enterprise, but its not always available in theformat business users want. Data comes from within and from outsidethe enterprise, and that means different codes, platforms, andterminology. One of Mapps jobs involves combining data from severaldifferent platforms into one enterprise data warehouse. Just lookat something simple like some systems use an alpha state code andsome use a numeric state code, Mapp says. So how do you know thatstate 04 and state CA are the same state? Thats a relativelytrivial example, but the problem gets to the level where it couldtake a half-hour or more to describe another example.

There is one simple answer to the problem, according to AaronZornes, senior vice president and research director for enterpriseinformation integration at the consultancy META Group: The carriercan buy it all [software] from one vendorspend a lot of moneyor buyan integrated package. But insurers have legacy systems to dealwith, so simple answers arent likely to happen, he says.

Particular to Insurance

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

Dealing with your business partners can be a challenge forinsurers as well. You might have an agency management system on oneplatform that talks to a policy management system on anotherplatform, notes Mapp. Theres a problem in getting the data betweenthose two platforms. Sometimes we have different policy systemsthat are on different technological platforms, so getting them totalk to each other is not trivial.

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

Nobody said it was simple. Mapp adds: Its not an ideal situationbecause you end up with repetition and partial solutions. Someonemay come back a month later and say, When you did that agencymanagement thing, you forgot this piece of data. So someone has torevisit the issue, and it takes more time.

The Solution as Problem

Sometimes, solving problems causes other problems. Thee-business age has created yet another complicationgetting tasksaccomplished in real time. Tony Candito, senior vice president andCIO of individual business for MetLife, believes some solutions tothe problem have to examine the business process as well. Somethings need to be done in real time and can be, he says. Otherthings, though they may want to be done in real time, dont need tobe.

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

Zornes says getting a consolidated view of the customer has itsbenefits, not the least of which is it can help a carrier cutexpenses. There are several steps to get to that level, heexplains. Being better able to understand whom the customers are,service them, sell them. The difficulty comes from employees whodont look at their company at an enterprise level. Sometimes itsdifficult to get this job done in certain organizations because ofthe politics, says Zornes. A division or product line feels it ownscertain customer data, and it doesnt want to share it with the restof the company. Sometimes its difficult because each division ofthe company or each product line went off and did radicallydifferent computer systems, so they have a very difficult timetalking to each other.

Whos the Boss?

When this has happened, the solution must come from thecorporate 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 customerdata. Every business segment turns in its customer data so onemaster file can be created. When customers call in, theyll onlyhave to tell us their name, address, phone number, and maritalstatus once, Zornes says.

An MCIF is not only beneficial to the customer, who often tiresof answering the same questions over and over again, but theproduct line people will receive the benefit of having the mostcurrent information on a client just a click away. What thebusiness segments have to learn, though, is they are notmaintaining 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 Min MCIF switches meanings from master to marketing.

Candito is in the process of implementing a new integrationpackage at MetLife. The focus has been on establishing a singlecustomer file, which he calls the Gold Copy. All the data residesinside these so-called legacy systems, he says. What were doing isextracting information out of the legacy systems and into thecustomer information file. He believes that redundant input ofclient information will be eliminated through the system and moremarketing opportunities will be available.

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

Whatever a company chooses to do, though, will take time, Mappcautions, but the results will bring about a speedier process forthe users. Youre going to speed development time on any projectsthat require cross-platform communication, he says. Youre going tobe able to develop some real-time reporting for the end users theywould not have had the ability to do before. Ad hoc reports andreal-time queries were not conceivable without an enterprisedatabase.

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

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

Multiply the Problems

Another challenge to integration is the multiple channelsinsurers deal with these days. Policies are sold online, throughagents, by call center reps and in storefronts such as Schwab orFidelity. Some of these channels have been thrown together quicklyin a reactionary manner. Just like some of the old product lines,these channels have their own databases and their own customerdata, says Zornes. Once again, things got iffy because one channelwould have information and another channel would not. Onlinee-business people would have certain data, and the other productlines wouldnt. From the customers viewpoint, they could get onlineand change some of their own information, but there was noguarantee those changes were being replicated throughout theenterprise.

E-business people support anything done in real time, but otherareas of the company might not be ready for that approach. It costsa lot of money to go real time, Zornes says. We cant haveeverything updated in real time at all places at the same time. Ifa customer calls in and gives a new order, that order cant bereplicated across the company in 15 different databasesimmediately. It might be reflected in one or two, but not all ofthem.

From this challenge has grown data integration software. Suchsoftware has to balance a need for integration with the ability toanalyze the data, says Zornes. Most systems realize everyone hasdifferent needs, and it is important to prioritize them. When acustomer name or address changes, or you get some new lifestyle ordemographic info, the data gets changed in one place and getsreplicated out to the other systems on an as-needed basis, Zornessays. If the real-time system is acting in real time, thee-business people get it in real time, whereas, perhaps, the batchbilling system only runs once a week. Thats something that can bebatched and sent over for the customer data integration [CDI]system once a week.

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

Mapp says programs can be written that can decipher data with 99percent accuracy. I wouldnt say we have a 100 percent solutionbecause of all the little things that could go wrong, he says. Todo that you would probably have to create some system where duringthe process of migrating your data, you would capture these errorsand feed them back to the different user departments to actuallycorrect 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 isstraight-through processing (STP), the end-to-end processing ofpolicy applications that integrates front- and back-officesolutions. Ken Mapp, manager, special projects for Grange InsuranceGroup, says STP is coming, but were not at the point where an agentcan take an application and it turns into a policy in a halfhour.

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

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

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

One thing that is holding STP up for Grange is the fact theinsurer has three different policy management systems. He believesGrange has the process down to three or four steps. Were not thereyet, he says. Right now, the agent takes the application and sendsit 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, hasthree recommendations for insurers looking to integrate theirdata.

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

Having a world view is second. Imagine the world is a largernumber of smaller systems and transactions, rather than a smallernumber of larger systems and entities, and make appropriateplanning.

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

Insurers have many similarities with other members of thefinancial services industry, but Grosh believes there is oneimportant characteristic that distinguishes insurance from bankingand brokerages. Insurers are companies that actually make productsin computer systems, he says. You create a new product by definingit differently to your computers. Its defined strictly by certainattributes in the machine over time.

With that comes what Grosh calls an explosion of data thatchanges over time. Terms that the industry used 10 years ago arenot the same as they are today. The definition of an annuity isdifferent today, yet the data still resides, often, in the samecomputing systems, some of which are 30 years old. So you have acompounding effect of the need for appropriate data integration, hesays.

Another key is giving computer systems the ability to overcomelanguage problems and to instill some human characteristics intothe machines. Humans scale very well for variety, but they dontscale well for volume, Grosh says. Whereas computers are just theopposite. They scale very well for volume, but they scale muchworse for variety.