1

Case Study – Replacing our Case Study – Replacing our Claims ApplicationsClaims Applications

Jerry Dalla CorteVice President, Head Office Operations

March 27, 2008

2

Introduction – Who are we?Introduction – Who are we?

• 2007 - $1 Billion (approx.) GWP

• Write all major lines including Automobile, Personal

Property, Commercial P & C, and Surety

• Offices in 10 major cities

• Multiple legacy systems and support apps

• Trust Matters / Do the Right thing

3

Brief historyBrief history

• Claims to be a Core Competency

• Restructuring - Standard Procedures and

Service Metrics

• Re engineering – Customer Service

4

System LimitationsSystem Limitations

• Productivity challenges (limited efficiency gains)

• Limited opportunities for new gains

• Multiple sign-ons – 3 to 4 applications

• Very ‘codey’ system

• Information challenges

Applications were still not enablers

5

Claims IS StrategyClaims IS Strategy - 2004- 2004

• Launched a Claims IS Strategy project

• Started with an assessment of where we were and what we needed

6

Claims IS StrategyClaims IS Strategy

• We considered the following options:

Extend our existing system

Develop new claims system

Buy and implement an application

7

System LimitationsSystem Limitations

• Multiple sign-ons – 3 to 4 applications

• Very ‘codey’ system

• Information challenges

• Productivity challenges (limited efficiency gains)

• Limited opportunities for new gains

• Lack of business rules and work mgmt

8

Existing System – Information ServicesExisting System – Information Services

• 3 main systems\applications assessed:

Legacy system – aging technology, cost of maintenance, ease of change

Notes – reliable, but technology problem and scalability issues

Web – proprietary technology, difficult to change

• Technically our systems were partially adequate to adequate

• Data quality & document storage were problems

9

Extend Existing ApplicationExtend Existing Application

• Would require extensive rewrite of front-ends with no increase in functionality

• Other applications needed to be developed

• Not sufficient to meet information and business needs of the next decade

10

Develop New Claims ApplicationDevelop New Claims Application

• Too Costly

11

Implement Commercial ProductImplement Commercial Product

• Focus on 2 questions

Is there something we can buy to meet our needs?

Can we implement it?

• Developed a list of key attributes and business requirements

• Assessed a number of products on the market

• Short listed vendors who met our attributes, requirements, and we felt we could work with

12

Selection ProcessSelection Process

• Assessment based on RFI, scenario configuration, ‘hands on’ sessions, and on site visits

• Based on scoring performance, not ranking vendors

• Claims completed ‘scores’ based on function; IS ‘scores’ based on technical design and ability to implement

• Jointly considered miscellaneous requirements

13

DecisionDecision

• Selected Guidewire because:

Met functional needs

Architecture: Java consistent with our technical architecture and is consistent with SOA

Proven implementation track record

Way of doing things

14

Project - Phase 1 Project - Phase 1

• Immediate success was important• Project was divided into 4 phases • Started Oct 2005, UAT Oct 2006• Pilot Jan 2007• Training completed in 3 days• Well received by adjusters

15

Project TeamProject Team

• Team consisted of approx 25 people• Broken into 3 Groups: Configuration, Integration,

and Project Management• Configuration – Screen design, business rules• Integration – Mainframe, Java, BA’s, Technical• Had traditional teams for testing and training

16

How we worked (Methodology)How we worked (Methodology)

• Agile for Configuration

• Integration, Waterfall, but parts of Agile

• Agile drove schedule

17

BenefitsBenefits

• No real quantitative measures for ROI

• Process Improvements – reduced handoffs, e.g. payments

• Activities\Work Mgmt\Abeyance system

• Reduced keying, easier to read information

18

Objectives for futureObjectives for future

• Service – initially as is, but expect future increases, particularly for those very satisfied

• Cost management - look for ways to improve cost

• Performance to standard operating procedures being revised. Anticipate a higher pass benchmark.

19

Lessons LearnedLessons Learned

• People work to the standards they are measured to!

• Communication

• Surprises happen – plan for them

20

ConclusionConclusion

• Change is reality

• Technology does not mean change

• Change does not need technology, but technology can enable more change