A practical guide to superior performance: Focusing on the portal and policy administration

Insurers would be wise to understand and consider all available options before making significant decisions about upgrading, replacing, or integrating systems. There are many approaches to modernizing an application portfolio. Particularly for the individual life segment of the industry, converting an entire book of business can be prohibitively expensive. Since some blocks of business can be substantially more expensive to convert, it is best to consider the appropriate options not as a whole, but on a block-by-block basis to potentially develop a multi-option, cost-effective solution that bolsters the firm’s strategic aspirations. Unfortunately, many third-party vendors and consultants don’t have a full grasp of the challenges facing insurers across the portfolio. They lack practical experience in business transformation, or cannot help to implement systems and processes across the enterprise. Whatever the reason, many vendors aren’t giving insurance companies the whole story.

To fully benefit from modernization, an insurer must understand all of the available options – including their strengths and weaknesses – in order to select the right one (or the right combination of options). Those options (which many vendors and consultants may not fully understand, offer, or otherwise share) include:

• New modern platform option

System replacement may only solve part of your problem. It is by far the most common step recommended by vendors, but insurers seldom hear all the facts about the potential costs and impact on the current environment.

For policy administration systems, for example, a replacement system may be implemented for new products only, and the older systems retained or outsourced. Another common strategy is to replace and convert the older in-force blocks into the new system. The benefits of system replacement can be significant – the ability to deploy new products or functional capabilities, the ability to provide web-enabled producer/customer self-service, and the ability to reduce the complexity of existing business processes, to name a few.

However, adding a new policy administration system without retiring another makes the system environment more complicated because it is a new application that must be maintained. Long-term plans for managing or retiring existing systems, including the costs of conversion and infrastructure, must be included in the business case for the new system. While it is the ideal approach in a vacuum, system replacement and consolidation may be impractical for various reasons:

• No credible vendor package is available
• There is no business mandate to support large-scale change (or willingness to compromise on requirements)
• The functional gap between systems is too significant
• The cost of replacement is too high for the size of the company

It is strongly advised not to customize the new platform at all if possible, and no more than is absolutely necessary. Most vendors don’t mind if you want to customize their software if it means more services revenue and possibly more retrofitting work down the road at upgrade time, so they may not stop you from customizing even though you shouldn’t. Historically, most carriers purchased an administration platform and customized the source code for their specific requirements, or they simply patched an older version of the system to meet new business needs, such as new regulatory requirements.

Customization can be a way to add new functions and fix problems faster than keeping the system updated to the most current release. However, this creates long-term consequences as it is not uncommon for some carriers to have modified as much as half of the original source code over the years to meet their custom requirements. What saves in the short term almost always costs more over time, and when carriers must update that old release, they must deal with a plethora of custom in-house modifications that can be expensive to retrofit. So, be wary of this strategy.

Whether the target system is one of the existing systems used for the administration of closed blocks or in this case a new, modern system, some data conversion considerations are available to simplify conversion.

• Conversion with system modifications: This is the default, and the costliest plan – not only is all of the data migrated for all products, but all the functions available in the source systems are supported in the target systems. This often requires some level of modification and/or enhancement to the target system(s), especially if you are trying to recreate functionality for products that haven’t been sold for 30+ years.
• Fully converted data: This is the default option for data All data supported by the target system is transformed , including all of the required historical data, and normalizing the data structures if the target system requires it. It does not assume you need to be able to automatically re-create transactions in the past; rather it just ensures that all of the data is stored in one system and that manual transactions can be done on closed blocks if needed.

Conversion with data modifications: It is not always a given that all data supported in the target system needs to be provided in the conversion. In this approach, the full functionality is not migrated, and since the target system may possibly provide storage for extensive historical data that is not available in the source system (e.g., it may have more fields than the source system), it may be worth considering converting to the source system with limited historical data. Should a transaction be performed on the converted policy that requires the historical data, some level of manual processing and access to non-converted data will be required. The need for – and the support of – such processes should be recognized and included within the conversion plan.

In many cases, full conversion is not done, and one or more of the options below are used instead of or alongside these conversion approaches. As noted previously, sometimes a new platform is used only for go-forward business and no conversion is done at all. Accordingly, analyzing each block of business and making a decision early on is critical.

One final option for getting new products out to the market quickly is to leverage a third-party administrator (TPA) with a modern platform. This allows an insurer to get up and running on a modern platform quickly while also taking advantage of the shared resources of a TPA to get operations for the new product up and running quickly.

• Refurbish or wrap/extend:

While it’s difficult to believe this is still an option for consideration in the 2020 decade, portfolios based on outdated products with complicated features may simply not be serviceable on a modern platform at a reasonable cost, or the conversion cost may simply be prohibitive. Rebuilding a home grown or legacy vendor solution is often not plausible, as it can require extensive and expensive efforts to recreate the functionality, business rules, etc. The process of rediscovering an application’s business requirements and redeveloping it from the ground up may only be practical for specialized, proprietary applications, and even then is likely unrealistic. It probably makes more sense to look for a configurable software package that can perform the needed functions. Unfortunately, many insurers over the years have tried to rebuild their core applications and failed.

Recently, wrap-and-extend has become a more viable options, with a handful of solutions becoming available that offer an approach of “everything but the core.” These solutions aim to replace essentially all functionality of a core systems suite except for policy processing/transaction processing, but in a modular approach that allows you to wrap-and-extend wherever pain points exist. This “hollow the core” approach can minimize dependence on the legacy platform and make it easier to migrate away from the legacy platform later.

If the alternatives are simply impossible, rather than rebuild a homegrown or legacy platform, insurers should look to embrace “legacy revitalization,” in which the code is simply refactored, moved to a lower cost platform (e.g., the cloud), and wrapped with modern components, APIs, and/or web services to provide a serviceable platform without the costs of conversion and rebuilding. This is far from a preferred solution but may at times be necessary.

In today’s environment, with technologies and standards changing every 18 months, the prospect of a multi-year development project, with multiple iterations of testing and performance tuning, is too overwhelming for most IT departments even to consider. While the build-it-in-house option used to be foremost on IT department agendas, few if any companies today seriously consider rebuilding a legacy policy admin system.

• Run-off option:

Sometimes it’s okay to do nothing for select blocks. Typically, 80% of the cost of a conversion comes from 20% of the policies. As a result, it may not make sense to move that remaining 20%. Depending on the application and its organizational function, the best strategy may be to leave the legacy application in place for those policies and focus on reducing maintenance costs (which may be more plausible once the platform is supporting a much smaller block of business). Systems supporting small blocks of business in run-off or even larger non-strategic closed blocks that could be packaged and sold are potential candidates for system retention. Remember, though, that retained systems contribute to ongoing costs, requiring specialized teams to maintain and use, though this may be a lesser issue in cases where other applications continue to reside on the mainframe anyway. At a time when most insurers have moved or are starting to move to shared services organizations, these pockets of specialization could prevent both IT and back-office managers from achieving full value from internal consolidation efforts. This needs to be carefully weighed against the cost and risk of full conversion.

In general, it is best for a carrier to adopt a plan to retire its legacy systems – and stick to it. Most software vendors are more concerned with selling new systems than helping to retire old ones. It takes effort and dollars to move policies off the old system, archive the legacy application’s data, and decommission supporting infrastructure. It can be a challenging project because of the lack of documentation or data – or both – but the more legacy applications retired, the higher the cost savings are from ongoing maintenance of hardware and software. This helps insurers meaningfully shift their IT spending to more business-focused initiatives rather than “keeping the lights on.”

Moreover, companies can manage operations more effectively with common technologies and processes. For legacy policy admin systems, the system can only be retired after all in-force blocks are converted to another system. When you accomplish this, you no longer face cross-training employees on multiple applications, and, as long-time employees retire, IT programs won’t need replacements with skills in older technologies.

• Alternative options: Divestiture (sell the block), ITO/BPO/TPA, policy exchange:

The divestiture option is perhaps the simplest. It involves selling a closed block of business and all its assets and liabilities to another business entity. Clearly, this approach relieves the enterprise of the need to operate any system to support the closed block. Conversely, all the business value of the portfolio, other than the purchase price, is also lost to the enterprise. If a block of business is not strategic and the conversion cost is prohibitive, this may be a viable option.

Alternatively, it may be time to outsource systems (ITO), processes (BPO), or both (TPA). This could include a “lift and shift” ITO approach, which is typically provided by an outsourcing vendor to manage the application for a predictable cost on a long-term basis (sometimes cynically referred to as “your mess for less”). Outsourcing technology enables organizations to refocus resources on IT activities that support the core business while leveraging third-party expertise and efficiency. Historically, this strategy came with a limited set of options. More recently, however, as systems have become more component-based – and as APIs and web services/microservices have become more prevalent – IT outsourcing can be effectively applied to much smaller pieces of the business. For instance, outsourcing can be used to support application development, maintenance, and infrastructure.

Similarly, discrete business processes can be outsourced (BPO), such as customer billing, printing, and mailing. As with ITO, this can help a carrier focus its resources on high growth or otherwise strategic areas. Consequently, interest is high in outsourcing legacy blocks through business process outsourcing (BPO) and application management. In some cases where the conversion costs may not be prohibitive but a line of business is not strategic, carriers may elect to leverage a third party administrator (TPA), opting to convert a block of business over to a TPA’s system, where the TPA then runs both the core systems and some or all of the business processes for the insurer.

It may also be possible to simplify the conversion problem by exchanging policies for a more straightforward, easily administered product. If the exchange does not disadvantage the policyholder, such exchanges may be legal.

• Upgrade or consolidate option:

It may be possible to upgrade a vendor package solution instead of “ripping and replacing” it. For companies with vendor-supported applications, upgrading to the latest version is a common strategy for modernization. While this may leave you on legacy infrastructure, some vendors of older platforms have continued to make improvements such as adding APIs, shortening batch windows, or other key changes. In some cases, vendors have even refactored their codebase (e.g., from COBOL to .NET or Java) to allow migration away from mainframe/midrange infrastructure. However, typically there have been few (if any) vendors that have fundamentally migrated their platforms from legacy to a truly modern, configurable one. Unfortunately, many insurance companies also wait too long to take advantage of their vendor’s modernization program. In addition, many vendor applications have come and gone over the decades, leaving insurers with unsupported applications and no migration path to a new system.

Where there is still an upgrade path available, thanks to years of missed upgrades, organizations often face a major licensing decision and/or complete system replacement instead of a series of routine upgrades. Equally challenging is that by the time insurers decide to consider an upgrade, they are often challenged by their penchant for revising and customizing the vendor’s code. Too much customization makes it difficult for companies to port these changes to the latest version of the software. Once two or three opportunities to upgrade are missed, the vendor system essentially becomes another legacy system maintained by the company’s IT department. As with the other approaches, insurers must weigh the costs and benefits of a continuous upgrade program against those associated with a big-bang upgrade or complete system replacement.

Consider converting your policies to a strategic in-house platform. While converting onto a modern platform is ideal, one of the next best responses may be to rationalize additional platforms and custom solutions that have come into the enterprise through mergers and acquisitions by converting the business onto a single in-house platform. Consolidating to an existing strategic system that can carry the merged business into the future may not achieve many of the business benefits of modernization, but it can potentially achieve many of the cost reduction benefits. This approach preserves the investment in company-specific system functionality while increasing the in-force policy volumes on the strategic, in-house platform. So, choosing a target platform with proven scalability is critical. Conversions  will often have high up-front costs, but their long-term benefits can be equally substantial. The articulation of a good cost-reduction case is a critical success factor.

Before going this route, insurers should seriously consider first undertaking the “legacy revitalization” options noted earlier (for home-grown solutions) or the upgrade approach discussed earlier in this section. These can help further reduce costs and/or risks and improve the longevity of the strategic solution.

• Modularization option:

One extension to the wrap-and-extend approach is modularization. System integration using web services and APIs is a substantial step in the right direction, but it is no silver bullet. To support complex systems environments, many insurance companies have attempted to service-enable their policy administration systems and add or replace components. Vendors are quick to recommend modular, externalized systems such as rating, billing, and claims that can be interfaced with legacy systems through a service-oriented architecture (SOA).

For this strategy, monolithic applications are partitioned off, allowing portions of the functionality to be externalized. A fully component-based system would, in theory, allow users to mix-and-match components as needed. This flexibility comes at a price, though, as the number of interface points increases. Therefore, clean component boundaries are imperative. As a matter of practice, the carrier often turns off or bypasses functionality in the old system in favor of a new dedicated application component for handling functions, such as new business or distribution management. Wrapping is a common strategy with predictable costs and well-tested patterns.

One common approach is to wrap systems with a common user-interface – often in the form of a portal – which masks the quirks of each system from the user. More recently, the focus has been on wrapping systems with service layers that let them plug into service buses (which can then be accessed by, for example, a portal); this architecture promotes reuse and high-level process assembly. This strategy makes sense for companies seeking short-term improvements to specific processes affected by several legacy applications.

Customer service and claims are prime areas of the enterprise that can benefit from this approach, which can enable the IT staff to be more responsive to the business. However, if legacy systems have fundamental technology issues or they can be converted and decommissioned in a relatively short period, a modular approach featuring wrapping may not be practical. While many organizations view SOA as a silver bullet for integration woes, it doesn’t eliminate the underlying legacy system complexity, drag on costs, or achieving business agility.

This blog was co-authored with Lawrence Krasner. To continue this conversation, connect with Lawrence or me on social media.

Also, you can e-mail to insurance@capgemini.com

Chad Hersh

Expert in Financial Services, Healthcare, Insurance

I lead the strategy and growth of Capgemini’s North American L&A/Group Benefits business, helping insurers transform across their businesses, from core systems to digital, and from data to AI.
Previously I led a division of a leading insurance software vendor. Prior to that, I was a Managing Director of an insurance-focused industry analyst firm. My research focused on core insurance systems strategies for insurers as well as emerging technologies. I authored reports on trends and vendors of core systems. I have written and presented extensively on the importance of selecting the right solutions for replacement. I have also served as an e-business Director for a large, global, multi-line insurer.
My consulting work includes helping insurance carriers select the right policy administration system for their needs and developing transformation and risk mitigation strategies for implementation.