So much has been written and said about core systemsreplacement over the last few years that separating the facts fromthe myths has become increasingly difficult. In this article,however, we'll do just that, which should help you to betterunderstand the core systems space and the challenges and rewards ofcore systems replacement. This extensive list is compiled from anupcoming Novarica report.

Before You Buy

MYTH: You don't need to replace your system.You can just continue wrapping/extending/plastering other systemson top of your old system and get the necessary benefits.

FACT: In the vast majority of cases, wrap andextend is rarely a good strategy. It also rarely makes sense tore-write/modernize your existing system(s). The cost of maintainingthe system(s) and of ongoing R&D is rarely better than thecost/benefit of replacement.

MYTH: Vendor package selection process has totake a long time.

FACT: Using the right approach can speed theprocess significantly and help you avoid the dreaded RFP; ifselection takes too long, your needs may have changed before youeven select a system much less implement it.

MYTH: You should document your current systemfunctionality in great detail before embarking upon a vendorselection process.

FACT: Until you understand what packaged,modern solutions can do in terms of both out-of-the-boxfunctionality and configurability, it's impossible to know whatyour future state should look like. It should almost certainly notlook like your current system, and documenting it in great detailwill simply lead you to build a new version of your old system.

MYTH: The system has to meet all of yourrequirements.

FACT: Even after the system is configured, itmay not meet all of your requirements—and that's okay. In manycases, you'll need to change your business processes to meet thesystem's capabilities, either to save time and money, or becauseyour business processes need improvement (or both). In fact, thesystem may not even have all of the core functionality you need,requiring additional components to be purchased.

MYTH: There is one “best” system on themarket and that's the one you should try to find and buy.

FACT: There are lots of great systems on themarket, and there is one that is best for your needs. Just becausea solution is in a “top right quadrant” or is highly rated doesn'tmake it the best solution for every carrier. Every carrier's needsare different, and different solutions may be right for any givencarrier.

MYTH: There's no need to involve your agents orcustomers in the project—after all, it's an in-house system thatlives in the back office.

FACT: Getting your agents involved early in theprocess is critical to the system meeting their needs. Even if theydon't interact with it directly, they'll want to have input intohow they get status updates, access to client data, etc. Similarly, in some cases it makes sense to have a focus group ofcustomers and/or prospects provide input about the type of featuresand functionality that they expect you to have.

MYTH: There are significant,hard-dollar, short-term benefits for all core systemsreplacements.

FACT: There are typically short term benefits,but the really significant hard-dollar benefits come later in theproject. Plus, there are a number of tough decisions betweeninception of the project and the realization of the benefits andare dependent upon many factors. Core systems replacements shouldeither be justified as strategic in nature or with a long-termcost-benefit analysis since the costs are heavily front-loaded andthe benefits achieved over a long time horizon.

MYTH: The vendor is a serviceprovider; you should consider the vendor to be a supplier andnegotiate every last penny out of the deal, with procurementleading the discussions around vendor selection.

FACT: Your core systems vendor(s) will beworking with you for years on what will likely be the mostimportant project your organization has worked on in decades. It isimportant that you partner with your vendor rather than treat themlike the vendor that supplies your hardware or database.Additionally, if you're squeezing the vendor on price, you're lesslikely to get their “A-team” and to be a top priority forthem.

MYTH: Detailed business requirements can/shouldbe fully determined up front to be used throughout the course ofthe project.

FACT: The world—and your business—will changeduring the course of the project, and requirements will need to beadjusted accordingly. Waterfall-type methodologies aren'twell-designed to deal with changing requirements, but agile-like(iterative) implementation methodologies are. Define requirementsat the start of the project only to the extent necessary forplanning purposes, but plan to embrace and be resilient to change.Set expectations that requirements documents will be living,breathing things that grow (or even shrink), and that constantlychange to meet changing needs. In addition, don't set requirementsfor where the business is today, but rather for where it wants tobe at the end of the implementation. Failure to take this approachoften leads to “repaving the cow path” in which you end up with asystem that limits your ability to truly transform yourbusiness.

After the Sale: Implementing the System

MYTH: Systems are sogood/complete/pre-configured that you can use the system straightout of the box

FACT: The best system for your needs will getyou as close as possible with pre-configured business products,processes, and rules, but every carrier is unique (see next myth)and will require some additional configuration, productdevelopment, etc.

MYTH: The project is going to go really fast;or the project is going to take a really long time.

FACT: In most cases, these projects takebetween nine and 24 months. If your vendor is giving you estimatesthat are longer or shorter, you should be asking why. There may bea perfectly good reason, but it's important to understand whatmakes your project different.

MYTH: My business is so unique, that nopackaged systems will work for me. It's better to build than buy toaddress those unique capabilities.

FACT: The success rates are much higher forpackaged solutions than for custom builds, and there are very fewcases in which it would be easier and/or cheaper to build a customsolution than to configure a packaged system. If you haveunique needs, you can either work to use the rules and otherconfiguration capabilities of the system to meet your needs, youcan work with the vendor to incorporate them into theconfigurability of the system, or you can change what makes youunique.

MYTH: Business analysts will make changes tothe system to make minor rule changes “in minutes.”

FACT: While business analysts (especially thosewith strong technical proficiency) may work on the system in adevelopment environment, no matter how simple it is to configurethe system, controls must be in place for promoting changes totesting, QA, and production, as well as for ensuring that rules arewritten properly, aren't duplicated, etc. This is best handled byIT.

MYTH: It's a technologyproject.

FACT: It is a business project and a processredesign effort with a really significant technical component. Thetechnology part of the effort must be in support of articulatedbusiness needs or else it will most likely not succeed (and even ifit does, the business may not view it as a success).

MYTH: A core systems replacement should betreated as a large project.

FACT: While this seems like a fact, in realitycore systems projects should be treated as programs rather thanprojects. Thanks to the slew of interdependencies between pieces ofthe project, simply managing it as a large project rather than aprogram that encompasses a series of projects and related effortsis insufficient. This also means you'll need to find an experiencedprogram manager at a minimum. Business process reengineering andproject management skills need to be built upon. If you haven'timplemented a solution of this magnitude before you likely don'thave the skills and abilities to do it in-house today.

MYTH: Once employees are onboard with the ideaof the new system(s) and the need for change, the battle is mostlywon.

FACT: While this is an important step in theprocess, a significant change management effort is typicallyneeded. If the program is implemented properly, lots of jobs willchange in areas ranging from new business to underwriting. Inaddition, employees will be helping to redesign processes in a waythat might eliminate their current role, so helping them understandhow their role could evolve amidst the process changes rather thanallowing people to assume that they'll be automated out of a jobcould be hugely helpful. Change is neither easy nor intuitive andneeds to be addressed early on.

MYTH: Automated conversion of policiesand historical data is key to a successful go-live.

FACT: In reality, while conversion is indeedcritical for life insurance core system replacements due to thelong tail of life insurance policies, annuities, etc. (though thereare options for avoiding/minimizing conversion for life insurers),for P/C insurers there are significant opportunities to minimizeconversion that many carriers should take advantage of. The onethat is most commonly utilized is manually converting policies atthe time of renewal. Another option is to convert as littlehistorical policy/claims/billing data as possible and moving therest of the data to a data warehouse that is accessible albeit lessconvenient. If need be, you can migrate additional data into thenew system over time.

MYTH: Functionality delivered on “Day One”needs to be nearly perfect because “Day Two” (the second majorrelease) may never come.

FACT: Business may be conditioned to expectthat IT will have other priorities once a system is live, thatmajor enhancements will fall into a queue that never getsprioritized, and that anything not included in the first releasewill simply never make it into the system. As a result, initialrequirements tend to be greatly over-defined and over-detailed,when in reality release one should include the bare minimumfunctionality to allow the business to run. This is what allows acarrier to start realizing benefits quickly, and those benefits canhelp to fund the remainder of the project.

MYTH: A system that works in one geographicmarket should work in others with some modifications.

FACT: The reality is that in most cases ittakes years to adapt a system's capabilities to a new geography inorder to deal with tax, language, currency, and regulatory issues.Carriers need to thoroughly research how much work has been done toprepare a system for a particular geography before committing to asolution.

Insurers need to consider a great number of factors both whenselecting a system and when implementing it.

Chad Hersh is a partner in the research andadvisory firm Novarica. He can be reached at [email protected].