Van 6 maanden naar 6 weken: een claimsysteem herbouwen in de verzekeringssector

Een Nederlandse schadeverzekeraar kwam bij ons met een bekend probleem: een claiminnamesysteem dat schade-experts vertraagde, data verloor tussen overdrachtsmomenten, en al drie jaar op de moderniseringsroadmap stond zonder dat er iets gebeurde.

Het bestaande systeem was een combinatie van een 15 jaar oude on-premise applicatie, een gedeelde e-mailinbox die als wachtrij fungeerde, en drie handmatige overdrachtsstappen tussen inname en de schade-expert die de claim daadwerkelijk zou beoordelen. Gemiddelde tijd van inname tot toewijzing: 4 uur. Foutpercentage bij de initiële data-invoer: 12%.

De business case was duidelijk. De vraag was hoe je daar komt zonder een project van 8 maanden dat zou landen tijdens een regulatoire freeze.

Waarom de klassieke aanpak niet zou werken

De schoolboekaanpak voor dit soort projecten bestaat uit discovery, requirements-documentatie, leverancierselectie, design, bouw, QA, UAT en deployment. In serie uitgevoerd, met een akkoord bij elke fase, duurt dit doorgaans 6 tot 9 maanden.

Voor dit project waren er twee specifieke blokkades.

Ten eerste, de regelgeving. Nieuwe rapportagevereisten voor claimdata zouden in Q3 van kracht worden, wat betekende dat elk vervangend systeem daarvoor live moest zijn, anders zou de organisatie voor claims die al in behandeling waren twee systemen tegelijk moeten draaien.

Ten tweede, de integratiecomplexiteit. Het claimsysteem was gekoppeld aan zes andere interne systemen: polisdata, betalingsverwerking, documentopslag, communicatielogs, het planningssysteem voor schade-experts, en het rapportagesysteem voor de toezichthouder. Elke integratie had een eigen datacontract, in beheer bij een ander intern team.

Een waterfallproject van 6 maanden met zes integratiepunten en een harde regulatoire deadline was geen plan. Het was een risico.

Wat we in plaats daarvan deden

We stelden een andere scope voor. In plaats van het volledige claimsysteem te vervangen, zouden we de innamelaag vervangen: het deel waar claims binnenkwamen, werden gevalideerd en werden doorgestuurd naar schade-experts. Dit was het meest pijnlijke onderdeel van het huidige systeem en het onderdeel met de meest directe impact op de productiviteit van schade-experts.

De aanpak:

• Begin op dag 1 met een werkend innameformulier gekoppeld aan het polisdatasysteem, zonder volledige integratiesuite, alleen de ene koppeling die nodig is om de claim te valideren
• Voeg elke week één integratiepunt toe, op volgorde van business impact
• Lever elke vrijdag naar productie, met een subset van echte claims die door het nieuwe systeem worden verwerkt
• Houd het legacysysteem parallel draaiend totdat de nieuwe innamelaag 1.000 claims foutloos had verwerkt

De tijdlijn

Week 1: Werkend innameformulier, gekoppeld aan polisdata. Eerste echte claims verwerkt via het nieuwe systeem, een pilot met vier schade-experts.

Week 2: Integratie met betalingsverwerking. Integratie met documentopslag. Pilot uitgebreid naar 20 schade-experts. Foutpercentage bij initiële data-invoer daalt van 12% naar 2,4%.

Week 3: Integratie met communicatielogs. Geautomatiseerde routeringsregels: claims worden gekoppeld aan schade-experts op basis van dekkingstype en werklast.

Week 4: Integratie met de planning van schade-experts. Realtime wachtrijdashboard zichtbaar voor teamleiders.

Week 5: Integratie met de rapportage voor de toezichthouder. Volledige compliance-logging voor elke claimgebeurtenis.

Week 6: Verkeer naar het legacysysteem teruggebracht naar nul voor nieuwe claims. 1.247 claims verwerkt via de nieuwe innamelaag.

Zes weken van kick-off tot volledige productie-overgang, ruim voor de regulatoire deadline in Q3.

Het resultaat

De meetbare resultaten in week 6:

• Tijd van inname tot toewijzing: van 4 uur naar 22 minuten
• Foutpercentage bij data-invoer: van 12% naar 1,8%
• Vrijgemaakte capaciteit van schade-experts per week: ongeveer 11 uur (voorheen besteed aan handmatige datacorrectie en wachtrijbeheer)
• Alle zes integratiepunten live en getest onder reële belasting

Het project kwam uit op ongeveer 40% van het budget dat was gereserveerd voor het volledige programma van 6 maanden.

Wat het mogelijk maakte

Versmalde scope met duidelijke succescriteria. In plaats van \"vervang het claimsysteem\" werd de opdracht \"verwerk 1.000 claims via een nieuwe innamelaag zonder fouten, vóór Q3.\" Dat is een toetsbaar resultaat. Je weet wanneer je het hebt bereikt.

Wekelijkse productiedeployments. Elke vrijdag stond er iets live met echte gebruikers en echte claims. Dit dwong tot vroege ontdekking van integratieproblemen: in plaats van ze tegen te komen tijdens UAT, vonden we ze al in week 1 met vier schade-experts en losten we ze op voordat ze tot vertraging leidden.

Verantwoordelijkheid bij één team. Eén team hield de volledige cyclus in handen, van briefing tot gedeployde code. Er was geen QA-overdracht, geen apart integratieteam, geen change approval board tussen de developers en de productieomgeving. Als er iets kapotging, losten dezelfde mensen die het hadden gebouwd het ook op.

De schatting van 6 maanden was niet onredelijk, gegeven de oorspronkelijke scope. De levering in 6 weken was geen magie. Het was het resultaat van het beperken van de scope tot wat daadwerkelijk moest veranderen, continu leveren, en het wegnemen van de overdrachtsmomenten waar vertragingen zich opstapelen.