Make or buy? Wer nur kauft, wird abgehängt! Eigene Software ist der Erfolgsfaktor

Ist die Investition in proprietäre Software für Versicherer eine Verschwendung von Zeit und Geld? Schließlich gibt es genügend Softwareanbieter, die scheinbar alle Wünsche erfüllen können (siehe ITFM-Marktübersicht). Doch wer seinen Kunden mehr bieten will, muss dafür auch mehr tun, meint Toby Dixon, Delivery Director Banking & Capital Markets Europe bei Endava: kaufen schafft Konformität, entwickeln Differenzierung.

von Toby Dixon, Delivery Director Banking & Capital Markets Europe bei Endava

Die Frage ist heute nicht mehr, ob Unternehmen in neue digitale Plattformen investieren sollen, sondern wie sie bei der Einführung vorgehen sollen. Dafür gibt es drei Optionen: Software einkaufen, eigene Lösungen entwickeln oder eingekaufte Software selbst weiterentwickeln. Die erste Antwort scheint die offensichtlichste zu sein, aber wie so oft ist der einfachste Weg nicht immer der beste – zumindest nicht für diejenigen, die ihre Wettbewerber in den Schatten stellen wollen.

Das Pendel schwingt zurück in Richtung eigene Software

Der Blick in die Vergangenheit zeigt: Schon in den 1950er-Jahren haben Versicherer mit neuen Großrechnern ihre Digitalisierung begonnen, zunächst mit proprietären Anwendungen. Die Entwicklung von COBOL gegen Ende des Jahrzehnts vereinfachte diesen Prozess zwar, doch die Einstiegshürden blieben hoch. Wenige Jahre später war die Notwendigkeit dann nicht mehr gegeben: 1962 führte IBM eine standardisierte Software für die Versicherungsindustrie ein und seitdem greifen Versicherer auf Produkte von Drittanbietern zurück.

Allerdings: Wer den Standard nutzt, kann (potenziellen) Kunden auch nur den Standard bieten.”

Um in der Masse der Versicherer hervorzustechen, braucht es aber mehr: mehr Funktionen, mehr Personalisierung, mehr Differenzierungsmerkmale. Gleichzeitig ist die Entwicklung differenzierter Plattformen für Versicherer dank Cloud-Plattformen, moderner Frameworks, Low-Code- oder No-Code-Ansätzen und besseren Tools für die Datenverarbeitung einfach wie nie – kein Vergleich zu den 50ern.

Wann kaufen, wann selbst entwickeln?

Die entscheidende Frage bei der Wahl zwischen Software kaufen und (teilweise) selbst entwickeln ist: Was soll sie leisten können – nur etwas, das notwendig ist, oder etwas, das einen von der Masse abhebt? Natürlich gibt es Anwendungen und Funktionen, für die der Standard vollkommen ausreichend ist. Es würde wohl kein Versicherer einen eigenen Service zum Nachschlagen von Postleitzahlen entwickeln wollen. Zudem existieren auf dem Markt so viele Lösungen für gängige Geschäftsprozesse wie Buchhaltung, HR- oder Projektmanagement, dass sich dafür leicht geeignete Tools finden lassen.

In anderen Fällen lohnt sich aber die Investition, um selbst eine passende Plattform zu entwickeln. Wenn etwa die vorhandene Software das Nadelöhr ist, das eine schnelle und flexible Reaktion auf veränderte Marktbedingungen verhindert, ist das ein Problem. Ähnliches gilt für fehlende Funktionen: Wenn eine Versicherungsplattform zum Beispiel nur jährliche oder einmalige Policen unterstützt, der Versicherer aber wöchentliche Beiträge anbieten möchte, braucht er eine andere Lösung. Hier muss das System genau überprüft und geklärt werden, inwieweit man die implementierte Software als Basis nutzen und anpassen kann oder ob eine maßgeschneiderte eigene Lösung notwendig ist.

Die richtige Architektur und Technologie

Bevor es an die (Weiter-)Entwicklung geht, sollten Versicherer drei wesentliche Punkte beachten:

• In Plattformen und Business Value denken, nicht in Anwendungen

Die Produkte und Services, die Versicherer Ihren Kunden anbieten, kommen im Laufe der Customer Journey mit vielen anderen Systemen in Verbindung. Wenn man die Komponente der Unternehmensarchitektur identifiziert, die einen Aspekt dieses Services am besten anbieten kann, wird das die Art verändern, wie man über die Interaktion von Technologie denkt, und eine überlegtere User Experience fördern. Dieser Ansatz bietet auch den besten Weg für Versicherer, um ihre Change-Maßnahmen zu organisieren sowie die Teams, die daran beteiligt sind.

Die alten Tage von „hier das Business, da die IT“ haben nun Platz gemacht für neue Modelle der Zusammenarbeit, die sich darauf konzentrieren, schnellstmöglich das beste Ergebnis für den User zu erreichen.”

• Kontrolle behalten, nicht zu kompliziert werden und Lösungen zukunftssicher gestalten

Es nützt nichts, wertvolle Ressourcen aufzuwenden, um eine Lösung zu bauen, die nach kurzer Zeit schon wieder ersetzt wird. Der Blick muss deshalb in die Zukunft gehen: Wie gehen Produktanbieter mit dem Thema Langlebigkeit um und was sind aktuelle und künftige Standards in der Softwareentwicklung?

Wenn Versicherer überlegen, Lösungen von Drittanbietern einzusetzen, lohnt es sich anzuschauen, wie diese mit Wandel umgehen und welchen relativen Stellenwert man hat. Die Hersteller solcher Produkte stehen vor denselben Herausforderungen wie ihre Kunden: Sie müssen monolithische Architekturen modernisieren und sich gut auf den Wandel vorbereiten – aber in einem viel größeren Umfang. Die Softwarelösung eines Unternehmens ist ganz speziell auf dieses ausgerichtet, aber deren Lösung ist für eine Vielzahl an Kunden gedacht. Wie gehen die Anbieter damit um? Wie oft werden Updates veröffentlicht und wie lästig ist das für die Kunden? Welche Priorität haben die eigenen Change Requests im Vergleich zu anderen? Wenn man sich als Unternehmen für eine Paketlösung entscheidet, dann sagen die Erfahrungswerte:

Die Lösung sollte so weit wie möglich „von der Stange“ eingebunden und diese Komponenten als Teil der Gesamtplattform genutzt werden.”

Die Individualisierung solcher Plattformen erhöht die Abhängigkeit von der Fähigkeit des Anbieters, gut mit Wandel umgehen zu können.

Wenn man sich fürs Entwickeln entscheidet, geht der Trend schon länger hin zu Microservices und Komponentisierung. Traditionelle, monolithische Architekturen werden als ein großes System gebaut und wenn eine Komponente ausfällt, kann es passieren, dass das ganze System nicht mehr funktioniert. Microservices-Software besteht dagegen aus vielen kleinen Services, die einzelne, definierte Aufgaben ausführen. Sie funktionieren unabhängig voneinander und kommunizieren über APIs miteinander. Entsprechend können sie bei mehreren Produkten, die denselben Service brauchen, wiederverwendet werden, was Komplexität und Kosten reduziert. Sie können parallel entwickelt und getestet werden, was Zeit spart. Zudem kann man bei diesem Ansatz klein anfangen und Schritt für Schritt nach Bedarf skalieren und neue Features ergänzen. So können Komponenten von monolithischen Plattformen im Laufe der Zeit ersetzt und die Umsetzungsrisiken dabei verringert werden.

• Die Qual der Wahl bei der Technologie

Versicherungen können aus einer immer größeren Auswahl an modernen Technologien wählen, um ihre Software zu bauen: Infrastruktur-Optionen wie Microsoft Azure, Amazon Web Services oder Google Cloud, Serverless oder Container, Programmiersprachen und Frameworks wie Python oder Go, React oder Angular und vieles mehr – die Liste wird jeden Tag länger. Die Entscheidung über den Tech-Stack wird am Ende auf den Anforderungen der Entwickler und der Anwendung basieren.

Die ausdrückliche Empfehlung:

Orientierung am Mainstream – Vorsicht vor Ego-Projekten, die dazu führen, dass es in ein paar Jahren nur eine Handvoll Leute im Land gibt, die das System betreiben können (und für dieses Privileg entsprechende Rechnungen stellen werden).”

Die gängigsten Sprachen werden sich weiterentwickeln und dadurch können es auch auf ihnen basierende Plattformen, was wiederum die Notwendigkeit von umfassendem Refactoring reduziert.

Low-Code- oder No-Code-Plattformen legen einige Geschäftsfunktionen, zum Beispiel Rating-Engines, direkt in die Hände der Business-User. Das kann durchaus von Vorteil sein, solange der Wandel auch hier verantwortungsvoll gemanagt wird.

Fazit

Es gibt immer weniger Gründe, warum Versicherungen sich darauf beschränken sollten, Software nur von Drittanbietern zu beziehen.

Zwar erfüllt diese in der Regel ihren Zweck, wer aber durch individuelle Angebote und innovative Funktionen hervorstechen will, muss heute eigene Lösungen für seine Kunden entwickeln.”

Immerhin ist das inzwischen wesentlich einfacher als noch zu den Anfängen der Versicherungssoftware.Toby Dixon, Endava