1 Case Study – Replacing our Claims Applications Jerry Dalla Corte Vice President, Head Office Operations March 27, 2008

2 Introduction – Who are we? $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 history Claims to be a Core Competency Restructuring - Standard Procedures and Service Metrics Re engineering – Customer Service

4 System 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 Strategy Launched a Claims IS Strategy project Started with an assessment of where we were and what we needed

6 Claims IS Strategy We considered the following options:  Extend our existing system  Develop new claims system  Buy and implement an application

7 System 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 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 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 Application Too Costly

11 Implement 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 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 Decision 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 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 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) Agile for Configuration Integration, Waterfall, but parts of Agile Agile drove schedule

17 Benefits 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 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 Learned People work to the standards they are measured to! Communication Surprises happen – plan for them

20 Conclusion Change is reality Technology does not mean change Change does not need technology, but technology can enable more change