MYTH: Vendor package selection process has to take a long time.

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

MYTH: You should document your current system functionality in great detail before embarking upon a vendor selection process.

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

MYTH:  The system has to meet all of your requirements.

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

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

FACT: There are lots of great systems on the market, and there is one that is best for your needs. Just because a solution is in a "top right quadrant" or is highly rated doesn't make it the best solution for every carrier. Every carrier's needs are different, and different solutions may be right for any given carrier.

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

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

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

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

MYTH: The vendor is a service provider; you should consider the vendor to be a supplier and negotiate every last penny out of the deal, with procurement leading the discussions around vendor selection.

FACT: Your core systems vendor(s) will be working with you for years on what will likely be the most important project your organization has worked on in decades. It is important that you partner with your vendor rather than treat them like the vendor that supplies your hardware or database. Additionally, if you're squeezing the vendor on price, you're less likely to get their "A-team" and to be a top priority for them. 

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

FACT: The world—and your business—will change during the course of the project, and requirements will need to be adjusted accordingly. Waterfall-type methodologies aren't well-designed to deal with changing requirements, but agile-like (iterative) implementation methodologies are. Define requirements at the start of the project only to the extent necessary for planning 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 constantly change to meet changing needs. In addition, don't set requirements for where the business is today, but rather for where it wants to be at the end of the implementation. Failure to take this approach often leads to "repaving the cow path" in which you end up with a system that limits your ability to truly transform your business.

After the Sale: Implementing the System

MYTH: Systems are so good/complete/pre-configured that you can use the system straight out of the box

FACT: The best system for your needs will get you 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, product development, 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 take between nine and 24 months. If your vendor is giving you estimates that are longer or shorter, you should be asking why. There may be a perfectly good reason, but it's important to understand what makes your project different.

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

FACT: The success rates are much higher for packaged solutions than for custom builds, and there are very few cases in which it would be easier and/or cheaper to build a custom solution than to configure a packaged system.  If you have unique needs, you can either work to use the rules and other configuration capabilities of the system to meet your needs, you can work with the vendor to incorporate them into the configurability of the system, or you can change what makes you unique.

MYTH: Business analysts will make changes to the system to make minor rule changes "in minutes."

FACT: While business analysts (especially those with strong technical proficiency) may work on the system in a development environment, no matter how simple it is to configure the system, controls must be in place for promoting changes to testing, QA, and production, as well as for ensuring that rules are written properly, aren't duplicated, etc. This is best handled by IT.

MYTH: It's a technology project.

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

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

FACT: While this seems like a fact, in reality core systems projects should be treated as programs rather than projects. Thanks to the slew of interdependencies between pieces of the project, simply managing it as a large project rather than a program that encompasses a series of projects and related efforts is insufficient. This also means you'll need to find an experienced program manager at a minimum. Business process reengineering and project management skills need to be built upon. If you haven't implemented a solution of this magnitude before you likely don't have the skills and abilities to do it in-house today.

MYTH: Once employees are onboard with the idea of the new system(s) and the need for change, the battle is mostly won.

FACT: While this is an important step in the process, a significant change management effort is typically needed. If the program is implemented properly, lots of jobs will change in areas ranging from new business to underwriting. In addition, employees will be helping to redesign processes in a way that might eliminate their current role, so helping them understand how their role could evolve amidst the process changes rather than allowing people to assume that they'll be automated out of a job could be hugely helpful. Change is neither easy nor intuitive and needs to be addressed early on.

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

FACT: In reality, while conversion is indeed critical for life insurance core system replacements due to the long tail of life insurance policies, annuities, etc. (though there are options for avoiding/minimizing conversion for life insurers), for P/C insurers there are significant opportunities to minimize conversion that many carriers should take advantage of. The one that is most commonly utilized is manually converting policies at the time of renewal. Another option is to convert as little historical policy/claims/billing data as possible and moving the rest of the data to a data warehouse that is accessible albeit less convenient. If need be, you can migrate additional data into the new system over time.

MYTH: Functionality delivered on "Day One" needs to be nearly perfect because "Day Two" (the second major release) may never come.

FACT: Business may be conditioned to expect that IT will have other priorities once a system is live, that major enhancements will fall into a queue that never gets prioritized, and that anything not included in the first release will simply never make it into the system. As a result, initial requirements tend to be greatly over-defined and over-detailed, when in reality release one should include the bare minimum functionality to allow the business to run. This is what allows a carrier to start realizing benefits quickly, and those benefits can help to fund the remainder of the project.

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

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

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

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