CTO NEED TO KNOW Podcast

Legacy-Modernisierung: Wie ticken Versicherungen?

Zu Gast: Jörg Rippchen, Geschäftsführer arc innovations

Wie ticken Versicherungen? Wie modernisieren sie ihre Bestandssysteme? Stefan Paal spricht mit Gast Jörg Rippchen, Geschäftsführer von arc innovations, über Herausforderungen und Ansätze zur Modernisierung im Versicherungsbereich. Jörg teilt seine Erfahrungen und betont die Notwendigkeit, über rein technische Updates hinauszugehen und auch organisatorische und geschäftsbezogene Aspekte zu berücksichtigen. Außerdem: die Rolle von Dunkelverarbeitung, das Spannungsverhältnis zwischen IT und Geschäftsbereichen, und die Bedeutung von Change Management in Modernisierungsprojekten.
Weitere Episoden anhören

Transkript

Transkript ausklappen / einklappen

Stefan Paal Hallo und herzlich willkommen zu einer neuen Episode des Podcasts “CTO Need To Know”. Heute wieder mit einer Folge zum Thema Legacy Modernization bzw. Modernisierung vom Bestandsystem. Mein Name ist Stefan Paal und ich bin Principal Consultant bei der Firma INNOQ. Ich bin seit über 35 Jahren in der Softwareentwicklung unterwegs, als Entwickler, Architekt und seit meiner Zeit bei INNOQ auch zunehmend als Berater auch für die Softwaremodernisierung. In dem Podcast „CTO Need To Know“ sprechen wir aber nicht über INNOQ und auch nicht über mich, sondern über ausgewählte Themen, wie heute eben über Legacy Modernization. Und das wollen wir mit Entscheidern tun, als ob sie mit anderen Entscheidern sprechen. Ich freue mich heute daher besonders auf Jörg Rippchen von arc innovations, der sehr viel und oft mit Entscheidern über Modernisierung spricht. Bevor wir starten, die obligatorische Vorstellung. Jörg, wer bist du? Wer ist arc innovations? Und was machst du da?

Jörg Rippchen Stefan, vielen Dank und auch herzlich willkommen in die Runde. Herzlich willkommen an dich! Jörg Rippchen mein Name, ich bin jetzt seit über 35 Jahren im Versicherungsumfeld unterwegs. Tatsächlich habe ich mal Versicherungskaufmann gelernt, bin dann aber direkt in die IT gewechselt, habe dort so ziemlich alles programmiert, was man programmieren konnte. Dann in Richtung Architektur, Architekturmanagement, das ganze noch als Angestellter. Vor, mittlerweile sind es 16 Jahre, haben wir mit ein paar Leuten zusammen die arc innovations gegründet. Eben damals noch sehr stark mit dem Fokus Architekturmanagement quasi in die Unternehmen reinzubringen, aber immer wieder auch mit dem Fokus bei Versicherungen. Letztendlich muss ich gestehen, ich kann nur Versicherung, ich habe nichts anderes gemacht. Dieser Fokus, der hat sich über die Jahre weiterentwickelt. Wir haben gesehen, was für Herausforderungen die Kunden haben. Wir haben gemerkt, dass hier auch stark auf der fachlichen Seite Dinge zu tun sind, also Richtung Facharchitektur und eben auch die ersten Transformationsvorhaben. Dazu haben wir uns ein paar Gedanken gemacht, haben auch Ergebnistypen entwickelt, die den Kunden unterstützen sollen. Und so ist die arc innovations immer noch klein aber fein, aber eben sehr spezialisiert. Wir haben einen kurzen Ausflug auch mal in das Gesundheitswesen gemacht, DiGas, digitale Gesundheitsanwendungen waren mal auch für uns ein Thema. Aber jetzt sind wir eigentlich wieder hauptsächlich in den Fokus Versicherung und Transformation von Versicherung. Alle, die in arc innovations unterwegs sind, haben eben genau diesen starken versicherungsfachlichen Background. Wenn ich zusammenrechne, kommen wir wahrscheinlich auf über 100 Jahre Versicherungserfahrung, gebündelt und konzentriert.

Stefan Paal Super. Jetzt höre ich schon einen Begriff Transformation und wir sprechen über Modernisierung. Wo ist denn da für dich der Unterschied? Gibt es da einen Unterschied?

Jörg Rippchen Man muss immer erst mal gucken, wo man herkommt und gucken, was die Zukunft so bringt. Ja, es ist tatsächlich so, rein Legacy Modernization, dann denkt man wahrscheinlich sehr stark mit einem IT technischen Fokus. Das sind Anwendungen, die müssen wir irgendwie neu machen. Die Erfahrung zeigt aber, dass man das Einfache neu machen und alles so lassen, auch die fachliche Ausprägung dieser Anwendungen, wie sie heute ist, eigentlich nicht reicht. Das heißt, wir haben Entwicklungen am Markt, Weiterentwicklungen am Markt, die es erforderlich machen, auch Dinge neu zu denken und vor allen Dingen auch Herausforderungen, die dann nicht nur IT-technischer Art sind, sondern eben auch die ganze Organisation betreffen. Vielleicht sogar in Teilen manchmal das Geschäftsmodell, also die Frage der geschäftlichen Ausrichtung. Und spätestens dann, wenn man merkt, es ist eben doch ein fachliches Thema, dann spreche ich in der Regel von der Transformation.

Stefan Paal Schön als Unterscheidung noch mal, dass wir bei der Modernisierung auch weiterdenken müssen, dass wir nicht einfach nur die Technik uns anschauen. Bei der Technik, wir reden über Bestandssysteme. Was ist denn für dich ein Bestandssystem? Vielleicht auch im Bereich Versicherungen, glaube ich, gibt es da doch schon einiges, was da als Bestandssystem herumliegt.

Jörg Rippchen Genau. Wenn man Bestandsysteme im engeren Sinne betrachtet, klar, dann ist es dort das System, was den Vertrag führt, sage ich mal. Lassen wir mal das Ganze außen vor, wie ist der Vertrag zustande gekommen. Ein Vertrag will geführt werden, das heißt, er will natürlich gespeichert sein in seiner Ausprägung. Was ist genau versichert? Welches Produkt hat der Kunde? Er will auch dort geändert werden können, vielleicht gibt es jährliche Anpassungen und Ähnliches. Letztendlich irgendwann am Ende eines Vertragslebenszyklus wird auch irgendwann storniert oder er läuft eben aus. Aber das ist zu kurz gedacht. Bestandsführung ist tatsächlich nur ein Teil, ein Aspekt. Den gibt es oftmals auch mehrfach bei einer Versicherung, weil die Lines of Business oder ich sage mal die großen Gesellschaften, also Leben und Kranken nochmal getrennte Systeme oftmals haben. Und innerhalb dieser Systeme findet man sogar noch manchmal die Ausprägung für Privatkundensegment oder auch für gewerbliches oder Industriegeschäft. Das heißt, das ist ein ganzes Konglomerat in der Regel an Anwendungen, was wir bei den Versicherern finden. Und wenn wir das mal weiter fassen, dann ist die Bestandsführung nur ein Teil der gesamten Anwendungslandschaft, die es zu betrachten gilt. Auch im Hinblick auf Legacy Modernization. Was haben wir? Wir müssen kassieren, wir haben das Nebenbuch, wir haben das Hauptbuch für die Bilanz, wir haben Input- und Outputmanagement, noch wird viel Post natürlich rausgeschickt, aber auch natürlich kommt viel Post auch rein, das will verarbeitet werden. Zudem natürlich auch digitalisierte Medien, die wir im Inputmanagement verarbeiten. Und dann haben wir natürlich diese ganze Verkaufsstrecke. Wie kommt der Vertrag oder der Antrag zu uns? Klarifierung, Angebot, Antrag an die dunkle Verarbeitung heute schon oftmals. Dann haben wir natürlich Schaden, leider. Muss man auch darüber sprechen, dafür macht der Kunde seine Versicherung, will natürlich auch seine Schäden abgerechnet bekommen. Und wie die die Arbeit letztendlich am Kunden verrichten. Sprich unsere Vermittler und Makler, die wollen Provision. Auch dafür braucht man ein System. Und dann ist da drumherum natürlich das ganze Thema Prozesssteuerung, Arbeitscore und darum herum wiederum Security. Das ist also das ganze Universum einer Versicherung, was eigentlich zu betrachten ist, was man idealerweise auch wirklich ganzheitlich betrachtet. Denn überall in diesen Komponenten können eben Altlasten stecken. Das, was die Kette ist, ist so stark wie das schwächste Glied. Sprich, wenn man End-to-End Betrachtungen auf einer Prozessebene angeht, dann ist die Bestandsführung, wie gesagt, ein Thema. Man muss aber die gesamte Kette betrachten und schauen, wo man überall welche Herausforderung hat, als Unternehmen, wenn man sich da modernisieren oder erneuern will.

Stefan Paal Ich merke schon, du bist sehr in dieser Versicherungsdomäne eingetaucht mit den ganzen Begriffen. Ich kenne das jetzt mittlerweile, ich musste das auch lernen. Im ersten Moment dachte ich auch was ist das denn? Aber vielleicht für die Zuhörer, die das nicht wissen. Was ist denn eine dunkle Verarbeitung in der Versicherung?

Jörg Rippchen Wir kennen alle noch den Prozess, dass der Vermittler bei uns am Kaffeetisch oder Wohnzimmertisch saß und sein Papierantrag ausgefüllt hat und uns einen Durchschlag gegeben hat. Ich glaube, so haben wir alle mal vor vielen Jahren unseren ersten Versicherungsvertrag unterschrieben.

Stefan Paal Ich erinnere mich, aber sehr dunkel.

Jörg Rippchen Und du hast vielleicht auch mitbekommen, über die Zeit hat er wenigstens schon mal einen Laptop mitgebracht und hat dort in einem Tarifrechner dir den Preis am Bildschirm zeigen können. Und dann hat er aber oftmals noch versucht zu drucken. Ich kann mich erinnern an Zeiten, da hat man versucht, mobile Drucker mitzunehmen. Damit man tatsächlich wiederum die Unterschrift des Kunden bekommt und eben den Antrag verarbeiten kann. Was heißt Antrag verarbeiten? Das Stück Papier wurde zum Versicherer transportiert, zum Backoffice und dort saß jemand und hat es wieder abgetippt. So haben wir viele, viele Jahre Versicherung gemacht. Und Dunkelverarbeitung ist jetzt quasi der technische Transfer meiner Angebot- und Antragsinformation, idealerweise auch mit einer entsprechenden elektronischen Unterschrift, dass wirklich kein Papier mehr notwendig ist. Die Daten gehen digitalisiert ins Backoffice und werden dort auch in die Systeme automatisiert übernommen, verarbeitet, sofern keine Probleme und Fehler auftreten, auch dunkel. Das heißt dann eben, niemand fasst im Backoffice dann diese Anträge mehr an oder muss noch was tun. Dunkelverarbeitung heißt, sprich automatisiert verarbeiten. Und das gibt es nicht nur im Tarif Firmenangebot, Antrag, sprich am POS zunehmend oder bisher sehr stark für Neugeschäft. Was jetzt sehr stark im Trend ist, ist auch Änderungsgeschäft. Das heißt, dir fällt ein Jahr später ein, dass du noch zwei wertvolle Gegenstände für deine Hausratversicherung angeben musst. Und auch diese Art von Änderungen können dann elektronisch prozessiert werden, vielleicht sogar im Selfservice. Die ersten Kunden haben ihre Portale, wo du das selber machen kannst. Aber der Vermittler auf jeden Fall schon auch an seinem Laptop wieder die Änderung durchführen kann und automatisiert verarbeiten kann. Und wenn wir das weiterdenken, dann ist Dunkelverarbeitung auch die elektronische Schadenaufnahme, die auch zunehmend Selfservice behaftet wird. Sei es durch den Kunden, den Endkunden selber oder durch den Vermittler und wo ebenfalls wieder die Information, eben, ohne dass ein Mensch das noch beifügen muss, entsprechend übertragen werden kann. Das ist das Ziel, diese Automatisierung zu erreichen.

Stefan Paal Kann man das vereinfacht so sagen, dass wenn man jetzt über eine technische Modernisierung spricht, also wenn wir bei dieser Transformation, die du vorhin angesprochen hast, den technischen Teil mal betrachtet, dass sich das hauptsächlich dann um die dunkle Verarbeitung dreht?

Jörg Rippchen Es ist ein wichtiger Aspekt. Automatisierung ist in der Tat ein wichtiger Aspekt, den es zu betrachten gilt, allein diese Schnittstellen zu schaffen und diese dunkle Verarbeitung zu ermöglichen. Dazu müsste man jetzt ein bisschen tiefer einsteigen, warum das so scheinbar kompliziert ist. In der Regel ist es halt kompliziert, können wir vielleicht später nochmal darauf zurückkommen, weil man das Produktwissen, also das versicherungsfachliche Produkt mit seiner Tarifierung, sprich dem Pricing, wie kommt man zum Preis? In der Regel bei vielen Kunden doppelt vorfinde. Man findet es in der Vertriebswelt vor, in den Tarifrechnern, ein eigener Techniker, der das Produktwissen hält und die Berechnungen durchführt. Und das gleiche nochmal in der Bestandsführung, die wir eben schon genannt haben, wo das Produkt Wissen ebenfalls implementiert ist. Du bist Techniker, du weißt es, verschiedene Prozessorwelten, verschiedene Programmiersprachen gehen mit Nachkommastellen oder mit bestimmten Datentypen unterschiedlich um. Dann hast du plötzlich Abweichungen in den Beiträgen, Pfennige oder auch mehrere Cents, die dann abweichend sind. Da musst du überlegen, wie gehe ich damit um und und und. Das sind so Herausforderungen, die man da hat und das ist zu lösen. Aber es gibt noch viele, viele andere Gründe auf der technischen Seite, die wir da betrachten müssen. Das geht in Richtung kann das die Anwendung noch, ist sie so geschnitten, dass sie das kann. Dann Richtung Partneranlage, du schickst ja nicht nur den Antrag, quasi das versicherungsfachliche Produkt, du schickst auch Personendaten, die dann automatisiert angelegt werden müssen. Du schickst Dokumente vielleicht mit, die müssen ins Archiv und verschlagwortet werden, damit man sie auch wiederfindet. Und all diese Dinge sind dabei zu betrachten. Das ist ein großer, großer Aspekt diese Automatisierung zu erreichen. Und damit sage ich mal auch Kosten zu sparen. Da, wo der Mensch diese repetitiven Tätigkeiten nicht mehr durchführen muss, spart man ja auch Geld.

Stefan Paal Du baust mir gerade diese Brücke, da wollte ich jetzt gerade hin. Du hast ja vorhin schon auf der sehr fachlichen Ebene beschrieben, dass es Bestandsführung gibt, dass es Systeme gibt, die den Vertrag führt. Jetzt weiß ich aus eigener Erfahrung, du sagst gerade Techniker, dass wenn man bei der Versicherung reinschaut, man da viele technische Systeme vorfindet. Bei dir hat man jetzt einen Riesenvorteil, du hast mehrere Versicherungen schon gesehen, du arbeitest ja nicht bei einer Versicherung, sondern berätst Versicherungen, du bist bei denen dabei. Was ist denn dieses Potpourri, was man da noch vorfindet? Ich nehme mal an, man findet da alles und jedes System, an das man sich in den letzten 30 Jahren noch erinnern kann.

Jörg Rippchen Ja, Punkt eigentlich. Volltreffer. Man findet noch viele Hostsystemen, das ist glaube ich jetzt keine Überraschung. Wobei das in den Sparten ein bisschen unterschiedlich ist. Bei Lebensversicherungen hat man schon früh angefangen, auf Standardsysteme zu gehen. Na ja, gut, da gibt es auch schon noch Systeme, die noch in Native C programmiert sind. Oder man findet Exkurse in Visual Basic. Es gibt ja auch so was wie individuelle Datenverarbeitung, also manchmal sogar lebenswichtige Funktionen eines Versicherers wie irgendein schlauer Mensch, ein schlauer Kopf, ein Aktuar oder wer auch immer sich mal ausgedacht hat und dann an seinem PC einfach runterprogrammiert hat und die mittlerweile Kernsystem geworden sind. So was gibt es natürlich auch. Dann natürlich die ersten Gehversuche mit Java, die sind schon viele Jahre her. Die können mittlerweile auch schon Legacy sein, muss man ganz ehrlich sagen. Die Technologiesprünge waren ja enorm. Allein was man sieht an GUI Frameworks, wie programmiert man eigentlich Oberflächen? Da hat man auch schon x Generationen jetzt, die man dann vorfindet. Es ist tatsächlich, wie du schon sagst, es ist ein Zoo an Funktionen, an Technik. Und es ist immer komplexer geworden, auch für die jeweiligen Betriebsabteilungen der IT. Diesen ganzen Zoo auch wirklich so zu managen, dass die Verfügbarkeit, die Performance, der Durchsatz auch da ist. Und das sind natürlich Herausforderungen, die man nach vorne raus auch lösen will, weil es einfach zu komplex geworden ist.

Stefan Paal Da kommen wir eigentlich schon zu diesem Punkt. Was sind denn so diese Problemstellungen, die man in Versicherungen vorfindet? Wenn du erzählst, dass jemand vor ich weiß nicht 25 Jahren so ein System mal erstellt hat, der ist vielleicht jetzt schon in Rente gegangen und das System ist aber immer noch im Betrieb. Keiner weiß genau, wie es funktioniert, aber es funktioniert, es tut. Sieht man einen Modernisierungsstau bei eine Versicherung, dass diese Systeme einfach in die Jahre gekommen sind und immer noch funktionieren, aber eigentlich würde man die austauschen wollen?

Jörg Rippchen Ja, ich glaube, das ist genau der Punkt. Man darf den Wert, den diese IT hat, nicht gering schätzen. Das sind Systeme, die wirklich teilweise hunderttausende von Verträgen managen, das Geld dafür einkassieren, die Schäden bearbeiten usw., auch die Provisionen zahlen. Es ist ein in sich eingeschworenes System. Und auch die Organisation ist darauf komplett eingeschworen, da sind sie total optimiert. Man kommt in die Häuser und in ihrer alten Welt, wissen sie genau, dann kennen sie auch jeden, der irgendwo noch der Spezialist ist. Es gibt dann den einen oder die zwei, die für eine bestimmte Komponente dann noch wissen, genau wie sie funktioniert und wie sie im Inneren aufgebaut ist. Und das ist natürlich einer der Hauptprobleme. A) das Alter. Software hat einen Lebenszyklus, das weißt du als Architekt. Man kann noch so gut Komponenten basiert denken und Strukturen in die Software bringen, irgendwann weicht man davon ab. Es ist oftmals so, dass die Kunden hingegangen sind und haben geschaut Ja, ich muss jetzt was Neues machen aus dem Blickwinkel Regulatorik, oder ich habe hier ein spezielles Abkommen mit einem Makler drin, der was Besonderes will. Und dann gucke ich halt nicht unbedingt, wo gehört sauber hin diese Funktion oder dieses Wissen, sondern wer hat gerade Zeit? Und so sind über die Zeit auch wirklich Dinge entstanden, wenn man heute drauf guckt, sagt: Wie konnte das denn sein? Warum habt ihr das denn da jetzt programmiert? Na ja, aber es gibt dafür gute Gründe. Und das alles hat natürlich dazu beigetragen, dass dieser Lebenszyklus, ich denke das immer so gern in S Kurven, sprich, man fängt an, man kann dann viel, viel machen über die Zeit mit der Software. Aber irgendwann flacht die Kurve halt wieder ab, weil die Zeit, die ich brauche, um eine Änderung in die Software zu bringen, immer länger wird. Du hast es gerade gesagt, Demografie ist ein Thema. Natürlich sind das Leute, die vor 30 Jahren aus der Ausbildung kamen, vielleicht auch 40 Jahre, je nachdem. Und diese Systeme quasi mit aufgebaut haben. Das Wissen geht natürlich raus. Natürlich unterschiedlich bei den Kunden. Viele versuchen natürlich auch noch Leute zu bekommen, die auch wieder Cobol, PL1, teilweise noch Assembler auf dem Host kennen. Die findest du natürlich nicht so einfach, die müssen ausgebildet werden. Aber der Effekt, der dabei entsteht, ist, dass, auch wenn du die Technik, die Programmiersprache beherrschst, diesen inneren Aufbau der Software nicht unbedingt nachvollziehen kannst und verstehen kannst. Das ist das, wo es viel Zeit braucht und die Leute gehen aber in Rente und das ist so ein Dilemma. Sprich die Software ist schon am Ende des Lebenszyklus und die Leute müssen sich viel, viel mehr reindenken, wenn sie eine Änderung durchführen. Gleichzeitig haben wir natürlich auch den Druck vom Markt, schneller Änderungen durchzuführen. Und das ist eigentlich ein Dilemma, es muss irgendwie schneller gehen, die Leute müssen erst mal reinwachsen, müssen sich in der Software auskennen. Und der Aufwand, dort in einer entsprechenden Qualität Änderungen durchzuführen, wird immer höher. Und dieser höhere Aufwand, wieder bei dem Thema Kosten, kostet irgendwo auch Geld. Das ist eigentlich so eine Entwicklung, die wir da bei vielen Kunden sehen, die auch nicht aufzuhalten ist. Auch bei aller Bemühung, da jetzt auch noch das Skill wieder aufzubauen und einzubringen und die dann dazu führt, dass man dann überdenkt, wie kann man damit umgehen? Das sind verschiedene Stellen, ich habe gerade Regulatorik genannt, die oftmals kommt, da muss man dieses noch machen, jenes dran machen, jene Daten rausgeben und folgende Berichtswesen Anforderungen erfüllen. Aber spannender ist es in der Produktwelt, sprich wie viel Produktinnovationen kann ich eigentlich noch rausbringen? Das ist nicht unüblich heute bei vielen Kunden, die ich kenne, dass man bisher in ein Jahreszyklen gedacht hat und sagt okay, einmal im Jahr mache ich ein Produktupdate oder ein Facelift, manchmal auch zwei Jahre. Ich habe Systeme gesehen bei Kunden mit Produkten, weil der Produktkern schon älter ist und das Pricing dahinter auch so alt ist, dass man teilweise 30 - 40% Rabatt geben muss, um überhaupt auf Marktniveau zu kommen. Es wird immer langsamer, es wird immer schwerfälliger und der Markt erwartet ja eigentlich, dass es immer schneller geht, dass es einfacher geht, dass ich mich mehr an meine Mitbewerber anpassen kann. Da kommen auch die rein digitalen Versicherer auf den Markt, die ganz anders agieren. Gut, da muss man sich überlegen, mit wem will man da überhaupt sich messen? Wer ist meine Peergroup? Aber es ist nicht zu leugnen, dass der Druck von außen höher wird, dass es schneller gehen muss. Und das steht halt im Kontrast zu dem, mit welchen Leuten ich eigentlich welche Änderungen wie schnell durchführen kann.

Stefan Paal Jetzt hast du schon einige Problemstellungen mal aufgeführt, die Versicherungen haben. Schneller am Markt sein, Demografie, Regulatorik. Was ist denn aus deiner Sicht das häufigste Ziel, wenn man so ein System jetzt noch mal anfasst und modernisieren will? Was versuchen Versicherungen am häufigsten in den Vordergrund zu stellen, wenn sie das tun?

Jörg Rippchen Ja, das ist eine interessante Frage deswegen, weil ich jetzt schon das eine oder andere Mal bei Kunden aufgeschlagen bin, aus welchen Gründen auch immer und festgestellt habe: naja, der erste Impuls, was zu erneuern, kam aus der IT. Man hat genau diese Probleme gesehen, man hat die Skillentwicklung, man hat gesehen, wann gehen die Leute in Rente? Man hat natürlich auch die Probleme oder die Anfälligkeit einzelner Komponenten oder Systeme erkannt und dann sagt die IT irgendwann wir müssen es neu machen. Und dann kommen natürlich spannende Fragen, wie Make or buy. Das sind wirklich spannende Fragen oder auch wichtige Diskussionen, die man führen muss. Letztendlich muss man sich überlegen, naja, wenn ich jetzt das Thema neu aufsetze und vielleicht sogar Software kaufe, dann hat das was mit Standardisierung zu tun. Hat was damit zu tun, dass ich überlegen muss, wo differenziere ich mich überhaupt vom Markt? Du hast das Stichwort Bestandsführung eingangs genannt, obwohl es ein ganzes Ökosystem ist. Aber es ist ein spannender Aspekt, einen Vertrag zu führen. Das haben früher alle Versicherer für sich selber erfunden und sich selber Wege gegeben, wie sie es am besten hinbekommen, dazu passende Oberflächenfunktionen usw. Heutzutage ist das Commodity ein Vertrag führen, damit bin ich jetzt nicht der bessere Versicherer, der schnellere Versicherer. Ich kann den Vertrag führen, das ist Standard. Das ist eigentlich das Gute an der Versicherung, die hat sich nicht wesentlich verändert. Vertrag ist Vertrag, Produkt ist Produkt. Natürlich gibt es immer Besonderheiten. Natürlich sagt auch jede Sparte, sie sei die komplizierteste. Aber im Kern ist es eigentlich immer das Gleiche und deswegen sind an bestimmten Stellen meiner Anwendungslandschaft durchaus die Frage zu stellen, muss ich das wirklich noch machen? Also kann ich das nicht kaufen, ist das nicht Commodity und wo differenziere ich mich eigentlich? Und darüber kommt dann die Diskussion, naja, dann ist es wohl doch nicht nur ein technischer Austausch, sondern ich muss mir einfach überlegen, wo will ich eigentlich morgen sein? Wie flexibel will ich denn sein? Wo will ich mich am Markt positionieren? Wie viel Automatisierung will ich überhaupt? Soll alles dunkel gehen? Hast du schon mal mit einem Versicherer Kontakt gehabt, der diese ganz modernen, rein digitalen Strecken geht? Du schaffst es nicht, mit einem Menschen zu sprechen. Du sprichst mit einem Bot, du schickst eine Mail. Viele, viele Kunden und ich glaube, da gehöre ich auch noch dazu, die wollen auch manchmal mit einem Menschen agieren, sprich: wo ist Dunkelverarbeitung sinnvoll? Wo muss direkter Kundenkontakt möglich sein? Und das muss man sich auch als Unternehmen fragen, wie will man auftreten am Markt? Wo will ich mich differenzieren? Wenn ich nicht überall im Preis mithalten kann, dann ist es eben dieses Persönliche, da ist noch jemand, der mit mir spricht. Auch vielleicht jetzt in Richtung, wenn man denkt an Verkauf, Makler und so weiter, auch die, die noch Individuallösungen machen, die eben nicht nur 0815 von der Stange verkaufen. Diese Fragen, wie ist eigentlich mein Geschäft morgen? Wo gehe ich dahin und dann wieder zurück, wenn ich das erreichen will? Wenn ich diese Art von Arbeit und diese Ausrichtung haben will und diese Automatisierungsgrade und diese Prozesssteuerung, dieses Self-services und was immer wieder vorschwebt, dann überlege ich mir, was ist dazu die passende IT? Kann ich da was von der Stange kaufen? Gibt es da Anbieter, die mich dabei unterstützen können? Oder muss ich vielleicht tatsächlich an einzelnen Stellen wieder selbst ran? Oder es ist differenziert, ich kaufe was, aber zum Beispiel am Point of Sale, also da, wo ich verkaufe, da differenziert mich. Das sind Fragestellungen, beginnend von der IT, wir haben Handlungsdruck, dann schwappen die rüber zur Fachlichkeit idealerweise, denn daraus kommen neue und veränderte Anforderungen, die wieder zurückschwappen auf die IT und dort eben entsprechend umgesetzt werden müssen. Und wenn man das nicht tut, dieses Hin und Her einmal diskutieren, dann besteht die Gefahr, dass man das nachbaut, was man jetzt die letzten 30 Jahre gemacht hat. Und die Frage ist, ob man damit wirklich die Anforderungen der Zukunft mit abdecken kann.

Stefan Paal Ich finde das total spannend, wenn du sagst, dass der Auslöser oft oder vielleicht sogar noch mehr als oft von der IT kommt und Richtung Fachbereich, wir müssen was tun aus den verschiedenen Gründen, die wir jetzt besprochen haben und das es einen Dialog gibt zwischen Fachbereich und IT. Das ist das, was wir aus der Softwareentwicklung auch immer wieder anmahnen. Die beiden Seiten müssen miteinander sprechen. Wir können nicht einfach die Dinge über einen Zaun werfen, sondern miteinander sprechen. Wie ist bei dir der Eindruck bei den Versicherungen, klappt diese Kommunikation zwischen IT und Fachbereich?

Jörg Rippchen Das ist sehr unterschiedlich. Und das ist ein Stück der Geschäftszweck der arc innovations, sage ich mal. Genau da an dieser Grenze zu unterstützen. Es sind unterschiedliche Sprachen, das weiß man alles. Aus der Vergangenheit hat man schon viele Themen da gemacht. Es ist einfach was anderes, ob ich auf der Softwareebene denke oder ob ich aus der Businessebene denke. Dieses Zusammenbringen, also diese Sprachen anzugleichen, sodass man sich versteht, was man eigentlich will. Ich habe mal einen Kunden gehabt, der sagte, wenn wir Workshops machen mit dir, mit euch, dann dann ist es immer cool zu erfahren, ob ich mir gerade was wünsche, was in der IT eigentlich ein no brainer ist, also kein Thema oder ob ich gerade zum Mond fliegen will. So hat er es original formuliert. Das war ein Produktmensch, der hat Ideen, wie er die Produktgestaltung macht, wie flexibel und mit abschmelzen, selbst behalten und tolle, tolle Dinge. Und dann muss man halt manchmal sagen Stopp, Achtung, jetzt überschreitest du eine Grenze und du bist wirklich schon dabei die Rakete aufzutanken. Also finden wir nicht doch Lösungen, die dein fachliches Ziel erreichen, aber die in der IT besser umsetzbar sind? Und das ist genau das, den Fachbereich mal kommen lassen, sich Wünsche äußern lassen. Das ist das, was wir typischerweise mit so einem Ergebnis Zielbild formulieren. Das schreibt man es wirklich mal auf und das aber immer im Sparring zu was heißt das für die IT? Ist das in der Komplexität noch handlebar, machbar und steht das in einem ausgewogenen Verhältnis? Das ist eigentlich genau, was man tun muss. Und die Versicherer tun sich in der Regel mehr oder weniger schwer. Es hängt viel davon ab, wie zum Beispiel die Architekturabteilungen aufgestellt und ausgeprägt sind. arc innovations, Arc stand mal für Architektur und das ist aber noch unsere DNA so ein bisschen. Auch da dieses Übersetzen, Fachlichkeit in IT und Facharchitektur. Und je nachdem, wie gut die Architekten schon vernetzt sind auf der Businessseite und mit ihren IT Kollegen, wenn es nicht eh schon Unternehmensarchitektur ist, desto besser ist das Haus auch schon darauf getrimmt Fachbereichen IT zu syncen. Es gibt aber auch viele Bereiche, da gibt es reine IT Architekten und auf der Businessseite so gut wie nichts, da findet man die Leute nicht. Und da ist tatsächlich das Problem, dass man reingehen muss und erst mal dieses Verständnis, diesen Kontakt herstellen muss. Immer wieder die Frage: Wünsche ich mir gerade was, was gar kein Problem ist? Oder wünsche ich mir was zum Mond fliegen bedeutet? Das ist so das Wichtigste dabei.

Stefan Paal Das ist nochmal ein guter Anknüpfungspunkt zu dem, was du vorhin gesagt hast. Wir gehen auch in die Beratung rein und fragen auch immer: Ist das etwas, was euch jetzt differenziert vom Mitbewerber oder ist es etwas, was du sagst, das ist so ein Allgemeingut, das haben alle. Wie sind diese Diskussion bei den Versicherungen Fachbereich IT, make or buy, wollen alle selber machen, wollen Standardprodukte. Was ist denn da deine Erfahrung?

Jörg Rippchen Ja, dass es nicht leicht ist. Wenn man einsteigt, dann muss man immer sich vorstellen, dann trifft man auf eine Organisation, die seit vielen, vielen Jahren sehr erfolgreich unterwegs ist, sonst gäbe es die Versicherung nicht mehr. Sie verkaufen Produkte, sie machen damit auch ihren Ertrag und leben davon und bezahlen Gehälter und alles, das funktioniert ja. Und jetzt kommst du rein und sagst, naja, wir wollen vielleicht morgen etwas anders machen. Und wir wollen vielleicht auch ein bisschen mehr standardisieren und die Komplexität wieder rausnehmen. Denn über die Zeit entsteht sachlogisch Komplexität. Hier ein Öhrchen, da eine Besonderheit, hat man hier vielleicht mal festgestellt, dass man irgendwo ein Defizit hat. Hat noch ein paar Regeln eingebaut in die Software, ein paar Prüfungen, ein paar Prüfungen, die Menschen machen müssen, wo aber heute schon keiner mehr weiß, warum er das überhaupt tut. Da entstehen Dinge über die Zeit, die eingeschliffen sind, in die Organisation eingebrannt sind, würde ich fast sagen und die erst mal als gut und richtig empfunden werden. Und das Typische, wenn man darüber nachdenkt, vielleicht auch Standardsoftware einzusetzen, was zu kaufen. Dann kommen andere Beraterfirmen und machen Ausschreibungen und fragen die Anforderungen ab. Also werden riesige Excel Tabellen mit Anforderungen, teilweise über 1000 Anforderungen moduliert. Ja, was glaubst du, was da drin steht? Da steht, das ist drin. Das, was sie kennen. Woher sollen sie auch was anderes aufschreiben? Aber eigentlich muss man ja überlegen, wo will ich morgen hin? Wie wird das Haus morgen aufgestellt sein? Und was bietet mir vielleicht ein potenzieller Standard? Dieses Loslassen, dieses Sagen ja, bis gestern habe ich noch diese und jene Prüfung gemacht und die hat auch vielleicht mehr oder weniger Ertrag gebracht, in der Regel eher weniger. Brauche ich die morgen noch, kann ich das loslassen? Das ist eigentlich tatsächlich die Herausforderung, wenn man dann in Richtung einer Standardsoftware gehen will. Aber ehrlicherweise ist das gleiche Problem, wenn du versuchst, innerhalb deiner eigenen Anwendungssandschaft einfach durch sukzessive Erneuerung, das versuchen Kunden auch, also die behalten den Host und bestimmte Komponenten. Aber auch da musst du versuchen, die Komplexität wieder rauszukriegen. Wie kann ich eigentlich, in meiner S Kurve gedacht, wenn ich oben am Ende des S bin, muss ich die Komplexität wieder reduzieren, um wieder runterzukommen, einfacher die Dinge zu haben, sodass auch meine neuen Entwickler, die wir eben schon erwähnt haben, die ich vielleicht gerade in der Ausbildung habe, wieder eine Chance haben, da rein zu wachsen und, was auch logisch ist, die nächsten zehn, 15 Jahre wird ja wieder Komplexität aufgebaut. Es kommen wieder regulatorische Anforderungen, es kommen neue Produktideen, neue Prozessideen, was auch immer. Diesen Spagat zu gehen in den Häusern, das ist sehr schwer. Das ist überall wirklich Überzeugungsarbeit. Und das ist genau, wo wir auch in der Regel gerne ansetzen. Und das ist eine Topmanagement Aufgabe, muss von ganz oben gewollt sein, das heißt, die Menschen, die ihre Anforderungen aufschreiben, die kennen ja nur das, was sie heute tun und wie sie es tun. Und es muss ihnen jemand sagen: Ihr dürft neu denken, ihr dürft loslassen, ihr könnt Dinge vereinfachen, macht uns die Vorschläge. Das ist dieses Kommunikative, was in der Transformation drinsteckt, der Change. Man sagt, Change Management ist abgegriffen, der Begriff, aber letztendlich geht es darum, den Leuten wieder den Freiraum zu geben, loszulassen, anders zu denken, neu zu denken und das aufzuschreiben. Und das dann eben auch für die Zukunft, sei es nun intern oder durch Kaufsoftware, dann auch wieder die Umsetzung zu bringen, das ist die Herausforderung.

Stefan Paal Ich finde das ein schönes Bild, was du gerade beschreibst. Wenn man sagt, Modernisierung alleine reicht nicht, wenn man sich nur auf das Bestandssystem konzentriert, sagt man macht das einfach nur neu, sondern man muss auch weiterdenken, dass auch die Fachlichkeit, dass auch die Welt sich verändert hat und dass man dann Richtung Transformation, also wie kann ich auch meine fachlichen Prozesse transformieren, was muss ich vielleicht loslassen, um das auch überhaupt tun zu können? Man hat ja nicht unbegrenzt Ressourcen, man muss sich irgendwann auch mal fokussieren. Ich habe bei einer Versicherung erlebt, dass die gesagt haben das sind nicht wir. Wir haben Leute, die wollen sich nicht verändern. Wie ist denn deine Erfahrung? Ich meine, Versicherungen haben so ein bisschen den Touch, sag ich mal, dass sie schwerfälliger sind. Das sind ja riesige Tanker, so wie du schon sagst, seit vielen Jahren am Markt, funktionieren, warum soll man was ändern? Warum sollen die Versicherungen was ändern, wenn ihre eigenen Leute schon sagen: die brauchen wir nicht?

Jörg Rippchen Ja, das ist exakt die Situation. Das hat zum einen was damit zu tun, wie ich gerade sagte, eben den Freiraum zu schaffen, also darf ich überhaupt anders denken? Da kann man viel über Organisationsstrukturen und Modelle nachdenken. Welche Führungsebene tickt eigentlich wie? Ich sage keine Kundennamen, aber klassisch ist ein Topmanagement will erneuern, will Komplexität rausnehmen, will einfacher werden, will Kosten sparen. Einzelne Mitarbeiter, wenn man sie richtig packt, wollen das auch. Die sehen ihre täglichen Dinge, wo sie was tun, wo sie denken: Warum habe ich das eigentlich?

Stefan Paal Die merken den Schmerz meinst du.

Jörg Rippchen Die merken den Schmerz, genau und haben auch einen Anreiz, etwas dagegen zu tun. In der Regel sind es die Geschichten dazwischen, sprich verschiedene Führungsebenen, die jetzt auch selbst kurz vor der Rente stehen und sich sagen: was soll ich mir jetzt hier noch einen Kopf machen?

Stefan Paal Genau.

Jörg Rippchen Ich muss noch zwei Jahre durchhalten, dann ist das durch. Durch Automatisierung und vielleicht auch eine bessere Arbeitssteuerung oder automatisierte Arbeitssteuerung, die vielleicht vorher noch, ich sage mal, ein Gruppenleiter gemacht hat. Sein Daily Business war, Arbeit zu verteilen. Und jetzt sage ich: Nein, das kann morgen die Maschine, das kann sie noch viel besser. Sie kann Servicelevel berücksichtigen, Wirtschaftssituation berücksichtigen, Krankenstand und so weiter. Und dann fragen sich die Leute natürlich: Was mache ich denn dann morgen? Wo ist mein Aufgabenfeld? Und das sind alles Beharrungskräfte einer Organisation, die es zu durchbrechen gilt. Das heißt, man muss viel reden, man muss den Leuten ihre Perspektive geben, man muss klar ziehen, dass die einfachen Dinge nur wegfallen, dass wieder Zeit ist für höherwertige Tätigkeiten. Und das gehört eben mit zur reinen Techniktransformation dazu, eben auch ein Bild zu entwickeln, wie eigentlich die Organisation von morgen aussieht. Und da ist es eben nicht nur, dass Arbeit wegfällt oder sich anders strukturiert, es werden auch andere Skills benötigt plötzlich in Zukunft.Viele Unternehmen, die jetzt in eine Erneuerung gehen, leben jetzt endlich mal dieses Konstrukt der Produktmaschine. Das haben wir schon vor 15 Jahren, ich weiß nicht, ob du auch schon mal an solchen Themen beteiligt warst, wo man so die Idee hat. Es muss doch eine Maschine, eine Produktmaschine geben und die gibt es auch schon seit vielen Jahren, wo alles Produktwesen gebündelt ist und die kann ich gleichermaßen im Vertrieb einsetzen und das gleiche Produkt ist auch in meiner Bestandsführung. Mittlerweile gibt es wirklich Konzepte, die wirklich so gut sind, dass man das jetzt wieder aufgreifen kann und komplett in Richtung Produktzentrierung gehen kann. Das verlangt aber auch an Disziplin, Standardisierung und so weiter. Dann kommt dieser harte Bruch zwischen Was haben wir gestern gemacht und was machen wir morgen? Und das muss dann nochmal besser kommuniziert werden und besser in die Organisation gebracht werden, weil auch da dann plötzlich Jobs sind, die so wie sie gestern waren, nicht mehr stattfinden. Und plötzlich brauche ich Skill eines Produktmodellierer oder eines Produktarchitekten. Die gibt es typischerweise nicht, die müssen aufgebaut werden. Das sind so Sachen, das kann ja auch eine Chance sein, innerhalb der Organisation diese Rollen mal auszuprägen und zu sagen: Hey, da sind Entwicklungspfade für pfiffige Menschen meiner Organisation. Und es ist auch eine Chance, sich dahin zu entwickeln. Das ganze Thema Transformation, du siehst es schon, IT ist ein nicht unwichtiger Anteil, aber in meiner Welt ist die Businessseite und eben die organisatorische Seite mindestens genauso wichtig.

Stefan Paal Und das was du gerade gesagt hast, genau diese organisatorische Seite, dass man die Menschen auch mitnimmt und dass man denen die Ängste nimmt, dass dann morgen vielleicht ihr Job nicht mehr da ist, sondern dass es neue Perspektiven gibt, dass es vielleicht auch einen Mehrwert gibt, auch für sie. Das finde ich gut. Wie gehen die Versicherungen vor, wenn sie das tun, holen sie sich Beratung, machen die selber Task Forces? Wie ist der Prozess bei der Versicherung, wenn Sie so eine Transformation angehen?

Jörg Rippchen Auch unterschiedlich. Ich glaube, oftmals ist das ganze Thema unterschätzt. Idealerweise würde man tatsächlich das in Ruhe und zeitlich auch getaktet angehen. So ist meine Idealvorstellung. Mögen die Kunden jetzt anders sehen, aber ich habe schon einige sage ich mal, in die Richtung beraten können. Erstmal aufschreiben, was man eigentlich will, wo man hin will. Ordnungsrahmen, Zielbild, also irgendwelche Ergebnistypen, da reichen nicht die zehn Seiten Strategie, die jedes Haus hat. Natürlich hat jedes Haus eine Strategie, Manche haben auch 30 Seiten Papierstrategie, aber es ist eine Ebene tiefer zu beschreiben. Wie soll es denn funktionieren morgen. Da ist auf jeden Fall ein Gap, das kann man immer nur raten, das sollte man auf jeden Fall zunächst tun. Dann sollte man kritisch schauen make or buy, wie kann ich mir das vorstellen, weil damit einhergehend ja auch Diskussionen anfangen, was ist meine IT von morgen? Was macht denn meine IT, wenn ich alles kaufe. Kann ich eher Richtung Suite denken? Sollte man Richtung einer Suite denken oder Best of Breed, also will ich noch irgendwie integrieren? Schwierige Fragen, schwierige Diskussion. Dann haben wir aus meiner Sicht idealerweise ein Readiness Check. Wenn ich ungefähr weiß, da will ich hin, technisch will ich dies und jenes kaufen und nicht kaufen, selber bauen. Readiness Check, was meine ich damit? Mal schauen, wo stehe ich denn? Ich habe es eben schon gesagt, diese Häuser ticken und funktionieren. Die funktionieren gut. Das heißt, sie sind auf Run the Company komplett optimiert. Jetzt haben wir aber einen größeren Change, ein Umbau meiner Anwendungslandschaft fachlich, technisch. Dafür muss ich mal schauen, habe ich dazu die Verfahren und Methodiken? Habe ich gute Programmmanager? Haben die ein Vorgehensmodell, wie sie so etwas angehen würden? Es sind hochkomplexe Projekte oder Programme, die ablaufen, weil sie auf der End-To-End Kette Veränderung bringen. Typischerweise heute in den IT Organisationen getrennt. Irgendwer macht Vertriebssysteme, irgendwer macht das Bestandssystem, irgendwer kümmert sich um Finanzströme, irgendwer kümmert sich um Data Warehouse. Jetzt baue ich neu oder anders oder will umbauen und ich muss die End-To-End Kette denken, ich muss sie steuern inhaltlich vom Scoping, von der Qualität, vom Test und so weiter. Da einfach mal den Blick rausnehmen, kritisch auf die eigene Organisation gucken und sagen Schaffen wir das, können wir das? Und da hast du Recht, idealerweise dann natürlich auch wirklich ehrlich sein und sagen: da brauchen wir externe Unterstützung. Ganz wichtig zu schauen, wer könnte denn in so einem Projekt mitarbeiten? Ich weiß nicht, ob das allen so bewusst ist, wie viel Menschen man eigentlich zieht in so ein Programm, wenn man es wirklich von Scratch neu baut. Das sind Größenordnungen durchaus von 70 bis 100 FTEs, also Full Time Equivalents, die man braucht. Die ziehe ich aus der existierenden Organisation. Das sind Fachexperten, Business Analysten. Das sind natürlich auch die ganzen Querschnittsfunktionen wie Releasemanager, Umgebungsmanager, Testmanager, Testexperten für Testdaten. All diese Menschen, die ziehe ich eigentlich aus der Organisation für mehrere Jahre, wahrscheinlich in einem Programm. Und da muss man ganz ehrlich zu sich selber sein. Kann ich das staffen? Wo brauche ich externe Unterstützung? Und diese externe Unterstützung, die wird Geld kosten. Da komme ich dann langsam in die Thematik: Was wird uns das kosten? Was darf es uns eigentlich kosten in diesen Umbau zu gehen? Wie lange kann ich das durchhalten? Wie lange braucht mein internes Skill Management, die Leute an die Fähigkeiten aufzubauen, damit ich die extern wieder ersetzen kann? Ein hochkomplexes Zusammenspiel, was man, wenn man es richtig macht, im Vorfeld überlegt und dann gezielt auch mit seinem Dienstleister, den man dann einkauft, ein oder mehrere. Auch das ist wieder so ein Thema. Wenn ich von mehreren Leuten oder von mehreren Unternehmen Software einhole oder mir auch Unterstützung hole, brauche ich einen Provider Management, muss überlegen, wer muss wie wann wo, welche Anforderungen, welche Releasezyklen, um das wieder zu synchronisieren. Es stehen eine ganze Reihe von Aufgaben und notwendiger Fähigkeiten, die typischerweise im Haus so nicht vorhanden sind. Es sei denn, es sind Häuser, die quasi alle 3,4,5 Jahre Merger gemacht haben. Die kennen das, die haben tatsächlich diese Fähigkeiten irgendwo schon in den Genen drin und sind besser aufgestellt für so ein Transformationsvorhaben. Kleinere Unternehmen, die kommen da wirklich schnell an ihre Grenzen.

Stefan Paal Aber wie geht ihr denn damit um, wenn sie jetzt zum Beispiel nicht genügend eigene Leute haben, sowas zu begleiten? Ich habe eine Versicherung kennengelernt. Die haben alles rausgegeben. Und dann haben wir gesagt: Ihr könnt doch nicht alles rausgeben, ihr müsst doch selber noch steuern, ihr müsst noch selber wissen, was da passiert.

Jörg Rippchen Genau. Das ist dann so der Kurzschlusseffekt, wenn man sagt: Ich gebe alles raus und mein Dienstleister wird es schon richten. Wobei das schwierig zu steuern ist. Allein das zu steuern, auch in Verträge zu gießen und in entsprechende Mechanismen, die mir als Kunde sicherstellen, dass ich auch das bekomme, was ich bestellt habe. Das ist nämlich gar nicht so einfach an vielen Stellen. Das ist aus meiner Sicht nicht der richtige Weg. Man kann natürlich um sich eine verlängerte Werkbank natürlich irgendwo auch in den Dienstleistern holen. Aber die Steuerungshoheit intern zu halten und fachlich technisch zu sagen: Was bekomme ich hier eigentlich in welcher Qualität? Und ist es das, was ich auch wirklich brauche? Das darf man nicht rausgeben, niemals. Und da rate ich auch immer dringend von ab. Dann eher sich vorbereiten, die Zeit nutzen, intern Skills aufzubauen. Sich wirklich im Sinne von längerfristiger Planung wirklich auf so ein Vorhaben einrichten und auch sich nicht nur neue Projekte fokussieren. Was brauche ich alles da? Denn egal, wie viel ich rausgebe oder nicht rausgebe. Der Punkt ist, dass es auf jeden Fall meine interne Organisation belastet. Das sind Menschen, die heute da irgendwas, wichtige Dinge gemacht haben. Denn idealerweise gibt man die Besten raus in das Projekt, denn dort soll das gute Neue entstehen. Das Alte muss trotzdem weiterlaufen. Keep the business alive. Das gilt fachlich als auch technisch. Wer betreut denn dann meinen Host? Wer betreut denn dann, wenn da ein Absturz irgendwo in der Bestandsführung oder im Schadensystem gibt? Das muss auch geregelt sein. Wenn ich überall die Leute rausziehe, dann entstehen Lücken und da muss ich mir sehr gut Gedanken machen: Wie kompensiere ich das? Wie fahre ich vielleicht auch in der alten Welt meine Änderungsgeschwindigkeit runter? In der Regel bremse ich durch den Start von Transformationsvorhaben eigentlich die alte Welt aus. Wenn die aber eh schon produktseitig vielleicht schon weit zurückliegt, dann ist das auch ein Commitment der Organisation in Summe. Nicht nur: Die da machen das neue Projekt, sondern wir als Organisation akzeptieren, dass wir übergangsweise vielleicht mehr Arbeit haben und dass unsere Produkte eben nicht nur einmal Jahr ein Facelift kriegen, sondern wir mal jetzt mal zwei, drei Jahre durchhalten müssen, bis das Neue kommt. Das ganze Haus muss es wollen, dass diese Transformation stattfindet. Und jeder muss seinen Beitrag leisten. Nicht nur die, die in dem Projekt sind, sondern alle anderen unterstützen quasi das Vorhaben und sorgen dafür, dass das Haus an sich noch weiter vernünftig Produkte verkaufen kann.

Stefan Paal Ja, vor dem Hintergrund, dass du sagst, dass es in der Regel mehrere Jahre dauert. Das kommt natürlich auf das System an, aber trotzdem über mehrere Jahre. Dann ist es wahrscheinlich eher so ein schrittweises Ablösen des Bestandssystems. Das alte Systems wird neu.

Jörg Rippchen Es ist eine ganz spannende Diskussion, aber es gibt kein Richtig und kein Falsch. Aber die zwei grundlegenden Modelle, gut, dass du es noch mal ansprichst, das ist wirklich eine ganz wichtige Diskussion, die man im Vorfeld führen muss, ist nämlich die Frage: Will ich Komponenten-weise ersetzen? Ich hatte am Anfang mal grob skizziert: Wir haben das Partnersystem, wir haben Inkasso, wir haben Bestandsschaden und so weiter. Partner hatte ich übrigens eben vergessen, aber ist ganz wichtig natürlich. Weil der Kunde muss irgendwo gespeichert sein. Und dann gibt es natürlich die Ideen zu sagen: Ich kaufe mir eine Suite, dann nehme ich das Partnersystem und tausche erstmal das Partnersystem gegen mein altes Partnersystem, weil da ist die Person XY, die jetzt nächstes Jahr in Rente geht. Den Gedanken kann man haben, aber eine alte Welt an ein neues Partnersystem anzuschließen, ist unendlich komplex, weil die Modelle unterschiedlich sind, Historisierung unterschiedlich ist, weil ich vielleicht dann vom Host irgendwo in der Cloud auf eine Java Komponente zugreife oder oder oder. Viele, viele Fragen. Deswegen muss man sehr genau durchdenken, was man da tut. Und für mich immer der wichtigste Aspekt: Man holt sich eigentlich durch diesen Anschluss „Alt an neu“ die Restriktion des alten Systems in die neue Welt. Da rate ich immer dringend von ab. Ich bin ein Freund, ganz ehrlich, des Greenfield Ansatzes. Das heißt, die neue Welt wird neben die alte Welt gesetzt. Und ein ganz wichtiger Punkt. Das macht auch Probleme, es ist auch nicht, dass dann alles gut ist, aber ich habe schon mal die Chance, die neue Welt End-to-End mäßig in meiner Idealvorstellung aufzubauen, möglichst nah am Standard zu bleiben, falls ich mir was kaufe bzw. mein Standard neu auszuprägen, meine neue Komplexitätsstufe, die ich reduziert habe, auszuprägen und weil es eben mehrere Jahre dauert, muss man trotzdem noch an bestimmten Stellen synchronisieren. Es geht eben nicht ganz „green“. Das wäre natürlich ideal. Aber natürlich kommen Anforderungen wie: Naja, ich will aber noch eine Kundensicht erhalten. Der Kunde ist in der neuen Welt, ist in der alten Welt. Irgendwo muss ich sehen, dass es ein Kunde ist. Da kommen CRM Systeme ins Spiel, wo Dinge zusammenlaufen. Spätestens in der Bilanz müssen wir uns treffen. Sprich, wenn ich Geld verdiene mit meinen neuen Produkten, müssen die bilanziert werden. Im Hauptbuch kann man schon darüber streiten: Wo kassiere ich? Über alt, über neu? Man muss sich sehr genau die Frage stellen. Greenfield ist immer noch mein präferiertes Szenario. Stelle ich die neue Welt daneben, überlege mir ganz genau die Synchronisierungspunkte. Die liegen in der Regel beim Partner, beim Hauptbuch und im Data Warehouse. Regulatorik, gewisse Berichte und Reports, die wir erzeugen müssen, müssen wieder gesamtheitlich gesehen werden. Und Provision, spannendes Thema. Auch da viel Diskussion. Kann man einem Vermittler über eine gewisse Zeit zwei Provisionsabrechnungen zumuten? Das ist wie als ob du zwei Gehaltsabrechnungen bekommen würdest.

Stefan Paal Nehme ich gerne.

Jörg Rippchen Wenn zweimal das gleiche darauf steht.

Stefan Paal Genau.

Jörg Rippchen Aber das ist tatsächlich ein spannendes Thema und sehr emotional. Und das sind Fragen, die man dann im Ansatz klären muss, wie man eigentlich vorgehen will. Und die Zeit wird oftmals unterschätzt. Und da muss ich ehrlicherweise auch mal Richtung der Softwareanbieter schauen, die da am Markt sind. Ich kenne schon einige, ich habe mit einigen schon Projekte mehr oder weniger intensiv durchführen können. Es wird immer viel zu optimistisch geplant. „Ja, nach drei Jahren sind wir durch.“ Das habe ich noch nicht gesehen. Ganz ehrlich, ich will auch nicht entmutigen, aber es dauert länger. Und vor allen Dingen, wenn ich ein Mittelständler bin, der jede Sache hat, der wie eben schon gesagt Privatkundengeschäft, Gewerbliches oder Industriegeschäft hat. KFZ ist immer ein ganz besonderes Thema. Es dauert, aber man muss sich die Zeit nehmen. Und nehmen wir mal an, wir hätten die neue Welt aufgebaut. Ich habe noch die alte. Ich habe Bestand in den alten Welten. Das große und mysteriöse Wort Migration kommt dann irgendwann ins Spiel. Naja, wie komme ich denn aus der alten Welt in die neue Welt? Und da stellen sich wieder ganz andere Fragestellungen und da insbesondere auch braucht man auch viel vom internen Know-how und auch die Menschen, die noch die Bestände und die Bestandsverteilung kennen. Tarif Generation so ein Stichwort. Teilweise stößt man auf Haftpflichtversicherungen, die wurden in den Vierzigern, teilweise noch davor, abgeschlossen. Aber nehmen wir mal an, es ist 1948. Du hast quasi die erste Haftpflichtversicherung dieser Welt. Viel Bestand liegt dann in den Sechzigern. In den Achtzigern gab es dann mal größere Umbrüche, was die Risikoselektion, aber auch die Ausgestaltung der Produkte anging. Und das musst du jetzt alles versuchen in die neue Welt zu bringen. Da braucht es auch schlaue Ideen, viel Mut, auch Dinge loszulassen in Teilen. Ich kenne auch Kunden, die gesagt haben: Wir durchforsten unsere Bestände und wir bereinigen auch. Das heißt, denn der Kunde jetzt nicht sagt: Ich will auf ein neues Produkt bei euch, dann müssen wir ihn leider kündigen. Auch sowas muss diskutiert werden. Wie viel Bestandsabrieb habe ich? Wie viel Neugeschäft erhoffe ich mir? Um auch diese Fragestellung: Wie komme ich denn wirklich so weit, dass ich die alte Welt abschalten kann? Das ist noch mal eine ganz besondere Herausforderung. Und mit zwei, drei Jahren ist da nichts zu machen, aus meiner Sicht. Ab einer gewissen Größe des Versicherers, dauert es schon mehr. Da kann man durchaus mal Richtung fünf oder acht Jahren auch denken. Und die muss man durchhalten. Für alles, was man tut, für alles, was wir gerade an einem anderen Personalthemen oder auch rhetorischen Themen, muss man eben einen Fahrplan haben, das über die Zeit durchzuhalten.

Stefan Paal Ich habe noch zwei Themen, die ich gerne ansprechen will. Wir haben schon lange geredet, muss ich mal auf die Uhr gucken. Wie ist denn das Thema Cloud bei der Versicherung? Das ist bestimmt auch noch mal ein besonderes Thema, gerade was diese Datenschutzthemen angeht und natürlich auch wie die Zusammenarbeit mit dem Alt-System ist.

Jörg Rippchen Zunächst erst mal die Frage der internen IT: Will ich mich überhaupt damit anfreunden? Das ist On-premise. Sprich, die Maschinen in den Keller stellen ist immer noch die präferierte Variante.

Stefan Paal Immer noch auch bei den Versicherungen?

Jörg Rippchen Diskussion beginnt, aber ich kenne viele Kunden, die es mir gesagt haben: Neue Software kommt auch mal auf meinen Server hier im Hause. Security habe ich unter Kontrolle. Aber Cloud kommt natürlich. Das ist jetzt ein Thema und es geht dann in der Regel nicht nur darum, die Infrastruktur auszulagern. Sprich, ich habe den Server nicht mehr im Keller, sondern in der Cloud, sondern einhergehend eigentlich mit der Diskussion Managed Service. Und wenn man das weiterdenkt, auch unter Betrachtung: ich kaufe vielleicht Software, die dann in der Cloud unter Managed Service läuft. Was machen dann meine Leute und meine Entwickler? Und da entsteht so eine Diskussion, die dann in der Regel der IT Vorstand sehr stark treiben muss, noch eine Strategie für entwickeln muss. Nämlich verbunden mit der Frage: Wie viel IT gönne ich mir noch? Scherzhaft gab es früher immer so oft den Spruch: Wir sind eigentlich ein IT-Unternehmen mit angeschlossener Versicherung.

Stefan Paal Den Spruch kenne ich noch.

Jörg Rippchen Kennst du auch, genau. Und da will man eigentlich wieder von weg. Wir sind eine Versicherung im Kern und leider ja, wir müssen auch irgendwo IT haben und betreiben. Und dieser Umbruch, der ist gar nicht so einfach zu diskutieren, weil natürlich auch da wieder Menschen dranhängen, weil da auch entsprechende Fähigkeiten und Skills dranhängen. Nichtsdestotrotz, die Diskussionen werden zunehmend geführt und wenn man sie ganzheitlich führt, im Sinne der Transformation, dann auch relativ radikal im Sinne von: Raus, sprich eher weg. Natürlich die Kontrolle behalten, natürlich den Überblick behalten, das Ganze auch steuern können in einem passenden Provider Management. Denn ich muss all diese Dienstleister koordinieren. Wenn mir mein Software Lieferant sagt: Pass mal auf, wir brauchen eine neue Java Version und überhaupt vom Kubernetes brauchen wir eine andere Version. Da muss ich das wieder organisieren mit meinem Cloud Anbieter. Das muss alles gemanaged werden und dann sagt aber SAP: Ich kann aber noch nicht, ich muss aber auf der alten Version bleiben. Das sind so lustige Themen, die dann entstehen, die gemanaged werden müssen, in den Release Plan rein müssen. Das sind Diskussionen. Man diskutiert immer gerne: Cloud Ja, nein. Das ist so die erste Frage. Ja, ich will nicht alles kompliziert machen, ich will nur so ein bisschen mitgeben: Dahinter stecken immer noch eine ganze Menge mehr Fragestellungen, die man eigentlich gesamtheitlich wieder betrachten muss, um da zu vernünftigen Lösung zu kommen. Und wie wir eben schon gesagt haben, wenn das Ganze mehrere Jahre dauert, dann gibt es nicht nur die Beschreibung des Endzustandes, sondern ich muss die Zwischensteps sauber beschreiben, damit ich sie managen kann. Denn jede Transformation, egal ob ich kaufe, was selber mache, mich verändere, Greenfield oder auch Komponenten-weise austausche, es wird erstmal schlimmer. Es ist so. Es tut mir leid, in den Orbit das sagen zu müssen, weil es wird erst mal komplexer, weil ich was Neues daneben stelle oder umbaue. Und das muss man sich sehr stark vor Augen halten. Und deswegen mein Appell auch immer an die Versicherer: Fangt früh genug damit an! Also wenn wirklich 10%, 15%, 20% meiner Belegschaft vor der Rente stehen, dann ist es schon fast zu spät.

Stefan Paal Früh anfangen. Ja, früh darüber nachdenken. Gerade weil du sagst, wenn es 5 bis 7 Jahre dauert. Wenn Cloud ein Thema sein soll. Ich habe einen Kunden, der ist keine Versicherung, sondern eCommerce. Sie haben angefangen mit On-premises und haben dann festgestellt nach zwei Jahren: Oh, es wird ein bisschen viel mit den ganzen Services, mit der ganzen Infrastruktur und sind dann in die Cloud gegangen. Das hat noch ganz gut funktioniert, weil das System noch nicht zu weit fortgeschritten war, aber trotzdem war es schon mal Schmerzen, weil man natürlich schon eine Infrastruktur aufgebaut hat. Man hat die Software, die ganze Landschaft schon darauf ausgerichtet hat, on-premise zu betreiben und geht dann in die Cloud. Und dann ist natürlich, wenn man vom Cloud Anbieter, wenn man das Cloud Native macht, hat man natürlich bestimmte Dienste, die man selbst vorher betrieben hat. Die kriegt man dann quasi „gegen Geld“. Man muss sie nicht selbst betreiben und warten.

Jörg Rippchen Exakt, aber du hast einen Aspekt eben noch erwähnt. Ich weiß nicht, ob wir die Zeit noch haben.

Stefan Paal Wir nehmen uns die Zeit.

Jörg Rippchen Wir haben diese Mischkonstellation. Selbst wenn wir Greenfield machen und wir wollen mindestens den Partner synchronisiert haben oder zumindest mal geshared haben, dass ich sehe, dass ein Kunde ein Produkt in der neuen Welt, in der alten Welt hat. Dann habe ich genau dieses Phänomen: Wer ist mein führendes Partnersystem? Entweder muss ich sehr viel aus der Cloud in Richtung meines Hosts sprechen oder mein Host muss irgendwann lernen, mit der Cloud zu sprechen. Da kommen noch mal im Sinne der nicht-funktionalen Anforderungen, sprich Performance, Durchsatz, Stabilität nochmal Fragen. Gerade die Netzwerkanbindung lassen sich auch Cloud Anbieter ganz gut bezahlen. Da mal Überlegungen zu machen, wie oft kommt es vor? Was ist mein Durchsatz? Wie wird sich vielleicht Match Verarbeitung morgen verändern? Das sollte man auch im Vorfeld überlegen, bevor man dann in die Vertragsverhandlungen mit seinem Cloud Anbieter einsteigen wird. Da lauern tatsächlich auch noch Gefahren. Und wenn der Durchsatz nachher nicht mehr da ist und meine Inkassoverarbeitung nicht mehr abends durchgeht und die Monatsverarbeitung sondern jetzt zwei Tage braucht. Das sind dann Dinge, die bringen auch dann die alte Welt in Unwucht. Wo man eigentlich nichts mehr tun wollte. Eigentlich wollte man gar nichts mehr daran ändern, weil man das Neue baut. Aber so kann es Abhängigkeiten geben, die dazu führen, dass ich doch mal was tun muss. Und das sind dann ungeplante Kosten, die dann quasi auf dem Weg auftreten und dann auch in Schwierigkeiten bringen.

Stefan Paal Ungeplante Kosten. Du hast es schon angesprochen, ich habe schon fast eine Stunde rum, ich könnte mir dir noch viel länger reden. Ich habe noch 1000 Fragen, aber wir müssen, glaube ich, jetzt auch mal zum Ende kommen. Jörg, es hat mich total gefreut, dass du heute ein bisschen mehr Einblick gegeben hast, wie Versicherungen ticken, wie sie ihre Modernisierung angehen. Ich würde dich gerne zum Schluss noch mal für die Entscheider, für die Zuhörer, die aus der Versicherungsbranche kommen, noch mal bitten: Was für eine Botschaft gibst du denn den Versicherungen, wenn du sie heute triffst und sie darüber nachdenken, wie sie ihre Versicherung, ihre IT, ihre Fachlichkeit verändern, modernisieren, transformieren wollen? Welche Botschaft gibst du ihnen mit?

Jörg Rippchen Die hat sich vielleicht so ein bisschen als roter Faden schon erkennen lassen. Meine Kernbotschaft ist: Beginnt fachlich, nicht technisch. Das ist tatsächlich meine Hauptbotschaft, die ich immer wieder bestärken kann. Und selbstkritisch zu bleiben als Unternehmen. Was kann ich tun? Was kann ich leisten? Was kann ich personell leisten, finanziell leisten? Ich glaube, kleinere Versicherer sollten überlegen, Richtung Suiten zu gehen, vielleicht Insurance in eine Cloud. Erste Modelle kommen da hoch. Wirklich komplett vielleicht rauszugehen, sich nur noch übers Produkt quasi differenzieren. Mittelständler werden das wohl nicht machen, aber sich sehr genau überlegen: Was ist die Leistungsfähigkeit meiner Organisation? Und wo wollen wir hingehen? Das Schlagwort KI natürlich zu berücksichtigen. Ich will es einmal kurz erwähnt haben.

Stefan Paal Ich wollte es rauslassen. Aber dann erzähl mal zwei Sätze.

Jörg Rippchen Das ist natürlich ein Thema der Zukunft, aber es löst jetzt nicht meine Probleme. Ich sage immer gerne: Erst die Pflicht, dann die Kür. Erst mal die Basis schaffen. Und auf dieser Basis kann ich dann intelligenter werden, auch mit künstlicher Intelligenz. Bitte die Reihenfolge einbehalten wäre so eine Botschaft. Und tatsächlich sich auch Unterstützung holen, den Blick von außen holen. Das soll nicht nur Werbung für uns sein, sondern ich meine das wirklich ernst. Man schmort oftmals im eigenen Saft, sieht vielleicht nicht die Möglichkeiten, Potenziale oder aber auch die Fettnäpfchen, in die man treten kann. Deswegen der Appell, sich mal da einen Blick von außen zu holen und eben dieses ganze Umfeld, das ganze Universum einmal komplett zu betrachten. Und dann kann man wieder seine Überlegungen machen. Aber das ist eigentlich mein Appell. Genauso wie wir das in so einem Gespräch hier gemacht haben, müsste man das eigentlich mit dem Kunden machen. Einmal den ganzen Bogen spannen und dann mal überlegen: Wo hat eigentlich welches Unternehmen seine Schwerpunkte und wo sieht es welche Herausforderungen? Und dann kann man sehr viel gezielter dann auch in so eine Auswahl Umsetzungsphase gehen.

Stefan Paal Jörg, Wir bleiben unter der Stunde. Es hat mich gefreut, mit dir heute zu sprechen. Und ich habe auch ein bisschen noch was mitgenommen. Auch dein Blick, die Fachlichkeit, das durchzuhalten, das finde ich gut. Ich bedanke mich für deine Zeit. Ich bedanke mich bei den Zuhörern. Vielleicht machen wir noch mal ein Gespräch in einem anderen Kontext, Jörg. Weil es freut mich, wenn ich noch mal mit dir über solche Themen sprechen kann. Es war sehr, sehr gut.

Jörg Rippchen Ich bedanke mich auch und würde mich freuen, wenn wir das fortsetzen könnten. Es gäbe da noch ein paar Aspekte zu betrachten.

Stefan Paal Das macht es schon mal spannend. Also, ciao!

Jörg Rippchen Bis bald, ciao!

Principal Consultant

Stefan arbeitet als Principal Consultant bei INNOQ Deutschland und besitzt mehr als 35 Jahre Erfahrung in der Software-Entwicklung. Sein aktueller Schwerpunkt liegt in dem Aufbau von web-basierten Anwendungssystemen. Der Einsatzbereich erstreckt sich über die Strategieberatung, die Systemkonzeption, den Architekturentwurf, die Softwareentwicklung bis zur Inbetriebnahme.

Geschäftsführer arc innovations

Jörg Rippchen, Geschäftsführer von arc innovations, bringt über 35 Jahre Erfahrung im Versicherungssektor mit. Ursprünglich als Versicherungskaufmann gestartet, hat er sich auf die Modernisierung von Bestandssystemen und die Integration von Technologien wie Automatisierung spezialisiert. Bei arc innovations zielt er darauf ab, Versicherungen durch das Verbinden von IT und Geschäftsprozessen bei ihrer Transformation zu unterstützen.