ID#51

08.11.2022

Bernhard Klett, Maria Oganian, mgm: Digitale Zusammenarbeitsmodelle in der Industrieversicherung – ID#51

Wie genau arbeiten die Marktpartner in der Industrieversicherung im Alltag digital miteinander? Bernhard Klett und Maria Oganian teilen Erkenntnisse aus ihrer IT-Expertensicht als Projektleiter und Business Analystin, sprechen über den Digitalisierungsalltag, Schnittstellen und Erfolgsfaktoren.
Im Gespräch: Bernhard Klett, Maria Oganian und Toni Klein
Länge: 33 Minuten

Transkript

 

Toni Klein: Hallo und herzlich Willkommen zu einer neuen Episode unseres Podcasts. Mein Name ist Toni Klein. Heute werden wir das Thema digitale Zusammenarbeit in der Industrieversicherungsbranche etwas näher beleuchten. Meine beiden Gäste haben beide eher einen mathematisch-naturwissenschaftlichen Hintergrund und sind Experten für Digitalisierungsprojekte in der Industrieversicherungsbranche, zum einen als Business-Analysten, zum anderen als Projektleiter. Ich begrüße herzlich Maria Oganian und Bernhard Klett, beide von mgm technology partners. Hallo.

 

Maria Oganian: Hallo zusammen.

 

Bernhard Klett: Hallo Toni. Ich freue mich auf das Gespräch.

 

Maria Oganian: Ich mich auch.

 

Toni Klein: Ich freue mich auch. Wir duzen uns, weil wir uns schon eine Weile kennen. Ich starte gleich einmal mit der ersten Frage, um das einmal ein bisschen einzugrenzen: Digitale Zusammenarbeit bedeutet, dass mehrere Parteien oder Partner miteinander arbeiten und die Industrieversicherungsbranche ist teilweise schon sehr komplex und es gibt viele Player. Wenn wir heute darüber sprechen, haben wir uns geeinigt, benutzen wir das Wort Marktpartner. Bernhard, ich wollte einmal dich fragen, wenn du das Wort Marktpartner hörst, woran denkst du dann aus deiner täglichen Arbeit heraus?

 

Bernhard Klett: Prinzipiell denke ich erst einmal daran, dass es natürlich die Risikoträger gibt, wir haben auf der anderen Seite Makler und in einigen Fällen gibt es noch einmal die Möglichkeit, dass es einen Assekuradeur gibt, der bestimmte Underwriting-Vollmachten von den Risikoträgern bekommt. Das sind grundsätzlich erst einmal diese drei Gruppen, die ich sehe. In der Praxis könnte man es natürlich noch weiter aufspalten und sagen, ein Rückversicherer zum Beispiel arbeitet noch einmal ein bisschen anders als ein Versicherer und bei den Rückversicherungsmaklern ist es ähnlich, aber grundsätzlich würde ich sagen, dass wir die drei Gruppen haben.

 

Maria Oganian: Was mir noch spontan dazu einfällt, man hätte noch den Versicherungsnehmer, der ein Marktpartner sein kann und im ganz speziellen Fall, wenn man verschiedene Abteilungen innerhalb von einer Firma oder von einem diesen Partner innerhalb von Maklerhäusern oder Risikoträgerhäusern hat, dass es auch Inhouse-Marktpartner sein können.

 

Toni Klein: Also ist es ganz komplex, weil Makler auch mit anderen Maklern zusammenarbeiten, mit mehreren Versicherern. Bei der digitalen Zusammenarbeit habt ihr beide als Projektmitarbeitende und Projektleiter viel Erfahrung. Wie würdet ihr digitale Zusammenarbeit definieren? Ist das schon, dass man miteinander End-to-End-Prozesse teilt oder wie würdet ihr das einordnen von den Leveln, was man digital miteinander tun kann?

 

Maria Oganian: Es gibt verschiedene Abstufungen. Wenn man auf digitale Zusammenarbeit schaut, könnte man ganz banal anfangen und sagen, eine E-Mail oder ein Telefonanruf ist schon einmal eine digitale Zusammenarbeit, was aber ganz unstrukturierte Daten sind, die man miteinander austauscht. Dann gibt es eine nächste Stufe, zum bisschen Excel-Sheets, wo es ein bisschen strukturierter zugeht, aber noch nicht ganz digital, wenn man Excels hin und her schickt, und dann kommen wir schon in die stärkere Digitalisierung, wenn zum Beispiel Portal- oder Webseiten, sogenannte Digital Points of Sales, wo wirklich strukturiert Daten ausgetauscht werden, wo Marktteilnehmer miteinander reden können und sich austauschen können, und dann gibt es noch einen Schritt weiter, wo wirklich komplette Systeme miteinander reden, vielleicht Synchronisationen stattfinden. Also das zum einen mit dem digitalen Zusammenhalt und zum anderen, wenn man von digitalen End-to-End-Prozessen spricht, geht es eher darum, wie die Ausbaustufe von der Digitalisierung ist, also wie viel von dem Prozess wirklich digital abläuft.

Ist das der komplette Prozess von Anfang bis Ende oder ist es nur ein Teil, wie zum Beispiel ein Angebot kann digital gerechnet werden und die Police können digital abgeschlossen werden und das sind die verschiedenen Ausbaustufen. Je nachdem, was man als Anfang und Ende definiert, kann man dann von End-to-End-Prozessen sprechen. 4:27

 

Toni Klein: Andere Gäste im Podcast haben gesagt, PDFs hin und her schicken ist für mich keine Digitalisierung. Da würdet ihr sicherlich zustimmen, oder?

 

Bernhard Klett: Ja. Das war ein ganz wichtiger Punkt in dem, was Maria vorhin gesagt hat. Oft ist es so, es gibt natürlich irgendwie einen bestehenden Prozess in den Unternehmen und der erste Gedanke, den zu digitalisieren ist erst einmal, dass man guckt, was sind die einzelnen Schritte und was gibt es für ein digitales Analogon dazu. Dann ist es zum Beispiel so etwas wie, dass man keinen Brief mehr schickt, sondern dann schickt man irgendetwas per E-Mail oder ein Dokument wird eingescannt und solche Sachen. Man könnte sagen, in irgendeiner Form ist es digital, aber es erfüllt erstmal noch nicht das, was sich die Menschen von der Digitalisierung erhoffen, sondern vielfach geht es wirklich darum, dass man Effizienzsteigerungen hat, dass man Kosteneinsparungen hat und da geht es viel darum, dass die Daten nicht einfach nur im System sind, sondern dass sie in einer strukturierten Weise vorhanden sind, sodass sie automatisch weiterverarbeitet werden können.

Das sind wirklich die Stellen, wo wir sehen, dass da wirklich die Effizienzsteigerung da ist, dass Prozesse, wo vorher verschiedene Personen daran arbeiten mussten, Sachen abtippen mussten, etwas einscannen müssen, abspeichern oder wie auch immer, wenn das alles nicht mehr notwendig ist oder diese Absprachen, die wir teilweise sehen zwischen Kollegen oder verschiedenen Marktpartnern, dass die technisch umgesetzt wurden, dass es nicht mehr nötig ist, dass man als Mensch wirklich noch etwas machen muss. Das ist das, was Maria vorhin als eine weitere Ausbaustufe beschrieben hat von der Digitalisierung. 5:58

 

Toni Klein: Wenn wir heute miteinander sprechen, meinen wir nicht Mensch-Maschine-Schnittstelle, sondern Schnittstellen im Kontext Maschine mit Maschine beziehungsweise System mit System beziehungsweise Software oder Applikation mit einer anderen Software. Jetzt gibt es Schnittstellen nicht nur zwischen externen Partnern, Partnern außerhalb des eigenen Unternehmens, sondern auch möglicherweise im Unternehmen. Ihr habt mir erzählt, das trifft in der Praxis häufig zu. Ein Klassiker ist Underwriting-Systeme mit Claim-Systemen. Wie ist da eure Erfahrung in der Praxis? Werden da Schnittstellen gebaut oder wie kommunizieren diese Abteilungen technisch miteinander, außer vielleicht mit E-Mail?

 

Bernhard Klett: Vielleicht ganz kurz, bevor wir in die Frage tiefer einsteigen, um die Zuhörer alle mitzunehmen: Was genau ist eine Schnittstelle? Mit der Frage würde ich ganz kurz anfangen, bevor wir gleich zu deiner Frage kommen, Toni. Grundsätzlich ist es erst einmal so, wenn ich als Mensch mit einem Computer spreche, gibt es eine Nutzeroberfläche und da habe ich die Möglichkeit, dem Computer zu sagen, was er machen soll, oder der Computer kann mir sagen, was er gerade von mir braucht an Daten zum Beispiel.

Das ist eine Form von Schnittstelle, die Schnittstelle zwischen dem Nutzer und dem Programm. Was wir häufiger meinen mit einer Schnittstelle, ist eine technische Schnittstelle, wo ein Computerprogramm oder ein Computer mit einem anderen Programm spricht. Da ist es so, dass da definiert ist, wie die Daten austauschen können, was es für Möglichkeiten gibt, dass man Daten in einem neuen System neu anlegt, überschreibt oder nur abfragt und solche Sachen. Das sind die Schnittstellen, mit denen wir im Alltag sehr viel zu tun haben. Mit den Nutzeroberflächen natürlich auch, aber, wenn wir von einer Schnittstelle sprechen, meinen wir normalerweise diese technischen Schnittstellen, die sogenannten APIs, die es gibt. Die sind das, was es uns ermöglicht, dass wir die Prozesse automatisieren können, dass Daten zwischen Systemen ausgetauscht werden können und so weiter. 8:05

 

Toni Klein: Vielleicht an der Stelle noch ein kleiner Hinweis: Wir haben vor kurzem eine andere Folge dazu im Podcast veröffentlicht. Das ist der Podcast ID 48. Da geht es auch um Schnittstellen und um APIs. Da war es im Zusammenhang mit dem Thema Embedded Insurance oder Affinity, je nachdem von welcher Seite man aus betrachtet. Da geht salopp gesagt um das Einstöpseln von digitalen Lösungen in digitale Verkaufsprozesse von anderen Partnern, zum Beispiel von Produktherstellern, die noch eine produktbezogene Versicherung mit dem Produkt an ihre Endkunden mitverkaufen. Das läuft idealerweise auch über Schnittstellen und vollautomatisch.

Jetzt würde ich gerne noch einmal auf meine ursprüngliche Frage zurückkommen. Die Inhouse-Kommunikation, die digitale Zusammenarbeit innerhalb von einem Unternehmen, also einem Versicherer oder einem Makler, wie sind eure Erfahrungen zu diesem Thema Schnittstellen oder Zusammenarbeit?

 

Bernhard Klett: Ich kann einmal mit einem kleinen Beispiel anfangen und dann würde ich an dich weitergeben, Maria, weil ich weiß, dass ihr in einem von deinen Projekten irgendwie einen sehr schönen Prozess eingebaut habt. Bei mir ist es so, ich bin vor allem auf der Schadenseite tätig. Eine sehr wichtige Schnittstelle, die wir hier haben, ist zu dem Underwriting-System. Das fängt bei uns damit an, wenn wir die Schadenanlage machen, das wir gerne prüfen möchten, macht es überhaupt Sinn, diesen Schaden so anzulegen, gibt es zu diesem Schaden einen gültigen Vertrag, ist der Vertrag zu dem Schadendatum gültig, hat der richtige Deckung, dass diese Art von Schaden überhaupt gedeckt sein kann. Das sind alles Fragen, wo wir die entsprechenden Daten aus dem Underwriting-System abrufen.

Es gibt noch einen anderen Prozess und das beleuchtet es vielleicht noch einmal ganz gut, was es für Ausbaustufen gibt bei der Digitalisierung. Und zwar war ein Beispiel, dass wir neulich hatten, da ging es um einen sogenannten Schadenfreiheitsrabatt und da ist es so, dass es bei dem Renewal der Verträger bestimmte Daten gibt, die von der Schadenseite kommen müssen, die man als Kriterien benutzt, um zu entscheiden, was bei dem Renewal mit der Prämie des jeweiligen Vertrages passiert. Da hatten wir das bei unseren Kunden gesehen, dass die einen sehr umständlichen Prozess hatten, dass wirklich jemand aus der Schadenabteilung die Kollegen im Underwriting angerufen hat und gesagt hat, „Bei dem und dem Vertrag ist ein Schaden vorgefallen, da muss beim nächsten Mal die Prämie erhöht werden und im Underwriting haben die sich ganz umständlich eine Erinnerung im Kalender gemacht und als das Renewal von dem Vertrag anstand, musste man in den Notizen schauen, was passiert mit der Prämie.

Die niedrigste Ausbaustufe wäre gewesen, wenn man die Möglichkeit gehabt hätte, ein Notizfeld zu haben, dann schreibt jemand aus der Schadenabteilung etwas hinein und dann wird es später in dem Vertrag angezeigt, wenn man den verlängern möchte. Das wäre die niedrigste Ausbaustufe gewesen, die man sich da hätte vorstellen können.

Was wir gemacht haben, ist, dass wir wirklich eine technische Schnittstelle umgesetzt haben, die die entsprechend Daten aus dem Vertrag abruft und beim Renewal kann das System automatisch entscheiden, was mit der Prämie passieren soll.

Das bedeutet insbesondere, dass man die Verträge nicht mehr einzeln verlängern und irgendwie muss jedes Mal jemand draufschauen und entscheiden, was mit der Prämie passieren soll, sondern das erlaubt uns vor allem auf der Underwriting-Seite, dass wir das komplette Portfolio verlängern können und dann kann das System bei jedem einzelnen Vertrag selbstständig entscheiden, was mit der Prämie passieren soll, dass wir eine fortgeschrittenere Ausbaustufe direkt haben. Da sehen wir tatsächlich diese Effizienzgewinne, die wir mit einem einfachen Notizfeld zum Beispiel nicht hätten. 11:56

 

Toni Klein: Das bedeutet, dass man Teile von Renewal komplett in Dunkelverarbeitung Portfolio-Management-mäßig abwickeln kann?

 

Bernhard Klett: Genau.

 

Maria Oganian: Vielleicht ein anderes Beispiel noch zu Inhouse-Arten ist zum Beispiel typisch die Buchhaltung. Man hat ein Underwriting, man hat Claims und beide erzeugen irgendwie Buchungen und da gibt es viele Häuser, die ganz umständlich mit verschiedenen Systemen arbeiten. Dann muss die Buchhaltung das alles buchen oder irgendwie eintippen in ihrem Buchungssystem.

Natürlich gibt es irgendwie Systeme, wo das alles aus einer Hand passiert, wo ein System alles kann, Vertragsverwaltung, Schadenverwaltung und Buchhaltung, und dann gibt es die Möglichkeit, die verschiedenen Systeme, die Bestandsverwaltung, das Schadensystem und die Buchhaltung miteinander kommunizieren zu lassen. Das ist ein typisches Beispiel, wo man sehr viel Zeit sparen kann und die Fehlerhäufigkeit niedrig halten kann, weil, wenn man mit Zahlen oder mit irgendwelchen Buchungen umgeht, passiert so ein Type einmal schnell oder ein Zahlendreher. Wenn das natürlich automatisch passiert, hat man die Sicherheit, dass es in den meisten Fällen problemlos und ohne Fehler durchlaufen kann.

 

Toni Klein: Jetzt klingt das total schön, wie wir über die Schnittstellen sprechen. Bezogen auf den Datenaustausch ist es strukturiert, man macht weniger Fehler und es gibt keine manuellen Übertragungen mehr, aber wir wissen aus der Praxis, dass das nur der eine Teil der Wahrheit ist und der andere ist, dass es vermutlich relativ teuer ist, solche Schnittstellen zu bauen. Dann ist es nie damit getan, dass es einfach nur gebaut wird, sondern es muss leben, es muss angepasst werden. Könnt ihr aus dem Bauch heraus sagen, was sind ganz grob Vor- und Nachteile von diesen Schnittstellen?

 

Bernhard Klett: Einen ganz wichtigen Teil hast du gerade schon genannt, Toni. Es ist in der Tat so, dass die Schnittstellen in der Praxis oft aufwendig sind. Der aufwendige Teil ist aber meines Erachtens nicht so sehr, diese Schnittstelle einmal zu bauen, sondern, wie du es gerade schon gesagt hattest, Toni, es ist wirklich so, dass diese Schnittstellen sich mit der Zeit weiterentwickeln. Oft ist es so, dass es noch weitere Informationen gibt, die angefragt werden oder die werden in einer anderen Struktur abgefragt und so weiter. Das ist viel eher der Grund, den wir sehen.

Wir hatten vorhin bei der Schnittstelle gesagt, dass es ein fest definiertes Format gibt, in dem Daten ausgetauscht werden können, in dem Abfragen getätigt werden können und jetzt ist es natürlich so, wenn ich verschiedene Marktpartner habe und die sich darauf verlassen, dass diese Schnittstelle auf eine bestimmte Art und Weise funktioniert, die haben ihre eigenen Arbeitsprozesse darauf aufgebaut. Jetzt ist es so, wenn ich etwas an dieser Schnittstelle ändern möchte, reicht es nicht, die Schnittstelle zu ändern, das ist der kleinere Teil der Arbeit, sondern es ist so, dass wir diese ganzen Folgeeffekte noch sehen, dass bei allen, die ihre Arbeitsprozesse darauf aufgebaut haben, dass die unter Umständen noch einmal ihre eigenen Systeme anpassen müssen. Das ist der Teil, der das sehr komplex machen kann.

In dem Moment, wo eine Schnittstelle von anderen genutzt wird, wird es auf einmal sehr viel aufwendiger, die Schnittstelle noch einmal anzupassen, weil es alle anderen Systeme gibt, die implizit Erwartungen haben daran, wie diese Schnittstelle funktioniert. Da sehen wir das in der Praxis oft, dass es auf einmal nötig ist, dass man nicht nur eine Version dieser Schnittstelle hat, sondern vielleicht noch eine ältere Version, damit alle, die die Schnittstelle benutzen, die Möglichkeit haben, erst einmal ihre Systeme an die neue Version anzupassen, damit es in der Verarbeitung keine Lücken gibt, dass sie weiterhin diese Schnittstelle nutzen können, bis sie wirklich in der Lage sind, auf die neuere Version umzuswitchen. Das sind die Sachen, wo wir das viel häufiger sehen, dass die großen Aufwände damit verbunden sind.

Das Ganze Inhouse, zwischen den eigenen Systemen, zu machen, ist tendenziell ein bisschen einfacher, weil es weniger Absprachsbedarf ist. Diese Kollaboration ist leichter an der Stelle, sich im eigenen Unternehmen abzusprechen, als wenn man mit verschiedenen externen Partnern zusammenarbeitet. Das macht es natürlich deutlich schwieriger, noch einmal Anpassungen zu machen an der Schnittstelle. 16:28

 

Toni Klein: Das ist mein Stichwort. Wenn man seine Partner datentechnisch zusammenbringen will, um gemeinsam Vertrieb zu machen, Policen zu verkaufen und Risiken zu decken, wer bezahlt dann die Schnittstellen? Man sagt immer, wir laden unsere Partner ein, auf die Plattformen zu kommen, aber wie es ist das in der Praxis bei euch? Gibt es da Diskussionen oder wird das geteilt oder habt ihr dazu irgendwelche praktischen Erfahrungen schon gemacht?

 

Maria Oganian: Es gibt ganz unterschiedliche Kooperationsmodelle. Genau wie du sagst, man teilt sich die Kosten oder der eine Partner übernimmt die Kosten, weil es für ihn mehr Vorteile bringt oder aus Marketinggründen oder aus sonstigen. Da gibt es ganz unterschiedliche Zusammenarbeitsmodelle. Das kann man so pauschal gar nicht beantworten, was die beste Strategie da ist.

 

Toni Klein: Wenn wir einmal von der Inhouse-Sicht auf die Sicht der Marktpartner wechseln, die tatsächlich extern miteinander arbeiten, Makler mit Versicherern, Assekuradeure mit Maklern, vielleicht Versicherungsnehmer mit Versicherern oder Risikoträgern selber, stelle ich mir das relativ kompliziert, das ist das, was ihr beide gerade gesagt habt, dort Schnittstellen miteinander zu definieren. Was würdet ihr sagen, wie muss eine Geschäftsbeziehung sein zwischen zwei Marktpartnern, damit so etwas funktionieren kann? Was sind da eure Erfahrungen, Maria?

 

Maria Oganian: Im ersten Schritt ist, beide Parteien müssen daran Interesse haben. Es bringt nichts, wenn der eine Partner möchte und der andere nicht, weil, wie Bernhard gesagt hat, die Kommunikationsbereitschaft muss wirklich da sein. Man muss sehr viel miteinander abstimmen, man muss vielleicht Kompromisse eingehen, man muss abstimmen, welche Sachen können dunkelverarbeitet werden, was gibt es für Regeln, die KOs sind, wo man sagt, das darf auf keinen Fall dunkel-, digitalverarbeitet werden.

Man muss wirklich sehr viel und vor allem beim Aufbau der Schnittstelle sehr oft miteinander reden und ins Gespräch gehen, Details klären, weil oft ist es so, das Grobe steht vielleicht nach ein, zwei Wochen, das ist vielleicht geklärt, und dann merkt man wirklich, der Teufel steckt im Detail, hier gibt es noch Fragen. Da muss wirklich die Kommunikationsbereitschaft sehr hoch sein und von daher ist es sinnvoll, wenn man ein gutes Verhältnis miteinander hat und beide Parteien Interesse daran haben, da eine Digitalisierung voranzutreiben. 19:11

 

Bernhard Klett: Vielleicht eine kleine Ergänzung dazu: Das Erste, was du gerade genannt hattest, Maria, war diese Kommunikationsbereitschaft. Der tiefere Grund, warum die wirklich notwendig ist, ist, dass wir insbesondere in der Industrieversicherung sehen, dass die Arbeitsprozesse bei den verschiedenen Kunden sehr unterschiedlich sind, auch wenn sie formal das Gleiche machen, in dem Sinne, dass sie irgendwie Risikoträger oder Makler sind. Es gibt immer einmal wieder diese Diskussion, dass man nicht irgendwie einen Standard benutzen kann. Das würde es in der Tat einfacher machen. Wenn alle einem gemeinsamen Standard folgen würden, bräuchte man diese Absprache nicht.

In der Praxis ist das tatsächlich so, dass wir sehen, dass die Unternehmen, auch wenn sie formal das Gleiche machen oder ähnliche Sachen machen, dass sie halt trotzdem immer ihre eigene Art und Weise haben, das zu machen, ihre eigenen Sonderheiten haben. Zumindest wenn die Unternehmen daran festhalten müssen oder möchten, ist es tatsächlich notwendig, dass sie mit dem Partner, mit dem sie zusammenarbeiten, in diesen engen Kontakt treten.

Für den Fall, dass sie bereit sind, davon abzuweichen, macht die Idee mit dem Standard tatsächlich einen Sinn. Da ist natürlich noch einmal die Frage, wer entscheidet, wie dieser Standard aussieht und so weiter. Das ist auch nicht ohen Probleme. Das sind eigentlich diese beiden Möglichkeiten, die wir haben. In der Praxis sagt meine Erfahrung mir, dass es vor allem so ist, dass die Unternehmen gerne an ihrer alten Arbeitsweise festhalten möchten. 20:39

 

Toni Klein: Du meinst, dass verschiedene Arbeitsweise unterschiedliche Prozesse nach sich führen und damit ein Datenaustausch erschwert wird?

 

Bernhard Klett: Jetzt kommen wir wieder ein bisschen zu diesen Ausbaustufen von der Digitalisierung zurück. Erst einmal Daten austauschen kann man machen, das ist erst einmal nicht das Problem. Das Problem bei den Schnittstellen ist, dass die Daten einer ganz strengen Struktur folgen müssen, damit das jeweilige andere System weiß, was mit den Daten zu tun ist. Man möchte zum Beispiel Daten aus der Datenbank des anderen Systems abfragen, so wie ich das vorhin mit dem Schaden beschrieben habe, wenn ein Schaden angelegt wird, möchte ich gerne wissen, möchte ich gerne wissen, was ist die Laufzeit von dem dazugehörigen Vertrag und passt das Schadendatum dazu. Da muss ich genau sagen, was möchte ich von dem Vertrag haben und an welcher Stelle kann ich das herbekommen. Das sind alles Sachen, die in dieser Schnittstelle ganz genau definiert sind. Solange man da keinem gemeinsamen Standard folgt, was bedeutet, dass alle Systeme und alle internen Prozesse relativ ähnlich ablaufen müssen. Wenn das nicht gegeben ist, muss man sich auf Einzelfallbasis dafür entscheiden, wie diese Schnittstelle genau funktioniert und das bedingt genau diesen Kommunikationsaufwand, den Maria erwähnt hat.

 

Maria Oganian: Ein interessanter Punkt, den du gesagt hast, will ich noch ergänzen. Wie du schon sagst, wir kommen zurück an die erste Frage, aber ganz wichtig ist, einen strukturierten Datenaustausch zu machen. Vor allem ist es so, dass ganz vorne im Prozess, wenn die Daten hereinkommen, müssen sie am strukturiertesten oder am detailliertesten sein, damit alle anderen die Daten herausziehen können, die sie brauchen. Wenn es ganz vorne komplett unstrukturiert ein Freitextfeld mit allen Infos ist, können die nächstfolgenden Systeme überhaupt nichts damit anfangen. Das ist ganz wichtig, dass man wirklich ganz vorne so einen Detailgrad von strukturierten Daten hat, dass alle anderen Systeme und Partner damit auch arbeiten können mit ihren Bedürfnissen und ihren Zielen damit.

 

Toni Klein: Ich würde gerne mit euch beiden noch ein bisschen konkreter werden. Ihr habt netterweise ein Beispiel mitgebracht für eine sehr enge, digitale Zusammenarbeit. In dem Fall geht es, Maria, einen Assekuradeur, der sehr nah mit einem Makler zusammengearbeitet hat. Könntest du netterweise darauf einmal kurz eingehen? Was ihr da gemacht hat, wir nennen keine Namen und auch keine Zahlen, aber das Prinzip wollen wir gerne beleuchten, wie das funktioniert hat und was ihr damit erreicht habt oder auch den Assekuradeur und der Makler. Kannst du einmal kurz umreißen, worum es da bei euch ging?

 

Maria Oganian: Sehr gerne. Wir haben sehr viel oder eine sehr große Ausbaustufe von der Digitalisierung gemacht zwischen dem System von einem Makler und einem Assekuradeur. In der Mitte von diesem ganzen Digitalisierungsprozess stehen die beiden Bestandsverwaltungssysteme, einmal von dem Makler und einmal von dem Assekuradeur, die für eine bestimmte Versicherung für ein bestimmtes Produkt das gleiche Datenmodell haben, was es erlaubt, die Daten synchron zu halten und mehr oder weniger live die Daten auszutauschen. Wenn beim Makler ein Vertrag entsteht, dass es Sekunden oder Minuten später im System vom Assekuradeur landet. Das ist quasi der Kernbaustein von dieser Digitalisierung, die wir gemacht haben. Dann kamen noch viel mehr Punkte dazu.

Wir hatten ganz vorne im Prozess ein Kundenportal gebaut, genau das, was ich am Anfang erzählt hatte mit einem Digital Point of Sale, wo der Versicherungsnehmer als Marktpartner mit dabei ist. Der kann sich über dieses Kundenportal ein Angebot rechnen lassen, er kann aber auch, wenn es in die Dunkelverarbeitung läuft, direkt eine Police abschließen und seine Rechnung bezahlen, sodass er wirklich den kompletten Prozess auf dieser Webseite machen kann. Das landet direkt in dem Bestandsverwaltungssystem vom Makler, der den Vertrag da hat, der die Partnerdaten vom Kunden da hat und der hat entsprechend auch eine Rechnung, die der Kunde bereits bezahlt hat, und eine Buchung und diese Buchung landet dann in dem Buchhaltungssystem von dem Makler.

Das ist das Thema, was wir vorhin schon einmal hatten. Das landet gleichzeitig beim Assekuradeur im System, da auch im Bestandsverwaltungsverwaltungssystem und genauso verhält es sich mit Buchungen und Rechnungen in dem Buchhaltungssystem. Da hat man sehr viele Teile vom Prozess oder von diesem End-to-End-Prozess, in dem Fall von einer Neu-Policierung, von Angebot bis Buchhaltung digitalisiert. 25:44

 

Toni Klein: Da sprechen wir schon, korrigiere mich bitte, von einem End-to-End-Prozess, digitalisierte End-to-End-Prozesse zwischen zwei Partnern? Eigentlich sind es drei, weil der Versicherungsnehmer ist noch mit dabei.

 

Maria Oganian: Genau. Wenn wir nur über die Neu-Policierung sprechen, ist das wirklich ein End-to-End-Prozess, weil damit ist die Neu-Policierung abgeschlossen. Dann gibt es ganz viele verschiedene Ausbaustufen, dass man zum Beispiel Nachträge, Renewals et cetera auch vielleicht über den gleichen Weg abbilden kann. Dann gibt es natürlich die Schadenbearbeitung, da kann Bernhard gleich noch einmal etwas dazu sagen, was auch in das Spiel kommt, wie weit das digitalisiert ist.

Da gibt es noch viele weitere Systeme, also dass man irgendwie noch ein Dokumenten-Management-System anbindet, dass irgendwie alle Dokumente abgelegt werden in einem bestimmten System für die spätere Weiterverarbeitung. Die Frage ist immer, wo definiert man Anfang und Ende, um End-to-End-Prozesse zu haben. Wenn wir jetzt rein über die Neu-Policierung und Rechnungstellung sprechen, wäre das schon ein sehr gutes oder fortgeschrittenes Beispiel von einem End-to-End-Prozess.

 

Toni Klein: Du hast gerade schön erzählt, wie es im Rückblick auch aussieht. Das ist schon wirklich sehr nah beieinander. Wir sprechen hier von einem Datenaustausch in Echtzeit und dem gegenseitigen Vertrauen der beiden Partner. Teilen die ihre Datenbanken oder wie muss ich mir das vorstellen?

 

Bernhard Klett: Man hat nur begrenzt Freiheiten beziehungsweise ist es sehr eng definiert, was man in dem jeweiligen anderen System machen kann. Es ist zum Beispiel nicht so, dass man automatisch in die Datenbank des anderen Systems schreiben kann. Inhouse kann man das machen, mit einem externen Partner macht man das typischerweise nicht oder nur in bestimmten Einzelfällen.

Das kann die Schnittstelle direkt vorgeben, was sind genau die Änderungen, die jemand anderes machen kann in dem System, welche Daten kann die Person abrufen, welche Daten kann die Person überschreiben, welche Daten können neu angelegt werden, welche Daten können gelöscht werden. Das ist alles streng definiert in der Schnittstelle. Das ist nicht so, dass man da Tür und Tor öffnet für alles. 28:03

 

Toni Klein: Okay, das ist gut zu wissen, weil darum geht es oft. Du teilst so viel, wie du kannst, aber du willst natürlich so wenig wie möglich teilen, damit du sozusagen die Hoheit über die Daten hast. Das ist immer wieder ein Thema in diesem Podcast in dieser Reihe hier bei Industrieversicherung Digital. Da sind so viele Aspekte dran gewesen. Wir haben sozusagen den Datenaustausch zwischen zwei Partnern, der strukturiert erfolgt, der sogar synchron fast erfolgt, wir haben die Anbindung von Dritten, also dem Versicherungsnehmer, in dem Fall könnten das auch Gewerbekunden sein, die quasi sich Deckung besorgen, wir haben E-Commerce-Anteile quasi mit der Bezahlung auch, das heißt, es werden da richtige Zahlungsanbieter und Zahlungsmechanismen vorkommen, plus die Buchung, plus das Ganze wieder zurückgespielt in alle Systeme synchron.

Das ist schon enorm und dann wahrscheinlich das alles in Dunkelverarbeitung plus Regeln für Validierung, quasi für Referrals oder Abweichungen, die dazu führen, dass es nicht dunkelverarbeitet wird. Habt ihr das auch abgedeckt?

 

Maria Oganian: Genau. Diese Referral-Regel ist natürlich ein sehr wichtiger Bestandteil und das ist etwas, wo wir am Anfang gesagt hatten, darauf müssen sich die Partner natürlich einigen, welche Fälle dürfen dunkelverarbeitet werden, welche nicht und die, die nicht dunkelverarbeitet werden, müssen natürlich über solche Regeln abgedeckt werden.

Das steht ganz vorne im Prozess quasi beim Versicherungsnehmer, wo kann sich der Versicherungsnehmer ein automatisches Angebot rechnen lassen und eine Police direkt abschließen und bei welchen Fällen läuft es in einem manuellen Prozess, wo der Versicherungsnehmer eine Info bekommt, es meldet sich ein Underwriter bei ihnen mit einem individuellen Angebot oder solche Sachen. Das ist natürlich ein ganz wichtiger Bestandteil, dass man Regeln hat und entsprechend sein Risiko steuern kann. 29:56

 

Toni Klein: Jetzt hast du am Anfang ein Wort gesagt: Datenmodell, sie haben ein gemeinsames Datenmodell. Was bedeutet das in echt? Man setzt sich hin im Workshop und dann malt man Daten auf? Kannst du das ganz grob umschreiben, was das bedeutet, gemeinsame Datenmodelle zu definieren, um solche digitalen Zusammenarbeiten möglich zu machen?

 

Maria Oganian: Im Prinzip heißt das nichts anderes, als gemeinsam festzulegen, welche Daten möchte man in einer strukturierten Art und Weise haben. Wenn man es ganz plastisch sagen will, welche Felder muss der Versicherungsnehmer ganz in seinem Formular auf der Webseite ausfüllen, in welchem Format sollen die sein, damit der Makler und der Assekuradeur oder später der Versicherer die Daten, die Risikofragen beantwortet hat, die er oder sie braucht. Ganz einfach gesprochen, man muss sich definieren, welche Daten sollen abgefragt werden und in welchem Format. Zum Beispiel ein Versicherungsbeginn soll ein Datumsfeld sein. Das ist ein Teil vom Datenmodell, was man klären soll, und nicht ein Freitextfeld. Oder die Deckungssumme soll ein Euro-Feld sein. Es muss ganz klar sein, da muss jemand eine Zahl eingeben und kein Text.

Solche Sachen sind die Grundbausteine von der Definition von einem Datenmodell und ein Workshop ist immer gut dafür geeignet, um so etwas festzulegen.

 

Bernhard Klett: Typischerweise gehen wir da heran, indem wir uns den Prozess quasi von hinten anschauen. Ich mache es einmal als Beispiel für die Underwriting-Seite: Am Ende ist es so, dass man irgendwie an den Versicherungsnehmer einen Vertrag schicken muss, die fertige Police und dann kann man sich angucken, um diese Police zu erstellen, wie sie am Ende aussehen soll, was brauche ich.

Dann ist es zum Beispiel so, ich brauche natürlich die Laufzeit von dem Vertrag, in irgendeiner Art und Weise muss ich natürlich die Prämie berechnen für den Vertrag und dann muss ich Informationen haben wie was ist die gewünschte Versicherungssumme, was ist eventuell ein Selbstbehalt, was sind die ganzen Risikofaktoren, die es mir erlauben, einen Preis zu bestimmen für diese Art von Versicherung. Das sind die ganzen Informationen, die wir sammeln.

Es gibt natürlich auch eine ganze Reihe von Partnern, die an dem Vertrag dranhängen, Makler, Mitversicherer und so weiter, und da muss man sich auf eine Struktur einigen, zum einen welche Daten insgesamt gebraucht werden und noch einmal genau in welcher Struktur die sind. Das ist das, was ein Datenmodell auszeichnet. 32:37

 

Toni Klein: Dann haben wir heute ein bisschen einen Kreis geschlagen zwischen Marktpartner schicken einander E-Mails, über sie schicken einander Excel-Sheets mit teilstrukturierten Daten, hinzu sie können Datenstrukturen oder Daten austauschen, die zeitlich versetzt synchron gehalten werden und, das war das letzte Beispiel, Partner, die eng miteinander arbeiten und synchron Daten halten, direkt buchen können, direkt Dritte mit einbeziehen können.

Vielen Dank euch beiden für diesen kurzen und dieses Mal etwas technischeren Einblick in die Industrieversicherungspraxis. Ich bin mir sicher, dass wir hier noch andere Beispiele noch einmal besprechen werden mit anderen, sehr kompetenten Menschen wie euch. Vielen Dank, dass ihr heute dabei gewesen seid und bis zum nächsten Mal. 33:33

 

Maria Oganian: Danke Toni.

 

Bernhard Klett: Herzlichen Dank.