L&A PAS Replacement: Slaying the Hydra

Best Practices for Life & Annuities Policy Administration System Replacement “Slaying the Hydra” October 21, 2009

Stacey Cheese Director of Insurance Practice, Edgewater Technology, Inc. Laura Gleason Principal Consultant, Edgewater Technology, Inc. Today’s Speakers

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

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

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

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

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

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 Jail

Source: Accenture

The Nature of the Beast (Why best practices are important) Policy Administration System Selection and Replacement

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

Project Statistics – The Challenges and Failures Source: WSR Consulting Group, LLC 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.

Key Steps to Successful System Implementation

Driving a Successful Policy Replacement Solution Strategic Definition System Selection & Negotiation Planning Enhance vs. Build Requirement Definition Data Conversion System Integration, Deployment, Maintenance

Strategic Definition Planning picture

Strategic Definition – Planning

What are the End Goals?

Administrative consolidation

Strategic platform for new products

Administration replacement

Consolidate interfaces into one robust solution

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

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

Start broad, reduce rapidly – focused search System Selection & Negotiation Planning

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

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. LONG LIST Qualified Vendor SHORT LIST FINALISTS Qualified Vendor Qualified Vendor Qualified Vendor Qualified Vendor Final Final STEP 3: Based on v endor demonstrations, vendor analysis and RFI responses, the best solution is selected. Selection VENDOR VENDOR VENDOR VENDOR VENDOR VENDOR VENDOR VENDOR VENDOR VENDOR VENDOR VENDOR

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

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?

Capturing the Critical Business Requirements Requirements Definition

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 process reengineering candidates

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

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

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

Customize the system? Or build external module? Enhance vs. Build

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

Ignorance is not bliss Data Conversion

Data Conversion – Don’t Ignore the Data

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

INCORRECT MASTER LISTS POOR DATA QUALITY MISCODED FIELDS IN LEGACY SYSTEM SOURCE FIELDS USED FOR MULTIPLE PURPOSES CONFLICTING DATA DEFINITIONS Not addressing these early can severely impact your conversion effort

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

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)

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

Conversion Approach – Its all about being Prepared Time Spent on Analysis & Planning Your Conversion Will Provide a Return on Investment Many Times Over GOVERNANCE

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 Subject Area A Subject Area B Subject Area X Business Data Quality Referential Integrity De - Dup Processing Data Formatting Technical Data 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 New Platform Extract – Transform – Load Processing Old Legacy Platform

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.

Connecting disparate systems & keeping current System Integration, Deployment, Maintenance

System Integration – Technologies