Digitalisierung der Versicherungsbranche: Quo vadis?

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

Viele denkbare Ursachen

• 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.