Von 6 Monaten auf 6 Wochen: der Neuaufbau eines Schadensystems in der Versicherungsbranche

Ein niederländischer Schaden- und Unfallversicherer kam mit einem vertrauten Problem zu uns: ein Schadenaufnahmesystem, das Sachbearbeiter ausbremste, Daten zwischen Übergaben verlor und seit drei Jahren auf der Modernisierungs-Roadmap stand, ohne dass sich etwas bewegte.

Das bestehende System war eine Kombination aus einer 15 Jahre alten On-Premise-Anwendung, einem gemeinsam genutzten E-Mail-Postfach als Warteschlange und drei manuellen Übergabeschritten zwischen der Aufnahme und dem Sachbearbeiter, der den Schaden tatsächlich bewertete. Durchschnittliche Zeit von Aufnahme bis Zuweisung: 4 Stunden. Fehlerquote bei der initialen Datenerfassung: 12%.

Der Business Case war klar. Die Frage war, wie man dorthin kommt, ohne ein 8-Monats-Projekt zu riskieren, das mitten in einen regulatorischen Freeze fallen würde.

Warum der klassische Ansatz nicht funktioniert hätte

Der Lehrbuch-Ansatz für ein Projekt dieser Art umfasst Discovery, Anforderungsdokumentation, Vendor-Auswahl, Design, Build, QA, UAT und Deployment. Sequenziell durchlaufen, mit Freigabe bei jeder Stufe, dauert das typischerweise 6–9 Monate.

Für dieses Projekt gab es zwei konkrete Blocker.

Erstens, das regulatorische Umfeld. Neue Meldepflichten für Schadendaten traten in Q3 in Kraft, was bedeutete, dass jedes Ersatzsystem vorher live sein musste – sonst hätte die Organisation für bereits laufende Schäden zwei Systeme parallel betreiben müssen.

Zweitens, die Integrationskomplexität. Das Schadensystem war mit sechs weiteren internen Systemen verbunden: Policendaten, Zahlungsabwicklung, Dokumentenspeicher, Kommunikationsprotokolle, das Terminplanungssystem der Sachbearbeiter und das regulatorische Meldesystem. Jede Integration hatte einen eigenen Datenvertrag, verantwortet von einem anderen internen Team.

Ein 6-Monats-Wasserfallprojekt mit sechs Integrationspunkten und einer harten regulatorischen Deadline war kein Plan. Es war ein Risiko.

Was wir stattdessen gemacht haben

Wir schlugen einen anderen Scope vor. Statt das gesamte Schadensystem zu ersetzen, würden wir die Intake-Schicht ersetzen: den Teil, in dem Schäden eingingen, validiert und an Sachbearbeiter weitergeleitet wurden. Das war der schmerzhafteste Teil des bestehenden Systems und der mit dem direktesten Einfluss auf die Produktivität der Sachbearbeiter.

Der Ansatz:

• Start mit einem funktionierenden Intake-Formular, das am Tag 1 mit dem Policendatensystem verbunden ist – ohne vollständige Integrationssuite, nur mit der einen Verbindung, die zur Validierung des Schadens nötig ist
• Ein Integrationspunkt pro Woche, in der Reihenfolge des geschäftlichen Impacts
• Jeden Freitag Deployment in die Produktion, mit einer Teilmenge echter Schäden, die durch das neue System verarbeitet werden
• Das Legacy-System parallel weiterlaufen lassen, bis die neue Intake-Schicht 1.000 Schäden fehlerfrei verarbeitet hatte

Der Zeitplan

Woche 1: Funktionierendes Intake-Formular, verbunden mit den Policendaten. Erste echte Schäden werden durch das neue System verarbeitet, ein Pilot mit vier Sachbearbeitern.

Woche 2: Integration der Zahlungsabwicklung. Integration des Dokumentenspeichers. Pilot auf 20 Sachbearbeiter erweitert. Fehlerquote bei der initialen Datenerfassung sinkt von 12% auf 2,4%.

Woche 3: Integration der Kommunikationsprotokolle. Automatisierte Routing-Regeln: Schäden werden Sachbearbeitern nach Deckungsart und Auslastung zugeordnet.

Woche 4: Integration der Sachbearbeiter-Terminplanung. Echtzeit-Warteschlangen-Dashboard für Teamleiter sichtbar.

Woche 5: Integration des regulatorischen Meldesystems. Vollständiges Compliance-Logging für jedes Schadenereignis.

Woche 6: Traffic auf dem Legacy-System für neue Schäden auf null reduziert. 1.247 Schäden über die neue Intake-Schicht verarbeitet.

Sechs Wochen vom Kick-off bis zur vollständigen Produktionsumstellung, vor der regulatorischen Deadline in Q3.

Das Ergebnis

Die messbaren Ergebnisse in Woche 6:

• Zeit von Aufnahme bis Zuweisung: von 4 Stunden auf 22 Minuten
• Fehlerquote bei der Datenerfassung: von 12% auf 1,8%
• Freigesetzte Sachbearbeiter-Kapazität pro Woche: rund 11 Stunden (zuvor aufgewendet für manuelle Datenkorrektur und Warteschlangenmanagement)
• Alle sechs Integrationspunkte live und unter realer Last getestet

Das Projekt blieb bei rund 40% des Budgets, das für das vollständige 6-Monats-Programm vorgesehen war.

Was es möglich gemacht hat

Verengter Scope mit klaren Erfolgskriterien. Statt „das Schadensystem ersetzen" lautete das Briefing „1.000 Schäden fehlerfrei über eine neue Intake-Schicht verarbeiten, vor Q3". Das ist ein überprüfbares Ergebnis. Man weiß, wann man es erreicht hat.

Wöchentliche Produktions-Deployments. Jeden Freitag war etwas live, mit echten Nutzern und echten Schäden. Das erzwang die frühe Entdeckung von Integrationsproblemen: Statt sie im UAT zu finden, fanden wir sie in Woche 1 mit vier Sachbearbeitern und lösten sie, bevor sie zu Verzögerungen wurden.

Verantwortung durch ein einziges Team. Ein Team verantwortete den gesamten Loop vom Briefing bis zum deployten Code. Es gab keine QA-Übergabe, kein separates Integrationsteam, kein Change-Approval-Board zwischen den Entwicklern und der Produktionsumgebung. Wenn etwas kaputtging, reparierten es dieselben Leute, die es gebaut hatten.

Die 6-Monats-Schätzung war angesichts des ursprünglichen Scopes nicht unangemessen. Die 6-Wochen-Lieferung war keine Magie. Sie war das Ergebnis davon, den Scope auf das zu reduzieren, was sich tatsächlich ändern musste, kontinuierlich zu deployen und die Übergabepunkte zu entfernen, an denen sich Verzögerungen ansammeln.