Managing Data Management
Insurance Networking News, November 2007
And therein lies the problem. Carriers need to change their way of thinking and start building data management into the project from the beginning rather than incorporating it later.
With any project—whether it's building a house or a new policy system—whatever's added after the original plans have been set can delay completion and add costs. If data management concepts are built into a project, they won't add to the project timeline and may actually aid in project development and decrease total time and costs.
Data is not just a few numbers compiled for a report to some outside statistical or rating bureau. Data is the information used to underwrite and rate the policies. It is the information used to bill the insured's for their premiums. It is the information the claims adjuster uses to determine coverage and pay for losses in case of a claim. It is the information used to determine the adequacy of rates. It is the information used to evaluate the effectiveness of specific products or lines of business. Finally, information used for the financial reports indicates the financial stability of a company. Without quality data, insurance companies could not operate.
The question becomes, "What must we do to ensure that we have the necessary data?" The answer is that we must be aware of data management at every step of a project because each decision affects the quality of the data. Whether the outcome is good or bad, our decisions involve the data and, therefore, data management. Unfortunately, in many projects, team members overlook the potential benefits of good data management and end up making decisions that ultimately delay the project, drive up costs and result in poor-quality data.
DATA ABOUT DATA
The first data management tool to understand and use is metadata or "data about data." It includes data definitions, field or data element descriptions, valid values, tables, edits, collection techniques and storage criteria. The "standards" reduce development work. For example, existing standards for date fields dictate collecting the full month, day and year. Standards then specify storing the date in a YYYYMMDD format. Further examination of existing standards reveals edits that ensure collection of accurate data.
Failing to use existing standards increases the number of steps to perform, while boosting costs and lengthening the time needed to establish the data criteria. That's because failing to use existing standards necessitates developing new metadata. The new metadata may not match the existing standards for those data elements. That would add costs later when the data has to be converted to make it compatible with similar data items from other systems.
But, the best data management means nothing without an understanding of the needs of the users, especially those in underwriting, claims and management. And this understanding goes beyond simply determining what data is needed to underwrite and rate the policy, to adjust the claims and to determine the combined ratio. Instead, it includes determining what information underwriters will need about losses and what information they will need to evaluate the insured's experience when the renewal is processed. Claims people need information to settle claims, such as policy coverages, limits, deductibles, exclusions and thrown-in coverages. And, upper management needs information to determine the profitability of the product or line of business.
Statutes require that insurance companies submit data concerning policies and claims. Examining reporting requirements early in the project will provide time to submit questions to the various bureaus that require the reports and get their responses as the project is developing. This avoids delays and costly changes late in the project.
Then there are the issues of testing and the initial quality of the system and the data it produces. Testing has been misunderstood and viewed in a negative light. It is thought of as something done after the project has been completed-just before implementation. Putting off testing could delay the discovery of a major problem until late in the project development cycle, driving up the cost in delays and corrections.
The key to successful testing is to do it at every step of the project and not just at the end. Perform tests as "parallel steps" while the development is occurring, not in "series" after each step.
For more information on related topics, visit the following channels: