Börsennotierte Startups wie Lemonade (Market Cap 3,5 Milliarden Dollar) oder Deutsche Familienversicherungen (330 Millionen Euro) treten gegenüber Investoren als Insurtechs auf und werden entsprechend mit dem Vielfachen des Prämienvolumen bewertet – obwohl sie operativ mittelfristig kaum Gewinn ausweisen werden. Ähnliches gilt für die nicht börsennotierten Startups, die entweder unabhängig sind, wie zum Beispiel Wefox und Neodigital, oder als Bestandteil von Konzernen gemanagt werden, wie IptiQ von der Swiss Re (intern angeblich mit 1 bis 1,5  Milliarden Franken bewertet) und Friday von der Baloise oder Nexible bei ERGO.

Partner-Inhalte
 
 
 
 
 
 

Aktuell entsteht mit dem bevorstehenden IPO von Ant Financial, einem Ableger von Alibaba, der für Digital-Finance-Lösungen berühmt ist, in den nächsten Monaten einer der grössten börsennotierten Finanzkonzerne der Welt. Eine Marktkapitalisierung von 200 Milliarden Dollar scheint möglich. 

Autor: Roland Auer (Pseudonym)
Der Autor verfügt über jahrzehntelange Erfahrung bei der Digitalen Transformation von Versicherungsgesellschaften.

Nebst der Tatsache, dass sich alle vorgenannten als Technologie-Unternehmen begreifen, ist auch ihr Versprechen gleich: Mit der Digitalisierung werden gleichzeitig sowohl Verwaltungs- als auch Schadenkosten gesenkt und das digitale Kundenerlebnis optimiert. 

Angesichts dieser Entwicklung ist es höchst verwunderlich, dass sich jüngst auch Helvetia in die unrühmliche Reihe jener Versicherer einreiht, die mit der Digitalisierung des Kerngeschäfts offenbar nicht vorankommen.

Nur wer weiss, woher er kommt, weiss, wohin er geht

Zunächst offenbart ein Blick in die Branche, dass es vielen Schweizer Versicherern mit unterschiedlichen Projektansätzen ähnlich erging: 2015 musste die Zurich ihre ambitionierten Europa-Ideen begraben und Wertberichtigungen im dreistelligen Millionenbereich verkraften. Manchen sind auch noch gescheiterte Grossprojekte bei Baloise, Nationale Suisse und anderen in lebhafter Erinnerung. Ein Blick über die Grenzen bestätigt, dass es sich nicht um ein helvetisches Phänomen handelt: 2015 Projektstopp bei der Wiener Städtischen mit Abschreiber im dreistelligen Millionenbereich, MF-(Motorfahrzeug-)Projekte bei HDI und ERGO mit sehr wesentlichen Verzögerungen und Kostenerhöhungen etc. Allein die Liste der öffentlich bekannten Fälle ist auch im Ausland sehr lang.

Viele denkbare Ursachen

Mögliche Ursache könnte die gewählte Software-Plattform sein. Bei genauerer Betrachtung erscheint das aber wenig stichhaltig: sowohl die in den letzten Jahren sehr seltenen Eigenentwicklungen als auch die Lösungen namhafter Hersteller sind von Projektab-/-unterbrüchen und/oder wesentlichen Kostenüberschreitungen gleichermassen betroffen. 

Da es immer wieder auch etablierte Versicherer gibt, denen die digitale Transformation des Kerngeschäfts gelingt, wie beispielsweise Helsana mit Adcubum, Baloise mit Guidewire oder HDI-D mit SAP, führt die Suche nach den Ursachen in die Interna. Hier zeichnet sich in der gesamten Branche ein ähnliches Bild: 

  • Das Management der Versicherer setzt sich im Schwerpunkt aus 40- bis 55-Jährigen zusammen, denen eines gemeinsam ist: die Digitalisierung der Versicherungsbranche (und damit die Einführung der Systeme/Prozesse, die nun ersetzt werden müssen) hatte bereits stattgefunden, als sie Führungsaufgaben übernommen haben. Das Management, das die Einführungen der 80er, 90er und 00er Jahr verantwortet hat, ist meist schon pensioniert. Es fehlt allgemeine praktische Erfahrung, um die spezifische Komplexität der einzelnen Sparten und Produkte einordnen zu können. Dem kommt besondere Bedeutung zu, wenn man die Reihenfolge der Produkte im Projekt plant. Für Nicht-Leben ist MF fast nicht an Komplexität zu übertreffen und auch Unfallversicherungen sind auf der Schaden-/Leistungs-Seite häufig Lebensversicherungen nicht unähnlich. Die Projekt-Planung sollte nach Möglichkeit zunächst die Integration in die Umsysteme mit einfachen Produkten stabilisieren und dann erst zu komplexen Sparten kommen.
  • Die Migration der Vertrags-Bestände gelingt dann am besten, wenn sie bereits von Anfang an dediziert betrachtet wird. Dabei kommt es auf die richtige Mischung von alt und neu an. «Brauchen wir auch in Zukunft» darf nicht missverstanden werden als «es muss so sein wie früher». Klappt das nicht, hat es spätestens bei der Datenmigration zum neuen System deutliche Auswirkungen, wenn man feststellt, dass die alten Produkte nicht zum neuen System passen. Das passiert leider häufiger, als man denkt.
  • Digitale (Preis-)Transparenz, Niedrig-Zins und die seit den 90er Jahren gelockerte Regulierung haben den Wettbewerb verschärft. End-to-end-Prozess-Know-how wird im stabilen operativen Geschäft nur selten benötigt und ist daher ein teurer Luxus. Startet ein Projekt, ist das End-to-end-Know-how nur noch in wenigen Fällen im Unternehmen vorhanden, extern schwierig zu beschaffen und muss daher im Projekt erarbeitet werden. Es empfiehlt sich, das im Projektvorgehen als besonderen Schwerpunkt zu setzen und mit übergreifenden Workshops zu unterstützen. 
  • Agilität ist das, was Startups allen vormachen. Damit ist Agilität als Projekt-Methode gesetzt. Das kann dazu führen, dass auch hoch komplexe integrierte Prozesse mit agilen Methoden angegangen werden. Die Agile-Methode sieht vor, dass man ein MVP (Minimum Viable Product) erstellt. Wichtig ist hier insbesondere das Wort «Viable». Es kann im Deutschen viele unterschiedliche Bedeutungen haben, im agilen Kontext wird es am besten mit «brauchbar» übersetzt. Der etablierte Versicherer denkt an das Tagesgeschäft mit hunderten von neuen Verträgen: Kaum ein Kunde ist bereit, ohne sofortige digitale Meldung an das Strassenverkehrsamt oder Berücksichtigung des Rabatts einen Vertrag abzuschliessen. Startups (z. B. Nexible/ERGO) planen mit viel kleineren Volumen und können es sich leisten, erst im Laufe der Zeit Lösungen dafür zu schaffen. Für «Brauchbarkeit» im Sinne eines etablierten Versicherers sind (unabhängig von der eingesetzten Software) oft tausende von Projekttagen für komplexe Integrationen notwendig, die sich wegen der projektexternen Abhängigkeiten nicht mit einer agilen Methode umsetzen lassen.
  • API, Microservices, devops und andere IT-Schlagwörter können suggerieren, dass schon mit der Wahl der richtigen Tools/Methoden/Software/Berater Probleme gelöst werden. Helfen kann das alles bestimmt. Wer sich mal aufmerksam die Details der Webseiten z. B von. Ebay oder Amazon ansieht, wird aber feststellen, dass der Teil mit der Business-Funktion doch noch sehr verdächtig nach 90er-Jahre-HTML aussieht. Die topmodernen IT-Tools/-Methoden/-Technologien beherrschen diese Unternehmen mit Sicherheit. Trotzdem ist es schwierig, eine komplexe Business-Applikation mal so eben umzustellen. Es sind die oft ungeliebten Monolithen, die für Business-Applikationen pragmatische Lösungen sind. Wer will schon für jedes Prüfen eines neuen Datenelements einen neuen Webservice schreiben? Im Markt sind auch hier die Fälle zahlreich, in denen z. B. die dogmatische Auftrennung in Microservices zu einer kaum beherrschbaren Komplexität geführt hat.
  • Der gewählte Software-Lösungsanbieter und/oder Integrationspartner ist oft derjenige, der im Verkaufsprozess selten oder nie «geht nicht», «schwierig», «teuer», «können wir nicht», «würden wir nicht vorschlagen» oder «komplex» mit seiner Lösung in Verbindung gebracht hat. Wer was verkaufen will, sagt schliesslich nicht «Nein». Häufig werden dann auch komplett unrealistische Erwartungen vertraglich scheinbar zementiert, indem man z. B. Projektaufwände und Ergebnisse festschreibt. In den seltensten Fällen sind diese Regelungen tatsächlich belastbar. Die Schicksalsgemeinschaft mit den Lieferanten zwingt die Versicherung, immer mehr Ressourcen nachzuschiessen, was regelmässig dazu führt, dass selbst «erfolgreiche» Projekte ein Mehrfaches des ursprünglichen Budgets verschlingen. Der Kunde darf davon ausgehen, dass das dem Lieferanten bei Unterschrift bekannt ist.