Wer den Schaden hat, hat keinen Service

Zumindest noch nicht. Wieso haben Versicherer eigentlich keinen genormten Webservice zur Meldung von Schäden? Kein Witz! Es gibt bis dato keinen offiziell nach BiPRO Normen arbeitenden Service, der es ermöglicht eine Schadenmeldung direkt an den Versicherer abzusetzen. 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 realisiert hat.

Zu Beginn des Jahres 2019 haben sich die Zeitspringer aus Pforzheim mit mir zusammengesetzt und wir haben gemeinsam mit einem deutschen Versicherer an der Idee eines Schaden Services nach BiPRO Norm 503 gearbeitet, mit dem es möglich sein soll Schadendaten an den Versicherer zu senden.

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.

Was passiert eigentlich im Schadenfall?

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 zusammen und sendet dieses dann per E-Mail oder tatsächlich noch per Fax an den Versicherer. 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 Schadenprozess schon irgendwie ein wenig wie aus dem letzten Jahrtausend.

Wie sollte der Schadenprozess im Jahr 2019 aussehen?

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 benötige, 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 ein 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 BiPRO dazugehörigen BiPRO Normen und der Anbindung des Schadenservices dann doch sehr komfortabel einfach.

Ein ganzes Orchester an Services

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.

  • BiPRO Norm 503 zur Meldung eines Schadens an den Versicherer inkl. Regulierungsangaben
  • BiPRO Norm 430.5 zur Übermittlung von schaden- und leistungsbezogenen Daten
  • BiPRO Norm 480.4 zur Suche von Versicherungsnehmern im Datensystem des Versicherers
  • BiPRO Norm 501 zur Anforderung des aktuellen Datenbestands eines Versicherungsnehmers
  • BiPRO Norm 502 zur Anforderung des aktuellen Datenbestands eines Vertrages (Partnerdaten und -dokumente)

Insgesamt habe ich fünf Normen für die Zeitspringer 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.

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.

Und was ist mit GDV genormten Daten?

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.

Die Technik

Über das komplette Jahr 2019 hinweg ist für die zeitsprung GmbH & Co. KG aus Pforzheim ein PHP MVC Framework auf grüner Wiese entstanden, welches sich ausschließlich auf die Anbindung und Realisierung von BiPRO genormten Webservices 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 zukünftiger Consumer 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. Ich persönlich finde das schon ziemlich sexy.

Die Zukunft

Wie man mir sagte, wäre dies der erste BiPRO genormte Service für Schadenmeldungen, der demnächst von einer nicht ganz kleinen deutschen Versicherung genutzt wird. Das Datenmodell ist bereits jetzt schon sehr komplex und deckt allerhand 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.

Ihr wollt mehr?

Na? Konnte ich Eure Neugier wecken? Für weitere Informationen stehen Euch die unfassbar beeindruckenden Köpfe der zeitsprung GmbH & Co. KG mit Rat und Tat zur Seite.

zeitsprung GmbH & Co. KG
Zentrale: +49 (0) 7231 166093-0
Support: +49 (0) 7231 166093-2
Fax: +49 (0) 7231 166093-1
service@zeitsprung.digital

Natürlich dürft ihr Eure Fragen auch hier in den Kommentaren stellen. Ich versuche zeitnah zu antworten.

About Author: Marcel
Ich bin Senior PHP Developer bei MM Newmedia. Seit 2005 bin ich begeisterter Webentwickler und arbeite als Freelancer für namenhafte Firmen und entwickle jede Menge abgefahrenes Zeug und berichte darüber in meinem Blog.

2 thoughts on “Wer den Schaden hat, hat keinen Service

  • Hi Marcel. Wie hast Du es geschafft, die Entitäten von den Daten zu entkoppeln? Ich hab Deinen Quellcode zur Norm 410 angesehen. Da waren viele encode-Funktionen drin, die letztlich z.B. SaopVar exportiert haben. Ist es so, dass man dann alle Entitäten immer erweitern muss? So ganz durchschaue ich noch nicht die Trennung von Daten-Objekten und dem Teil, der das rendern muss. Man könnte ja annehmen, dass man 3 Renderklassen schreibt, für Soap, JSON und ggf Datenbank und dann das nackte Formar, also den Objektbaum übergibt.

    • Hallo Tom,

      so wie es im beispielhaften Quellcode der Norm 410 zu sehen ist, ist es lediglich für das Beispielmodul praktikabel. Das Beispielmodul enthält keine Render Klasse. Sofern man die Entitäten normübergreifend nutzen möchte, wird man an den Punkt kommen, an dem einer Deiner Ansätze wahrscheinlich unumgänglich sein wird. Ein Soap Renderer erzeugt aus dem Entitäten-Objektbaum einen entsprechenden SoapVar Objektbaum. Dieser Objektbaum wird dann durch die PHP nativen SoapServer und SoapClient Klassen automatisch in valides XML umgewandelt. Aus meiner Sicht sind SoapVar Objekte zwingend notwendig, um XML Typen und die verschiedenen Namensräume sauber abbilden zu können. Ein JSON Renderer wäre denkbar, ist aber nicht zwingend notwendig, weil PHP das JSONSerializable Interface mitbringt. Dieses könnte man über eine abstrakte Klasse für BiPRO Entitäten implementieren, von der sich alle Entitäten ableiten und somit ihre Eigenschaften im JSON Format zur Verfügung stellen können. Für Datenbanken finde ich den Einsatz von BiPRO Entitäten schwierig, da hier Primär- und Fremdschlüssel nicht als Eigenschaften der Eintitäten vorhanden sind. Grundsätzlich ließe sich aber auch das realisieren.

      Ich verfolge mittlerweile den Ansatz die WSDL Datei in das Rendering über BiPRO Entitäten mit einzubeziehen. Anhand der WSDL Datei ist die Struktur des Objektbaums einer Response bzw eines Requests definiert und alle zu verwendenden XML Typen und Namensräume findet man hier auch. Aus diesen Informationen ließe sich der BiPRO Entitäten Objektbaum in einen sauberen SoapVar Objektbaum umwandeln. Somit gelangt man dann in eine strikte seperation of concerns Umsetzung.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.