Lösungen von zeitsprung
für Versicherungsgesellschaften
für Makler, Pools & Vertriebe
Unser BiPRO-Softwareentwickler Marcel teilt seine Eindrücke, Erfahrungen und Ideen mit dem zeitsprung BiPRO Server 503 für den Schadenbereich. Kurzweilig, lebendig und ehrlich - wie immer. Das Motto: Wer den Schaden hat, hat hoffentlich Service...
Von der Idee der digitalen Schadenmeldung zum Prozessorchester mit BiPRO Normen
Wieso haben Versicherer eigentlich keinen genormten Webservice zur Meldung von Schäden? Kein Witz! Es gibt bis dato keinen offiziell vollständig (Hin- und Rückweg inkl. Fremdschlüsseln) nach BiPRO Normen arbeitenden Service, der es ermöglicht eine Schadenmeldung direkt an den Versicherer abzusetzen und ein Schadentracking darauf zu machen. :( Ganz genau so habe ich auch aus der Wäsche geguckt, als man mir sagte, dass ich der Erste wäre, der einen BiPRO genormten Schaden Server in diesem Umfang realisiert und in Produktion gebracht hat.
Zu Beginn des Jahres 2019 haben wir uns zusammengesetzt und wir haben gemeinsam mit einem deutschen Versicherer an der Idee eines Schaden Services nach BiPRO Norm 503 und Norm 430.5 gearbeitet, mit dem es möglich sein soll Schadendaten an den Versicherer zu senden und den kombinierten Schadenstatus-Rückweg zu realisieren.
Wir alle haben die Idee nach Fertigstellung der ersten Version des Schaden Services ein paar Monate reifen lassen und stehen heute hier mit einem Schaden Service, der nicht einfach nur ein Schaden Service ist, sondern eine ganze Reihe von BiPRO Webservices abbildet, die gemeinsam miteinander funktionieren, um am Ende eine vollständige Schadenmeldung absetzen zu können. Aber bevor ich Euch verrate, was wir da entwickelt haben, werfen wir zunächst mal einen Blick auf die Ist-Situation.
Wenn ich als Versicherungsnehmer einen Schaden habe, und diesen meiner Versicherung melden möchte, wende ich mich in den meisten Fällen an meinen Versicherungsmakler oder an die Plattform, über die ich den Vertrag abgeschlossen habe. Entweder wird der Schaden dort per Telefon aufgenommen oder man ist schon so weit in der Zukunft angekommen, dass ich den Schaden über ein Formular auf einer Website eingeben kann. Aber was passiert eigentlich danach?
Aus eigener Erfahrung bei einem größeren Online-Vergleicher weiß ich, dass der Prozess jetzt erst so richtig los geht. Der Makler läuft dem Versicherungsnehmer oftmals eine Zeit lang hinterher, da die erste abgegebene Schadenmeldung unvollständig war. Ist sie laut Meinung des Maklers vollständig, fasst er sie meist in einem standardisiertem PDF Dokument und/oder Schadenformular zusammen und sendet dieses dann per E-Mail oder tatsächlich noch per Fax an den Versicherer (wir hätten z.B. gar kein Faxgerät mehr). Auf Seiten des Versicherers sitzt dann jemand und wertet das PDF Dokument aus und gibt die Daten dann in das System des Versicherers ein. Meist erfolgen hier aber noch ein paar Nachfragen zum Schaden, so dass sich der Prozess aus heutigen Gesichtspunkten schier endlos in die Länge zieht.
Irgendwie haben wir aber auch 2019 und schieben so ein riesiges Thema namens Digitalisierung vor uns her. Da wirkt so ein real existierender analoger Schadenprozess schon irgendwie ein wenig wie aus dem letzten Jahrtausend.
Aus meiner Sicht - als Programmierer - stellt es sich recht einfach dar. Der Rahmen für eine standardisierte Schadenmeldung ist mit den Normen des BiPRO e.V. eigentlich schon gesteckt. Die technischen Voraussetzungen, um einen digitalen Schadenprozess von Anfang bis Ende umzusetzen, sind im Grunde genommen auch gegeben. Wie könnte man das also realistisch darstellen?
Ich gehe erstmal auf die Situation bei einem Vergleichsportal ein. Durch den BiPRO Standard weiß ich, welche Daten ich unmittelbar zur Verfügung habe, um einen Schaden an ein Versicherungsunternehmen zu melden. Mit diesem Wissen lässt sich also ein ganz einfacher Prozess programmieren. Die meisten Vergleichsportale bieten ihren Nutzern einen passwortgeschützten Bereich an, in dem der User dann seine Verträge einsehen kann. Quasi eine Art digitaler Versicherungsordner. Es wäre denkbar, dass man hier über einen Button „Schaden melden“ auf ein Schadenformular gelangt, welches dem User ermöglicht alle benötigten Daten zum Schaden anzugeben. Darüber hinaus könnte der User bereits hier Dokumente für Rechnungen oder Gutachten hochladen und die Schadenmeldung somit noch ausführlicher gestalten. Sobald der User die Schadenmeldung absendet, läuft diese im Maklerverwaltungsprogramm des Vergleichers auf. Hier kann der Makler die Schadenmeldung nochmals mit aktuellen Vertrags- und Partnerdaten anreichern. Darüber hinaus kann er hier auch schon Regulierungsinformationen, z.B. ein Vorschlag, in welcher Höhe der Schaden reguliert werden soll, an den Versicherer weitergeben.
Der Versicherer erhält in diesem Fall eine qualitativ hochwertige Schadenmeldung, die im allerbesten Fall keine Rückfragen mehr zulässt. Somit kann der Versicherer direkt in die Regulierung gehen und diese dem Makler direkt mitteilen. Der Makler seinerseits kann mit einer Nachmeldung reagieren oder die Rückmeldung des Versicherers direkt an den Versicherungsnehmer in Form von Daten und Dokumenten weitergeben.
Rein technisch gesehen müsste in der Strecke vom Versicherungsnehmer über den Makler hin zum Versicherungsunternehmen und wieder zurück kein Mensch mehr stehen. Soweit möglich können alle Mechanismen zur Validierung auch technisch dargestellt werden. Einfache Regulierungsentscheidungen könnten seitens des Versicherers auch automatisiert dargestellt werden. Lediglich bei umfangreicheren Schäden müsste der Versicherer tätig werden.
Klingt vielleicht erstmal ein wenig komplex. Ist aber mit der Umsetzung der Webservices mit dazugehörigen BiPRO Normen und der Anbindung des Schadenservices dann doch sehr komfortabel und einfach.
Der gerade beschriebene Prozess lässt sich tatsächlich heute schon realisieren. Mittlerweile sind wir mit dem BiPRO Schaden Service in der Lage verschiedene Use Cases abzudecken. Werfen wir aber zunächst einmal einen Blick auf die einzelnen realisierten Services.
Insgesamt habe ich fünf Normen hierfür umgesetzt, die allesamt sowohl einzeln als auch miteinander funktionieren. Gerade bei einem Schadenfall ergeben diese Services in Zusammenarbeit einen ziemlich großen Vorteil.
Vor dem Absetzen der Schadenmeldung kann der Makler den aktuellen Datenbestand zum Versicherungsnehmer und zum betroffenen Vertrag beim Versicherer abfragen. Somit wird sichergestellt, dass aktuelle Daten in der Schadenmeldung vorhanden sind. Nur mit aktuellen Daten werden Rückfragen seitens des Versicherers reduziert bzw. ganz vermieden. Der Makler selbst hält seinen Datenbestand somit auch so aktuell wie möglich in dem er die Daten für seine eigene Verwaltungssoftware weiternutzt.
Ist die Schadenmeldung an den Versicherer übermittelt worden, kann der Makler jederzeit aktuelle Daten zum Schaden abrufen und seinem Kunden im Endeffekt immer aktuell Auskunft zum Stand der Bearbeitung seines Schadens liefern.
Selbst Regulierungsdaten kann der Makler an das Versicherungsunternehmen senden. Somit werden auch Makler mit Regulierungsvollmacht berücksichtigt.
Viele Versicherer arbeiten ausschließlich mit GDV genormten Daten. Auch dafür hat man sich eine entsprechende Lösung einfallen lassen. Für den BiPRO Schaden Server hat man gleichzeitig einen GDV Adapter programmiert, der es ermöglicht die erhaltenen Daten aus den BiPRO genormten Requests in GDV Daten zu wandeln, so dass Consumer, die einen GDV genormten Datenbestand pflegen, diesen Schaden Service benutzen können. GDV Schadenmeldungen können wir also auch noch, falls Versicherer den Schadenbereich nur über das GDV Schadennetz verarbeiten könnten.
Über das komplette Jahr hinweg ist ein PHP MVC Framework entstanden, welches sich ausschließlich auf die Anbindung und Realisierung von BiPRO genormten Provider-Webservices für den Bestands- und Schadenbereich konzentriert. In dieses PHP Service Framework sind meine Erfahrungen der letzten Jahre im Umgang mit BiPRO Webservices und SOAP XML im Zusammenhang mit PHP eingeflossen. Das Erstellen von XML Requests und Responses auf Basis von PHP Entitäten, welche den BiPRO Definitionen entsprechen, wird somit zum Kinderspiel. Fakt ist aber auch, dass ich mit dieser objektorientierten Struktur frei entscheiden kann, in welchem Format ich die Daten am Ende liefere. Für den BiPRO Webservice sind es XML Daten. Für eine REST API sind es Daten im JSON Format und für die interne Weiterverarbeitung bleiben wir einfach bei den PHP Objekten.
Auf Basis dieses Frameworks ist auch der Schaden Server entstanden, der BiPRO genormte Schadenmeldungen entgegen nimmt und diese so aufarbeitet, dass die Kommunikation zwischen Service Consumer und Provider so schnell und ressourcenschonend wie möglich über die Bühne geht. Unter strikter Beachtung aktuell gültiger Web Standards soll die Anbindung vieler weiterer Provider (Versicherungsgesellschaften) des Schaden Services so einfach wie möglich gehalten werden.
Für die Speicherung der Daten in der Datenbank wurde ein eigenes kleines ORM System entwickelt, welches die relationale Datenbankstruktur direkt in PHP Objekten abbildet.
Zusammengefasst ist alles auf BiPRO getrimmt, bleibt aber soweit offen, dass auch andere Datenformate bedient werden können. Wir finden das insgesamt betrachtet schon ziemlich bemerkenswert.
Wie man mir sagte, wäre dies der erste BiPRO genormte Service für Schadenmeldungen in dieser Ausprägung, der bereits produktiv von einer nicht ganz kleinen deutschen Versicherung genutzt wird. Das Datenmodell ist bereits jetzt schon sehr komplex und deckt alle Anwendungsfälle ab.
Meiner Meinung nach könnte man den BiPRO Schadenprozess technisch aber noch weiter vereinfachen. Gerade mit Hinblick auf RNext, bei welchem die BiPRO selbst gerade dafür sorgt, dass die aufwendig gestalteten Normen weiter verwässert, dezentralisiert und dadurch aus meiner Sicht unbrauchbar im Sinne einer Norm macht, bietet dieser BiPRO Schaden Server ein unglaublich gutes Beispiel, wie man BiPRO auch als JSON verwenden kann, ohne die Norm neu erfinden zu müssen. Warum auch? Die Norm funktioniert so wie sie ist schon verdammt gut.
Spinnt man die bereits jetzt machbaren Möglichkeiten weiter, wären z.B. automatisierte Schadenmeldungen aus Kraftfahrzeugen denkbar. Schon heute sind Fahrzeuge technisch so gut aufgestellt, dass sie selbstständig eine technische Analyse durchführen können. Findet ein Unfall statt, könnte das Fahrzeug den selbst ermittelten Schaden mit dem im Fahrzeugsystem gespeicherten Versicherungsdaten nutzen, um eine Schadenmeldung selbstständig an den Versicherer abzusenden.
Das wäre nur eine Idee, die mir da gerade durch den Kopf schießt und erste Gespräche mit anderen Branchen finden ja bereits im Vertrieb statt. Ich freue mich also auf meine Zukunft in diesem Betriebssegment und bin sicher, dass mir die Arbeit nicht ausgeht.
Wir haben vor Kurzem ein Interview mit unserem Business Analyst Wilhelm Brenner gemacht - schaut mal rein: https://www.youtube.com/watch?v=uwM5ek73ZAE
