Suddenly things are coming in nines! The lastShop Talk article, published in the March edition of TechDecisions, was written around answers to nine questionsconcerning core system implementation. Recently my companyreceived a questionnaire concerning policy administration systemselection from a carrier doing its homework. There were ninequestions.

And they are good questions and should be of general interest soI decided to go with the nines thing again for this article. So, my thanks to the carrier which submitted these questions (andwho will remain anonymous in order to avoid a flood of unsolicitedcalls from policy admin system vendors).

1. What are the reasons mostcompanies are moving forward with a new policy administrationsystem?

Reasons are varied and are usually a combination of those listedbelow:

Business: Most carriers list several businessdrivers. These usually include speed-to-market (for both rateand product changes); easier regulatory compliance (especially forgeographically diverse companies); need to reduce operational coststhough straight-through processing and other reductions inadministrative and operational tasks; and promotion of ease ofdoing business (via portals) for agents/insureds or both.

Technical: Technical reasons, appropriately, are usuallysecondary to business reasons but include: the need to replaceaging and unsupported technologies; lack of software flexibility(which is usually stated as cost and time parameters in makingchanges) inherent in legacy systems; and increased difficulty inhiring legacy system maintenance and support staff (e.g. for COBOLapplications).

People (aging workforce): Aging workforce is sometimesmentioned both for operations and IT. On the operations sidecarriers want to capture business rules (e.g. underwritingeligibility) and instantiate them in systems so that not only canthe system do automated underwriting, but reliance on an agingworkforce can be reduced while operational decisions can be morestandardized. On the IT side we have seen several instanceswhere carriers have mission critical systems such as policy orbilling where only one or two people remain who have the requisiteknowledge to maintain the system.

Financial: Many carriers attempt a cost benefit analysisand predict a payback on a given horizon. However, often thenumbers do not cooperate in that the projected cost savings do notmaterialize, or by the time the new system is fully operationalseveral other major financial metrics have changed sufficientlythat isolating the effects of the new system is difficult. Inthe final analysis legacy system replacement is usually more to dowith competitive survival, customer satisfaction and growthpotential than hard dollar returns. Carriers that try for thefinancial argument cite cost savings that accrue from automatedunderwriting, straight-through processing and the like butultimately this usually requires headcount reductions which seldommaterialize. Other plausible dollar benefits can be garneredfrom better underwriting (loss avoidance and more accurate pricingusing sophisticated underwriting rules and predictive analytics),lower loss adjustment expense and fewer fraud losses for claimsadministration and increased submissions due to greater ease ofdoing business for agents. While we have seen instances ofthese benefits being delivered they are usually the result of veryfocused implementations (e.g. automated underwriting or frauddetection) rather than from the implementation of a “generic”policy administration system.

2. How are companies selectingwhich replacement system they need? Are they finding onesystem for both commercial and personal lines?

Increasingly it is the case that carriers can findenterprise-wide policy administration system solutions. Traditionally vendors wrote commercial- or personal-lines specificsolutions and built domain and delivery expertise in one area orthe other. The more recent vendor arrivals in the market havetended to write software toolkits which they then use to configureline of business solutions and in doing so have been able to createsingle platform solutions for carriers that write in bothcommercial and personal markets (and workers’ compalso).

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

3. Do most policy admin systemscome with the following components? Are companies replacingthese components at the same time they are implementing policyadmin?

Statistical Reporting: Stat reporting is notusually included in third-party policy systems. Many carrierseither continue to use their legacy stat system, buy a separatethird-party product (of which there are few options) or addressstat reporting as part of a warehousingstrategy.

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

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

Document Creation/Archive: Some third party policysolutions include a document management capability which while notbest-of-breed may suffice for smaller carriers. All policysystems, whether they include a document management capability ornot, should integrate readily with third party specialistsolutions.

Agent Portal: An increasing number of policy solutionsincorporate some form of agent portal. The key is tounderstand what the policy vendor means by an agent portal andwhether it is sufficient for the carrier’s purposes. Policyvendors tend to provide a proprietary quoting and submissioncapability rather than a portal which an agent can use to overseeand manage their book of business with a given carrier.

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

4. Whatapproaches are being used for implementation?

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

Internal resources/vendor assistance: There are two mainclasses of implementation tasks from the resourcingviewpoint. First there are tasks that the vendor must lead(at least initially). These include software installation,initial system configuration, and (the vendor side of) integrationwith other software assets in the client environment. Thesetasks are those things which require expertise in the vendor’ssoftware. Second, there are tasks that the carrier resourcesmust lead. These include definition of business requirements,carrier side integration, rollout planning, data conversion, andacceptance testing. Obviously the vendor may use integrationpartners and the carrier may retain an SI or “body shop” tosupplement the resource spike that results from core systemsreplacement. The key objective for the carrier is tomanage costs while controlling risk. Core system replacementis complex and risky, and often requires skill sets that cannot befound in an in-house resource pool. Getting key experiencedresources either from the software vendor or from a third-partyconsultancy can mitigate much of the risk.

Testing: Core system implementations (especially policysystems) are large and complex and require a lot of testing. Increasingly carriers use automated testing tools (often nowopen-source tools) to lower the manpower commitment and improvequality. Some software vendors recommend specific test toolsand strategies. Also there are third-party consultants thatoffer a specialization in testing certain types of application oreven certain vendor systems. The fact remainsthat testing is hard and is seldom allocated enough time orresource to do the job thoroughly.

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

5. Are companies making changes toprocesses and workflows to conform to the newsystem?

The question implies that carrier workflows have to conform tovendor systems. This is only true to the extent that thevendor solution is relatively rigid. The recent upsurge inhighly configurable systems has significantly reduced theconstraints 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 usuallydepends on the project business drivers (to what extend does thecarrier want or need to change processes and workflows) and thenature of the system being purchased. Highly configurablesystems are capable of creating carrier specific workflows whichcan be designed and built interactively (in an Agile projectenvironment). If the carrier is interested in a more “out ofthe box” legacy system they should be more careful about processand workflow requirements because they will be more difficult toimplement and should probably be key selection criteria.

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

This is not usually done in any detail prior to systemselection. Certain key requirements may be gathered and usedas selection criteria in the business functionality assessment areabut usually no more. Some carriers will assure themselvesthat requirements can be met by talking with reference customers ordesigning scripted demos that require the vendor to perform certaindetailed examples of importance to the carrier. (For moreinformation on the use of scripted demos see Shop Talk December2008 “StickingWith the Script.”

Are companies completing detailed business requirements up frontor 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 projectmethodology of the new highly configurable vendors. There are obvious problems with trying to gather complete detailedrequirements up front for a complex project—requirements areincomplete, no one knows the answers, future state requirements arevery hard to define without seeing the system, and requirements canchange during the project lifecycle.

6. How importantis it that companies adhere to standards when selecting asystem? In other words, what should drive systemselection—functionality or infrastructure standards?

It is critically important for a carrier to define a set ofselection criteria and apply those criteria consistently incomparing and ultimately selecting a vendor. A viablemethodology for software selection should start with a series ofgroup conversations with carrier stakeholders which are designed tocatalogue, define, and rank those criteria that the carrier willuse to assess vendors and ultimately choose one. Thesecriteria commonly include such categories as businessfunctionality, support for business drivers, technology,partnership fit, vendor risk profile, price, terms and conditions,and additional services.

7. Do systems allow movingfunctions like configuration of rating engines or rules engines tothe business areas? If so, how successful have companies beenat doing this? Has change management been anissue?

The new breed of vendors develops and sells highly configurablesystems. These systems are development toolkits (written inlower level languages), which are used to create and maintaincomplete business applications with minimal if any need to writeprogram code. Some vendors claim these toolkits can be usedby business users to maintain and modify the business behavior ofthe system, thus freeing the business from the constraints of theIT department. The reality is mixed and cloudy. Somevendor toolkits are more user-friendly than others and even thosethat are user-friendly are not in practice widely used by businesspeople. This may be due to several reasons including thereluctance of IT to cede ground, the lack of training anddiscipline on the part of business users, and the actual nature ofthe toolkit. One fact to note is that a toolkit onlygenerates system behavior. The hard work of defining detailedrequirements and testing and verifying those requirements are notfacilitated by the toolkit and still require extensive disciplineand effort to create a successful project. These are notnecessarily things that business users know how to do well.

So, carriers are not commonly succeeding in moving thesefunctions to the business area. Where this has beentried (and even succeeded) requires more change management andtraining than just teaching the toolkit and “letting herfly.” Roles change, new hybrid skill-sets are required, andincremental “experiments” are needed to figure out who can do whatand how much authority and responsibility can be transferred to thebusiness community.

8. What are the major risks thatcompanies face when replacing core systems? Any mitigationstrategies that you have seen companies usesuccessfully?

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

Mitigation strategies include:

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

9. Can you share any costinformation (averages or percentages or percentage of DWP) thatcompanies should expect?

This is a reasonable question which is difficult to answerwithout understanding the shape, size and objectives of theproject. There are some rules of thumb such as annualmaintenance costs are about 20 percent of license cost, ASP servicefees vary between one percent and two percent of premium processeddepending on extent of services, and implementation costs areusually two or three times the license fee. But what is the licensefee? The answer is . . . it depends on several factors thatvary by carrier project.