In this series of blogs, my colleagues and I will look at the insurance sector in Growth Markets, with a particular focus on technology, digitisation, platforms and ecosystems.

Life and P&C insurers share similar drivers in their need to modernise core systems. After all, they face many of the same challenges, including digitalisation, the rise of platform competitors, changing customer expectations and the need for online servicing.

Life insurers, though, face unique challenges when it comes to modernising core platforms. As a result, their choices are more complex, while the ways in which they can implement the necessary changes also differ.

Awash in paper and old code

In large part, differences stem from the time factor: life insurers’ products cover far longer periods – decades for retirement products versus a year for car insurance, for instance. In addition, products are more likely to be held on antiquated systems. And there are different rules for different products, which complicates any solution.

On top of this, even if the insurer knows the product rules, migrating policies to a new system is a complex and risky exercise. Some of my clients hold tens of millions of policies. Extracting these from old systems and moving them to a new one that has a very stringent set of data rules is a logistical nightmare. And unlike for P&C insurers, there are very few compelling off-the-shelf software solutions – though Accenture’s Life Insurance Platform (ALIP) is an exception to that rule.

The complexity increases because life insurers need to resolve data conversion. That’s a challenge because the old systems’ data rules have typically been long forgotten, while any experts maintaining them are nearing retirement.

That goes some way to explaining why many life insurers haven’t acted. It’s not that they don’t want to; after all, no CIO wants to be responsible for a dozen inefficient systems that are costly, run badly and written in a language that few people can maintain. It’s because taking action isn’t easy. If it were, life insurers would have done so years ago.

Many life insurers, therefore, are in a similar position: operating numerous separate systems at great cost and with limited efficiency. Unable to migrate policies from old systems, they’ve simply accepted that they need to keep all of them running. One client in France, for instance, had 17 separate life systems.

The decoupling lifeline

There are four strategies open to life insurers looking to change their core systems, with the best option dependent upon carrier strategy, technology stacks and product types. Let’s look at the first three:

  • Replace: this typically involves using a cloud-based platform and SaaS, and is best suited for standard product-types in large geographies. As noted above, one fundamental challenge is converting old policies.
  • Re-platform: the legacy core platform is ported from mainframes to the cloud, with conversion factories converting, say, COBOL to Java. However, in practice, a poorly developed execution in COBOL becomes a poorly developed execution in Java, which means this doesn’t deliver flexibility and the need for a truly digital architecture.
  • Retire: aspects of the system are put in run-off mode and core functions are reduced. This typically isn’t of great use for life insurers.

It’s at this point that life insurer clients often ask: Well, what can we do?

The answer is to rearchitect. This involves digitally decoupling and hollowing the core. I’ll go into this topic in much greater detail in an upcoming blog series, but briefly this approach sees the insurer develop a strategy that gradually replaces the system’s functions and reduces the scope of the applications used. This brings flexibility, improved time to market, and better journeys for digital distributors and customer journeys.

Click/tap to view larger image.

As the diagram shows, life insurers have a couple of options when it comes to defining the right decoupling strategy. In both cases, they remove business rules from front-end and back-end systems to avoid duplication, and hollow the core of the legacy system by using APIs and microservices to run processes. Strategy B differs by incorporating real-time access to a data lake to ensure instant updating and processing.

(It’s worth stating that a decoupling approach is usually less applicable to P&C insurers, because their products have a short timeline, and they can more readily choose from numerous replacement software options.)

For life insurers dealing with multi-year products and a lack of software alternatives, decoupling is typically the best approach – as one of my clients in Asia found. This client had multiple group life systems and highly complex policies, and it couldn’t process information in real-time.

We helped the client to roll out a decoupling strategy progressively across every country it operates in. Crucially, this meant changing the company’s culture so that it could implement agile development methodologies. This ensured that local operations in each country could go their own way, yet they still operated under the decoupling template.

Today, this client has an extremely efficient system that develops new products quickly and updates information for customers and operations in real-time. (The backend system updates on a delayed basis, but that has no impact on what the customer sees or on the insurer’s operations.) With this in place, it can leverage its agility and digital architecture in all its markets, putting it far ahead of the competition.

Having a responsive, digital platform places both life and P&C insurers in an excellent position to seek out partners and expand their customer base. As we’ll see in my next blog, partnering brings both opportunities and challenges.



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here