Johannes Mainusch: Hallo David, schön, dass wir uns treffen. Du bist CPO bei der LV 1871. Was ist eigentlich die LV 1871 und was macht ein CPO dort?
David Ibl: Die LV 1871 ist eine mittelständische Lebensversicherung mit Sitz in München. Wir versichern in erster Linie die elementaren Risiken rund ums Älterwerden. Das Risiko, plötzlich zu sterben, und auch die Berufsunfähigkeit sind bei uns zentrale Produkte. Die Rolle des CPO habe ich seit anderthalb Jahren inne, das bedeutet bei uns Chief Platform Officer. Als CPO verantworte ich inhaltlich die Weiterentwicklung und auch die strategische Ausrichtung unserer technischen Versicherungsplattform.
Du bist ursprünglich Softwareentwickler, also hast du, wie viele von uns, den Beruf mit Programmieren begonnen.
Ja, so habe ich vor zehn Jahren in der Versicherung begonnen. Aber als Softwareentwickler muss man viel von der Fachlichkeit verstehen, da das gesamte Produkt als Software abgebildet wird. Wir kalkulieren Geldströme und verwalten Daten rund um das Vertragsverhältnis. Mit der Zeit wuchsen mein Interesse und der Wunsch, intensiver daran mitzuarbeiten.
Lebensversicherungen sind eine komplizierte Domäne. Es ist also auch das Produkt kompliziert und nicht nur, wie üblich, die technische Umsetzung, etwa, wenn man den Beitrag für eine noch 30 Jahre laufende Lebensversicherung kalkulieren möchte.
Die reine Beitragskalkulation macht in der Versicherung nur einen kleinen Teil aus. Komplex wird es vor allem, weil wir viele Regularien beachten und eine enorme Menge an Produktvarianten pflegen müssen. Insbesondere Lebensversicherungen sind herausfordernd. Ein Vertrag, der 1950 abgeschlossen wurde, läuft unter Umständen heute noch. Dabei müssen die Algorithmen ihn heute noch genauso berechnen wie damals, als er abgeschlossen wurde. Das muss auch funktionieren, wenn die Systeme inzwischen teilweise erneuert wurden. Das bedeutet, mit jedem neuen System müssen wir sicherstellen, dass die alten Berechnungen erhalten bleiben. In einem Online-Shop braucht man das nicht.
Wie viele Plattformen hat euer ältestes Produkt durchlaufen? Es gibt sicher Verträge, die früher auf Papier waren und dann computerisiert wurden.
Ich kenne drei Plattformen, einschließlich der neuesten. Die älteste läuft seit vielen Jahren, und wir arbeiten daran, sie zu ersetzen.
Wie beim Fußball, nach der Migration ist vor der Migration. Wie lange kann man mit einem System arbeiten, bevor eine Migration nötig wird?
Die Digitalisierung hat die Komplexität des Gesamtsystems drastisch erhöht. Vor 30 oder 40 Jahren bestand die Computerarbeit hauptsächlich aus der Digitalisierung von Berechnungsformeln, während die Sachbearbeitung manuell erfolgte. Heutzutage erwarten Kunden die Möglichkeit, Verträge online einzusehen und auch Änderungen online vorzunehmen. Zudem ist die Erwartungshaltung an die Geschwindigkeit der Erfüllung von Wünschen natürlich eine ganz andere. Die Gesamtmenge an Software ist dadurch drastisch gewachsen. Die Frage ist, ob eine vollständige Systemmigration in 10 Jahren überhaupt möglich ist oder ob sie aufgrund ihrer Dimensionen zum Scheitern verurteilt wäre. Daher denken wir über die richtige Modularisierung nach, um Systeme so zu strukturieren, dass wir keine vollständigen Migrationen mehr durchführen müssen, sondern einzelne Systempunkte kontinuierlich aktualisieren oder kleinere Migrationen durchführen können.
Also geht es um die Auflösung monolithischer Strukturen durch Domain-Driven Design oder Vertikalisierung, wie im E-Commerce? „Druck“ ist doch so eine der Problemdomänen in der Versicherung, oder?
Druck ist wahrscheinlich ein ausgezeichnetes Beispiel, für die Herausforderung beim Domänen-Schnitt. Denn wir sind auch aufgrund der Regulatorik gezwungen, viele Schriftstücke für den Kunden anzufertigen. Diese Schriftstücke enthalten viel Fachlichkeit, und je nachdem, wie man nun die Fachlichkeit zwischen den Teams verteilt, muss man achtgeben, dass Druck nicht zu einer großen Querschnittsdomäne wird, in der sich alle Fachlichkeit wiederfindet. Wenn allerdings der Bereich „Druck“, also die Druck-Domäne, sich rein auf die Erzeugung der PDFs konzentriert, also Layouting, die Präsentationsschicht von Druckstöcken, dann ist das eine sehr einfache Domäne. Und die kann später sehr gut migriert werden. Die richtige Bildung von Domänen mit schön getrennter Technik, Fachlichkeit und Organisation ist halt wichtig, insbesondere auch, um kontinuierliche Updates durchführen zu können.
Vor einigen Jahren hast du auf der JAX-Konferenz einen Vortrag zum Thema DMN, Decision Model and Notation, gehalten, also einer einfachen, strukturierten Notation für Entscheidungsbäume im Business. Warum ist das für Versicherungen interessant?
Bei uns ist die IT-Kapazität ein großes Thema, besonders in Bezug auf die digitale Produktabbildung. Mehr Digitalisierung erfordert mehr Entwickler, und ich denke, dass wir Fachexperten befähigen sollten, an der Softwareentwicklung teilzunehmen, soweit es möglich ist.
Ist das euer Shift-left in der Produktentwicklung?
Genau. Mit Low-Code-Systemen oder Technologien wie DMN können Fachbereiche fachliche Regeln modellieren. Das ist definitiv eine wertstiftende Technologie, um die Kluft zwischen den verschiedenen Gruppen zu überbrücken. Man kann das einfach als Möglichkeit betrachten, um Spezifikationen zu generieren, die dann von Entwicklern umgesetzt werden, oder man kann einen Schritt weitergehen und den Fachbereich so weit befähigen, dass er aktiv an der Softwareentwicklung teilnimmt. Heute haben wir den Fachbereich tiefgreifend in die Softwareentwicklung integriert, sodass die Fachexperten wirklich an der Anwendungsentwicklung teilhaben können. Dadurch schaffen wir natürlich viel mehr Kapazitäten, um den Entwicklungsprozess mitzugestalten und umzusetzen.
Wie viele Leute seid ihr bei der LV 1871 und wie viele davon arbeiten an der Digitalisierung von Produkten?
In unserem Unternehmen sind insgesamt etwas mehr als 500 Mitarbeiter beschäftigt, wovon rund 120 im Bereich der Digitalisierung tätig sind, was bei uns als Anwendungsentwicklung bezeichnet wird. Das schließt Fachexperten ein, die größtenteils aktiv mitarbeiten. Unsere Arbeitsmodelle sehen vor, dass Fachexperten zu 20 Prozent in ihrer Heimatabteilung und zu 80 Prozent als Teil eines IT-Teams an der digitalen Produktentwicklung beteiligt sind. Dies umfasst Mathematiker und Produktentwickler, die aufgrund ihrer Ausbildung besonders gut dafür geeignet sind, aber auch Risikoprüfer, Mitarbeiter des Kundenservice, Spezialisten aus verschiedenen Abteilungen und Vertriebspartnerbetreuer. Die alle arbeiten aktiv an der Produktentwicklung mit, sei es durch Fachkonzepterstellung oder die Modellierung von Regelwerken und Prozessen.
Gibt es bei euch noch so etwas wie ein Fachkonzept im klassischen Sinne?
Wir arbeiten heute tatsächlich nach Scrum und die IT-Teams sind mit Fachentwicklern so aufgefüllt, dass sie die meisten Anforderungen dann im Teamrahmen ad hoc generieren.
Und wie erstellt ihr die von der Regulatorik geforderte Dokumentation?
In der Produktentwicklung setzen wir heute auf ein System, in dem das Produkt in all seinen Facetten auf Attributebene gepflegt wird, hauptsächlich durch Produktentwickler. Dieses System kann die Informationen strukturiert darstellen, sodass daraus ein Geschäftsplan und alle notwendigen Dokumente, etwa für die Einreichung bei der BaFin, erstellt werden können. Allerdings sind wir noch nicht so weit, dass dies vollständig automatisiert geschieht. Wir haben jedoch alle Daten strukturiert vorliegen, um diese Dokumente zu erstellen. In der Digitalisierung, also der Ebene darunter, die alle Prozesse darstellt und die Oberflächen materialisiert, dokumentieren wir hauptsächlich über GIT und übliche Dokumentationstools.
Ihr habt mitten in der Corona-Zeit ein neues System eingeführt und umfangreiche Renovierungsarbeiten vorgenommen. In einem Podcast auf eurer Webseite wird das neue System erwähnt, insbesondere die Vertriebsschnittstelle und der durchgängige Prozess von der Antragsstrecke bis zum vollständig policierten, also gültig ausgestelltem Vertrag. Auf LinkedIn habe ich etwas über einen Vertrag mit der Nummer 8 Millionen und 8 gesehen. Könntest du mehr darüber erzählen?
Der Vertrag 8.000.008 war tatsächlich der Erste, der über das neue System lief. Um persönlich diese Versicherung abzuschließen, habe ich unsere Endkundenschnittstelle genutzt und war dann ganz begeistert, als ich nur Sekunden später die Bestätigungsmail an meine E-Mail-Adresse und den Zugang zum Kundenportal in Händen hielt. Und das ist dann tatsächlich alles vollständig digitalisiert verarbeitet worden. Das ist einer der großen Schritte, die wir mit dem neuen System endlich gestemmt haben.
Gibt es in Deutschland noch eine andere Versicherung mit ähnlichem Digitalisierungsgrad?
Ja, es gibt bereits einige Versicherer, die eine digitale Risikoüberprüfung anbieten. Dennoch sehen wir uns ganz vorn, da unser Prozess sehr nutzerfreundlich ist und nach modernsten Maßstäben entwickelt wurde. Grundsätzlich gibt es jedoch auch andere Lebensversicherer, die dazu in der Lage sind.
Welche alten Systeme könnt ihr durch das neue ablösen?
Früher hatten wir einen Rechenkern, der von der Mathematikabteilung entwickelt und dann von zwei IT-Teams in zwei verschiedene Bestandssysteme sowie von einem dritten Team in eine Angebotssoftware eingebaut wurde. Diese drei Softwaresysteme waren getrennt und werden durch das neue System abgelöst. Dazu planen wir, auch die Bestände aus diesen Systemen im nächsten Jahr ins neue System zu migrieren.
Macht das neue System die Erstellung von Produkten einfacher?
Das neue System hat vieles signifikant vereinfacht. Früher mussten viele Dinge programmiert und die Kommunikation zwischen Produkt- und Softwareentwicklern koordiniert werden. Heute geben Produktentwickler ihre Regularien und Einstellungen direkt in ein Datenmodellierungstool ein. Dadurch sind Fachexperten wieder wesentlich in die Softwareentwicklung integriert.
Gab es Widerstände von Kollegen, die lieber bei den alten Methoden bleiben wollten, und wie habt ihr den Übergang zum neuen System geschafft?
Vor der Entscheidung, das neue System einzuführen, hatten wir bereits einen Prototyp auf der neuen technologischen Basis erstellt, mit einer ausgewählten Gruppe getestet und diskutiert, ob es funktionieren kann. Wir haben mit vielen Abteilungen im Unternehmen gesprochen, um eine breite Akzeptanz zu schaffen. Wenn man einem Produktentwickler bei uns sagt, wenn du morgen herausfindest, dass man in bestimmten Berufsgruppen das Risiko anders kalkulieren kann und du dafür das Produkt optimieren möchtest, dann kannst du das zukünftig einfach selbst machen. Und es ist drei Tage später auch in Produktion und kann so verkauft werden. Das hat bei uns große Begeisterung erzeugt.
Drei Tage, echt?
Das hängt tatsächlich von der Art der Änderung ab. Bestimmte Änderungen müssen genehmigt werden, und es gibt Abnahme- und Testverfahren, die länger dauern können. Auch gibt es Prozesse, die prüfen, ob ein Risiko sinnvoll darstellbar ist, was ebenfalls Zeit in Anspruch nehmen kann. Dennoch ist die reine Realisierung eines Updates heute grundsätzlich viel schneller möglich, und wir können in einem breiten Spektrum Änderungen zügig umsetzen. Man kann es auch so sehen, dass wir eine 4GL-Sprache eingeführt haben, mit der Produktentwickler heute ihre Produkte selbst modifizieren können.
Kann der Einsatz einer Fourth Generation Language die heutige Programmierung ersetzen?
Wir haben nun eine domänenspezifische Sprache (DSL), die speziell für unseren Einsatzzweck entwickelt wurde. Diese Sprachen haben naturgemäß Grenzen, da man nur Vorgesehenes ändern kann. Uns war wichtig, eine hohe Breite an häufig benötigten Änderungen in der Produktentwicklung schnell umsetzen zu können. So bleiben wir handlungsfähig. Unsere Entwicklungs- und Teamstrukturen sind darauf ausgelegt, auch mit größeren Änderungen umzugehen, wenn diese notwendig werden. Da kann dann auch wieder wie heute neue Software entstehen, oder benötigte Erweiterungen der DSL.
Gibt dies der Lebensversicherungsbranche Möglichkeiten, ähnlich wie bei A/B-Tests im E-Commerce, leichtgewichtige Experimente durchzuführen, um innovative Produktvarianten schneller zu testen und auf Marktveränderungen agil zu reagieren?
Teilweise. Früher haben wir viel Zeit investiert und überlegt, ob wir die Ressourcen einsetzen sollten, selbst wenn aus einer Risikoübernahmesicht klar war, dass wir das tun könnten. Heute fällt es uns leichter, solche Entscheidungen zu treffen und Aktualisierungen oder Ideen schneller am Markt auszuprobieren. Das hat sich signifikant geändert. Vor fünf Jahren konnten wir etwa ein Produktupdate pro Jahr darstellen, und es wurde viel Research betrieben, um sicherzustellen, dass dieses eine Update optimal ist. Heute sind wir risikobereiter und probieren mehr aus. In der Versicherung ist das allerdings nicht so einfach wie in anderen Bereichen, da wir keine Teile des Kollektivs unterschiedlich behandeln und in A/B-Tests beurteilen können. Das wäre nicht zulässig.
Das hört spätestens beim Kunden auf, denn der kauft sich ja nicht jede Woche eine neue Lebensversicherung ...
Wir haben zum Beispiel letztes Jahr ein Update rausgebracht, das es möglich macht, dass sich Kinder noch ein bisschen früher versichern gegen Berufsunfähigkeit.
Eine Berufsunfähigkeit ab 6 Jahren, habe ich gelesen, das heißt, Oma steckt die Berufsunfähigkeitsversicherung in die Schultüte?
So könnte es aussehen, tatsächlich funktioniert das. Je jünger man ist, desto besser ist der eigene Gesundheitszustand und desto offener auch noch die Berufswahl. Daher kann es sinnvoll sein, sich früh zu versichern, weil dann die Beiträge niedriger sind. Bei der Entscheidung, ob wir das probieren oder nicht, war die Frage, was die Realisierung kosten würde, kein Diskussionspunkt mehr. Wir haben ausschließlich darüber diskutiert, ob das ein sinnvolles Produkt ist und ob das am Markt Anklang finden kann. Ich bin persönlich überzeugt, in der Softwareentwicklung ist es grundsätzlich ein Asset, schnell liefern zu können, das schafft Räume und Möglichkeiten, die man in jeder Branche nutzen kann.
Habt ihr jetzt Softwareentwickler übrig oder benötigt ihr immer noch welche?
Wir brauchen weiterhin Softwareentwickler, da die Digitalisierung voranschreitet. Das nächste große Thema wird Interoperabilität und Anschlussfähigkeit sein, wo wir einen großen Schritt nach vorn machen wollen. Automation in der Lebensversicherung bleibt ebenfalls wichtig, und es gibt viel zu tun, um alle Prozesse voll automatisiert durchführen zu können.
Am Ende des Interviews passiert etwas Magisches, die gute Fee kommt vorbei und gewährt dir einen Wunsch, der in 365 Tagen in Erfüllung geht. Was wünschst du dir?
Ich wünsche mir, dass die Digitalisierung im Lebensversicherungsmarkt schneller voranschreitet. Der Markt entwickelt sich aufgrund der fachlichen Komplexität und seiner Funktionsweise nur langsam. Ich würde mir mehr Tempo bei anderen Marktteilnehmern wünschen und hoffe, dass wir in den nächsten Jahren noch besser und großartiger werden.
Vielen Dank für das Interview.
David Ibl ist Chief Platform Officer (CPO) bei der LV 1871. Er verantwortet die Weiterentwicklung und strategische Ausrichtung der technischen Versicherungsplattform. In seiner Freizeit macht er Sport und fotografiert gerne.
