"Big Bang" Theory

All indications are that carriers are purchasing and implementing new policy administration systems in increasing numbers. The trend and the reasons driving it have been documented widely in the trade press.  Two of the defining marks of such a large and risky undertaking are that a policy system replacement project is not one project, it is several, and the benefits side of the cost/benefit equation is stubbornly back end loaded.  The carrier does not enjoy the full benefit of the new system until the system is not only live, but the in-force book of business is converted and the legacy system(s) is retired. 

The key word in the last sentence is “converted”.  Every carrier, except the occasional start-up, has an in-force book of business which has to be moved in a careful and disciplined way to the new system.  Much as been written about data conversions and the various tools and strategies for executing them successfully.   However, beyond the generic issues of data cleansing, data mapping and tool and service vendor discussions, there is one particular issue in the policy space which is critical to success and yet attracts little attention in the press.  This is the “in-force or big-bang versus renewal” debate.

An in-force or big bang conversion is where the in-force policies are converted at a point in time, either in one massive big bang conversion or maybe in several smaller “banglets”.  A renewal conversion periodically creates copies of policies from the legacy system during the renewal period prior to expiration and renews in the new system rather than in the legacy.  The renewal option therefore creates a gradual migration over time of live policies from teh old to the new system.

The decision essentially turns on the issue of speed versus risk.  In-force or big bang conversions should be quicker than renewal conversions and, if they work, should be less expensive.  However, in-force conversions, in addition to the obvious risks associated with doing a large conversion in a short amount of time have some special “gotchas” in the policy arena.  Subtle differences between the way the legacy and replacement systems rate policies, (in one instance I am familiar with it came down to the differing number of decimal places the two systems allowed for storing rating variables ) or how (if indeed the even do) they earn premiums can throw the policy, statistical and financial reporting systems out of balance and may present insureds with unexpected premium changes.  I have heard tell of successful in-force conversions but they are like Big Foot sightings, rare and hard to verify.

The alternative, the renewal conversion doesn’t carry the risk of getting the books all out of whack, or of upsetting insureds with sudden premium changes.  The earning algorithm starts anew at the beginning of a new policy term, and insureds are hardly surprised to see pricing changes as policies renew, given that is when carriers are allowed to apply new rates.  So, what is so bad about a renewal conversion?  Well first, it takes a long time.  If a carrier writes twelve month policies (which most do) they must execute the conversion for a minimum of a full year to get all the policies as they come up for renewal.  Second, during the conversion period the operations staff must interact with both the legacy and the replacement system, and need to know such basis facts as which system to search to find the current term of a given policy.  Third, any endorsement activity which has an effective date during the renewal period, usually between thirty and ninety days, must be applied in both systems.  So, there is an extended period of duplicate work, and a significantly slower acquisition of benefits associated with the renewal approach.

So why do most carriers opt for the slow, costly way?  Because it works.  And because it won’t plunge the business into chaos. But, I hear you protest, the risks associated with the big bang can be mitigated by detailed analysis, disciplined testing and adequate rehearsal time.  And in theory you are correct.  The question is, when all the additional work is done to ensure a safe big bang, or series of banglets, what has the carrier really gained in time and cost?

Conversion strategies is not exactly the most exciting topic and won't win you many friends at a cocktail party (certainly not the type of friends you would be interested in) but it is important and not well understood.  So, please, share your experiences with the rest of us.  If you have a comment post it.  If you have a more lengthy contribution, or a reference to share send us a link.  And if you do, I will buy you a cocktail at IASA (we are going to have to stay inside and drink - it's in Minnesota). 

Wishing you many successful conversions - GG

Comments

[Mark Clark]

There are some implementation issues as well. New software packages are configurable, and thus require that insurers configure their unique products as part of the implementation. I have experienced projects where companies choose to implement new insurance products as part of the software implementation. These situations create additional costs for in-force conversions. If a new product is part of the software implementation, then an in-force conversion will require configuration of the new and existing product structures. The efforts to configure products add cost and time to such a conversion effort with questionable benefit, and often place the conversion into the critical path. Additionally, legacy systems often lack information that is required in the new systems and the rules and views must accommodate special handling for converted policies.

Sunsetting existing systems and pressure to eliminate the need for users to access dual systems always seems to raise the interest from the business to convert historical data. However, once explained I have seen that the complexity of supporting historical product and rating configurations outweighs any benefits of such a conversion.

The more stable the insurance products, the simpler and less costly the conversion of in-force business. However, one key reason insurers are implementing new systems is to provide additional flexibility and speed to market. My experience is that the forward view becomes more important and renewal conversions usually make sense.

[Robert Symons]

With proper time and resources, conversions need not be feared. They are all part of the system migration, which is to enable the company to improve its ROI and competiveness.

Each company needs to asses the cost, time and bennefits, If sufficient resources and time are allocated, success is manageable.

Conversion options

Single phase conversion.

All data is converted at one time with 2 options;
a) Sufficient history levels (number of years) are converted that enables the discontinuance of the existing system.
b) The latest versions of data are converted to allow the New system to be used for all future transactions. The existing system is retained for a period of time for inquiry purposes into past transactions.

The advantages of a single phase conversion are that the required resources are used during the shortest period of time and therefore costs. Longer conversion runs the risk of losing some resources, which need to be replaced, and leading to a lengthier task.

Multi-phase conversion.

Data is segmented by line of business or territory;
a) The initial phase will encompass the installation of the whole system but will include only a portion of the portfolio. This will include Underwriting, Billing, Claims, Reinsurance, Document Issuance, Management Reporting, Financial Reporting and Bureau Filing. Each module will be tested using a portion of the portfolio. The initial phase is comparable to a single phase implementation as the whole system is tested.
b) The subsequent phases involve adding other parts of the portfolio. This mostly affects the underwriting system to ensure proper rating, document issuance etc. These are much smaller phases and can be achieved with fewer resources. The portfolio being added will need to be tested through all modules (Billing, Claims, Reporting etc.). However as these modules have already been tested the additional work is related to tracing the new transactions through the system to ensure that they are being processed correctly.

The multi-phase approach can be implemented where each phase is implemented, User acceptance testing completed and then go live as they are completed. Alternatively, each phase is completed up to the User Acceptance testing and only once all parts of the portfolio have been completed is the system put into Live production.

Full conversion versus on renewal conversion;

The portfolio is converted once or is converted as it comes up for renewal;
a) A full conversion requires that all policy, billing and claims data for that portfolio be converted at the same time. Once User acceptance testing has been completed and the system goes live all processing will be done in the New system.
b) On renewal conversion requires that the existing system is retained until there are no more policies to be renewed and all billing have been collected. In this scenario, the existing system will be used for any changes to the current and previous policy terms and the New system would be used for any changes to the renewal term and beyond. Any billings and collections will be done in the system where the policy term is managed.

A renewal conversion may be viewed as limiting the conversion risk to only the new policies and renewing policies and allowing the existing system to handle previous policy terms.

To accommodate a Full conversion, the policy, billing and claims data that are related to the portfolio have to be converted all at once. This is to enable the new system to collect billings, settle claims and allow policy changes to the existing portfolio. The advantage to this approach is that all interested parties are being served by a single system. One common billing and reporting system instead of two systems and resulting reports. In addition there is only one system to use and users don’t need to decide if they need access to the previous system or the new system.

General Conversion Issues;

Policy and Claims conversion are most likely to be relatively straight forward with difficulties to be addressed between the use of existing codes and new codes. These are managed by the use of mapping tables where the existing codes are looked up and the new codes applied. To support this effort and to prepare for the new system, all tables that will be used for the new system need to be defined and set up. These include areas such as policy types, billing types, coverage codes, agents, adjusters etc.

Billing and collection poses its own unique challenges where the two system have to be compared as to how they maintain and apply billing and collection data and late payment or cancellation rules. These will have a great affect on the conversion as they need to be translated correctly by fully understanding how the current system works and converting this data with appropriate dates and codes. Areas to be addressed are when payments are deemed to be late and possibly policies cancelled.

Client based system versus Policy based systems. Where each policy contains the client data as apposed to using a client record, this is a Policy based system. To migrate from a Policy based system to a Client based system requires that all policies for one client are linked to a single client record. If the policy, billing and claims data are not linked to a common client record during conversion, this will result in multiple client records for the same client. The conversion process needs to establish a client lookup when converting policy data, where the client name and address is used to set up a client record and to be used to link policy data where the client is the same. Once a client record is established for all policy data, this can be used to link billing and claims data to the client record.

[Bill Garvey]

George, you are truly courageous launching your blog with the fascinating topic of conversion. I was going to weigh in after the Super Bowl, so I could broach the subject at half-time with friends - add their ideas - but I just can't wait.

Conversion is that thing we talk a lot about while struggling to implement the new technology. I would agree with Alex's conservative renewal approach to best mitigate risk. At my little company we have three conversion strategies in the works; policy, claims and general ledger. It's interesting to me to hear the different concerns each of these areas raise.

In IT we seek a strategy document from the client so we can begin a useful dialogue. It helps the client define what they really need from legacy systems, what they can "live without." Claims and Finance favor the big bang approach, but are willing to limit the amount of data/years we bring over. I don't think, however, taking that tactic with them is as risky as a policy big bang.

[Alexander C. Naddaff]

I have run into the big bang conversion vs. the migration at renewal topic a number of times. In each case I have favored the migration at renewal approach. In fact the actually conversion could be more than 12 months. If a carrier is operating in 50 states and they deploy the 50 states over a six month deployment schedule the carrier will take 18 months to complete conversion for a 12 month renewal period across all states. In some cases carriers support these states using a common call center. So the call center could be interacting with two systems for 50 months. Even considering the 18 month migration I favor the migration at renewal approach. Here are some thoughts that lead me to this conclusion:

1. Risk is limited to renewing policies as opposed to the entire book. Any new system and accompanying procedures face risk and should enjoy an adjustment period. Yes testing can mitigate risk but there is nothing that can completely simulate a real production environment in the field.

2. Insured’s normally get a printed policy on renewal. You could argue that the insured would need to receive a printed policy on big bang conversion and if they do there is a communication overhead between the carrier and the customer that has very limited value. Why burden the implementation with the added cost for limited value?

3. Most important, there is a risk that a big bang renewal will force a carrier to limit the improvements that the carrier is trying to introduce with the new policy system. Carriers are legally restricted when making mid term changes to policies. The new system would need to be restricted by those same rules for the current policy term. In some cases those rules are simply in place because of legacy technology limitations. When evaluating the value of big bang conversion the legacy system limitations should be considered. It is very difficult to predict the actual limitations that exist early in the project. Some of the limitations end up being identified through deep analysis and throughout the implementation. Legacy system can be as old as 30 years with a lot of hidden code. The hidden code is ripe to teach lessons to the replacement teams. Big bang will drive the implementation team to provide code to limit all current policies to the legacy constraints regardless of the correctness of the constraint.

Once all of the factors are considered it may actually be more costly in both time and money to accomplish the big bang conversion. It is certainly more risky.

Another topic of interest is making sure the replacement technology is highly flexible as the implementation team is learning about 30 years of legacy. But that topic is not directly related to the merits of conversion approach.

Alexander C Naddaff
Professional Services Vice President
Guidewire Software