Transforming the claims landscape

With cost cutting becoming ever more important in every area of the insurance industry, claims departments are racking their brains in order to save money. Yet, with finances tight, how can insurers overhaul outdated systems while meeting their budgets? Andy Jones explains

As claims departments face burdening pressure to reduce claims costs, it is no wonder that there is a growing acknowledgement that this is only achievable through a complete overhaul of the claims process itself. This need for 'claims transformation', already much mooted among the insurance community, has become no longer a 'nice to do', but a 'have to do'.

And, while it would be impossible in pretty much any business debate to ignore the impact of today's unprecedented economic climate that is naturally, and rightly, dominating most boardroom time currently, it is vital that insurers don't let this distract from the need to provide for long-term sustainability and, indeed, to unlock the profitability that resides within claims.

Claims processes need to be underpinned by a technology landscape that will ultimately, and drastically, improve the customer experience and release greater profit. To achieve this, the infrastructure must be inherently rich in many things.

It must be agile enough to be readily adaptable to satisfy future business and customer demands; it needs to join up the gaps in what is generally a fragmented supply chain; it needs to provide more meaningful business intelligence and management information than is currently available and, perhaps the most fundamental of all, be built on a platform that is more than likely to be fully Web 2.0 enabled.

The applications themselves will permit, for instance, more effective and faster workflow, better automation with third parties, and greater collaboration with customers and suppliers of goods and services in the supply chain. All of this is tied together with vastly improved management information to direct and guide the overall process.

Reviewing the technology that lies behind many claims processes today generally highlights a clutter of stuff that has been amassed over the years, with each component having a story to tell and a role to play and yet ending up in a spaghetti junction of applications where the whole is not greater than the sum of the parts. For instance, in some cases, claims processes may be relying on 25-year-old core systems, which have been changed and maintained to the point of becoming arthritic.

Spring clean

Cost, risk, agility and compliance are all affected by the impact caused by such prolific IT acquisition over time and, in the claims environment, where the end-to-end supply chain is so complex and touches on so many parties, this clutter is stifling the process to the point where, unless it is drastically altered, it will see insurers' claims management costs continue to stick at unacceptable levels.

With an urgency to reduce indemnity costs, risk exposure and cycle times, there's a chasm between the utopia that claims transformation promises and the legacy world of today.

From a technology perspective, there are two basic strategies - to buy (or build) the end-to-end 'killer' claims application and sweep away the existing legacy systems that currently support the claims process, or to engage in a piece by piece re-engineering effort to renovate what you already have and, where needed, bolster this with new components to fill any gaps. In today's economic circumstances, a lack of available cash and a lack of tolerance for large scale IT adventures will tend to mandate the second more incremental approach. This takes us into the territory of what is frequently called 'legacy transformation'.

Transformation can be distilled into eight 'levers' that can prompt analysis or question a particular strategic direction (see box). Whether, how or when to use each lever and the combination of them is what then underpins the legacy transformation roadmap for a company.

So where does a company start with its transformation? A few assertions should help to set expectations. For instance: this will be a multi-year task; there will be no quick fix (rip-and-replace was meant to be the quick fix, too often it proved neither a fix nor quick); it will take time to plot the course that will work - "start slow, finish fast" is as true in legacy transformation as anywhere; every firm's situation is likely to be different and so therefore will the route ahead; and a company will probably need to consider every tactic, and strategy, open to it in order to blend the different options together into a routemap that will represent the first critical success factor.

In an ideal world a routemap will comprise a number a short initiatives, each with its own payback, with earlier initiatives funding later ones. In the real world, based on our experiences, we have found the notion of agreeing an 'overdraft' between the legacy transformation programme and the organisation can help. Here, the programme can borrow up to its overdraft to fund the investments needed, but will need to pay this back through savings achieved if further initiatives are to be undertaken.

Finish what you started

Another critical success factor is the tenacity to see the transformation through. Devise the plan, work the plan, revise the plan when needed and go for it.

So how should a company apply this to claims transformation specifically?

First, it will need to consider whether or not its system for recording claims is competent and, if the company has many systems, whether or not it can consolidate them down to one if at all possible, regardless of whether the end-to-end process support is deficient as this can be dealt with by adding new components.

If the company is facing a situation where it needs to contemplate sweeping away its legacy it may need to replace it wholesale. This is unlikely, but it may be tempting to imagine this is the case as a justification for the big bang claims projects.

Companies also need to decide where it may have functional gaps in the support of its end-to-end process? Most frequently these relate to workflow, business process management and supply chain management. As such it needs to ask itself what are its immediate priorities? What can wait? What can it reuse? What does it need to buy?

Another issue to be considered is how will the company integrate its selected components. Typically, this is done through a service-oriented architecture, though more tactical approaches may be selected, at least in the short term. Alternatively, problems may be able to be fixed by code re-engineering or re-writing, or by changing the hardware platform from mainframe to Unix, for example.

The outsourcing of infrastructure or applications management may also be considered to save costs, especially if a company is able to use the savings to fund at least part of the claims transformation strategy?

It is also important to put claims transformation in the context of, not just of how things are being done today but, increasingly, how the growing sophistication of technology and its entrenchment in our every day lives is determining how business is conducted.

The importance of Web 2.0 in claims transformation should not be underestimated. Web 2.0 is coming into its own as IT is becoming more 'consumerised'. This consumerisation of IT is an area that is been investigated closely and is the term given to the sort of IT many people use daily in their personal lives whether it is web searches, email, Wikis, blogs, social networks, tagging, sharing (for example Flickr). In many instances, people do not even think of this as technology per se, but of course it is. Often the use of and access to these are free. But, more remarkably perhaps, they give the public better capabilities and user experiences than they are used to in the workplace.

Claim to fame

So why is this important when addressing claims transformation? How can this consumerised IT be applied be help insurers manage claims better?

Think about how a capability like Flickr could be used to allow a photograph of damage to a vehicle to be shared at no cost with a loss adjuster working remotely? And how might the insurance industry use any of the range of collaboration tools to share information and truly collaborate, in real time, both across the supply chain and with claimants? And what about the expectations set by consumers? If they're used to using all of these applications daily, they are sure to demand similar levels of experience with their insurers.

It's early days - and much too early to claim that everyone will be transacting business tomorrow on free-to-use public infrastructures - but imagine a world where blogs, wikis, instant messaging and mash-ups (an application that combines data from more than one source) are integrated into the claims process. The opportunity for improved collaboration with people in the supply chain and the claimant is there to reduce claims cycle times and take customer service up to another level. And it is pretty straightforward to grasp how this will extract more profit from the claims process.

Of course, little of this is likely to be much use to anyone if they are still burdened by a clumsy IT legacy infrastructure. So, by transforming the legacy, firms will have every reason to look forward to thriving in the new adapting claims operating model.

- Andy Jones, associate partner, financial services consulting, CSC.


1. Consolidate: pick a legacy system as the target to convert others onto

2. Replace: build or buy a new application and convert to this

3. Componentise: remove functionality from existing applications and delegate to some common components

4. Wrap: reuse functionality from existing applications by wrapping them through techniques such as service-oriented architecture (SOA)

5. Renovate: fix problem areas in a system through, probably, manual code re-engineering

6. Re-write: convert from legacy language to something more relevant such as Java, using a combination of manual and automatic techniques

7. Replatform: change the hardware platform from, say, mainframe to Unix

8. Outsource: delegate responsibility to a third party

  • LinkedIn  
  • Save this article
  • Print this page  

You need to sign in to use this feature. If you don’t have an Insurance Post account, please register for a trial.

Sign in
You are currently on corporate access.

To use this feature you will need an individual account. If you have one already please sign in.

Sign in.

Alternatively you can request an indvidual account here: