Editor’s Note: This is the first in a series of three articles.
Core systems modernization efforts—defined here as pertaining to the policy, claims and billing functions—have dominated the industry over the past several years. Insurers continue to pour millions of dollars and significant human resources into the substantial work required to modernize legacy systems. At stake is an insurer’s ability to stay competitive in its current markets and the potential to compete in new and emerging markets by employing systems that are more adaptive, responsive to changing market conditions and focused on the customer experience. However, in all of that activity, the need to modernize non-core systems similarly remains. Many insurers have struggled with how to approach and scale their efforts for systems that don’t have the bulk or sizzle of the newer core systems. This three-part article will suggest an approach for dealing with non-core systems in a way that matches the resources and efforts required to the potential benefits derived.
The assessment process for non-core systems is similar to the process for core systems but with some tweaks to contextualize the approach for the size and scale of the project effort. In either case, the assessment begins with a thorough analysis of the current and future state business challenges and opportunities, the solution provider space and the functional parameters of the systems that might be considered. The tweak here is that while this might be an elaborate process that includes a specialized software product to manage the assessment and analysis, smaller non-core systems don’t necessarily require that kind of investment. A thorough analysis can still be done with more moderate tools. With non-core systems, the processes are simpler and don’t require as detailed or as lengthy of analysis.
For many insurers, the move to a modern non-core system might mean a move from a homegrown platform with homegrown processes. It’s important to keep in mind that while the systems may be lacking in modern touches, those who have been accustomed to working on them may show some reluctance in letting them go. These tend to bias the requirements for the new system toward acting and behaving like the legacy system, potentially adding time and training to the overall process. The senior management team can also significantly impact the evaluation and solution selection process. For example, a company might have a culture of working a certain way or of being reticent to change. If the leadership can make the decision to shift the company culture, it can significantly help with finding the best solution fit.
The next step is a review of the relevant vendor space. Here again, there are some tweaks to the standard assessment process because of the non-core nature of the systems being evaluated:
- The solution provider space for non-core systems is typically smaller, so there will likely be fewer options to consider. Technology, hosting, integration and reporting are a few factors that may help to narrow the field.
- Besides from a few exceptions, the solution providers are also typically not large companies themselves. Many have somewhere between 20-50 employees in the organization. This can be good and bad news.
- The good news is that smaller solution providers mean easier access to the provider’s leadership. This can lead to quicker review and decision times.
- The bad news is that smaller solution providers, while willing and cooperative, don’t typically have the bandwidth for a steady stream of change requests for their system.
- When it comes to non-core systems, there are also international providers in the mix. These companies typically have U.S. clients and support multiple currencies.
Like core systems analysis, both functional and non-functional requirements are analyzed and scored, solution providers perform in-person demonstration where possible, and references are provided and contacted. The tweak with references for non-core systems is that it’s often easier—and better for decision-making—to visit a client of the provider to see their solution in action. The smaller functional footprint of most of these systems means that the users of them are knowledgeable about them and are often willing to talk about all of the positives and negatives about the system. Another important aspect of the assessment is any solution provider’s ability to deliver. It’s not unusual for smaller solution providers to over-commit themselves. Keep the following in mind:
- Functional proof of concepts and technology deep dives are needed to ensure that what is “sold” actually exists. There is a larger chance of overselling with smaller solution providers than with the larger ones.
- Ask about in-flight implementations and how they’re being resourced. Many smaller providers typically don’t have the bandwidth to support multiple implementations at the same time, so the timeline of when they’re available for the next implementation is key.
- Build timing flexibility into the analysis and proposed project plan. The project may need to be delayed until a time when the provider’s teams are available.
- Request dedicated resources and be sure to carefully review the depth and breadth of experience of those resources.
Additionally, most non-core systems rely heavily on integration with feeder systems and other data sources. Be sure to carefully assess the relative maturity of the integration points and protocols of any system under consideration. As opposed to larger core systems, the sophistication of the integration architecture can vary widely in smaller non-core systems. Request specific documents that depict the architectural structure of any potential solutions as that’s a great way to assess the architectural strengths and weaknesses of the overall platform. Finally, it’s important to understand that many non-core systems do not have robust reporting capabilities—sometimes that’s intentional. Many smaller solution providers will work with the insurer to customize the kind of reporting required and to identify the required data integrations. This can be time-consuming, so it needs to be accounted for in the overall project plan once a solution is selected.
In part two of this article, the focus will shift from assessments analysis to contracts and implementations.