Achieving Technology Self-Sufficiency Requires a Marathon, Not a Sprint

While independence from the solution provider sounds attractive, self-sufficiency doesn’t come without a learning curve, challenges, and risks.

For as long as policy administration systems have been around, the ability for insurers to gain self-sufficiency has been the goal for many. While the definition of self-sufficiency has changed over the years, from co-development coding to shared configuration and metadata management, the insurer's objective has remained consistent: to decrease or eliminate reliance on its vendor.

Indeed, for these insurers, the ability to rely on their own know-how and have the tools in hand to maintain their own environment plays an equally important role as the technology itself when it comes to long term cost efficiencies, process flexibility, and speed to market for new products.

While independence from the solution provider sounds attractive, self-sufficiency doesn’t come without a learning curve, challenges, and risks. Just as insurers carefully evaluate the underlying technology and a system’s functionality, they should just as carefully evaluate the vendor promises of self-sufficiency, as well as their own in-house skills and wherewithal.

[For more on insurance CIO priorities, see Breaking the "Hot Technology" Circle: Technology Ranks Third in 2013 CIO Priorities .]

As insurers work to achieve self-sufficiency, they need to proceed with eyes wide open. They should be well prepared, and take stock of both their organization, and the vendor’s organization and solution offering.

Resource Availability

Self-sufficiency requires the available resources to achieve and maintain the insurer’s independence. The number of resources with the right subject matter expertise is critical to the success of the implementation as well as the long term health and well being of the new environment. Throughout the implementation, these resources will have the responsibility to define requirements for the new system, provide input to testing, and demonstrate guidance/leadership to the entire team.

These same resources will most likely continue to have critical day-to-day responsibilities for the legacy platform. Can their time be spared to not only provide support for the new implementation, but also take on self-sufficiency responsibilities once in production?

Functional Domains

As knowledge transfer from vendor to insurer takes place, there will be a division of labor between the organizations. Many commercially available solutions provide multiple functional areas of rules management and potential self-sufficiency: product configuration, functional security, document generation, workflow, expert underwriting, claims adjudication, etc.

Rather than trying to “boil the ocean” and achieve self-sufficiency in all areas at once, insurers should compare the functional domains against available resources, as well as expertise. Prioritization of these functional areas relative to their frequency of change is also helpful. After all, there is little value in mastering a functional area of the system that rarely changes.

Solution Readiness

Not only is evaluating in-house expertise and resource availability critical to the self-sufficiency goal, so is assessing a solution provider’s track record in enabling self-sufficiency. Does the vendor offer structured programs to help its clients achieve self sufficiency? Is the system capable of supporting and being optimized for self-sufficiency?

A few criteria to consider when evaluating vendor and solution include:

- Does the vendor have a successful track record of aiding its customers to become self-sufficient? It can be of enormous help to speak to a referenceable account about its experience in working with a particular vendor.

- Can the division of labor between insurer and vendor be easily managed and automated, so it is clear which party is working in and "owns" a particular functional domain?

- Does the solution provide "out-of-the box" capabilities that the insurer will be extending through configuration, or is it more of a tool kit requiring the insurer to build the system? Depending upon the answer, the resources required and time commitment could vary drastically.

Schedule and Timing

A goal of early self-sufficiency requires longer initial project duration, and will likely increase the project expense to accommodate the knowledge transfer. If the insurer is planning on achieving self-sufficiency as part of the initial implementation, the knowledge transfer process should be structured to ensure the early self-sufficiency activities are not on the critical path and won't unnecessarily jeopardize the success of the overall project.

Insurers may plan self-sufficiency as the goal, but should also have a backup plan should the goal become overwhelming or cause too much of a project delay. And it’s critical to select a provider and solution able to accommodate this change in plans in the middle of a project, should it become necessary.

Regardless of the insurer, provider, or solution, self-sufficiency should be viewed as an insurer competency that will take time to develop. Slow and steady progress towards self-sufficiency is going to ensure the greatest amount of self-sufficiency at the right time – without risking the viability of the overall project.

About the Author: Mark Cummings is VP of Business Development for the North American operations of Sapiens, a global provider of software solutions for the life & pension, property & casualty, and reinsurance markets. He can be reached at (908) 202-7286 or [email protected]