Slaying the Beast

Most insurers are either in the midst of, or on the verge of starting, the onerous process of replacing one or more core legacy systems. There are far too many reasons to stop delaying the inevitable — reduced maintenance costs, better customer service via web-based portals, business partner needs, competitive pressures and business agility are just a few examples. However, the task of replacing systems that have driven core processing for organizations for decades is a significant undertaking, and downright scary for business and IT management.

These projects are fraught with closets full of skeletons: frequently, they run significantly over budget and beyond targeted timelines. Worse, they can get cancelled or completely fail.

Companies in the financial services sector have generally done a good job of replacing legacy technology and modernizing processes, but the insurance industry continues to lag behind. Historically, the industry has approached IT as a cost of doing business rather than as a strategic business opportunity. The bulk of IT spending often goes towards maintaining the legacy systems. Given a typical IT budget of between 1.5% and 2% of written premium, that’s quite an investment to just maintain the status quo.

Up until recently, the competitive environment, consumer demand and the distribution channel have not pushed the issue to the forefront. And so, given the expense and risk involved in core system replacement, insurers have been able to kick the proverbial can down the road. However, insurers are increasingly compelled to upgrade core systems and processes as direct writers and more technically savvy insurers gain market share.

Even so, some insurers still find themselves sitting on the sidelines, hesitant to commit. Let’s face it, making the wrong decision when replacing core processing systems can be a career-limiting — or even a career-killing — move.

Excuses, risks and foot-dragging aside, we can probably all agree it is best for businesses to replace their core processing systems with new technologies. But where is the best place to start when an insurer reaches the inevitable conclusion that it’s time to slay the legacy beast?

Slaying the Legacy Beast

First things first: Some ‘must-haves’ must ensure the effort kicks off on the right foot. They include the following:

• Buy-in from business and executive sponsors. This results in a business-led project, for which IT provides the solution, the heavy lifting and guidance for delivery.

• Dedicated business sponsors and subject matter experts, combined with a dedicated IT project team. This team may be small, depending on the insurer’s approach to the legacy replacement effort.

• A clear and definitive plan on expected deliverables and timelines.

• Well-documented anticipated cost savings and business benefits. This not only helps gain early support for the initiative, but also keeps the project on track and measure the results once in production.

Should the insurer buy or build the new system? Insurers are in the business of insurance and not software development, so a strong argument could be made for the buy option. Unless an insurer truly has the in-house expertise — not to mention the time and budget — to build a system, they might consider evaluating and choosing from a plethora of packaged insurance software solutions on the market. A winning combination includes a carrier that knows what it really needs in technology, functionality, maintainability and scalability, as well as a software solution vendor that represents a good organizational and cultural fit for the insurer.

In the buy approach, working with a software vendor is not a matter of all-or-nothing. Depending on the size of the initial project and the insurer’s appetite for in-sourcing some of the work, the insurer can determine the right balance of internal IT and business staff involvement, combined with expert vendor resources.

Once the vendor and software solution are chosen, the goal of minimizing risk often leads insurers to start small to achieve some quick results and success. The project expands as insurers become more confident and as the joint team becomes more competent. Rarely do insurers employ the ‘Big Bang’ approach to their legacy replacement projects.

When starting small, separating a large project into manageable bites, insurers typically need to have a new technology solution co-exist with legacy systems via interfaces. This may sound like a difficult feat, but the additional work required is small compared to the risk of replacing the entire core legacy environment in one fell swoop. Also, interfacing with legacy systems offers the insurer an opportunity to assess the quality of legacy data; this knowledge comes is certainly handy when it comes time for data conversion.

Now that the decision has been made to start small, where is the best place to begin? There is no one best answer. It all depends on the insurer and what its biggest pain point might be, or where the opportunity for the quickest results might be.

One insurer, for example, might target a line of business that is being managed manually. Manual underwriting might work in low volume, but as volume increases the cost to administer becomes prohibitive. This insurer could ‘start small’ by choosing this one line of business and implementing a solution for this line in its entirety.

Another insurer might see an opportunity to gain market share by delivering a solution to agents through an agent portal, allowing agents to enter new business easily and effectively. At the end of the ‘start small’ project, policy administration transactions might still be executed by the legacy system, while the new business is processed in the new environment.

Yet another insurer might see cost avoidance as the primary motivation for its ‘start small’ focus. For example, by implementing something new, perhaps the carrier can avoid further licensing charges or high service costs charged by its legacy system provider.

Or perhaps it might choose to implement a system that initially mimics the limited functionality of the legacy system, but that leaves new capabilities such as automated underwriting, rules, workflow and other processing efficiencies for subsequent projects.

Regardless of its scope, the initial project should take no more than six to nine months from project kick-off until it is ready for prime time and for roll out to production.

Start slow and ramp up with incremental success along the way. Find a vendor offering the right team synergy and the most suitable technology and application functionality. Understand the legacy environment, data and processes in order to facilitate the transition to a new system. Establish a solid team of dedicated resources from both IT and business. And, get started.

No one ever said it was going to be easy, but there is still no time like the present to replace legacy systems.