Upload
whitney-arnold
View
220
Download
0
Tags:
Embed Size (px)
Citation preview
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