1

Best Practices for Life & Annuities Policy Administration System Replacement

“Slaying the Hydra”

October 21, 2009

2

2

Stacey CheeseDirector of Insurance Practice, Edgewater Technology, Inc.

Laura GleasonPrincipal Consultant, Edgewater Technology, Inc.

Today’s Speakers

3

3

Agenda

• About Edgewater

• Policy Administration System Selections• Insurance business environment, challenges, & root causes

• The nature of the beast

• Key Steps to Success

• Final Thoughts

• Q&A

4

4

About Edgewater

• Technology Management Consulting Firm • Provide a unique blend of specialty IT services • Leverage proven industry expertise in strategy, technology and enterprise

performance management• Focus on middle and Global 2000 market

• Stable and Proven• Founded in 1992• Headquartered in Wakefield, MA• 250 Employees, 200 Consultants• 700 Clients• Large North American Footprint• +2,200 Projects Completed to Date• Publicly Traded (NASDAQ: EDGW)

• Insurance Practice• Over 50 clients• Expertise in policy administration, system selection, implementations

5

5

Edgewater’s Policy System Selection and Replacement Expertise

• System Replacement Experience• Familiarity with vendors in the space

• Vendor selections

• System integration

• Custom build / customization

• Related Projects• Policy system implementation, forms generation, data conversion, Business

Intelligence and data warehousing

• Supporting Services• Project / Program management

• Requirements and gap analysis

• Testing: manual and automated

• Project triage / rescue

6

6

2009 Insurance Industry Trends

• Insurance Internet Commerce• Insurance and Web 2.0

• Portals – external and internal

• Analytics

• PAS – Replacement / Integration / Implementation• Best practices

• Keys for success

• Legacy Modernization and Integration

• Document Services• Straight through processing

• Automation and increased customer service

• Enterprise Information Management (EIM)• Data warehousing / Business intelligence

• Data readiness assessment – the path to data empowerment

7

7

Insurance Business Environment & Challenge

• Many insurance companies run multiple admin systems

• Frequent limitations on user reporting capabilities• Limited out-of-the-box system reporting capabilities

• No direct access to data

• Inaccurate data

• To remain competitive, carriers must:• Increase automation to improve discipline and efficiency, reduce error rates and

minimize leakage

• Provide flexible, secure, easy access for agents, employers and consumers

• Offer key reporting and BI capabilities both internally and externally

• Achieve seamless integration with existing systems

• Speed the time to market for new insurance products and riders

8

8

Project Statistics – The Numbers Game

As of 2007, 64% of North American insurance firms were planning or implementing PAS consolidations•Key Drivers:

• Compliance requirements

• Speed time to market

• Business unit productivity

• IT cost reduction

• Web Enablement

•Key Issues:• Platform functionality

• Discrete product lines

• Group vs. individual

• Integrated application upgrades

• (Claims, Commissions, Billing etc)

• Conversion JailSource: Accenture

9

9

Policy Administration System Selection and Replacement

The Nature of the Beast(Why best practices are important)

10

10

53%18%

29%

Challenged

Failed

Successful

Common Policy Replacement Roadblocks / Pitfalls

• New policy administration system typically deployed for a new product offering, without strategic focus• Drives new system addition vs. consolidation

• Conversion of multiple lines of business onto one strategic platform is rarely considered as a leading priority during the system implementation • Difficulty of integrating disparate LOBs supported by disparate technologies should not

be minimized

• Short term wins vs. long term gains• Launch of a simple, new product may not uncover the underlying system frailties

• Successful Project Resolution – Statistics

Source: Standish Group 2006

11

11

He Said… She Said…System doesn’t work; not what we needed. You changed your minds; You don’t know what you

want or need.

You delivered limited functionality. You continually changed project scope.

The system failed in the field and in production. You didn’t perform the required “business process reengineering” to make it work.

Your software, services, and expertise were oversold. You conducted your reference checks and due diligence. What didn’t you know?

No one can use system! Poor training. “Required staff” never came to primary training or refresher training.

The system is “fundamentally flawed.” We only need 2 more months to test/fix issues.

You never told us that! You gave poor advice! You didn’t follow our recommendations; you changed/delayed making key decisions.

The system is full of bugs! Bad data conversion/poor interfaces caused the problems. Systems always have bugs!

You baited, then switched! You provided unqualified, unstable, uncommitted staff, project manager(s), steering committee.

No, you baited, then switched! You provided unqualified, unstable, uncommitted staff, project manager(s), steering committee.

Source: WSR Consulting Group, LLC

Project Statistics – The Challenges and Failures

12

12

Key Steps to Successful System Implementation

StrategicDefinition

System Selection

& Negotiation

Planning

Enhance vs. Build

Requirement Definition

Data Conversion

System Integration,

Deployment, Maintenance

Driving a Successful Policy Replacement Solution

13

13

Strategic Definition

Planning picture

14

14

Strategic Definition – Planning

• What are the End Goals?• Administrative consolidation

• Strategic platform for new products

• Administration replacement

• Consolidate interfaces into one robust solution

15

15

Strategic Definition – Business Objectives

• Common motivation for a new system:• Reduce time to market for new products

• Improve efficiency of business processes

• Reduce cost of change (regulatory updates, new riders, rates)

• Consolidate to reduce operational overhead and complexity

• Enhance back-office integration

• Manage rising cost of legacy technology

• Improve agent communication and involvement

• Expand reporting capabilities

• Consider other initiatives• Centralized data environment

• BI Strategy

• Agency integration

• Re-facing or re-purposing existing systems

16

16

Strategic Definition – Planning the Approach

• Where is your competitive advantage? • Focus on strengths and weaknesses

• Start with a new product release or the conversion of an existing product?• Complex product initiative vs. Quick win release

• Respect conversion• Poor data quality and lack of forethought

are common reasons for failure

• Plan on early, iterative execution

• Obtain executive support• Identify clear, concise, defendable, &

executable business case

• Validate business vision with key senior management

• Articulate expected ROI or cost / benefit

17

17

Start broad, reduce rapidly – focused search

System Selection & Negotiation Planning

18

18

System Selection – Package Selection Vision & Approach

• Gather & document business & technical requirements • Including key functional areas and technical considerations

• Identify viable vendor options• System Types

• Code vs. tool based

• Technology platform

• Support for out of the box product definitions

• Best of breed vs. 1-stop-shop

• Various delivery and support / maintenance models

• Identify vendor “Long List,” reduce to vendor “Short List”

• Issue requirements (RFI / RFP) to vendor short list and score results • Develop scripted demonstrations for apples to apples comparison

• Qualify Vendor Options and Scoring Criteria

• Select enterprise / best of breed system

19

19

System Selection – Exclusion Methodology

STEP 1:

Vendor selection process begins with a “long list” of over twenty vendors. Based on the first high-level analysis, a long list is reduced to the short list using specific requirements as a filter.

STEP 2:

Edgewater and the client project team review the vendor “short list” and identifies vendors that could provide the best fit. These vendors are invited to the RFI process.

VENDOR

VENDOR

VENDOR

VENDOR

VENDOR

VENDOR

VENDORVENDOR

VENDOR

VENDORVENDOR

VENDOR

LONG LIST

QualifiedVendor

SHORT LIST

FINALISTS

QualifiedVendor

QualifiedVendor

QualifiedVendor

QualifiedVendor

Final

Final

STEP 3:

Based on vendor demonstrations, vendor analysis and RFI responses, the best solution is selected.

Selection

20

20

System Selection – Implementation Planning Steps

• Develop timelines & milestones for vendor implementation• Supporting project plan outlining phasing for POC, detailed requirements, customization,

and implementation

• Determine product migration strategy• Existing product migration

• New product launch

• Identify approach for external system integration, including recommended phasing strategy

• Identify potential area for proof of concept (POC) focus• Make meaningful and reusable

• Outline key data conversion considerations, decision points, and milestones

21

21

Negotiation Planning – Key Vendor Due Diligence Questions

• Is the vendor financially viable?

• Is the technology sustainable?

• What do we really get “out of the box”? • e.g., Billing, Commission, Claims, workflow integration, document imaging

integration

• Large part of the TCO

• Can the system be customized and still get maintenance releases from the vendor? • Can the customizations be performed in house?

• How will it integrate with my back-end systems?

22

22

Capturing the Critical Business Requirements

Requirements Definition

23

23

Requirements Definition – Selecting a System

• Capture business requirements for system functionality• Consider current and future requirements to draw a distinct line in the sand

• Level of detail is very important

• Don’t bound requirements by current system constraints

• Include reporting requirements

• Involve the right combination of business users• High Business Knowledge

• Progressive Thinkers

• Consider potential business processreengineering candidates

24

24

Requirements Definition – Requirements Analysis

• Identify unique / differentiating business capabilities that must be supported• E.g. “Can the system handle commission splits and commission hierarchies?”

• These capabilities should be areas of focus in evaluating PAS vendor products

• Consider cost of modifications• Varies depending on vendor

• Code-based or limited content changes = $$$$

• Configuration-based or high content changes = $

• Configuration to be weighed against cost of implementations

• Evaluate whether gap analysis vs. full requirements is sufficient • Gap analysis shorter duration, not reusable

• Requirements analysis longer duration, detailed, specific to organization, reusable

25

25

Requirements Definition – Business Requirements Value

• Provides a reference and record of agreement on business process and top-level system functionality that the project delivery must satisfy

• Provides context of environment (systems, processes and issues) and captures the proposed statements of capabilities needed

• Allows for testing of discrete business capabilities and clear picture of system capabilities that are not yet working as agreed upon

Drives consensus on definition of “complete” requirements

Ensures clarity in test planning and design

Facilitates focused test execution to ensure requirements are met

26

26

Requirements Definition – Detailed Requirements Capture

• During ongoing system selection process, detailed requirements capture should be started• Detailed business requirements need to be captured to ensure all critical

business capabilities are not overlooked

• Begin with identify business process / area that is challenging / unique as potential POC candidate • Unique business area / business process that system needs to support

• Once package has been selected and POC is in process, detailed requirements for remainder of system will be run concurrently

• Detailed requirements provide foundation for supporting system enhancements or build efforts

27

27

Customize the system? Or build external module?

Enhance vs. Build

28

28

Enhance vs. Build – Customization / Development

• Strongly consider an approach to enhancing out of the box capabilities and building external modules to obtain key functionality • Consideration: whether vendor allows customization

• Benefit of enhancements: lower cost, institutionalizes knowledge about system early

• Benefit of builds: specific functionality, eases maintenance updates to core components

• Benefit of frequent system releases from vendor • Reliable method to remain “current” on system features / capabilities

• System testing• “Early and often”

• Develop clearly defined test plans

• Include smoke, system, and user testing

• Level of customization directly relates to ease of maintenance and system upgrades

29

29

Ignorance is not bliss

Data Conversion

30

30

Data Conversion – Don’t Ignore the Data

Data Conversions can uncover multiple issues that have grown over the years

INCORRECT MASTER LISTS

POOR DATAQUALITY

MISCODEDFIELDS IN LEGACY

SYSTEM

SOURCE FIELDSUSED FOR MULTIPLE PURPOSES

CONFLICTINGDATA

DEFINITIONS

Not addressing these early can severely impact your conversion effort

31

31

Data Conversion – Data Quality

“Data quality management is one of the greatest challenges of information

technology. According to the experts, the cost of poor data quality can reach as high as

15- to 25-percent of operating profit.”

- “http://www.tdwi.eu/fortbildung-zertifizierung/onsite/courses/data-quality-fundamentals.html

Not making data quality an early focal point of your conversion effort significantly increases your potential cost and duration of the conversion

32

32

Data Conversion – Typical Challenges

Typical Data Conversion Challenges

Remediation Approach

• Data duplication

• Data cleanliness

• Incomplete data

• Master data issues (e.g., fields used for multiple meanings)

• Data collision

• Conversion Strategy

• Data Governance

• Data Quality Focus & Early Identification of DQ Issues

• Clear Definition of Master Data

• Flexible Conversion Architecture

Lessons Learned

• A comprehensive conversion strategy & centralized governance function is critical for successful conversions

• Never underestimate the importance of early & continued focus on data quality, especially in the area of master data/lists (ex. Customer, Policy, etc.)

• Conversions of major operational systems offer unique opportunities to leverage the "clean" data for other purposes (ex. Reporting & Analytics)

33

33

Data Conversion – Taking Charge of the Data

• Precision• Granularity

• Accuracy• Consistency• Completeness

• Member/Group• Product• Eligibility

• Policy• Claim• Etc

• Enterprise Definitions• Consistent Usage• Common KPI’s/Metrics

34

34

Conversion Approach – Its all about being Prepared

Time Spent on Analysis & Planning Your Conversion Will Provide a Return on Investment Many Times Over

GOVERNANCE

35

35

Leveraging Your Replatform Initiative to Provide Improved Reporting & Analytical Capabilities Provides Significant Business Value

Data Conversion – Leveraging the Conversion

“Data Clearinghouse”

Error Analysis & Reprocessing

Data Staging Area

Data Distribution

Area

Extract Grouping #1

Extract Grouping #2

Extract Grouping X

SubjectArea A

SubjectArea B

Subject Area X

Business Data Quality

Referential Integrity

De-DupProcessing

Data Formatting

TechnicalData Quality

Data Cleansing

Derived Metrics Processing

Data Collision Resolution

Business Rule Application

Subject Area Processing

Standardization

Data Cleansing & Transformation Area

Error/Reject Staging

Error/Reject Remediation

Error/Reject Reprocessing

Centralized Reporting & Analytics Platform

Subject Areas

Claims Policies

Members Groups

Centralized Master & Metadata

Standardized Reporting/Analysis Tools

Old Legacy Platform

New Platform

Extract – T

ransfo

rm – L

oad

P

rocessin

g

36

36

Leveraging the Conversion

• The conversion from a legacy platforms offers an unique opportunity as the foundation for improved reporting & analytics through the establishment of a “Data Clearinghouse”:• One of the most costly & challenging aspects of establishing a centralized reporting

& analytics environment is often the sourcing & cleansing of operational transaction systems

• The cleansed/transformed data that is required for the new operational processing system can be leveraged for the foundation of a centralized reporting & analytics environment

• The technology used in the operational system conversion (ex. Informatica) can be leveraged in the creation of the centralized reporting & analytics environment

• The establishment of a centralized reporting & analytics environment in parallel with an operational system conversion requires an overall data strategy and governance structure encompassing both initiatives. “Retro-fitting” these constructs later increases risk of required remediation.

37

37

Connecting disparate systems & keeping current

System Integration, Deployment, Maintenance

38

38

System Integration – Technologies

• With integration, one size does not fit all• Pick the right product to start with

• Understanding disparate architecture• Existing legacy platforms

• Distributed systems

• Consider the following interfaces• Consider using XML / standards such as ACORD for external communications

• Select technology for interfacing with all of these external or supporting systems

• Real-time vs. batch interfaces

• Reporting and business intelligence tools

• For all but the simplest cases, use a product!• BizTalk, WebSphere Integrator, ESB

39

39

Deployment and Maintenance – Best Practices

• Deployment Best Practices • Is objective to deploy with existing book of business (e..g, existing policies), or

release new product to market?• Combination of both is ideal

• Test system on two levels

• For converted block of business, run new admin system in parallel for period prior to cutover

• Release with all core interfaces complete (claims, commissions, etc.)

• Reporting is key – current out of the box PAS reporting, vs. new separate reporting structure

• Maintenance Best Practices• Stay with the vendor – i.e., as the PAS vendor makes changes, make sure you

follow on par with releases

• Key consideration is ability to customize without branching code

40

40

Final Thoughts

Best Practices

41

41

Final Thoughts

• Select the right product• Out-of-the-box functionality, integration friendly

• Manage expectations• There will be many bumps in the road

• Build the right Team• Project Management, Partners / Vendors

• Everybody wants a successful implementation

• Play to your strengths & be realistic about your weaknesses• Augment if necessary

• Minimize risk in all areas• Requirements, Development, Conversion and Rollout

42

42

Thank You for Joining Us

• Stacey Cheese• Director of Insurance Practice • scheese@edgewater.com• 813-464-4601

• Laura Gleason• Principal Consultant• lgleason@edgewater.com• 781-224-9043

Visit edgewater.com to learn more about our Insurance and EIM practices