Close Close
Sign In
Newsletters
Popular Financial Topics Discover relevant content from across the suite of ALM legal publications From the Industry More content from ThinkAdvisor and select sponsors Investment Advisor Issue Gallery Read digital editions of Investment Advisor Magazine Tax Facts Get clear, current, and reliable answers to pressing tax questions
Luminaries Awards
Podcast Center Video Center Webcasts Resource Center Events
About ThinkAdvisor Contact Us Advertise With Us Asset & Logo Licensing Sitemap Terms of Service Privacy Policy Copyright © 2024 ALM Global, LLC. All Rights Reserved.
ThinkAdvisor

Practice Management > Building Your Business

Legacy Systems Add To Insurer Costs In World Of Thin Margins

By Lisa S. Howard

X
Your article was successfully shared with the contacts you provided.

Legacy Systems Add To Insurer Costs In World Of Thin Margins

London Editor

As margins increasingly are squeezed in the insurance industry, company management is looking to rationalization of legacy systems as one area to cut costs, according to industry experts.

“We have seen an increased interest and focus on rationalization among our clients over the last year or two, and thats largely being driven by the intense cost focus within the insurance industry as a whole,” says Nick Meikle, senior manager with Accentures insurance practice in Manchester, England.

A stagnant equity market, increasing regulatory costs and the spate of mergers and acquisitions over the last five years have acted to put pressure on organizations to look at how they can simplify their IT architecture, he says. “In a world where you have great investment returns and growing business, you dont tend to focus on cost control as much. Were not in that world today.”

Global economic conditions, overcapacity and thin margins have created pressures for the insurance industry that can be addressed, in part, by improvements in IT, says Colin Rickard, senior consultant with Kognitio, a system integrator based in High Wycomb, England. A lot of the mergers and acquisitions over the last five to seven years have been completed to bring economies of scale, but then mergers create their own problems with efficiencies, he says.

Mergers have driven a lot of the projects to rationalize IT architecture and legacy systems, says Meikle. “There are many companies that have not just merged, but they are mergers of companies that previously merged,” he says. “So you have this cascade effect.”

In the United Kingdom, he says, insurers that have merged may have done some rebranding and some cosmetic IT rationalization by putting wrapper systems around old legacy systems. “But many really havent attacked the underlying number of legacy systems in their companies.”

Rickard notes that as a result of mergers, there have been instances where customers phone a call center and are asked which company their product is with: company A, B or C?

“The reason for that is that the insurer merged with these three companies a long time ago, but operationally it hasnt merged and hasnt conducted a platform rationalization,” he explains. “As a result, it isnt able to present a single new brand to the market.”

A group thats the product of mergers between three insurers that had four IT systems may now have 12 systems, although it probably needs only four, Rickard says. It is expensive for the company because an enormous amount of people, machinery and maintenance is required to run multiple systems, he says, adding that it is also bad customer relationship management because “you cant present a single face to your client base.”

As a result of these costs, a number of insurers have been forced by economic pressures to embark in platform rationalization of their legacy systems, he explains.

Meikle says there are two broad schools of thought about solutions to the problem of legacy systems.

Some companies will rationalize their existing systems down to a smaller number of systems–to three main policy engines from 12, for example. “Then they choose the one thats best suited and collapse the other two systems on to that one system.”

Another solution is to get a newer, leaner system and install it into the organization for new business, and then migrate the legacy systems on to that new platform, Meikle says.

Meikle explains that if a company has three main policy engines and they all have problems that are substantial and enduring, then a company may decide to “clear the decks and move on to something new.”

If, however, one of those systems is sustainable in the medium term, the company may decide to rationalize the other systems into the single viable system, he says.

The other possibility is to go from three to one and then one to a new one, he adds, noting that there are different routes a company can take.

In discussing the pitfalls of IT rationalization, Meikle says that some involve the generic problems of any big IT project or change programdoing it on time, doing it to schedule, doing it to quality and managing the risk.

“These are big programs and they need a lot of focus from both your technology and your business operations to get them to work,” Meikle says.

So the challenge for a company is to find a way to focus on data rationalization while it undertakes strategic changes in launching new products and new capabilities, he said. “Theres a real conflict in there, which is difficult to reconcile.”

As a result, he says, the organization must be committed to updating legacy systems. “The companies I know that have been the most successful at significant and radical rationalization have prioritized it very high on the strategic agenda” and realize it would be extremely difficult to undertake another change program at the same time because rationalization is their number one objective, he says. “Now if the company has spare capacity, it may contemplate doing other projects, but that requires a lot of commitment from very senior people in the organization.”

Meikle emphasizes that the IT department wont be able drive such a project. “It needs to be a business-driven change with an executive buy-in and commitment to prioritize rationalization above other things,” he says. “The IT department may sponsor it, but without the serious buy-in from management, youll always struggle to get them to buy into why you cannot do all the other functional and strategic changes they want at the same time.”

Meikle says that implementation is tricky with major rationalization because the company is making a very fundamental surgical change at the heart of the organization. “Again, if you tackle it purely as a technology project, youre going to miss a lot of activities. Youre going to miss the business training issue, youre going to miss the process issues, youre going to miss the reconciliation and the audit requirements.”

This isnt a technology project, he says. “Its a major business change project.” He explains that the companys end users in call centers or in operational centers or branch network will be going from working on perhaps three legacy systems to one.

“So all those processes need to be looked at to change in parallel with technology,” Meikle says. “This project requires a holistic change that sits significantly outside of the IT department.”

“If youre reconciling little systems that sit around the side, it might only hit one or two departments, but if youre really tackling the core, the heart of your business, everyone who touches those systems is going to be affected,” he says.

On a more micro-level, Meikle says, there are often problems that develop around detail knowledge, or the level of knowledge that some companies have about their legacy systems.

“What youll often find is, when systems have been in place for 20 or 30 years and theyve grown over time, there are actually comparatively few people who really understand these things cradle to grave,” he says. “You will find that typically when you get into the real deep bowels of some of these older systems, youre reliant on a small number of critical individuals who understand how this thing is hanging together,” he adds.

“There may be some bits of your systems that may not have been touched for 10, 15, 20 years,” he says. This means “you really have to open up something that may not have been opened up for quite a long time,” he notes. “Particularly in long-tail business like life and pensions, youve got data that goes back a hell of a long way.”

Rickard stresses that another problem with platform rationalization is that it is often relatively easy to move 95% of the data, but there will be 5% left that someone has a question about.

“A company will have to make some tough decisions about whether that rump of business is worth keeping,” Rickard says. He notes that some companies might decide to sell off blocks of business that dont mesh with the overall migration of data “just so that the old system can be shut down.”

As a result, a company must undertake return-on-investment studies to determine the benefit of platform rationalization projects, he says.

Another problem affecting the IT rationalization can involve the functionality gap between the target and legacy systems, Rickard says. “Maybe in 1981, someone designed a coverage with some special bells and whistles, and these bells and whistles arent incorporated in the target system. So you then have a functionality gap,” he contends. “You can either decide to build this functionality into the target system, which has a cost, or you can encourage this business to go elsewhere.”

Insurers should be left with legacy systems with five percent of the data “which still costs you an arm and a bloody leg,” while migrating 95% of the data onto target systems, he says. “That is such a common problem.”

“Most of the effort in these projects is spent on actually cleansing the data and getting it into the right structure to facilitate the ongoing operation,” says Gill Wylie, operations director for RoomSolutions in London. “Youve got to determine the right data to retain and move that across [to the new system] to optimize the quality of that data.”

At the beginning of the project, its important for the insurer to understand where the ongoing business wants to go, so the system strategy can be determined as well as the data conversion strategy, she says.

“Quite a lot of people pile everything into the conversion project without taking into account the overall company strategy,” Wylie says, explaining that some companies will try to migrate too much unnecessary data.

“You should migrate whats required to support your business. Dont spend masses of time on cleansing data that someone never looks at.”

As a result, the insurer must determine the scope of the conversion, Wylie says. “What do you want to do with your legacy systems? Do you want to support them for the next 10 years and just run them off? Or do you want to move all the data over to the new system and remove support for the old ones?”

Further, she says, its important in a data conversion project to run a lot of data integrity routines while the project proceeds so that it is quickly ascertained when quality is lacking both from a business and a systems integrity point of view.

“Obviously, when youve got a lot of data problems in these legacy systems, youve got to get to the root cause of those very early on in the project. That maximizes the chance of success,” she explains.

Its also important to assemble a team of people in the business that understands the data, which can help fast-track the project, she says.

Meikle says that rationalization of legacy systems is a little bit like going through a merger. “Most companies dont do this very often, so they dont necessarily have the skills and experience to go about it,” he explains. “If youre building new systems or new functionality or new products, its something that you do every six months or every year; you have the skills in the organization.”

However, many companies have never gone through a significant rationalization exercise and may not have the skills and experience in the organization to begin such a project, he says.

“At the end of the day, you have a small pool of resource,” Meikle says. “There are only two ways you are going to grow that pool of resourceby retooling people internally or bringing people in from the outside.”

Meikle says he has seen companies successfully complete such projects in-house as well as via outside collaboration.

“I wouldnt say that any one approach will consistently fail or consistently succeed, but you cant tackle it and resource it in the same way as you can probably resource 90% of your technology-driven projects because its a different skill set,” he says.

“Its not a design, build, test, implement, run type of project.”

How long do most projects take? “The most aggressive I have seen is an organization that has rationalized its business down to two core systems in 12 months,” he says. “That is very aggressive and theyve done it by focusing almost exclusively on this program of work. Theyve been very, very effective at doing the program,” Meikle notes.

“Typically, for a large legacy system, youre talking six months plus.” He says he deliberately leaves the time estimate open-ended because “it really depends on how big and how hairy your architecture is.”

Reproduced from National Underwriter Life & Health/Financial Services Edition, September 19, 2003. Copyright 2003 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.

NOT FOR REPRINT

© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.