To participate in the brave new world of customer self-service and straight-through processing, many insurance carriers find themselves having to deal with decades of information neglect and even apathy. As insurers take on the arduous task of moving from a legacy to a modernized information architecture and platform, they face many challenges. In this three-part series of blog posts, I'll outline some of the common themes and challenges, possible categories of solutions and practical steps that can be taken to move organizations forward in modernization.
Let's consider the case of Prototypical Insurance Company (PICO), a mid-market, multiline property/casualty and life insurance carrier, with regional operations. PICO takes in $700 million in direct written premiums from 600,000 active policies and contracts. PICO's customers want to go online to answer basic questions, such as "what's my deductible?"; "when is my payment due?"; "when is my policy up for renewal?"; and "what’s the status of my claim?” They also want to be able to request policy changes, view and pay their bills online, and report claims.
After hearing much clamoring, PICO embarks on an initiative to offer these basic self-service capabilities to its customers.
As a first step, PICO reviews its systems landscape. The results are not encouraging. PICO finds four key challenges.
1.
Historically, PICO has been using several policy-centric systems, each catering to a particular line of business or family of products. There are separate policy administration systems for auto, home and life. Each system holds its own notion of the policyholder. This makes developing a unified customer-centric view extremely difficult.
The situation is further complicated because the level and amount of detail captured in each system is incongruent. For example, the auto policy system has lots of details about vehicles and some details about drivers, while the home system has very little information about the people, but a lot of details about the home. Thus, choices for key fields that can be used to match people in one system with another are very limited.
2.
PICO has been operating with systems from multiple vendors. Each vendor has chosen to implement a custom data representation, some of which are proprietary. In order to respond to evolving business needs, PICO has had to customize its systems to its specific needs over the years. This has led to a dilution of the meaning and usage of data fields: the same field represents different data, depending on the context.
3.
PICO has business units that are organized by line of business. Each unit holds expertise in a specific product line and operates fairly autonomously. This has resulted in different practices when it comes to data entry. The data models from decades-old systems weren’t designed to handle today's business needs. To get around that, PICO has used creative solutions. While this creativity has brought several points of flexibility in dealing with an evolving business landscape, it's at the cost of increased data entropy.
4.
Many of PICO's core systems are batch oriented. This means that updates made throughout the day are not available in the system until after-hours batch processing has completed. Furthermore, while the after-hours batch processing is taking place, the systems are not available, neither for querying nor for accepting transactions.
Another aspect affecting availability is the closed nature of the systems: They do not expose functionality for reuse by other systems. Consider the life policy administration system. While it can calculate cash values, loan amounts, accrued interest, and other similar time-sensitive quantities, it doesn't offer these capabilities through any programmatic application interface that an external system could use to access these results.
These challenges will sound familiar to many mid-market insurance carriers, but they’re opportunities in disguise. The opportunity to bring to bear proven and established patterns of solutions is there for the taking.
In the next post in this series, we'll discuss possible categories of solutions, pros and cons of each solution category, along with considerations that should be made while determining the path forward in a given instance.
Samir Ahmed is an architect with X by 2, a technology company in Farmington Hills, Mich., specializing in software and data architecture and transformation projects for the insurance industry.
Readers are encouraged to respond to Samir using the “Add Your Comments” box below. He can also be reached at sahmed@xby2.com.
This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.
The opinions of bloggers on
