From product development to underwriting, policy administration and claims management modernization of technology in insurance can make a significant impact across many parts of the organization. Deloitte and McKinsey researches show that the potential benefits of modernization include a reduction in IT costs by 40 percent, increase in operations productivity by 40 percent, and a move to more accurate claims handling; in some cases, reduced churn and increased gross written premiums.
Technology modernization is vital, but—given the significant value at stake and the size of the investment—it should be approached with a healthy dose of caution. Indeed, many insurers miss out on the full benefits of the program for several reasons. First, they don’t have a clear view of what sort of actions are needed or the impact such actions could have, which may lead them to undersell both the business value at stake and what is needed to capture it. Second, many organizations have assumed that a front-end web portal, new-user interface, or new-customer-relationship-management software is all that is needed, only to find that some capabilities (such as rapid product configurations) require modernization of core systems. Third, insurers that do embark on modernization may falsely assume that a platform replacement will be a magic bullet that will solve all their efficiency and data-conversion problems.
To help insurers dispel these misconceptions, we explore a number of myths of tech modernization that many in the insurance industry believe in and provides guidance on how to successfully navigate them.
Myth 1: The business impact of technology modernization is underwhelming
The reality: There are two broad reasons why the business impact of technology modernization may appear insignificant. First, insurers may not aim high enough, embarking on partial or incremental programs that do not tap into the considerable promise of modernization. Consider that numerous duplicate systems within a company’s technology infrastructure are the single biggest source of cost differentials, compared with similar products and operations organizations. In fact, our review of policy and workflow-system consolidations reveals that the operating expenses for companies with many duplicate systems can be three to four times higher than those with just one or two systems. This massive variance is often underestimated in business cases for technology-consolidation programs, which are often approved at a breakeven of five years (the average amount of time that leaders are willing to wait for a positive return on investment).
Second, business growth, retention, and productivity benefits may not be fully factored into the business case during the planning phases of modernization. This is true even when a primary goal of modernizing systems is to enable a competitive customer experience or target new customers through the use of advanced analytics. Although revenue benefits are harder to quantify than changes in operational costs, even a directional estimate of benefits is useful to build buy-in.
How to navigate: To realize the considerable value at stake, insurers need to recognize—and commit to—a wide and transformative program of technology modernization. To justify the expense at the outset, insurers need to articulate the considerable gains in productivity and business impact that technology modernization programs can offer, and their business case should include an attractive ROI. This sets the right tone for the program and will ultimately yield a program that delivers meaningful impact.
For example, one insurance group used standardized business key performance indicators (KPIs) in the early stages of planning technology-modernization programs in its business units. These metrics outlined the target digital-adoption rate, retention uplift, operations productivity level, number of claims per full-time-equivalent employee, and straight-through processing ratio of applications, allowing the organization to draw up its business case and the predicted impact of achieving those goals. In this case, achieving these KPIs would improve customer retention by 5 percent and realize 20 percent in productivity savings.
Focusing on the outcomes and business value first helps teams plot their transformation path and timetable.
Myth 2: Modernization simply means replacing the core platform with the best-in-class option
The reality: Core-platform replacements often have higher up-front investment costs than in-place IT modernization, as they require both software and hardware, experts’ time, and extensive testing. Furthermore, migrating existing policies and their implicit contracts to a new platform is often expensive—these additional costs need to be factored into any decision—and time consuming.
One big reason for high modernization costs is the age and quality of the policy data and rules—poorly maintained policies are expensive to refresh and modernize to work in a new system. Product types and geographic context are also considerations. For instance in Kenya and the United States general policies or personal property and casualty (P&C) policies are generally issued annually and thus have up-to-date policy data and rules; this makes migration efforts more straightforward. By contrast, in countries such as Austria or Germany, policies are refreshed annually to adjust premiums for inflation, but policy data, rules, and terms only change when a customer switches to a new policy—which may not happen for many years. Therefore, policy rules need to be carried over to the target system or customers need to switch to a new policy during modernization, rendering it time consuming.
Life insurance policies are issued for longer periods (often decades) and tend to present even greater legacy-data challenges.
How to navigate: To mitigate the risk of disruption, some organizations might choose to take a hybrid approach: issuing new policies on the new core platform while maintaining existing policies on the legacy platform. However, this can create a period of inefficiency as both platforms will need maintenance and training for operations staff. Technology leaders will need to factor this cost bubble (the increased cost of maintaining assets across two platforms) into their business plan and have a set time frame to either migrate, minimize, or off-load the legacy policies.
In many cases, in-place modernization is significantly less risky than a core-platform replacement—and just as powerful. This is particularly true in the many situations in which existing products and policies are not well documented. The existing system can be divided into similar blocks of policies, with each block updated to deliver the most valuable benefits, with much less risk.
For example, one retirement-services player decided to pursue an in-place upgrade of its legacy platform to the latest vendor-supported version. Once the process was in progress, it started issuing new business on the platform and could then migrate existing blocks from the other record-keeping systems. This approach had less risk than a wholesale replacement, given that much of the operations and rules did not need to change right away.
Myth 3: Using a vendor platform will guarantee access to the latest cloud-based technology
The reality: Many vendor platforms are from the prior generation (such as on-premise, monolithic, or two- or three-tiered client-server architectures) and may be outdated by the time they are implemented. Indeed, many industry-leading vendors must satisfy the needs of large customers with custom solutions. Doing so can force these vendors to invest in bespoke platform solutions rather than pursuing the R&D investments that would otherwise allow them to offer innovations to their customers.
How to navigate: Insurers will need to decide if the latest cloud-based technology matters to them. Is access to innovations such as the latest data analytics and AI services the motivating factor, or is it sufficient to be a fast follower—that is, adopt technology once it has been proven, and stay updated on security patches? Once organizations are clear on their own priorities, they will need to understand the strengths of each vendor’s architecture. How, for example, does the vendor handle multi-tenancy and automatic software updates? Can it integrate into the broader ecosystem of traditional and cloud-based services?
Insurers need to understand whether the system was designed for the cloud or whether it was a lift-and-shift approach to an older platform; that is, the platform was moved to a new system without any accommodating redesign or changes. If vendors did use a lift-and-shift strategy, companies will need to ensure that the system will meet their future business requirements. The frequency of new update releases will also give a sense of the pace of innovation.
For instance, insurers may decide to conduct functional proof-of-concept demos and architecture proofs-of-concepts during vendor selection for a core insurance solution. During such a process, insurers could test the integration of a vendor’s application programming interface (API) with the customer front end to ensure feasibility and highlight possible challenges. In cases where complications arise—such as when the integration requires building effort-intensive API translation services in an enterprise service bus (ESB) —the process can be evaluated and the findings used to develop a much more robust and realistic implementation plan.
Myth 4: A vendor package will give us prescriptive guidance on how to modernize our business processes
The reality: Most vendor platforms use frameworks that suggest best practices for managing products and business processes, but they don’t necessarily deliver a template for a fully configured and coherent business model. These platforms were likely developed for specific customers, and their functionality expanded over time.
How to navigate: The best vendor platforms clearly configure and explain the parameters of their products and workflows rather than customizing their system for every customer. These platforms can accommodate business processes without compromising the insurers’ ability to upgrade their core systems. Furthermore, business users can apply no-code or low-code approaches to directly configure business processes without IT involvement, though these platforms are still relatively immature and should be thoroughly tested to handle realistic production volumes and use cases.
Insurers could look for vendor platforms that come with level-five specificity for typical business processes. For example, a new system designed to administer policies could define or standardize process steps for common transactions (such as policy issuance, loan approval, and disbursement) and have parameters that allow dynamic adjustment (such as loan interest rates based on market conditions). Existing processes like this can be reverse engineered and tailored to an organization’s needs; processes not already in place should be planned appropriately for the time it will take to configure the system.
Myth 5: A simple one-size-fits-all technology solution to our ‘spaghetti integration’ challenge already exists
The reality: Although it may seem that the latest integration technology can solve the problem of “spaghetti integration,” the truth is that there is no silver bullet. The introduction of new integration patterns—from point-to-point integrations to ESBs and now to API-based patterns—should simplify the architecture landscape. Yet doing so is not always straightforward. Many insurers, for example, will implement an ESB to replace the spaghetti mess caused by point-to-point integration. However, an ESB introduces an extra communication layer (the “bus”), which can increase latency and become a single point of failure.
Similarly, some enterprises have recently fragmented their systems into hundreds of reusable micro-services, but this level of complication can quickly become unmanageable if micro-services have overlapping functionality and data.
How to navigate: When modernizing legacy systems with a history of spaghetti integrations, IT organizations will likely need to employ a mix of approaches. ESBs are useful, for example, in situations where a heavyweight solution is needed to connect incompatible legacy systems, such as an enterprise resource planning (ERP) system or a mainframe. These tools are designed to support many data fields and handle complex logic. However, they should be used in conjunction with lighter-weight APIs (particularly those that require fewer information fields and data exchanges compared with a typical API) and through judicious use of point-to-point integrations.
Myth 6: It is always best to use industry-standard data schema
The reality: Decades of policy changes mean that legacy platforms and data are not easily mapped to industry-standard data schema. Either the Financial Services Logical Data Model or ACORD insurance standards can serve as a starting point when defining a data model, but the guidelines will need to be tailored and governed based on an individual insurer’s products, customers, and financial-data domains and definitions.
Some insurers may use the target platform’s data schema instead of an industry standard, as this can simplify and speed up modernization in the short term. This approach can be problematic, however, if the target platform schema is not well suited for integration or uses enterprise-wide standards like data warehouses or lakes.
How to navigate: Insurers should align their target product portfolio with the industry standard schema, extensively profiling legacy data sources to minimize the number of iterations to the final schema.
An alternative approach is to use the target system’s data schema. Although this method has its drawbacks in terms of potential lock-in to a target system (given the schema might be proprietary), it could be a more straightforward option since the schema has already been tested and mapped against the corresponding business processes in the relevant insurance domain.
Myth 7: Going from legacy to cloud-based platforms will reduce IT cost
The reality: Savings often materialize only from app or platform rationalization and not from the cloud-based platform per se. In fact, the cloud can be more expensive. We have observed many situations in which initial excitement over the cloud is replaced by surprise when the monthly bill comes. A lift-and-shift approach to the cloud, for instance, can add more complexity and lead to higher data egress and software-licensing charges, which cancel out any per-unit cost efficiencies on storage and computing. In addition, cloud platforms often come at a higher level of service quality than legacy systems, thus significantly improving IT stability but increasing cost.
A mature cloud-based system provides two fundamental sources of value: instant access to infinite scalability and speed of change through software (for example, quickly releasing new features). Building on these sources of value, we estimate that for every KES 110,210,000 ($1 million) of IT budget, the total potential value from cloud-based modernization is KES 27,552,500 ($250,000), split among business acceleration (about 25 percent), app development and maintenance productivity (about 50 percent), and infrastructure efficiency (about 25 percent).
How to navigate: Insurers need to think comprehensively about the business case of moving to a cloud-based platform. We find that the benefits of business acceleration and development productivity often dwarf the infrastructure cost. Furthermore, the off-book benefits of increased operational stability and reduced risk are often just as important as the cost savings, if not more so. By having a clear, realistic understanding of both the desired outcomes and what a cloud platform can (and cannot) achieve, insurers can make an informed decision about whether to invest in migrating to a public cloud-based platform.
Technology leadership at one insurer decided to update the infrastructure operating model in the company’s on-site data center, postponing a cloud migration to do so. This transformation established a cloud-like operating model (that is, the infrastructure teams engineer highly automated products and services that are consumable by application teams, in the same way that application teams consume public-cloud services) within the existing infrastructure team and realized significant savings without requiring the team to make the much bigger investment of migrating to the cloud.
Myth 8: Micro-services will make architecture agile and digitally savvy
The reality: In some cases, such as with core ERP functionality, the scope of an enterprise-wide system or business capability is not easily broken down into micro-capabilities. Forcing micro-services into these situations may result in increased complexity in an insurer’s architecture as teams create hundreds of overlapping services.
How to navigate: Given that each service needs to own its data and be sufficiently autonomous, insurers will need to carefully evaluate whether re-architecting an existing system into a micro-service is feasible. For example, insurance applications such as claims applications can be decomposed into a set of micro-services such as “update policy info,” “authenticate customer identity,” “get claims info,” and “auto-adjudicate claims decision”; all of these services should be designed to be interchangeable and autonomous. They can be developed in different languages and interact over lightweight APIs. Dedicated ownership of each micro-service by a product team can ensure a “you build it, you own it” mentality, leading to continuous improvement over time. As these new micro-services are built, previous integrations are rationalized to simplify the portfolio.
It is a business imperative that insurers get technology modernization right, but both the value at stake and the risk of failure are commonly underappreciated or misunderstood. By understanding these ten myths, insurers can start (or reset) their programs with a solid, realistic understanding of how and where technology can add real value.
