Quality Assurance Analysis

Details
Category: Poles of competences

Across the insurance sector change is everywhere. The front offices and back offices for general, life, health, pensions and commercial are all being shaken up like never before. New business models, constant technological progress, as well as ever-changing legal regulations require that companies replace their business applications from time to time.

Migration of insurance data often turns out to be a nightmare. Policyholder data in legacy systems do not fit the expectations of new systems: Mandatory factors required to calculate premiums in the new world are just not available for migration, underwriting rules in the new world do not accept legacy data, premium cash flows do not match.

If data is migrated incorrectly, the insurer will lose goodwill as angry policyholders complain. On the other hand, if the time taken to fix all issues related to migration is too high, the benefits of moving to the newer and presumably better system will be lost.

Modeling systems characterized by multiple sub-models

A migration is a fairly complex transfer from production data to another fairly complex data model. It's described by the specification as a set of mapping rules and transformation functions, but the degree of success depends heavily on the quality of data that emerges from the data migration used in your target applications, e.g. :  back-office environment, data warehouse (DWH), customer relationship management (CRM) and business intelligence (BI)

Quality Assurance Analysis is used to evaluate whether data have been generated according to specifications, satisfy acceptance criteria, and are appropriate and consistent with their intended use, and also meet a set of standards to ascertain their completeness, correctness, and consistency using the methods and criteria defined in the project documentation.

  • Completeness: check is performed to confirm that all records in the database are present.
  • Correctness: These errors are detected only when executing concrete test cases.
  • Consistency: Concerns contradictions and syntactical anomalies and interoperability with other applications.

Therefore, a sophisticated combination of automated and manual comparisons has to be applied for validating the data and its structure.

In conclusion, it is clear that Quality Assurance Analysis is not an absolute measure. You cannot take a product record out of context and determine its data quality. Quality Assurance Analysis always depends on the environment and the requirements, relative to your product information. In other words, the data, and the quality of that data, should match the requirements.

Our solution: Quality Assurance Analysis with a maximum of completeness, correctness, and consistency

Clearly, we do not provide a complete suite of Business Integration for Insurance solutions, it's not our job.

Using our insurance experience as actuary, we can effectively ensure that your policies, contracts, claims and accounting data from multiple source systems are migrated into your new policy administration system with a maximum of completeness, correctness, and consistency.

We can analyze and report on the quality and also the calculation of your data and show you exactly where there are gaps and inconsistencies, and we can provide a set of recommendations, approaches and innovations to help you deal with any data issues.

Comprehensive proven approach for a migration process

All data migration projects implement migration programs, scripts, and transformation rules. The programs handle and modify the data. They differ from company to company, and from project to project. Nevertheless, they are based on a generic data migration architecture.

The model below is based on a process model we have repeatedly applied in practice. It consists of four main stages which in turn each contain fourteen distinct phases.

  • Initialization, i.e., setting up the necessary organization and infrastructure
  • Development, i.e., developing the actual data migration programs
  • Quality Assurance Analysis, i.e., validating the correctness, stability, and execution time of both, data and the data migration programs
  • Cut-Over, i.e., finally switching to the target application by executing the migration programs

Here are a few tips:

Start with a gap analysis:
A business analyst should identify gaps from the frontend, while data analysts profile data and record data model gaps from the backend. Covers that are no longer offered and retired products/policies in particular need to be reviewed critically to decide whether they justify migration.

Don’t try to solve all problems:
If you do that, you will never go live. Or it may take you so much time to go live that the whole competitive advantage of moving to the new system will be lost.

Prioritize:
Use the profiling information gathered in the study phase to determine how many policies are affected by each requirement. For example, if subrogation functionality has only been used by 100 policies out of 50000, then it’s a low priority.

Iterate, iterate and re-iterate:
Data drives migration projects. Even if you have worked out a complete mapping, you have to take policies through their entire life cycle (endorsements, mid-term adjustments, addition of covers and so on) to be sure that they have been migrated correctly.

Do not mix data cleaning and data migration:
Data cleaning is a separate project by itself.

Don’t mix the migration project with other initiatives:
Some migration projects derail because of a sudden decision to upgrade the database or the programming language.