6 Pitfalls to Avoid With Core Systems

In spite of the fact that shiny insurtech objects have distracted some insurers from strategic core system (policy, billing, claims) replacement projects, many are moving forward with planned large-scale modernization initiatives. If the implementations were not complex enough already, the rip-and-replace of aging core systems must extend insurers’ capabilities toward full digital transformation and open the door to integrations with insurtech innovations, as well. Good executives and project managers minimize the risk of failure by going into implementations with eyes peeled for problems. These individuals plan for overcoming implementation pitfalls, because such risks can lengthen timeframes, create cost overruns or even derail the entire initiative. Here are six pitfalls to watch for: The Talent Crisis While insurance companies employ talented people who know the business and the company’s products intimately, many are not prepared for large projects, such as core system replacements, which typically occur only every 10 to 12 years depending on budget, company culture and the organization’s need for change. The significant time between such projects allows for turnover in key insurer team members and means that remaining, inexperienced insurer employees are often caught off guard by the project’s complexity. Clearly defining roles, responsibilities and time or additional resource requirements in the project planning process is critical for insurers’ success. See also: Change Accelerates in Core Systems   Documentation Deficiencies Documenting project requirements and specifications and gathering form examples can be very time-consuming, so, when it comes to documentation, shortcuts are often taken or the process is rushed. Even though most vendors have templates to aid in the process, insurers’ employees must aggregate all existing forms, notices, reports, rating algorithms, billing plans, dropdown boxes or picklist values, file formats for interfaces and a list of user permissions, as well. While the impulse to skimp on upfront documentation can be tempting (and understood), as the user acceptance testing process begins, the payback for a job done well here will become apparent. Extended Project Parameters Core system replacements are complex and touch virtually every area of insurers’ organizations, and, unfortunately, the duration of the project is typically long enough that business requirements can change during the implementation. An insurer’s necessary product refresh adds additional scope and risk to the replacement. Designing a new product, validating it, acquiring department of insurance approval and developing new integration points that may require additional contracts are some of the risks that can add cost and time to a core system replacement project. Resources may be required to manage these new, but needed, items, and new requirements may compete with other project priorities or strategic company objectives. It is hard to predict the domino effect caused when one change inevitably provokes another. That said, insurers may want to consider planning to undertake such changes to existing lines of business after the first line has been put in place and the new business processes have been vetted. This will help keep project momentum going and keep the timelines in check. Third-Party Integrations The ability of modern systems to seamlessly interact (interface or integrate) with third parties is a key business driver for updating core systems. Insurers often use implementation projects to introduce integration with new third-party solutions to improve operational efficiency and automation. The risk of doing this is when it takes longer than expected to finalize the relationships with the third parties. The delays hurt the project timeline and jeopardize related downstream project dependencies. Insurers can benefit by building extra time into the project plan for firming up any new third-party relationships. Data Conversion Conversion of historical policy data is an important aspect of core system replacement projects, which, in theory, seems simple. In practice, however, data conversion is a complex process that can be approached from innumerable directions and can cause as many problems as it solves if not done correctly. Many smaller companies opt to manually convert data, but larger insurers usually require an automated conversion as part of the project specifications. An insurer’s historical data requires verification and cleansing before it is usable for an accurate conversion, and the effort is successful based on the quality of the original data and the ability to make decisions about how to handle anomalies. Once the data is cleansed, it needs to be normalized or formatted to the new system specifications, and this usually involves some manipulation. At the end of the day, no insurer ever says data conversion was easier than originally thought. But this may be a result of vendors ensuring the data going into the replacement system is well validated and of high quality, which ultimately requires more effort on everyone’s part. The Customization Curse With data conversion running a close second, the biggest risk to a core system replacement project is extensive customization. All projects require some level of customization, but the impact of heavy customization can be catastrophic today, as well as down the road. Modern systems are developed to deliver preferred workflows and best practices. Customization inevitably leads to scope creep (for insurer and vendor alike), which hurts project timeframes and adds cost. Customization has another potentially negative side effect as deviations from standard configurations often make future upgrades more complex or impossible. Often, insurers find the cost and effort to upgrade highly customized systems unjustifiable. If an insurer requires extensive customization, it might be because business processes are out-of-date, or are in place due to legacy system limitations (paved cowpaths). So, actually accepting the ways the new system was designed to handle critical processes could save a lot of future pain if the insurer in question is willing to manage some level of process change. See also: Core Systems and Insurtech (Part 1)   It bears mentioning here that there are natural traps into which vendors or solution providers can fall, as well, and that will affect the potential of project success. However, if a vendor has performed multiple implementations successfully, there should be an efficiency inherent to that experience that will help avoid bad consequences. While it is not possible to foresee all of the challenges associated with a major IT initiative such as a core system replacement, it is worth understanding the basic tenets of the most common implementation pitfalls and taking measures to mitigate the associated risks. Taking precautions will go a long way in helping a core system implementation come in on-time and on-budget.