ID#05

02.12.2020

GGW: Die Kraft der Datenmodelle in Theorie & Praxis – ID#05

Auch in der Industrieversicherung sind Daten das Gold der Zukunft. In dieser Folge geht es aber nicht um Risikodaten, sondern um den Kern des Geschäfts: um das Versicherungsprodukt und die Datenmodelle dahinter. Wer kann diese Modelle in der Praxis erarbeiten?

Im Gespräch: Ansgar Knipschild und Benjamin Zühr im Gespräch mit Rebecca Stodt (Gossler, Gobert & Wolters Gruppe; GGW).

Länge: 35 Min.

Transkript

Ansgar Knipschild: Hallo und herzlich willkommen zur neuen Ausgabe vom „Industrieversicherung Digital“ Podcast. Hi Benni.

Benjamin Zühr: Hi. Grüß dich, Ansgar.

Ansgar Knipschild: Bei dem letzten Podcast hatten wir das Thema Digitalisierung sehr ausführlich ebenfalls beleuchtet und hatten festgehalten, dass wir noch das Thema Strukturierung von Daten und Prozessen einmal beschreiben wollten. Ebenfalls weil wir festgehalten hatten, dass es eine unabdingbare Voraussetzung für die Digitalisierung ist. Und wenn ich die Frage einmal zu dir herüberspiele. Was haben wir heute vor?

Benjamin Zühr: Genau. Letztendlich versuchen zu klären, was genau ein Datenmodell ist. Und vor allen Dingen, und das hast du letztendlich ebenfalls bereits gesagt, warum das vielleicht ebenfalls einen Industriemakler oder ein Industrieversicherer benötigen. Und dann wollen wir ein bisschen praxisorientierter werden. Nämlich, wie so ein Modell erarbeitet werden kann. Und vor allen Dingen wer so etwas machen kann. Und dann einmal schauen, so einen kleinen Ausblick vielleicht machen, inwieweit so ein Datenmodell in der Branche vielleicht ebenfalls zu standardisieren ist.

Ansgar Knipschild: Aber das willst du doch wohl nicht alles selbst erzählen, oder?

Benjamin Zühr: Nein. Das wäre dann eher ein Monolog. Und ich binde dich ebenfalls immer gerne mit ein. Aber nein. Natürlich können wir das nicht alles selber, sondern wir haben dazu einen Gast heute dabei eingeladen. Rebecca Stodt. Und Rebecca du arbeitest gerade an einem Modell bei einem größeren Industrieversicherungsmakler. Der Gossler, Gobert & Wolters Gruppe. Herzlich willkommen.

Rebecca Stodt: Hi. Vielen Dank, dass ich heute hier sein darf.

Benjamin Zühr: Sehr gerne. Erzähle einmal ein bisschen etwas zu dir.

Rebecca Stodt: Ich habe nach meinem Studium einige Jahre in der Strategieberatung gearbeitet. Und dort Erfahrungen sammeln können. Und leite heute den Bereich Digital Solutions bei GGW. Genau.

Benjamin Zühr: Das hört sich gut an. Und dann scheinst du ebenfalls mir die Frage beantworten zu können, was genau du unter einem Datenmodell verstehst.

Rebecca Stodt: Unter einem Modell verstehe ich grundsätzlich ein Modell, das verarbeitende Daten eines bestimmten Anwendungsbereiches und die Beziehung zueinander beschreiben kann. Das heißt, dass mit Hilfe von einem Datenmodell die verarbeiteten Daten, aber ebenfalls die Eigenschaften und die Beziehung zueinander, dann genau beschreiben werden können. Und das kann ich machen sowohl für bereits existierende Bereiche. Aber ebenfalls für Bereiche, die ich jetzt gerade erst neu designe und erschaffe. Anwendungsbereiche in dem Fall können dann ebenfalls fachlich und technisch zu sehen sein. Ich sage jetzt einmal, fachlicher Anwendungsbereich ist zum Beispiel, dass ich einen Geschäftsprozess beschreiben möchte, dass ich Organisationeinheiten oder Business Services beschreiben möchte. Während, wenn ich von technischen Bereichen spreche, dann ist es zum Beispiel die Entwicklung von Smartphone-Apps, von IT-Plattformen, Web Services und so weiter. Genau. Beispiele jetzt, ich sage einmal, für die strukturierte Abbildung von Daten können jetzt in unserem Fall zum Beispiel Anschriften und Namen von Versicherungsnehmern sein. Aber ebenfalls Risikodaten wie beispielsweise Fläche einer Lagerhalle et cetera pp. Genau. Da haben wir die volle Bandbreite und äußerst viel Auswahl an Datenfeldern, die wir strukturieren wollen und ineinander in Beziehung setzen. Genau.

Ansgar Knipschild: Wenn ich da einmal ganz kurz hereingrätschen darf. Rebecca. Ich denke jetzt gerade einmal an so Risikofragebögen, die wir, glaube ich, alle kennen. Die an Kunden verschickt werden oder im Gespräch darin sind. Das fällt ebenfalls da herein. Diese endlos langen Listen mit Feldern. „Ja.“ „Nein.“ Das würde für mich ebenfalls in so ein Datenmodell herein gehören, oder?

Rebecca Stodt: Genau. Absolut. Das ist ebenfalls ein sehr wichtiger Bestandteil. Und du hast jetzt gerade von endlos langen Listen gesprochen. Das ist in der Tat so. Und das ist ebenfalls eine ganz wichtige Aufgabe des Datenmodells. Denn wir benötigen eine klare Struktur und fest definierte Hierarchien, damit die Daten, die wir in den verschiedenen Systemen sowohl verarbeiten, aber ebenfalls am Ende natürlich ebenfalls speichern wollen… dass wir die immer wiederfinden, immer wieder verwenden können. Und ganz zum Schluss letztendlich natürlich ebenfalls auswerten können. Und nur, wenn wir das geschafft haben, dass wir diese klare Einordnung… und vor allem ebenfalls eine verständliche Einordnung von diesen Objekten und Risikodaten und allen möglichen Datenfeldern, die im Laufe einer Vertragsgestaltung jetzt im Versicherungsbereich konkret vorkommen. Dass man die abbilden kann, das ist ganz, ganz wichtig.

Ansgar Knipschild: Ich spiele hier so im Podcast immer die Rolle so vom IT-Menschen. Für mich ist das natürlich total klar. Ordentliche Datenablage ist ein ganz wichtiges Thema. Nur so kann ich über Schnittstellen Daten austauschen. Über Systemgrenzen hinweg. Vielleicht sogar über Unternehmensgrenzen hinweg. Stichwort Web Services hast du ebenfalls bereits genannt. Aber ebenfalls Analyse. Data Mining, Data Science und diese ganzen Themen brauchen strukturierte Daten. Und last but not Least ebenfalls das große Thema Machine Learning oder sogar AI profitiert natürlich von klar strukturierten Daten. Ich glaube, für einen IT-ler ist das, glaube ich, völlig klar. Neu ist aber diese Sicht zu sagen: „Das ist nicht nur ein IT-Thema, sondern das ist erst recht ein Business-Thema.“ Es muss von beiden verstanden werden, denn man braucht wirklich eine gemeinsame Sprache um Folgeanwendungen, Prozesse ebenfalls wirklich einheitlich und gleich verstanden modellieren zu können. Und das führt uns dann ebenfalls so ein bisschen zur Frage. Warum braucht das zum Beispiel ebenfalls ein Industriemakler oder Versicherer?

Benjamin Zühr: Ich würde da gerne einmal darauf antworten. Ich glaube, letztendlich muss sich die Branche – die Industriemakler-, Versicherer-Branche – die Frage stellen, wie sie sich zukünftig grundsätzlich aufstellen wollen. Und wenn wir überlegen, dass Daten immer mehr wert sind, dass es vor allen Dingen darum geht, Daten immer verständlicher zu machen, da, glaube ich, stellt sich die Frage gar nicht, ob wir das brauchen. Wir brauchen es auf jeden Fall. Und letztendlich, wenn man sich jetzt einmal anschaut, was in der Industrieversicherung alles verarbeitet werden muss, mit wie vielen Partnern zusammengearbeitet werden. Wir haben einerseits die total unterschiedlichen Kunden. Wir haben natürlich Versicherer. Wir haben vielleicht einen Assekuradeur. Wir haben vielleicht noch einen anderen. Wir haben Makler. Wir haben im Schadenfall Sachverständige und so weiter und so fort. Und letztendlich brauchen wir das Bild gar nicht so groß machen. Wir können es ebenfalls kleiner lassen. Wie viele Unternehmen gibt es denn, die alle ihre Informationen in einem System abbilden können und vielleicht ebenfalls wollen. Die Frage. Ist es überhaupt sinnvoll? Aber ebenfalls dann. Gerade, wenn es nicht möglich ist alle Daten, alle Informationen, in einem System abzubilden, brauche ich einen Standard, eine Struktur, damit die unterschiedlichsten Systeme die Daten entsprechend verarbeiten, verstehen können. Das zumindest aus meiner Sicht. Rebecca. Du hast da sicherlich noch viele weiter Punkte.

Benjamin Zühr: So ganz grundsätzlich stimme ich dir da natürlich absolut zu. Daten ist das Gold unserer Zeit. Und es ist wichtig, die Daten gut zugänglich zu haben für jedes Unternehmen. Jetzt unabhängig von der Industrie und dass wir jetzt in dem Fall um Industriemakler sprechen. Was wichtig zu verstehen ist, ist, dass mit einem Datenmodell wir uns ganz klar auf das (Was?) eines bestimmten Anwendungsbereiches konzentrieren. Und das von allen Seiten beleuchten wollen. Gleichzeitig ist es aber ebenfalls so, dass wir uns in einem, ich sage jetzt einmal, sozio-technischen System, einem System zwischen Menschen, verschiedenen Abläufen, aber ebenfalls inzwischen mit IT-Systemen bewegen. Und dass wir in dieser Umwelt uns sowohl mit Daten beschäftigen, die wir im Ist-Stand, als ebenfalls in einem Plan- oder in einem Zielzustand befindend austauschen wollen. Und das, Benni, wie du es gerade sagtest, mit Kunden und Maklern, Assekuradeuren, Versicherern. Mit ganz, ganz vielen Akteuren. Und da kann ein gut strukturiertes Datenmodell als eine verbindliche Kommunikationsgrundlage dienen. Sowohl, sage ich einmal, zwischen Fach- und IT-Vertretern, aber ebenfalls zwischen Einzelakteuren, zwischen Teams, zwischen Bereichen in unterschiedlichen Hierarchieebenen. Und da kann das Datenmodell ein gemeinsames Vokabular verankern und so natürlich die Zusammenarbeit enorm fördern. Ebenfalls da jetzt, sage ich einmal, wieder das bezogen auf Industrieversicherung. Wir können durch dieses Datenmodell nicht nur die Daten austauschen. Wir können ebenfalls Dokumente generieren. Die austauschen. Wieder neu einlesen. Und das mit all den Akteuren, die wir jetzt bereits mehrfach genannt haben. Da sind wir sehr, sehr effektiv. Nicht nur in Entscheidungsdiskussionen, sondern ebenfalls sehr, sehr schnell, weil die Informationen unmissverständlich ausgetauscht werden können. Weil es die in diesem Datenmodell ebenfalls nur einmal gibt. Und nur einen ganz bestimmten Bereich genauso beschrieben, wie er beschrieben werden soll.

Ansgar Knipschild: Rebecca. Dem IT-ler geht jetzt wirklich das Herz auf. Ganz klar. Das Credo versuchen wir bereits seit Jahrzehnten irgendwie hereinzubringen. Und ich würde sagen, super, du bist sofort als Business-Analystin und IT-Expertin eingestellt.

Rebecca Stodt: Danke.

Ansgar Knipschild: Aber spricht so ein Makler? Spricht so ein Makler wirklich? Ist das bereits angekommen in der Branche diese Wichtigkeit, dass – wir reden hier von Datenmodellen, von Feldern und so weiter – das ein so wichtiges Thema ist? Ich kann das irgendwie noch nicht so richtig glauben.

Rebecca Stodt: Das ist natürlich bereits ebenfalls ein Change-Prozess, den wir da jetzt mitmachen. Ich sage einmal, es gibt viele, die den Wert von strukturierten Daten durchaus erkannt haben und den ebenfalls fördern. Aber es ist natürlich ebenfalls ein Stück weit neue Welt, die wir ebenfalls vor allem mit den Fachbereichen besprechen müssen, um da ebenfalls Werbung für diese neue Art der Datenerfassung zu machen. Denn gerade, wenn man in der Theorie spricht, klingt es immer zuerst nach sehr viel mehr Aufwand. Und das haben wir jetzt ebenfalls bereits einmal erlebt bei einem erfolgreich umgesetzten Projekt, dass es anfangs bereits ebenfalls Widerstand gab. Und, Gott, das ist alles viel mehr Arbeit, als es vorher war. Und jetzt ein paar Monate, nachdem das System ebenfalls angekommen ist und genutzt wird. kommen immer noch Nachrichten, wieviel Spaß es macht neu zu arbeiten mit so gut strukturierten Daten. Dass die Auswertungen funktionieren et cetera pp. Und das ist ein Learning, was, ich sage einmal, nicht nur die Abteilungen, die IT-Abteilung oder die Digital-Solutions-Abteilung, oder wie ebenfalls immer die Abteilungen in den jeweiligen Unternehmen genannt werden, durchlaufen müssen. Sondern das ist wirklich ein Learning fürs gesamte Unternehmen. Und irgendwo ebenfalls für die gesamte Branche, muss man sagen.

Benjamin Zühr: Für mich hört sich das total spannend an. Vor allen Dingen deswegen, denn, wie du gerade gesagt hast, es ist scheinbar kein Prozess, der nur in einer Abteilung vonstattengeht. Sondern das ist ein gemeinsamer Prozess, wo es darum geht letztendlich Fachlichkeit und Technik miteinander zu verbinden und auf der Basis eine Struktur zu schaffen. Und so wie ich dich verstehe, letztendlich ist es die Basis dafür das Risiko technisch abzubilden und in ein entsprechend bedarfsgerechtes und individuelles Deckungsmodell zu überführen. Was ich persönlich für genau den richtigen Weg halte. Genau. Total spannend.

Rebecca Stodt: Genau. Das ist absolut das ausgeschriebene Ziel, was wir bei GGW verfolgen. Absolut.

Ansgar Knipschild: Gut. Dann ist natürlich die große Frage. Butter bei die Fische. Wobei, keine Frage, sondern eher die Feststellung. Hört sich in der Theorie spannend an. Du hast bereits einen kleinen Einblick gegeben, dass der Einstieg nicht ganz so leicht war an der einen oder anderen Stelle. Wie erarbeitet man denn jetzt so ein Modell? Wie muss ich mir das vorstellen in einem tradierten Maklerhaus? Wie habt ihr das gemacht? Seid ihr so eher top-down, von oben angeordnet? Und, „hier ist der Vorschlag und so wird es gemacht“. War es bottom-up? Vielleicht kannst du da einmal so einen kleinen Blick hinter die Kulissen uns geben.

Rebecca Stodt: Sehr gern. Das ist, glaube ich, schwer zu sagen, ob es jetzt wirklich top-down, bottom-up ist. Es ist irre viel Kommunikation, die sowohl, sage ich einmal, zwischen den eher technischer versierten Bereichen und den Fachbereichen abgelaufen ist. Ganz grundsätzlich ist es aus meiner Erfahrung so, es ist immer der beste Weg inkrementell und iterativ vorzugehen. Dass man sagt, „ich starte im Groben und verfeinere das Modell schrittweise“. Das heißt, bevor wir mit der Modellierung begonnen haben, war es wichtig für uns die verschiedenen Bereiche zusammenzubringen und eine gemeinsame Basis zu schaffen, was jetzt konkret für uns die aktuelle Herausforderung war, dass beispielsweise im Vertrieb Daten gepflegt wurden, die aber ebenfalls für den Betrieb in der Vertragsausschreibung eine sehr hohe Relevanz hatten. Und dass es da natürlich Schwierigkeiten geben kann. Wer hat Datenhoheiten? Wie können sie geändert werden? Wie sollen sie beschrieben werden? Der eine braucht es so. Der nächste braucht es so. Und da ist ein gemeinsames Verständnis sehr wichtig. Und um da die unterschiedlichen Perspektiven, ich sage einmal, bündeln zu können, ist es wichtig diesen Informationsbedarf überhaupt zunächst zu identifizieren. Um dann ein einheitliches Begriffsverständnis zu schaden. Um dann im dritten Schritt letztendlich die Klarheit über die Notwendigkeit für vielleicht ebenfalls neue Daten überhaupt zu fördern. Und dass man da versucht mehrere Bereiche dann in der Form an einen Tisch zu bringen. Wenn ich jetzt einmal überlege so ganz konkret. Wie sind wir da entsprechend dann vorgegangen? Wir haben uns eine Sparte herausgenommen. Ich sage jetzt einmal, beispielsweise (Financial Alliance?)-Bereich. Und haben dann da versucht überhaupt zunächst zu verstehen. Was für Geschäftsobjekte habe ich? Wie kann ich die ineinander in Beziehung setzen? Und wir haben dann in PowerPoint einen, ich nenne es jetzt einmal, fast wie so eine Organisationsbaumstruktur, sage ich jetzt einmal, gemacht. Und haben da versucht die entsprechenden Objekte, die wir identifiziert haben, miteinander in Beziehung zu setzen. Und haben dann – und das ist ganz, ganz wichtig – immer wieder versucht das, was wir da versucht haben grafisch darzustellen, ebenfalls nicht nur in der Theorie, möglicherweise durch Gedankenspiele mit anderen Sparten, sondern ebenfalls direkt bereits mit der Technik, direkt zu verproben.

Benjamin Zühr: Und darf ich dich da einmal…

Rebecca Stodt: Klar.

Benjamin Zühr: Nutzt ihr dafür Testdaten oder nutzt ihr dafür reale Daten?

Rebecca Stodt: Dafür haben wir jetzt so… in dem Bereich haben wir noch gar nicht unbedingt überhaupt richtig Daten identifiziert. Sondern wir sind wirklich noch auf einer viel höheren Ebene. Ganz grundsätzlich würde ich immer dazu plädieren reale Daten zu nehmen. Dazu würde ich ebenfalls gerne ebenfalls gleich noch einmal eingehen im nächsten Schritt. Denn ich sage einmal, wir sind jetzt wirklich noch auf einer ganz High-Level-Ebene gewesen. Und erst als wir diese PowerPoint, diese Organisationsbaumstruktur fertig hatten, haben wir dann versucht die Modellstruktur zu verfeinern und wirklich richtige Informationsobjekte abzubilden. Und da sind es dann wirklich richtige Daten, wie konkrete Risikobeschreibungen. Da hat ebenfalls Ansgar ganz am Anfang bereits von ewig langen Risikofragen gesprochen da. Das ist dann der Detailgrad, den wir im zweiten Schritt haben. Und da geht es dann ebenfalls wirklich um reale Daten. Und das würde ich ebenfalls immer wieder jedem empfehlen, das so zu machen, weil man dann direkt verproben kann. kann ich die Daten, die ich mir jetzt vorgenommen habe, als ein Beispielfall, so abbilden oder nicht? Genau. Wenn ich jetzt noch einmal diesen zweiten Schritt… da noch einmal ein, zwei Sätze weiter zu verlieren kann. Wir haben dann diese Modellstruktur verfeinert. Und zwar in einer Excel-Liste. Wir haben es ein bisschen die Vorerfassung genannt. Und zwar ist das für uns ein Vormodell, wo jedes Datenfeld, was wir in Zukunft benutzen wollen, eine Excel-Zeile ist. Und das kann in diesen Excel-Zeilen durch diverse Spalten genau beschrieben werden. Ist es ein Pflichtfeld? Wenn es ein Drop Down ist, was sind die Auswahlmöglichkeiten? Da gibt es wirklich ganz, ganz viele Sachen, wie man dieses Feld näher beschreiben kann. Und ebenfalls da ist es am Ende wirklich wieder wichtig, dass wir dieses Datenmodell oder dieses vorläufige Datenmodell, nenne ich es jetzt einmal vorsichtig, ebenfalls immer wieder sowohl mit dem Fachbereich als ebenfalls mit der Technik abstimmen. Genau. Und erst der dritte Schritt, das ist eigentlich dann wirklich das richtige Datenmodell, das physische Datenmodell. Und dafür nutzen wir Low Code Tools, mit denen es uns da möglich ist die Datenfelder jeweils zu definieren und ebenfalls technisch zu erstellen. Um es dann in einem zweiten Tool ebenfalls wirklich an der Oberfläche es Systems, welches wir dann nutzen, wirklich ebenfalls selber zu platzieren. Und ebenfalls dort weitere Anpassungen vornehmen zu können.

Ansgar Knipschild: Wenn ich da einmal kurz den Übersetzer noch spielen darf. Low Code heißt, wir haben Tools, wir haben Werkzeuge, die ich ebenfalls als Nicht-Entwickler bedienen kann. Irgendwo zwischen Excel und so einer echten Programmierumgebung. Und du hast mir im Vorgespräch gesagt, dass du das dir ebenfalls jetzt hier im Rahmen dann der Arbeit da selber beigebracht hast. Oder natürlich einer kleinen Schulung. Aber, ich glaube, ebenfalls noch weitere Kollegen bei euch im Haus, die jetzt keine IT-ler sind, die dann mit diesen Tools arbeiten. Und das versteckt sich hinter diesem Begriff Low Code.

Rebecca Stodt: Genau. Absolut. Ich leite jetzt zwar den Bereich der Digital Solutions, aber würde mich jetzt absolut nicht als High-Level- oder tiefer IT-Experte, so ist wahrscheinlich die bessere Formulierung, selbst verstehen. Und ebenfalls erst recht als kein Entwickler. Aber mit diesen Low Code Tools ist es wirklich simpel diese Datenfelder zu erstellen und ebenfalls zu platzieren und zu verschieben. Und es hat natürlich ebenfalls einen gewissen Charme ebenfalls fürs Unternehmen, wenn man die Kompetenzen selber aufbaut, weil es natürlich ebenfalls viel Flexibilität ist, was da mit einhergeht.

Ansgar Knipschild: Genau. Du hast einmal geschildert. Das, was ihr dann wirklich bei GGW selbst modelliert habt, habt ihr dann praktisch am nächsten Tag bereits bei den Spartenverantwortlichen zeigen können. So sähe es in der Anwendung aus. Mit Oberfläche. Mit Feldern. Um dann iterativ, wie du es beschrieben hast, dieses Modell kontinuierlich voranzutreiben.

Rebecca Stodt: Genau. Oder sogar noch schneller teilweise in den Meetings selber das noch einmal mit ändern können und zeigen können. Meinst du das so oder so? Das geht natürlich nicht immer. Ein paar Sachen sind ein bisschen komplexer als andere. Aber für ein paar Sachen ist man da wirklich dadurch sehr, sehr schnell. Und die Flexibilität ist irre. Das macht ebenfalls wahnsinnig viel Spaß, muss ich gestehen.

Benjamin Zühr: Stichwort Flexibilität. Für mich stellt sich eine Frage. Wenn man die heutigen Systeme sieht, gerade im Versicherungsbereich, dann geht es häufig da darum. Ich will Verträge abbilden. Ich will Kunden abbilden. Ich habe das Ziel eine Rechnung da herauszubekommen et cetera. Ein paar Auswertungen et cetera pp. Bloß wir haben vorhin länger darüber gesprochen, dass bereits der Anspruch in gewisser Weise ebenfalls über das Datenmodell besteht. Das Risiko, dass Unternehmen nicht nur als solches, sondern ebenfalls mit den individuellen Versicherten oder ebenfalls Nicht-Versicherten Risiken abzubilden. Wie geht ihr denn da in dem Datenmodell mit um?

Rebecca Stodt: Ist eine gute Frage. Und ehrlich gesagt ebenfalls keine ganz triviale Frage. Da haben wir wirklich ebenfalls viel, viel darüber nachgedacht. Und haben ein bisschen gebraucht, um da wirklich dahin zu kommen, wo wir jetzt sind. Aber was wir machen und was uns da wichtig ist, ist, dass wir Risikoobjekte, ich sage jetzt einmal, flexibel und individuell miteinander verknüpfen können. Sodass wir ein Modell haben, wo wir Objekte und Risiken auf verschiedenen Ebenen ebenfalls miteinander anwenden können, sage ich jetzt. Was ich damit sagen möchte ist, dass wir beispielsweise einmal ein Haus oder eine Immobilie versichern. Und in dieser Immobilie stehen beispielsweise diverse Maschinen, die in der Versicherungspolice als mitversichert gelten. Und einmal haben wir eine Versicherungspolice, wo wir nur eine Maschine versichern und es gar nicht darum geht, wo sie steht und was für Gegebenheiten darum herum gelten. Und wenn wir beide Szenarien jetzt nebeneinanderlegen und auswerten wollen, dann wollen wir das, dass wir die Maschine in beiden Szenarien gleichzeitig und gleichwertig auswerten können. Sodass wir nicht den Unterschied machen müssen zwischen einer Maschine, die in einem Haus steht warm und trocken und einer Maschine, die es nicht steht, weil wir möglicherweise die Informationen dazu in der Form gar nicht abbilden können. Und das ist uns mit unserem Datenmodell in der Form gelungen, dass Risikoobjekte ebenfalls auf mehreren Ebenen angewendet werden können und trotzdem am Ende gleichwertig ausgewertet werden können.

Benjamin Zühr: Heißt auf gut Deutsch gesagt, dass wir Objekte oder … komplett flexibel aneinander, miteinander verbinden können et cetera pp. Aber natürlich ebenfalls die Sparten. Auf die unterschiedlichsten Objekt-, Risikoinformationen je nach Sparte individuell darauf zugreifen können. Wenn ich dich richtig verstehe.

Rebecca Stodt: Genau. Absolut. Die Modularität, die wir damit bieten können, gewährleistet uns das. Genau.

Benjamin Zühr: Ist natürlich dahingehend wirklich etwas Neues, da man das Risikomanagement und das Versicherungsmanagement über das Datenmodell total miteinander verbindet. Genau.

Rebecca Stodt: Absolut.

Ansgar Knipschild: Sehr spannend. Und ich kann mir vorstellen, dass man diese Themen, wie man jetzt ganz konkret so ein Modell ausarbeitet, noch endlich lange weiterspinnen kann. leider haben wir im Podcast nur begrenzt Zeit und das Ganze funktioniert natürlich auf der Audioschiene ebenfalls nicht ganz so gut. Aber ich glaube, das hat den Zuhörern bereits einen kleinen Einblick gegeben, wie so etwas funktionieren kann. Rebecca. Kannst du vielleicht noch so ein, zwei Learnings, vielleicht ebenfalls sogar Empfehlungen noch mitgeben an die Hörer, wenn die vielleicht ähnliche Digitalisierungsvorhaben in ihren Häusern entsprechend planen? Was würdest du denen mit auf den Weg geben?

Rebecca Stodt: Ganz wichtig. Und das habe ich jetzt ebenfalls bereits mehrfach ebenfalls betont als wir darüber gesprochen haben, wie wir ein solches Modell erarbeitet haben. Ist wirklich das frühe einbeziehen der Abteilung und der Fachbereiche. Es sind natürlich immer Änderungen am Modell möglich und die sollen ebenfalls passieren. Dafür bauen wir das Ganze und dafür wollen wir es ebenfalls so flexibel aufbauen. Aber vor allem jetzt in der Erstellung, wenn man jetzt beispielsweise bei der Erstellung der Excel-Liste feststellt, Mensch, da haben wir vielleicht irgendeinen Punkt vergessen… das müssen wir noch einmal anders machen. Und dann das ebenfalls noch einmal an der PowerPoint anpassen oder an einer der Low Code Tools etwas ändern, was wir ebenfalls an der Excel-Liste noch einmal wieder nachziehen müssen. All solche Themen können natürlich minimiert werden, wir die Abteilung frühzeitig einbeziehen. Aber ebenfalls dann – und da sind wir ebenfalls vorhin bereits einmal kurz darauf eingegangen – wenn wir konkretem reale Testfälle aus dem Bestand der jeweiligen Abteilungen durchgehen und die ebenfalls im Datenmodell verproben. Denn und dann können wir nämlich wirklich den richtigen Detaillierungsgrad treffen. Und erst, wenn wir die richtige Detailtiefe der Daten erfassen, können wir sie ebenfalls redundanzfrei speichern. Und das ist letztendlich ebenfalls genau das, was wir ebenfalls als Ziel haben. Dass nämlich jedes Datenfeld in unserer Datenbank ebenfalls wirklich nur einmal vorkommt. Genau. Und vielleicht ein dritter Punkt noch, was ebenfalls nicht ganz unwichtig ist gerade, wenn man dann versucht dieses Datenmodel in die Praxis einfließen zu lassen. Dass man sich vielleicht ebenfalls nicht ganz so versteift auf, ich sage einmal, statisch strukturelle Informationen, sondern ebenfalls versucht direkt Prozessabläufe und ebenfalls Wechselwirkungen mit zu berücksichtigen. Damit man dann ebenfalls den Übergang in die reale Welt… ebenfalls den Datenfeldern die mögliche Freiheit bietet sich ebenfalls entsprechend mit dem Prozess mit verändern zu können. Ganz grundsätzlich würde ich immer sagen, dass Datenmodelle für mich eine deutlich längere Nutzungsdauer haben als Prozessmodelle. Und deswegen. Eine sorgfältige Datenmodellierung entlang der Informationsbedarfe in Zusammenarbeit mit den Abteilungen zahlt sich da wirklich aus. Und da würde ich lieber eine Abstimmungsrunde mehr als zu wenig machen. Genau.

Ansgar Knipschild: Ich glaube, ebenfalls ein super wichtiger Punkt. Du hast jetzt häufiger von „wir“ gesprochen. Da drängt sich natürlich die Frage auf, wer kann denn so etwas machen? Gerade in einem Haus, das jetzt nicht klassische IT-Wurzeln hat oder ebenfalls sicherlich was Business-Prozessanalysen hat oder so nicht seine Ur-Gene hat. Wie habt ihr das bei euch gelöst?

Rebecca Stodt: Wenn ich von wir rede… ich mache das natürlich nicht alleine, sondern habe da wirklich ebenfalls ein tolles Team, was mich dort mit auf dem Weg begleitet. Und wir haben bei GGW ein Team aufgebaut. Das nennt sich Digital Solutions. Und haben da eine starke Kompetenz in der Prozessanalyse. Mit ebenfalls ein bisschen Projektmanagement. Und verstehen uns da als Bindeglied zwischen der Technik oder dem technischen Verständnis und den einzelnen Fachbereichen. Der tiefen Versicherungsfachlichkeit. Und versuchen da zu kommunizieren und entsprechend ebenfalls die Prozesse zu hinterfragen und ebenfalls zu verstehen. Damit wir auf die Art und Weise das richtige Datenmodell aufsetzen. Die richtige Prozesse dahinter legen, um dann ebenfalls letztendlich ein digitales Produkt zur Verfügung stellen zu können.

Benjamin Zühr: Aber ihr programmiert es nicht selber?

Rebecca Stodt: Es ist natürlich immer eine Frage, wie man sich da selber ebenfalls als Firma aufstellt. Wir sind der Meinung, dass letztendlich der reine Prozess einer Versicherung und die Tätigkeit einer Versicherung im Großen und Ganzen auf einer High-Level-Ebene immer gleich sind. Und haben deswegen einen technischen Partner, der mit uns gemeinsam den Weg bestreitet. Und der uns da für viele Prozesse ein System zur Verfügung stellt, was die Prozesse, ich sage einmal, zu achtzig, neunzig Prozent gut abbildet. Nichtsdestotrotz haben wir ebenfalls einen großen individuellen Teil. Und diesen individuellen Teil wollen wir selber gestalten. Und zwar so, wie er auf unsere Abläufe, Kundenstruktur und Vertragsstrukturen et cetera pp. passt. Und da bin ich gerade ebenfalls bereits einmal auf die Low Code Tools eingegangen. Und das ist für uns der wichtige und verbindende Part. Dass wir nicht nur sagen, dass wir unseren Partner haben, der alles für uns umsetzt. Sondern dass wir die Datenmodellierung in der Form bereits ebenfalls als unsere eigene Aufgabe verstehen. Und dass wir mit den Tools da eine einheitliche Kommunikation ermöglichen, die nicht nur die Geschwindigkeit, von der wir ebenfalls bereits ein paar Mal gesprochen haben, extrem erhöht. für die Entwicklung. Sondern aber ebenfalls das Verständnis fürs digitale Produkt insgesamt im Unternehmen wirklich deutlich verstärkt.

Ansgar Knipschild: Super. Vielen Dank, Rebecca, für die Ausführungen. Ich glaube, das hat einen echt spannenden Einblick einmal gegeben, wie so ein Change-Prozess beginnt, mit so trockenen Themen wie Datenmodelle, in einem Industrieversicherungs- beziehungsweise Maklerhaus aussehen kann heute. Ich schaue einmal auf meinen Spickzettel. So kleine Zusammenfassungen, die ich mir hier einmal aufgeschrieben habe, sind vier Punkte. Einmal. Datenmodelle sind wirklich die unabdingbare Basis für alles, was danach kommt. Für alle Prozesse. Für die Kommunikation. Bis hin dann zu den großen Zukunftsthemen Machine Learning und AI. Ganz wichtig die sparten- und prozessübergreifende Sicht auf das ganze Thema. Dass man da nicht nur isoliert ein Thema bearbeitet, sondern immer schaut. Stichwort war da ebenfalls von dir, Benni, dass man Versicherungsmanagement und Risikomanagement zusammenbringt. Das ist zwingend dann eine übergreifende Sicht. Die iterative Vorgehensweise habe ich mir notiert. Klein anfangen. Vielleicht mit einer Sparte, mit zwei Sparten, um dann sukzessive auszubauen. Und vor allen Dingen ganz wichtig, vierter Punkt, das Ganze ist keine IT-Aufgabe oder keine reine IT-Aufgabe, sondern Business- und Fachexperten müssen da zusammenarbeiten. Und letztendlich müssen die Risikoexperten, ich nenne sie einmal so, sei es auf der Makler- oder auf der Versicherseite, wirklich die Hoheit über diese digitalen Datenmodelle erhalten. Ich persönlich glaube sogar, dass es eine der Kernkompetenzen in der Zukunft sein wird, sein Datenmodell und die Möglichkeiten damit dann Geschäft zu machen wirklich ebenfalls selbst zu beherrschen. Prima. Nochmal vielen Dank. Rebecca.

Rebecca Stodt: Sehr, sehr gerne.

Ansgar Knipschild: Wir haben jetzt heute über Datenmodelle gesprochen, wie sie innerhalb von einer Organisation, innerhalb von einem Unternehmen entstehen können. Spannend wird es natürlich, wenn es die Unternehmensgrenzen verlässt. Und beim nächsten Mal wollen wir einmal schauen. Wo steht da die Branche? Wie kann man digitale Kommunikation oder ebenfalls den Datenaustausch über die Häuser hinweg entlang der Wertschöpfungskette optimieren? Wir kennen aus dem Privatgeschäft die Initiativen der BiPRO, der GDV mit seinem Datensatz. Und da wollen wir dann einmal in die Diskussion einsteigen. Wo steht da die Industrieversicherungsbranche heute? Und welchen Möglichkeiten sind da für die Zukunft da?

Benjamin Zühr: Ich freue mich auf den nächsten Podcast mit dir, Ansgar. Rebecca, dir vielen lieben Dank, dass du heute uns als Gast hier im Podcast einmal das Thema Datenmodelle näher beleuchtet hast. Und Ihnen, liebe Zuhörer, vielen Dank fürs Zuhören. Und bis zum nächsten Mal.

Ansgar Knipschild: Alles klar. Danke euch.

Rebecca Stodt: Vielen Dank, dass ich dabei sein durfte. Tschau.

Benjamin Zühr: Tschau.

Ansgar Knipschild: Bis bald. Tschüss.

Der Podcast „Industrieversicherung Digital“ ist eine Initiative für den offenen Austausch über die Digitalisierung von Industrie- und Gewerbeversicherung: Versicherer, Makler, Kunden und IT im direkten Dialog.

Machen Sie mit! Wenn Sie ein spannendes Thema, einen Erfahrungsbericht oder einen persönlichen Standpunkt mit Kolleginnen und Kollegen diskutieren möchten, melden Sie sich bei uns: E-Mail und LinkedIn-Gruppenlink auf der Mitmachen-Seite.

Podcast abonnieren über:

Apple PodcastGoogle PodcastSpotifyAmazon MusicDeezer