Business: Most carriers list several business drivers. These usually include speed-to-market (for both rate and product changes); easier regulatory compliance (especially for geographically diverse companies); need to reduce operational costs though straight-through processing and other reductions in administrative and operational tasks; and promotion of ease of doing business (via portals) for agents/insureds or both.

Technical: Technical reasons, appropriately, are usually secondary to business reasons but include: the need to replace aging and unsupported technologies; lack of software flexibility (which is usually stated as cost and time parameters in making changes) inherent in legacy systems; and increased difficulty in hiring legacy system maintenance and support staff (e.g. for COBOL applications).

People (aging workforce): Aging workforce is sometimes mentioned both for operations and IT. On the operations side carriers want to capture business rules (e.g. underwriting eligibility) and instantiate them in systems so that not only can the system do automated underwriting, but reliance on an aging workforce can be reduced while operational decisions can be more standardized. On the IT side we have seen several instances where carriers have mission critical systems such as policy or billing where only one or two people remain who have the requisite knowledge to maintain the system.

Financial: Many carriers attempt a cost benefit analysis and predict a payback on a given horizon. However, often the numbers do not cooperate in that the projected cost savings do not materialize, or by the time the new system is fully operational several other major financial metrics have changed sufficiently that isolating the effects of the new system is difficult. In the final analysis legacy system replacement is usually more to do with competitive survival, customer satisfaction and growth potential than hard dollar returns. Carriers that try for the financial argument cite cost savings that accrue from automated underwriting, straight-through processing and the like but ultimately this usually requires headcount reductions which seldom materialize. Other plausible dollar benefits can be garnered from better underwriting (loss avoidance and more accurate pricing using sophisticated underwriting rules and predictive analytics), lower loss adjustment expense and fewer fraud losses for claims administration and increased submissions due to greater ease of doing business for agents. While we have seen instances of these benefits being delivered they are usually the result of very focused implementations (e.g. automated underwriting or fraud detection) rather than from the implementation of a “generic” policy administration system.

2. How are companies selecting which replacement system they need? Are they finding one system for both commercial and personal lines?

Increasingly it is the case that carriers can find enterprise-wide policy administration system solutions. Traditionally vendors wrote commercial- or personal-lines specific solutions and built domain and delivery expertise in one area or the other. The more recent vendor arrivals in the market have tended to write software toolkits which they then use to configure line of business solutions and in doing so have been able to create single platform solutions for carriers that write in both commercial and personal markets (and workers’ comp also).

While these newer systems are not as functionally rich as their legacy predecessors they are much more flexible and can be used to (relatively) rapidly develop and deploy highly customized line of business solutions for carriers.

3. Do most policy admin systems come with the following components? Are companies replacing these components at the same time they are implementing policy admin?

Statistical Reporting: Stat reporting is not usually included in third-party policy systems. Many carriers either continue to use their legacy stat system, buy a separate third-party product (of which there are few options) or address stat reporting as part of a warehousing strategy.

Billing and Claims: Billing and claims solutions may be found as part of an integrated policy solution, as best-of-breed solutions from the same policy vendor, or as best-of-breed solutions from a vendor other than the policy vendor. Billing and claims solutions may be replaced at the same time as the policy system or quite commonly can be replaced independently and on a separate timetable.

Reporting and Analytics: Some policy systems incorporate a reporting and/or analytics component and some do not. It is generally the case that a reporting/analytics module from a policy vendor will be less powerful and functional than a reporting/analytics solution from a specialist vendor. Again, implementations may be done in conjunction with policy replacement or independent of. One fact to note is that reporting/analytics systems draw most of their data from underlying core systems and one of the advantages of a new policy system is that it will store a lot more data than the legacy system and will probably have flexibility in adding and storing user-required fields, making it logical to replace policy before reporting/analytics, all else being equal.

Document Creation/Archive: Some third party policy solutions include a document management capability which while not best-of-breed may suffice for smaller carriers. All policy systems, whether they include a document management capability or not, should integrate readily with third party specialist solutions.

Agent Portal: An increasing number of policy solutions incorporate some form of agent portal. The key is to understand what the policy vendor means by an agent portal and whether it is sufficient for the carrier’s purposes. Policy vendors tend to provide a proprietary quoting and submission capability rather than a portal which an agent can use to oversee and manage their book of business with a given carrier.

Any others? Some vendor policy administration solutions also include imaging and workflow capabilities.

4. What approaches are being used for implementation?

Implementation approach should reflect the timelines and business drivers of the carrier. However, where timelines allow, most carriers will implement in a phased approach, usually by some combination of function, line of business and geography. Obvious issues arise and must be planned for where carriers sell lines of business together e.g. auto/home, or where the carrier sells multi-state commercial lines policies. These kinds of details must be anticipated and resolved with the business stakeholders.

Internal resources/vendor assistance: There are two main classes of implementation tasks from the resourcing viewpoint. First there are tasks that the vendor must lead (at least initially). These include software installation, initial system configuration, and (the vendor side of) integration with other software assets in the client environment. These tasks are those things which require expertise in the vendor’s software. Second, there are tasks that the carrier resources must lead. These include definition of business requirements, carrier side integration, rollout planning, data conversion, and acceptance testing. Obviously the vendor may use integration partners and the carrier may retain an SI or “body shop” to supplement the resource spike that results from core systems replacement. The key objective for the carrier is to manage costs while controlling risk. Core system replacement is complex and risky, and often requires skill sets that cannot be found in an in-house resource pool. Getting key experienced resources either from the software vendor or from a third-party consultancy can mitigate much of the risk.

Testing: Core system implementations (especially policy systems) are large and complex and require a lot of testing. Increasingly carriers use automated testing tools (often now open-source tools) to lower the manpower commitment and improve quality. Some software vendors recommend specific test tools and strategies. Also there are third-party consultants that offer a specialization in testing certain types of application or even certain vendor systems. The fact remains that testing is hard and is seldom allocated enough time or resource to do the job thoroughly.

Conversion—big bang, at renewal, other? Very few carriers opt for a “big bang” (i.e. in-force) policy conversion. Most are (wisely) put off by the additional risks posed by such a strategy, although the idea of moving cleanly and quickly from one system to another is initially attractive. Of the few that opt for an in-force conversion most have significant problems balancing financials and avoiding other operational disruptions. We always recommend an at-renewal conversion method, which can be hard enough, and of course extends the overall implementation timeline considerably.

5. Are companies making changes to processes and workflows to conform to the new system?

The question implies that carrier workflows have to conform to vendor systems. This is only true to the extent that the vendor solution is relatively rigid. The recent upsurge in highly configurable systems has significantly reduced the constraints on carriers to have to change to fit the software.

What types of assessments are being completed up front re: processes and workflows?

The type and extent of upfront process/workflow reviews usually depends on the project business drivers (to what extend does the carrier want or need to change processes and workflows) and the nature of the system being purchased. Highly configurable systems are capable of creating carrier specific workflows which can be designed and built interactively (in an Agile project environment). If the carrier is interested in a more “out of the box” legacy system they should be more careful about process and workflow requirements because they will be more difficult to implement and should probably be key selection criteria.

Are things like underwriting rules or the amount of information being collected for a new business application being reviewed/changed before selecting a system?

This is not usually done in any detail prior to system selection. Certain key requirements may be gathered and used as selection criteria in the business functionality assessment area but usually no more. Some carriers will assure themselves that requirements can be met by talking with reference customers or designing scripted demos that require the vendor to perform certain detailed examples of importance to the carrier. (For more information on the use of scripted demos see Shop Talk December 2008 “Sticking With the Script.”

Are companies completing detailed business requirements up front or is a more agile approach being adopted (i.e., “once and done” out of sequence, etc.)?

Agile is becoming more common and is the preferred project methodology of the new highly configurable vendors. There are obvious problems with trying to gather complete detailed requirements up front for a complex project—requirements are incomplete, no one knows the answers, future state requirements are very hard to define without seeing the system, and requirements can change during the project lifecycle.

6. How important is it that companies adhere to standards when selecting a system? In other words, what should drive system selection—functionality or infrastructure standards?

It is critically important for a carrier to define a set of selection criteria and apply those criteria consistently in comparing and ultimately selecting a vendor. A viable methodology for software selection should start with a series of group conversations with carrier stakeholders which are designed to catalogue, define, and rank those criteria that the carrier will use to assess vendors and ultimately choose one. These criteria commonly include such categories as business functionality, support for business drivers, technology, partnership fit, vendor risk profile, price, terms and conditions, and additional services.

7. Do systems allow moving functions like configuration of rating engines or rules engines to the business areas? If so, how successful have companies been at doing this? Has change management been an issue?

The new breed of vendors develops and sells highly configurable systems. These systems are development toolkits (written in lower level languages), which are used to create and maintain complete business applications with minimal if any need to write program code. Some vendors claim these toolkits can be used by business users to maintain and modify the business behavior of the system, thus freeing the business from the constraints of the IT department. The reality is mixed and cloudy. Some vendor toolkits are more user-friendly than others and even those that are user-friendly are not in practice widely used by business people. This may be due to several reasons including the reluctance of IT to cede ground, the lack of training and discipline on the part of business users, and the actual nature of the toolkit. One fact to note is that a toolkit only generates system behavior. The hard work of defining detailed requirements and testing and verifying those requirements are not facilitated by the toolkit and still require extensive discipline and effort to create a successful project. These are not necessarily things that business users know how to do well.

So, carriers are not commonly succeeding in moving these functions to the business area. Where this has been tried (and even succeeded) requires more change management and training than just teaching the toolkit and “letting her fly.” Roles change, new hybrid skill-sets are required, and incremental “experiments” are needed to figure out who can do what and how much authority and responsibility can be transferred to the business community.

8. What are the major risks that companies face when replacing core systems? Any mitigation strategies that you have seen companies use successfully?

Hard numbers are difficult to come by for obvious reasons, but it is estimated that as many as half of all core system replacement projects fail either partially or completely. Causes for failure include selection of an inappropriate vendor, scope creep, lack of executive management commitment (or change of executive management), inadequate requirements definition, poor expectation management, and poor project management and estimation.

Mitigation strategies include:

• Ensuring that an appropriate and well understood vendor solution is selected. The single most effective way to ensure this is to execute a proof-of-concept (POC) as the final selection step. For more information on execution of a POC please see Shop Talk August 2007 “Unclear on the Concept.”
• Project issues such as scope creep, inadequate requirements, expectation management and poor project management can be mitigated in two ways: first by resourcing the project with key players who are expert in doing core system, legacy replacement projects; second by performing formal project health checks at appropriate points in the project lifecycle. For more information please see Shop Talk June 2009 “Projects, Sports and Journeys.”
• Making sure that favorable contract terms, including escalation and termination triggers, are agreed and enforced.

9. Can you share any cost information (averages or percentages or percentage of DWP) that companies should expect?

This is a reasonable question which is difficult to answer without understanding the shape, size and objectives of the project. There are some rules of thumb such as annual maintenance costs are about 20 percent of license cost, ASP service fees vary between one percent and two percent of premium processed depending on extent of services, and implementation costs are usually two or three times the license fee. But what is the license fee? The answer is . . . it depends on several factors that vary by carrier project.