In the Cuckoo's Nest

I recently spent time with a client that is in the final stages of selecting a claims administration system. The client needed to answer four questions posed by the company's executive management: Who (which vendor)? How (implementation approach)? How long (implementation time line)? How much (cost and payback)? My involvement at the time was with the "How?" To this end, I participated in "Road Map" meetings with IT staff and business people to understand where the claims system implementation would fit in the corporate timetable and how to structure the software rollout in order to minimize duplication of effort and disruption to the claims operation. Everything went swimmingly well until we hit the issue of data conversion.

Data conversion is that dangerous place inside a "package" implementation project where, if you are not careful, you give birth to a runaway, one-off, throw-away development effort that, like the cuckoo, grows way too big for the project's nest. Here is the basic problem: It is perfectly reasonable for a claims manager, when participating in the planning of a multimillion-dollar claims system replacement project, to assume when the project is done all the open and closed claims actually will be in the new system, put there by smart IT people writing the necessary code to move them over. What could be more reasonable than that?

The reality, of course, is significantly more challenging. Unless the carrier is very large and measures premiums in billions and policies and claims in hundreds of thousands, if not millions, it is not cost justifiable to design, write, and test the software necessary to perform an automated data conversion. What most business people don't know (and why should they?) is the conversion software may cost more than the new claims administration system. Let's say the license fee is $2 million for the new claims system. That doesn't mean it cost $2 million to build it. More likely what you get for $2 million has a development price tag of anywhere between $50 million and $100 million or more. The reason it can be bought for a mere $2 million is because the vendor writes the system once and shares the cost among the client user community–similar to why Microsoft Office didn't cost you a billion dollars when you bought your PC.

The price/function ratio of "packaged" software is low. The price/function ratio of one-off "bespoke" software is very high but at least can be amortized over a working life of up to 30 years if it is a core insurance application. What if the software in question is designed to run once and only once–essentially the case with conversion software? True, the conversion code may run multiple times in order to convert all claims, but it still has only one discrete function, which is to move claims from the old system to the new one; when completed, its useful life is over. The assumption for those not initiated into the arcane world of software development and pricing is building an automated data conversion is just one part of the project, where, in reality, it is disproportionately expensive and risky.

So, what is the big deal? Surely a data conversion program is just a series of "move statements," which, like a robot tractor trailer, hauls data from the old system to new, right? Not quite.

One of the activities I undertook at my client was to sit with IT folks who were at the end of an automated conversion development effort in support of a policy administration system replacement. My objective was to understand their goals and how they had accomplished them in hopes of finding reusable assets, skills, and tools. Their overall data conversion process amounted to 13 discrete steps, each of which required the development, testing, and execution of various flavors of software logic. Abstracting that process leaves us with the following generic steps.

o Select claims for conversion: An automated conversion may take place in one or more steps. The "big bang" approach is the cleanest approach in that all claims (both opened and closed) are converted at one time and are available in the replacement system when it goes live. Unfortunately, this also is the most risky conversion method in that large data volumes are involved along with all the combinations of data conditions created by the different lines of business and states that are supported by the carrier.

There are various less risky conversion schemes that separate the data into lines of business, states, or state grouping (often based on regional claims center coverage) or even adjuster groups. Some carriers may decide to convert only open claims, leaving closed claims history in the legacy world. One variation is to convert the last two years of closed claims, which statistical analysis will show captures the large majority of claims that might reopen in future. One point to note on the subject of closed claim conversions is a history of 20 to 39 years of closed claims almost certainly will entail version issues in the data that add to the complexity of any automated conversion. Looking back in time through claims history is a little like reading the strata of a geological time line. Just as environmental conditions changed over time and created different rock formations and attendant fossil records, so processing rules change over time, creating different data formats, meanings, and content.

o Cleanse data: The problem with legacy data is legacy systems usually lack adequate edit, validation, and data integrity checks. Often the resulting data is incomplete and inaccurate. And given these systems were written in the days when data storage was a major cost concern, meaningful data was reduced to codified shorthand whenever possible. Alphanumeric data usually was stored in free format areas where pretty much anything could be recorded. This combination of conditions usually leaves legacy data in need of some significant cleansing, massaging, and enhancement before it is of use in the new system. Common candidates for cleansing efforts are the various name and address areas that are found in core insurance administration systems. Many data conversions have discovered claims that occurred at nonexistent locations, placing policy risks at incorrect or absent addresses.

o Map data: The second major step in creating an automated data conversion is to map the data, field by field, from the legacy to the new system. This step sounds relatively straightforward until it actually is undertaken. Consider the following common findings: Field A in the legacy has no corresponding field in the new system; one or more fields exist in the new system for which there is no analogue in the legacy world; a field in the legacy system stores the result of a calculation, while the new system requires the component fields rather than the result; data values exist in the legacy system that are not allowed in the new system; and on and on.

So, in addition to specifying simple "move statements," the mapping requires the development of various classes of data transformation rules in order that the data is legal and sensible to the new system.

o Create new claims images: The third step is to create the transport mechanism by which the data actually gets extracted from the legacy system and is made available to the replacement system. Depending on the replacement system's ability to consume the data, this may be a multistep process. Some new systems can read and consume data from a batch feed and populate data without compromising data integrity. Other systems assume the only entry point into the system is via the "front door," through input screens that invoke the necessary edits and other validations. If the latter, then an additional "data entry script" must be developed and tested to act like a human data entry and drive the system's input screens.

In addition to populating the new system, this step also must recognize and record failed transactions and keep various counts that subsequently can be used to keep control of the overall data migration process.

o Verify claims details: A "normal" claim for claim conversion allows for a parallel comparison to take place, validating that any given claim has arrived successfully in the new system. This might be supported by a "file compare" type of utility or may require more original software to be written in order to provide verification. The complexity of this verification step is related to the extent of the data transformation undertaken earlier in the process. The greater the transformation, the more conditions the verification step needs to take into account.

o Balance claim populations: The penultimate step in any conversion cycle is to validate that every claim that should be transferred has been transferred to the new system. Two error conditions that must be monitored and managed include identifying claims that should be transferred but are not and claims that should not be transferred but are. These conditions are detected by balancing routines that trace the movement of actual claims, comparing them to the expected movement of claims and flagging any differences.

o Handle error conditions: Finally, as with any software process, there has to be a way to recognize, capture, fix, and resubmit claims that failed to complete the journey from legacy to replacement. This requires software that stores failed claim records, reports their existence, and allows a human agent to modify the offending data and then resubmit the "fixed" claims to the conversion process.

In our simplified discussion, we have identified seven significant steps that must be specified, designed, coded, and tested in order for an automated conversion to be utilized. No wonder that I recently have talked with several carriers that have made the arduous journey from a legacy claims environment to a modern vendor-based world but consistently have chosen to spend their implementation dollars on new functions and features rather than on bringing the legacy data forward. The one exception is the largest carrier, which would (as noted earlier) have the biggest operational "drag" from living in a dual-system environment for any significant period of time.

Want to continue reading?
Become a Free PropertyCasualty360 Digital Reader

Your access to unlimited PropertyCasualty360 content isn’t changing.
Once you are an ALM digital member, you’ll receive:

Breaking insurance news and analysis, on-site and via our newsletters and custom alerts
Weekly Insurance Speak podcast featuring exclusive interviews with industry leaders
Educational webcasts, white papers, and ebooks from industry thought leaders
Critical converage of the employee benefits and financial advisory markets on our other ALM sites, BenefitsPRO and ThinkAdvisor