Disentangling Disentangling System Conversions

Some view converting a book of business to a new system as the riskiest part of a new system implementation. But with proper time and resources, conversions need not be feared. They are all part of system migration, which enables companies to improve their return on investment (ROE) and competitiveness. Each company must asses the cost, time and benefits of a conversion; if sufficient resources and time are allocated, success is manageable.

With that in mind, here’s some thoughts on the pros and cons of various conversion methodologies.

CONVERSION OPTIONS

Single-phase conversion

In this type of conversion, all data is converted at one time using one of two options:

(1)Sufficient history levels (number of years) are converted to enable the discontinuance of the existing system; or

(2) The latest versions of data are converted, allowing the new system to be used for all future transactions. The existing system is retained for a period to allow inquiries about past transactions.

One advantage of a single-phase conversion is that the required resources are used for the least amount of time, thereby cutting down required costs. Longer conversions run the risk of tapping or losing resources, causing the need for such resources to be replaced, and therefore leading to a lengthier task.

Multi-phase conversion

Another option is multi-phase conversion. With this form of conversion, data is segmented by line of business or territory.

The initial phase will encompass the installation of the whole system, but will include only a portion of the portfolio. This includes 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, since the whole system is tested.

The subsequent phases involve adding other parts of the portfolio. This mostly affects the underwriting system, as checks are made 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, since these modules have already been tested, the additional work is related to tracing new transactions through the system to ensure that they are being processed correctly.

All implementations have phases. The option using the multi-phase approach is that you can go live as each individual implementation phase is completed (for example, when just the personal auto line is completed), or altenatively you can complete each phase up to user acceptance testing, but choose not to put the system into live production until all lines of businesses or phases have been completed.

Full conversion v. On-renewal conversion

Insurers also have the option of converting a book of business in one fell swoop or bit-by-bit, as policies come up for renewal.

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.

On the other hand, on-renewal conversion requires that the existing system is retained until there are no more policies to be renewed and all billing has been collected. In this scenario, the existing system would be used for any changes to the current and previous policy terms; the new system would be used for any changes to the renewal term and beyond. Any billings and collections would be done in the system in which the policy term is managed.

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

To accommodate a full conversion, the policy, billing and claims data 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 a single system is serving all interested parties. There is one common billing and reporting system instead of two systems and resulting reports. In addition, there is only one system to use; 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 straightforward, with difficulties to be addressed between the use of existing codes and new codes. These are managed by the use of mapping tables: existing codes are identified and the new codes applied. To support this effort, and to prepare for the new system, all tables the new system will use need to be defined and established. These include areas such as policy types, billing types, coverage codes, agents, adjusters, etc.

Billing and collection pose their own unique challenges: the two systems have to be compared on the basis of how they maintain and apply billing and collection data, as well as late payment or cancellation rules. These will have a great affect on the conversion because 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 include when payments are deemed to be late and possibly policies cancelled.

CLIENT-BASED SYSTEMS V. POLICY-BASED SYSTEMS

A policy-based system describes a situation in which each policy contains the client data. In a client-based system, a single client record contains the client data.

To migrate from a policy-based system to a client-based system, therefore, requires that all policies for one client be 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 look-up’ when converting policy data. The client name and address is used to set up a client record; the record is then used to link policy data attached to the same name. Once a client record is established for all policy data, this can be used to link billing and claims data to the client record.

Whether a single-phase or multi-phase conversion is planned — or whether it’s a full conversion or an on-renewal conversion — any of these scenarios can be handled with success and careful planning.

Robert Symons is the president and a major investor in Tritech. He began working for an accounting firm in Montreal that managed the reporting of Lloyds business in Canada. He established his own insurance data processing company in 1977. He then merged this company with Gerry Meinzer to create Tritech in 1992. Stmons has been involved in implementing property and casualty systems for more than 30 years for clients in Canada, the United States, Puerto Rico, and Bermuda.

Tritech Financial Systems is a Toronto-based firm and has provided enterprise technology solutions to the property and casualty insurance industry for 15 years. Tritech’s clients can be found in Canada, the USA, Puerto Rico, and Bermuda. For more information, go to www.trifin.com