1 / 20

Case Study – Replacing our Claims Applications

Case Study – Replacing our Claims Applications Jerry Dalla Corte Vice President, Head Office Operations March 27, 2008. Introduction – Who are we?. 2007 - $1 Billion (approx.) GWP Write all major lines including Automobile, Personal Property, Commercial P & C, and Surety

sloane-mills
Download Presentation

Case Study – Replacing our Claims Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 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 - 2004 • 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

More Related