(Image source: Siemens.)

Parts one and two of this series focused on assessing and implementing non-core systems (defined as just about anything other than policy, claims, and billing systems) that suggested ways to prioritize and scale the efforts required when modernizing non-core systems. This, the third part of the series, focuses on how to overcome the challenges inherent in supporting and maintaining non-core systems post production. As with the first two parts of this article, the premise remains on suggesting a framework that insurers can use to treat their non-core systems as if they were core systems, but adjusted for scale and scope.

The primary problem with maintaining non-core systems after their production implementation is that they are non-core systems and because of that, will never get the priority and resource dedication that core systems typically get. With core systems, there are often large teams of dedicated resources that are committed to the effort for years due to the strategic, operational, and financial importance of the system or systems. This makes perfect sense in an insurance landscape where modern core systems are the table stakes for many of the other innovations and initiatives insurers want and need to take on.

With non-core systems, however, the project teams are not nearly as large and are often disbanded and shifted to higher priority projects just as soon as the non-core system is implemented in production. More often than not the business group is left managing and supporting the system with a skeleton support staff that may not be dedicated to that effort, and may not even include any IT resources.  This often creates a cascade of problems:

• A business group left to their own devices to manage the newly installed system has other day-to-day priorities, and this reality will inevitably slow down the overall adoption and maturation of the new system.
• Modernized non-core systems typically introduce new processes and functions to business areas. To get to production, many customers defer some of these enhancements to hasten the delivery of the new system. That creates a post-production backlog of potential enhancements and features that nobody has the time to investigate.
• That backlog can lead to the system being sub-optimized and therefore unable to deliver the efficiencies it promised. The danger is that since non-core systems generally have a long lifespan, people will just come to accept the system as is, without it reaching its full potential.
• Since neither IT nor the business has the time and resources to maintain the system, insurers will turn to the vendor for that support. This often makes the problem worse. The vendor may, in fact, work diligently to resolve any issues, but without the proper internal attention required to separate technical problems from process problems, many vendors simply adapt the system to incorporate existing bad processes.
• This pretty typical cascade of events often results in an overall negative view of the new non-core system by most involved, and that can lead, quite unfortunately, to the insurer never achieving the potential improvements and innovations in effectiveness and efficiencies that modern systems can bring to any company.

That said, there are a few simple steps that insurers can take to avoid the scenarios above for their non-core systems modernization efforts. Employing a little foresight, insurers should plan at the outset for a temporary allocation of business and IT resources post implementation. These resources should be used to form two small teams—one for routine support (upgrades, patches, performance, etc.) and one for focusing on the process and functional impacts of the new system. Depending on the size of the system and the insurer, they may be as small as 2-3 people per team.

Roles of Support and Impact Teams

While the support team helps to settle the system into production, the impact team should begin the analysis of identifying the process changes that remain, quickly remedying any initial pain points, and prioritizing the enhancements backlog. The impact team can quickly gather the data they need to optimize the system by interviewing new users of the system to identify process opportunities, and by working with the vendor to make sure they’ve fully implemented the latest features of the system. The focus of the impact team is on process improvement first, followed by any technical system changes required to enable the process changes.

One of the biggest benefits of most new systems is the creation and availability of data not previously available. One of the key roles of the impact team is the identification of opportunities where any new data can be put to good use. That’s often in the form of business process improvement and regulatory efficiencies, but there are many other areas where access to new data elements could prove useful and valuable.

Both the impact and support teams should work toward creating a prioritized list of such opportunities. That list should then become part of an ongoing support plan that packages system improvement initiatives into regularly scheduled releases. The releases should be scheduled on a quarterly basis (as opposed to core systems where releases are often deferred for years due to the complexity and the disruption inherent in them) to take advantage of the value of performing incremental improvements on a consistent basis.

Finally, this ongoing support work can be done by a small team, sometimes even ad hoc, that comes together for a couple of weeks each quarter to implement the scheduled release. Resources from the original impact and support teams might be used for this purpose, but it’s not mandatory.

In fact, it’s often the case with non-core systems that after a year or two the system settles in and any functional or technical releases—from the vendor or the insurer—become fewer and farther between. Once any potential enhancements reach the point of diminishing return, many non-core systems can be put into a simple maintain mode until the next modernization cycle begins.

Non-core systems modernization should be an essential part of any insurer’s short and long-term technology plans. With the proper planning and execution, any insurer’s non-core systems should be humming as well as any of their core systems—perhaps even better.

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

Non-Core Insurance System Modernization Matters Too: Part Two – Contracts & Implementation