(Image credit: AdobeStock.)

Part one of this article was a discussion regarding an approach for assessing and analyzing non-core systems (just about anything besides the policy, claims and billing functions) that suggested ways to scale the effort to match the potential benefits derived from the system. This article will focus on two of the other elements necessary for modernizing non-core systems: contracts and implementation. The premise of this installment is to provide a framework that insurers can use to treat their non-core system acquisitions and implementations as if they were core systems, but adjusted for scale and scope.

When it comes to contract negotiations with many of the smaller solution providers that sell and support non-core systems, the good news is that the negotiations are often conducted with the owner or other senior members of the company. This usually means that decisions and changes can be discussed and made more quickly than with larger solution providers. It also means there may be fewer layers of lawyers and procurement managers involved. However, non-core solution providers often have their challenges and nuances, so among other things, it’s important to:

• Take extra care with the contracts to ensure that appropriate service level agreements have been defined. Many smaller providers have limited resources and can (and will) over-commit to what they can do and how quickly they can do it to close a deal.
• If the solution provider is hosting or is using a third-party hosting service, then an annual security review ought to be included in the contract beyond the initial review. Cyber liability coverage should be considered as well, either through the solution provided via an addendum in the contract or through an independent insurer specializing in such coverage.
• The contract should include a copy of the code that can be placed in escrow. This is particularly important for smaller solution providers, who may or may not have the financial wherewithal to stay in business for as long as the insurer uses their product(s). However, obtaining the code doesn’t always mean that standing up an environment to house and protect the code is easy or feasible, so the time it might take to do that should be part of the overall project plan.
• Including a clearly defined list of functionality and expectations in the contract can also help mitigate the possibility of overselling by any of the vendors. Although it may take a bit of time, it is worth the investment so that the vendor is contractually bound to deliver the functionality.

Implementations for non-core systems follow many of the same best practices as for core systems but with a few tweaks for scale and scope. Practices like leveraging the functionality of the non-core system out of the box to avoid customization and scope creep and avoiding the mistake of comparing the new functionality to any of the incumbent systems (often homegrown) remain valid.  That said, there are some wrinkles to be aware of when implementing non-core systems as follows:

• Smaller solution providers with multiple clients don’t typically have a deep bench to handle the flow of change requests that always occur once testing begins. Implementation timelines should take into account that the vendor development team is on the critical path.
• Don’t fall into the trap of attempting to make the non-core system compensate for functionality gaps and shortcomings in the core systems. This is especially important when it comes to data gaps or inconsistent data.
• Take into account the community using the non-core system. Many will be transitioning directly from older non-core systems, but others may be part of the group already exposed to modern core systems. This comes with the burden of ensuring that the user experience is a comparable one. Wherever possible, have the non-core system users use the new system and core system users stick to their core systems.
• As a result of not being a core system, reporting and analytics are usually under-developed in many non-core systems. Although the total user group might be small, the impact of processes can be significant if reporting and analytics structures need to be modified for the new system. For example, a premium audit group managing $200M in annual premium can typically recover 1-2 percent per year in premium leakage by using data analytics. If that capability is not immediately available in the new system then the cost it takes to replicate that functionality is more than just the time and resource burn for the technical effort.
• Similarly, if moving from a paper process to an automated one in the modern non-core system, then expectations have to be created and managed about what functions will be introduced over what period. It can be a fundamental process shift from a reactive analytics and reporting mode (usually paper-based) to a proactive one (usually automated). With the implementation of a modern non-core system, new data points are available, and companies should carefully consider their reporting options.

Finally, and as with modern core systems, good solution providers will take the time to understand the client’s needs and processes prior to any development. This will eliminate the round-peg-into-the-square-hole issue that can occur. If the solution provider is not starting there, then it’s incumbent on the client to begin that process to ensure that the capabilities are mapped to the appropriate business processes. Also, initial releases should be quick and contain as much out of the box as possible. Adjusting or updating the system as it matures with feedback from its actual use will be much more effective than attempting to build a “perfect” system in a whiteboard setting.

Following this suggested approach should benefit the assessment and implementation of any non-core system. While these systems are often in the background and don’t get the same kind of attention and fanfare as modern core systems, they are essential to the ultimate success of any insurer. Part three of this article will focus on post-implementation best practices, including sustaining and maintaining non-core systems in the most efficient and effective ways.

Non-Core Insurance System Modernization Matters Too: Part One, Assessment