Die vorliegende Fallstudie von Swiss Re zeigt die komplexen Anforderungen, die Systeme zur Unterstützung von wissens‐ und dokumentenzentrierten Prozessen in einem kollaborativen Umfeld zu erfüllen haben. Dabei geht es in erster Linie darum, das optimale Mass an Standardisierung und Flexibilisierung zu finden, um Wissensarbeiter von Routinearbeiten zu entlasten und in ihren Entscheidungen zu unterstützen. Auf der herausfordernden Reise zur Lösung näherte sich Swiss Re schrittweise und mit einem klaren Richtungswechsel den Bedürfnissen ihrer Wissensarbeitenden.

1 Kontext und Ausgangssituation

Die Swiss Re Group ist ein weltweit führender Anbieter von Rückversicherungen und massgeschneiderten Versicherungslösungen. Im Jahr 2015 betrug der Umsatz USD 35,7 Mrd. und der Gewinn USD 4,6 Mrd. bei einem Prämienvolumen von insgesamt USD 30,2 Mrd. Der grösste Teil des Prämienvolumens wird mit dem Sachversicherungsgeschäft (50 %) und dem Lebensversicherungsgeschäft (36 %) erzielt. Die Swiss Re Group beschäftigt weltweit über 12.700 Mitarbeitende und bietet neben dem klassischen Rückversicherungsgeschäft auch Versicherungslösungen für Grossfirmen und Grossanlässe an und unterstützt Kunden bei der Produkteentwicklung. Die Produkte von Swiss Re werden global nachgefragt. So stammen 44 % des Prämienvolumens aus Nord‐ und Südamerika, 22 % aus der Region Asien und Pazifik und 34 % aus Europa, Afrika und dem Mittleren Osten.

Die vorliegende Fallstudie ist angesiedelt im Business Process Management des Bereichs Property & Casualty IT. Dieses dient dem Nichtleben‐Rückversicherungsgeschäft als Kompetenzzentrum rund um BPM‐Lösungen und ist unter anderem verantwortlich für die Softwarelösungen, die den in Abb. 6.1 gezeigten Offertstellungsprozess begleiten. Das Team umfasst zurzeit 29 Mitarbeitende (4 intern, 25 extern) verteilt auf Standorte in Zürich, Chiasso, Bari (Italien), Bukarest (Rumänien), Chicago (USA) und Singapur.

Abb. 6.1
figure 1

Übersicht des Offertstellungsprozesses im Bereich Property & Casualty Reinsurance

Der Offertstellungsprozess umfasst mehrere Phasen und beginnt mit der sogenannten Origination, in der primär die Kundenbeziehung gepflegt oder aufgebaut wird und an deren Ende die Anfrage für eine Rückversicherungsquotierung (Submission) steht. Diese erste Phase des Prozesses ist überwiegend unstrukturiert und findet primär zwischen dem Kunden und dem Client Manager oder je nach Markt und Team gegebenenfalls mit dem Underwriter statt. In der darauf folgenden Offertphase kümmert sich ein interdisziplinäres Team um die Ausarbeitung der Rückversicherungsprodukte, die Risikozeichnung, Kosten‐ und Preiskalkulation sowie die Ausarbeitung des Rückversicherungsvertrages. Je nach Produkt werden dabei die jeweiligen Experten miteinbezogen und es findet eine intensive Kollaboration von Wissensmitarbeitern statt. Dieser Prozess ist schwach strukturiert und wird je nach Marktsegment, Produkt und Region den jeweiligen Bedürfnissen angepasst. Die Phase endet bei positivem Geschäftsausgang mit der Unterzeichnung der Verträge (Bound). In der darauffolgenden Post‐Bound‐Phase können nachgelagerte Vertragsanpassungen erfolgen, beispielsweise aufgrund neuer Informationen, notwendiger Korrekturen oder weil der Kunde noch Änderungen am Produkt wünscht. Je nach Umfang der Änderungen müssen dabei Teile des Offertprozesses nochmals durchlaufen werden. Mit dem Inkrafttreten der Versicherungsdeckung (Inception Date) beginnen die Claims und Accounting‐Phase, in der es primär um die Schadensabwicklung und das Einfordern der Prämien geht. Allerdings können auch in dieser Phase Prozesse aus der vorangegangenen Post‐Bound‐Phase gestartet werden, falls Vertragsanpassungen nötig werden.

Die Offert‐ und Vertragsanpassungsphase sind geprägt durch den intensiven Austausch mit dem Kunden und der Kommunikation zwischen den beteiligten Fachpersonen innerhalb der Swiss Re. Zudem wird eine Vielzahl neuer und bestehender Dokumente benötigt und ausgetauscht. In dieser Fallstudie wird die Softwarelösung vorgestellt, welche diese beiden schwach strukturierten Phasen unterstützt und es wird aufgezeigt, wie sich der Nutzen für die internen und externen Kunden ausgestaltet. Jährlich werden mit dem vorgestellten System über 50.000 Submissionen bearbeitet und mehr als 200.000 neue Dokumente archiviert. Die Lösung ist seit 2014 im Einsatz, wird seitdem kontinuierlich erweitert und wird im Verlauf des Herbsts 2016 für 1250 Benutzer auf der ganzen Welt ausgerollt.

2 Motivation und Zielsetzung

Die Arbeit an einem System zur Unterstützung der Offert‐ und Vertragsanpassungsphase wurde durch mehrere Elemente getrieben. Zunächst stand die strategische Stossrichtung der Swiss Re, den Kundenfokus («Customer‐Centricity») weiter voranzutreiben, im Vordergrund. In diesem Zusammenhang wurden sogenannte cross‐funktionale Teams (XFT) aufgebaut, die organisationsübergreifend die Wissensmitarbeiter verbinden, um die bestmöglichen Lösungen für die Kunden und den jeweiligen Markt zu erarbeiten. Dabei wird zu einem Kundenbedürfnis jeweils ein Kompetenzteam zusammengestellt, in dem alle benötigten Experten vertreten sind, welche dann gemeinsam mit dem Kunden ein Produkt erarbeiten oder im Rahmen einer Geschäftstransaktion die Kundenanforderungen und entsprechende Leistungen formulieren. Um diese organisationsübergreifende Zusammenarbeit zu ermöglichen, war die Orchestrierung der Prozesse ein zentrales Anliegen.

Hinzu trat etwas später ein weiteres wichtiges strategisches Element. Mit der Vision 2020 strebt der Nichtleben‐Rückversicherungsbereich an, den Anteil der Wachstumsmärkte (HGM, High Growth Markets) am Prämienvolumen von aktuell 15 % bis ins Jahr 2020 auf 30 % zu erhöhen (Swiss Re 2016). Der Head P&C IT erhielt das Mandat, im Rahmen dieser Vision die zum Erreichen des Ziels notwendige IT‐Strategie zu entwickeln. Die Swiss Re, wie wohl auch die meisten anderen Firmen, die in Wachstumsmärkten Personal beschäftigen, ist konfrontiert mit einer relativ hohen Fluktuationsrate und vermehrt jungen Mitarbeitenden mit entsprechenden Ansprüchen an eine moderne IT‐Infrastruktur. Um dieser Situation gerecht zu werden, wird ein IT‐System benötigt, bei dem für neu eingestellte Mitarbeitende ein möglichst geringer Schulungsaufwand nötig ist, so dass diese nach kurzer Zeit einen produktiven Beitrag leisten können. Zudem muss das neue System bezüglich Handhabung und Schnelligkeit den heutigen Anforderungen gerecht werden und ein positives Nutzererlebnis bieten. Neben diesen Anforderungen der Mitarbeitenden müssen zum Erreichen der Prämienziele in den Wachstumsmärkten aber auch neue Kundensegmente erschlossen werden. Abb. 6.2 zeigt, dass es sich bei den meisten Kunden in Wachstumsmärkten (HGM) um regionale und nationale Anbieter handelt (R&N). Um in diesen Markt vorzustossen, ist die Swiss Re auf die Zusammenarbeit mit globalen Partnern, Regierungen und multilateralen Institutionen angewiesen (Swiss Re 2016). Dies hat zur Folge, dass die Swiss Re nur für einen Teil des Prozesses verantwortlich sein wird und das IT‐System in der Lage sein muss, flexibel mit den daraus resultierenden Integrationsanforderungen umzugehen. Es muss gelingen, die internen Organisationsstrukturen und Abläufe stets den Markt‐ und Kundenanforderungen, aber auch den regulatorischen Anforderungen anzupassen.

Abb. 6.2
figure 2

Marktsegmente und Wachstumspotenzial

2 Die Ausgangslage

Vor dem Einführen der BPM‐Plattform 2014 waren in der Offert‐ und Vertragsanpassungsphase primär das E‐Mail System Lotus Notes und Shared Drives (Fileservers) die zentralen Tools für die Zusammenarbeit im Team und die Kundenkommunikation. Zwar stiess die Kommunikation per Mail mit bisweilen über 800 Nachrichten und unzähligen Dokumenten zu einer einzelnen Anfrage an Grenzen und machte es schwierig, den Überblick zu behalten, aber die Mitarbeitenden hatten über die Zeit gelernt, das System für ihre Zwecke zu optimieren. Aus Sicht der Führung gab es hingegen mehrere Gründe, über eine Anpassung der Systemlandschaft nachzudenken:

  • Das Verbesserungspotenzial bei den Antwortzeiten für Kunden.

  • Die veränderten Anforderungen durch die Einführung cross‐funktionaler Teams.

  • Die zu lange Einarbeitungszeit für neue Mitarbeitende, insbesondere auch lokationsübergreifend.

  • Die Ansprüche der Mitarbeitenden an ein schnelles, intuitives, einfaches IT‐System.

  • Die Arbeitszeit, die Wissensmitarbeiter für Routineaufgaben aufwendeten.

  • Die Schwierigkeit, einen Know‐how Transfer zu neuen Mitarbeitenden durchzuführen.

  • Die mangelnde Skalierbarkeit des Vorgehens auf kleinere Deals und grössere Volumina.

  • Die beschränkten Möglichkeiten, Daten zum Vorgehen zu sammeln und auszuwerten, um mögliche Verbesserungen daraus abzuleiten.

  • Die Zeit, die in die korrekte Archivierung von Dokumenten investiert werden musste.

Bis dato waren E‐Mail, Mobiltelefon und CRM die typischen IT‐Tools eines Client Managers. Der Bedarf für ein Prozessorchestrationstool war nicht sofort ersichtlich. Nun wird aber die Transparenz darüber, wo die Deals und dazugehörigen Aktivitäten stehen und woran die Kollegen arbeiten, geschätzt (Marco Peyer, Head BPM & Service Operations, P&C Reinsurance Swiss Re).

In Zentrum der Anpassungswünsche stand das Erreichen von Operational Excellence. Die Swiss Re hatte sich zum Ziel gesetzt, zum «Best Managed Reinsurer» zu werden. Um dies zu erreichen, sollte die Landschaft von IT‐Systemen dabei helfen, das vorhandene Know‐how möglichst effizient einzusetzen und die vorhandenen Daten und vor allem auch Dokumente optimal zu nutzen.

2 Ziel 1: Zusammenführen des Know‐hows zur richtigen Zeit

Die Swiss Re gilt als «das Unternehmen der tausend Berufe». In der Tat decken Swiss Re Mitarbeitende ein breites Spektrum an Professionen und Ausbildungen ab, die notwendig sind, um die vielfältigen Risiken fachmännisch einzuschätzen, aber auch, um in den Zielmärkten regionale Besonderheiten berücksichtigen zu können. Allgemein gilt das Rückversicherungsgeschäft als wissens‐ und dokumentenintensiv, und es setzt eine sehr enge Kundenbindung und ein Vertrauensverhältnis zwischen Kunden und Swiss Re voraus. Während der Offert‐ und Vertragsanpassungsphase findet eine intensive Zusammenarbeit derjenigen Mitarbeitenden statt, die für den jeweiligen Fall über die nötige Expertise und Erfahrung verfügen. Weil die angebotenen Versicherungsprodukte möglichst genau auf die Bedürfnisse des Kunden abgestimmt werden, wird auch die Zusammensetzung des Teams dem Markt‐ und Kundensegment angepasst. Darin liegt ein wesentlicher Unterschied zu cross‐funktionalen Teams, wie man sie aus anderen Bereichen wie beispielsweise der agilen Softwareentwicklung kennt. Sie vereinen ebenfalls Mitarbeitende mit verschiedenen Fähigkeiten, z. B. aus den Bereichen Requirements‐Engineering, Design, Entwicklung und Testing. Allerdings arbeiten diese Teams in der Regel über längere Zeit in derselben Zusammensetzung zusammen. Auch in den Teams der Swiss Re gibt es eine typische Rollenverteilung: Der Client‐Manager ist während des ganzen Prozesses prinzipiell die Ansprechperson für den Kunden. Der Underwriter kennt die fachlichen Grundlagen für die Einschätzung und Zeichnung von Risiken. Diese Einschätzungen dienen den Aktuaren, sprich den Mathematikern, als Grundlage für die Erstellung der Risikomodelle, welche die Mitarbeitenden aus dem Underwriting als Entscheidungsgrundlage verwenden. Diese müssen letztendlich das Risiko zeichnen, um ein Versicherungsprodukt dem Kunden anbieten zu können. Zudem sind am Verkaufsprozess auch noch Mitarbeitende aus dem Bereich Business Services beteiligt, die primär die Koordinations‐ und Administrationsaufgaben aus dem Underwriting übernehmen. Durch die Variabilität der Produkte ist es jedoch nötig, dass diese Rollen je nach Markt‐ und Kundenbedürfnis von unterschiedlichen Mitarbeitenden wahrgenommen werden. Diese Dynamik wirkt sich auf die Anforderungen an das IT‐System aus. Dieses muss es ermöglichen, dass ein geographisch, organisatorisch und funktional verteiltes sowie ad hoc zusammengestelltes Team effizient zusammenarbeiten kann.

2 Ziel 2: Verknüpfen der relevanten Daten und Dokumente am richtigen Ort

Neben den Mitarbeitenden kommt den Dokumenten eine zentrale Rolle zu. Die Swiss Re wurde 1863 gegründet und verfügt damit über einen riesigen Dokumentenbestand. Diese Wissensbasis gilt es zu nutzen und die relevanten Dokumente und Daten am richtigen Ort zur Verfügung zu stellen. Im Gegensatz zu anderen Branchen liegt der Fokus der Digitalisierung daher nicht in erster Linie auf dem Ersetzen von Papier durch elektronische Dokumente und Daten, sondern auf einer verbesserten Verknüpfung der Daten. Die zentrale Aufgabe des Systems in Bezug auf Dokumente ist es, den Teammitgliedern Zugriff auf alle relevanten Unterlagen zu ermöglichen. Hierfür müssen nicht nur die offiziellen Dokumente wie beispielsweise Verträge ins System einfliessen, sondern auch die Dokumentation des Entscheidungsprozess, der in E‐Mails, Chat und anderen Kanälen stattfindet. Im Zentrum stehen jedoch nicht Daten und Dokumente, sondern die Kollaboration innerhalb des Teams und die Kommunikation mit dem Kunden. Letztere muss so stattfinden, dass sie möglichst fortlaufend archiviert wird und nicht am Schluss transferiert werden muss.

Dass die Verknüpfung von Informationen in Zukunft für die Versicherungswirtschaft weiter an Relevanz gewinnen wird, legen auch jüngere Studien nahe. Gemäss der PWC‐Studie «Insurance 2020 & beyond» wären bereits heute 67 % der Kunden bereit, Sensoren am Auto oder am Haus anzubringen, wenn sie dafür von günstigeren Prämien profitieren könnten (PWC 2015). Die Studie zeigt ausserdem, dass die Auswertung von Daten in Zukunft eine zentrale Rolle spielen wird: 93 % der CEOs von Versicherungsunternehmen schätzen Data‐Mining und Datenanalyse mit Abstand als die zukünftig wichtigsten digitalen Technologien für die Versicherungsbranche ein. Obwohl sich diese Veränderungen rund um Themen wie «Internet of Things» (IoT) und die zunehmende Vernetzung zunächst auf das Erstversicherungsgeschäft auswirken wird, ändert es auch die Ausgangslage für die Rückversicherungen. Die zusätzlichen Daten werden es den Rückversicherern ermöglichen, die Risiken wesentlich präziser abzuschätzen und Änderungen der Risikolage frühzeitig zu antizipieren. Es ist daher wahrscheinlich, dass Erstversicherer die gesammelten Daten den Rückversicherern zur Verfügung stellen werden, um ihrerseits bessere Vertragsbedingungen aushandeln zu können. Damit kämen die Rückversicherer den Endkunden ein gutes Stück näher und würden sich ihrerseits die Möglichkeit schaffen, mit neuen Produkten neue Märkte zu erschliessen.

2 Gegenstand der Transformation

Die Antwortzeiten und die Komplexität der Zusammenarbeit stellen für Swiss Re, wie eingangs erwähnt, eine grosse Herausforderung bei der Interaktion mit Kunden dar. Die Antwort darauf wird jedoch nicht in der Digitalisierung der Kundenschnittstelle gesehen, denn die Komplexität der angebotenen Produkte und Dienstleistungen übersteigt nach heutigen Ansichten die Möglichkeiten von simplen Web‐Formularen und automatisch erzeugten Tracking‐ und Fortschrittsanzeigen. Auch die Kunden verlangten keinen konkreten Ausbau von Online‐Diensten, sondern schätzen den Brand, die Expertise, Kapitalkraft und die Interaktion mit Swiss Re. Der persönliche Kontakt und die über viele Jahre gleichbleibenden Ansprechpartner wurden sogar als wichtiges Argument für die Geschäftsbeziehung mit Swiss Re genannt. Der Hebel musste also intern angesetzt werden und es war bald klar, dass die Probleme nicht durch Anpassungen an einem einzelnen IT‐System behoben werden konnten, sondern dass eine verbesserte Verknüpfung der bestehenden Systeme erforderlich war. Es wurde daher beschlossen, ein neues System einzuführen, das die bestehenden Systeme verknüpft, deren Zusammenarbeit orchestriert und eine einheitliche Oberfläche zu den verwendeten Systemen bietet. Damit sollte maximale Transparenz für die Wissensmitarbeiter geschaffen werden und diese befähigen, ihr Fachwissen noch besser einzubringen, ohne durch Routineaufgaben unnötig belastet zu sein. Gleichzeitig bot sich mit diesem Lösungsansatz die Möglichkeit, den Aufwand zum Einarbeiten neuer Mitarbeiter zu reduzieren und den Wunsch nach einem zeitgemässen User‐Interface (UI) zu erfüllen. Das UI sollte zudem mit Chat und anderen Funktionen zur Unterstützung der Kollaboration erweitert werden. Durch das Verknüpfen der Systeme sollte ausserdem die Möglichkeit geschaffen werden, die Archivierung zu vereinfachen, den Fortschritt einzelner Cases zu überwachen sowie Daten über das Vorgehen zu sammeln.

3 Umsetzung und Wirkung

Die systemseitige Umsetzung der Anforderungen stellte Swiss Re vor grosse Herausforderungen. Schrittweise und mit einem klaren Richtungswechsel näherte man sich den Bedürfnissen der Mitarbeitenden an. Die Erfahrungen zeigen, wie anspruchsvoll es sein kann, trotz detaillierter Kenntnis der Sachlage ein System für äusserst vielschichtige Anforderungen zu realisieren und dabei die wahren Bedürfnisse und Gewohnheiten der Anwender im Fokus zu behalten.

Die Anforderungen wurden in sogenannten Process Discovery Workshops mit Experten aus den jeweiligen Geschäftsabteilungen, Business‐Analysten, Product‐Ownern sowie einzelnen Entwicklern und Anwendern des Systems erhoben. Diese wurden ergänzt durch Besuche vor Ort, bei denen den Systembenutzern über die Schulter geschaut wurde. Ferner hatte das IT‐Team bereits ein gutes Verständnis, wie die Benutzer die verschiedenen Systeme verwenden.

3 Der erste Anlauf

Der im April 2014 eingeführte erste Lösungsansatz sah wie folgt aus (Abb. 6.3): Den bisher hauptsächlich verwendeten Werkzeugen für Kommunikation und Dokumentenmanagement (Outlook, Documentum und Lotus Notes) wurde die BPM‐Plattform Appway zur Seite gestellt.

Abb. 6.3
figure 3

Architekturübersicht des ersten Lösungsansatzes

Die BPM‐Plattform umfasste folgende Komponenten:

  • Workbench: enthält die Übersicht aller laufenden Cases und die Tasks, gefiltert nach Mitarbeitenden oder Teams. Zudem zeigt die Workbench die neu eingegangenen Offertanfragen und bietet die Möglichkeit, zu diesen Anfragen den Offertprozess zu starten.

  • Client‐Offering: führt den Benutzer entlang von einzelnen Screens durch den Offerterstellungsprozess. Dieser besteht aus einem Hauptprozess sowie mehreren Subprozessen pro Untervertrag. Welche Subprozesse ausgeführt werden, ist produkte‐ und marktabhängig. Zudem enthält das Client‐Offering verschiedene Mittel für die Kollaboration: Eine Chat‐Funktion für den Austausch im Team, eine Kommentarfunktion für einzelne Tasks und Dokumente und die Möglichkeit, zu signalisieren, woran man gerade arbeitet.

  • E‐Mail‐Editor: erlaubt die E‐Mail Kommunikation mit dem Kunden direkt aus der BPM‐Plattform und sorgt für die automatische Archivierung der so abgewickelten Kommunikation.

  • Operational Dashboard: gibt einen Überblick aller laufenden Cases.

Der Arbeitsprozess gestaltete sich wie folgt: Während der Origination‐Phase wurde mit dem Kunden wie bis anhin via Outlook kommuniziert. In Abb. 6.3 entspricht dies der Verbindung mit der Bezeichnung (1). Mit dem Eingehen der Offertanfrage musste einmalig in der Workbench ein neuer Offertprozess gestartet (2) und anschliessend die bereits gesammelten Informationen und Dokumente manuell in den Prozess übertragen werden (3). Nun konnte das Team mit der Arbeit beginnen. Die Workbench respektive das Client‐Offering zeigte die offenen Tasks an und ordnete diese einzelnen Teammitgliedern zu (4). Das Team konnte sich bei der Ausführung über die Kollaborationsfunktionen austauschen und die Arbeit so koordinieren. Da mit dem E‐Mail‐Editor die Kommunikation mit dem Kunden direkt aus der Plattform geführt wurde (5), konnte die ganze Offertphase mit einem einzigen Tool bewältigt werden. Dieses Vorgehen hatte den Vorteil, dass alle Schritte ab dem Eingang der Offertanfrage korrekt und ohne zusätzlichen Aufwand archiviert wurden. Nur falls vom Kunden oder von anderer Stelle Unterlagen oder Informationen zum Fall unabhängig von der Workbench zugestellt wurden, mussten diese manuell dem Case hinzugefügt werden (6). Für die Archivierung wurden die bestehenden Dokumentenablagen Lotus Notes und Documentum über einen Service‐Layer an die BPM‐Plattform angebunden. Damit konnte die Plattform alle neu erfassten Dokumente sowie die Korrespondenzen automatisch an der richtigen Stelle in den Dokumentenablagen archivieren. Zudem wurde eine Suchfunktion für bestehende Dokumente integriert und mit dem sogenannten Digital‐Binder kombiniert. Dieser erlaubte es, bestehende Dokumente mit einem Case, einzelnen Subprozessen oder einem anderen Dokument zu verknüpfen. Diese Verknüpfungsinformationen blieben über die eigentliche Ausführung des Prozesses hinaus erhalten. Der Digital‐Binder half also dabei, den in den Dokumenten verborgenen «Wissensschatz» Stück für Stück zu heben.

Obwohl die Lösung viele Vorteile bot, fühlten sich die Mitarbeitenden noch nicht optimal unterstützt:

  • Der in die Plattform integrierte E‐Mail‐Editor erfüllte die Anforderungen der Benutzer nur bedingt. Im Vergleich zu Outlook fehlten wichtige Funktionen, wie zum Beispiel Formatierungsmöglichkeiten und die Anbindung des Adressbuchs. Zudem bot der E‐Mail‐Editor nur eine eingeschränkte Sicht auf die Kommunikation mit dem Kunden, denn er zeigte nur E‐Mails an, die entweder aus der Plattform geschrieben wurden oder als Antwort auf eine solche E‐Mail eingegangen waren.

  • Der Wechsel vom Outlook in die Plattform beim Übergang von der Origination‐ in die Offering‐Phase wurde als mühsam empfunden. Alle bereits gesammelten Informationen und Unterlagen mussten von Hand zusammengetragen und manuell in die BPM‐Plattform überführt werden.

  • Die Kollaborationsfunktionen entsprachen nicht den Bedürfnissen der Mitarbeitenden und wurden daher kaum genutzt. Diese bevorzugten es, wie bis dahin per Telefon und E‐Mail zusammenzuarbeiten.

  • Der Client‐Offering‐Prozess war trotz seines modularen Aufbaus mit parallel ausführbaren Subprozessen nicht flexibel genug und wurde als Einschränkung in verschiedenen Teams und Märkten empfunden.

  • Das Tool bot noch keinen Mehrwert bei der Entscheidungsfindung. Zwar verbesserte die BPM‐Plattform die Datenlage, es war jedoch nicht möglich, alle Daten eines Kunden zu aggregieren respektive Daten verwandter Fälle auszuwerten und zu vergleichen.

Aus der Sicht der Benutzer bot das neue System zweifelsfrei zufriedenstellende neue Funktionen wie den Digital‐Binder, aber die Unzulänglichkeiten überlagerten den Nutzen in dieser ersten Phase. Die User‐Interfaces waren den bewährten Systemen funktionell unterlegen und das neue System verlangte zusätzliche Aufgaben, wie den Datentransfer zu Beginn der Offertphase. Der Medienbruch am Anfang des Offertprozesses begleitete die Mitarbeitenden auch während der folgenden Arbeiten. Immer wieder mussten Informationen, die von ausserhalb der Plattform an die Mitarbeitenden herangetragen wurden, manuell in die Plattform überführt werden.

Das Prozessmanagement‐Team erkannte, dass die Lösung die Bedürfnisse ihrer internen Kunden noch nicht optimal erfüllte. Zudem wurde deutlich, dass der neue standardisierte Offertprozess nicht flexibel genug war für den beabsichtigten Ausbau des Geschäfts in Wachstumsmärkten sowie für die Zusammenarbeit mit regionalen und nationalen Anbietern. Der optimale Grad an Standardisierung und Flexibilisierung des Prozesses war mit der Lösung noch nicht erreicht. Oder in den Charles Darwin zugeschriebenen Worten: «It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.»

Eine global konsistente Definition von Aktivitäten ist wichtiger, als dass der exakt selbe Ablauf von Aktivitäten weltweit angeordnet wird. Eine Standardisierung des Prozesses kann durchaus wertvernichtend sein, wenn diese nicht genügend Flexibilität zulässt und den entsprechenden Markt‑, Kunden‐ und lokalen Arbeitsbedürfnissen entspricht (Marco Peyer, Head BPM & Service Operations, P&C Reinsurance Swiss Re).

3 Die zweite Version

Statt die Funktionalität des E‐Mail‐Editors weiter auszubauen und die Integration der Kommunikation mit dem Kunden in die Plattform weiter voranzutreiben, wurde ein klarer Richtungswechsel beschlossen. Im optimierten System, das sich heute im Einsatz befindet, ist Outlook das führende Tool in Bezug auf Kundenkommunikation und Korrespondenz, während BPM Plattform Appway und der Information Hub die intelligente Steuerung und Informationsversorgung des Offerterstellungsprozesses sicherstellen. Abb. 6.4 zeigt die Architekturübersicht, mit den neu hinzugekommenen Komponenten.

Abb. 6.4
figure 4

Architekturübersicht des zweiten Lösungsansatzes

Das System enthält die folgenden Erweiterungen:

  • Mail‐App: Ermöglicht es, zu einer vorhandenen E‐Mail‐Kommunikation einen neuen Offertprozess zu starten oder die Kommunikation einem bestehenden Offertprozess zuzuordnen. In beiden Fällen werden die Nachrichten sowie alle Anhänge automatisch in die BPM‐Plattform übertragen und von dieser in die Datenablage transferiert. Wird die Kommunikation fortgesetzt, wird diese automatisch in den entsprechenden Fall übertragen. Zudem werden Tasks aus der Workbench direkt in der Mail‐App angezeigt und können teilweise direkt in der App erledigt werden, ohne in die Plattform zu wechseln.

  • Case und Process Hub: Sind die neu geschaffenen Schnittstellen im Information Hub, welche die von der Mail‐App benötigten Funktionen zur Verfügung stellen.

  • Anbindung des Exchange‐Servers: Neben Documentum und Lotus Notes ist neu auch der Exchange‐Server via Information Hub an die BPM‐Plattform angebunden. Dies ermöglicht einen effizienten Transfer der Nachrichten und Anhänge von der Mail in die Dokumentenablagen.

  • Data Warehouse und Reporting Cockpit: Das DWH dient dem Speichern aller Aktivitäten aus der Mail‐App und der Workbench und kombiniert damit die Daten aus den beiden Front‐Ends. Diese Daten sind die Grundlage für das neu geschaffene Reporting Cockpit, in dem laufende und abgeschlossene Cases nach verschiedenen Kriterien ausgewertet werden können.

Mit der Überarbeitung ändert sich der Arbeitsprozess deutlich, indem gewisse Schritte nun ganz oder teilweise direkt in Outlook erledigt werden können (Abb. 6.4). Die Arbeit beginnt wie gehabt mit der Kommunikation via Outlook während der Origination‐Phase (1). Kommt es zu einer Offertanfrage, wird in der Mail‐App ein neuer Case eröffnet (2). Dabei müssen zusätzliche Angaben für die Einordnung der Anfrage gemacht werden und die Anhänge müssen einzelnen Kategorien oder Unterverträgen zugeordnet werden. Mit diesen Angaben startet das System in der BPM‐Plattform Appway den entsprechenden Case, transferiert alle Nachrichten und Anhänge vom E‐Mail in die Dokumentenablagen und verknüpft diese mit dem jeweiligen Case. Anschliessend werden jene Teile des Offertprozesses, die keine weiteren Angaben erfordern, automatisch durchlaufen. Abschliessend werden für die verantwortlichen Teams oder Mitarbeitenden Tasks erzeugt. Diese werden per E‐Mail über die anstehenden Aufgaben informiert. Gewisse, einfachere Aufgaben können direkt über die Mail‐App ausgeführt werden (3). Bei komplexeren Aufgaben muss über den entsprechenden Link im E‐Mail in die Workbench gewechselt und die Aufgabe dort ausgeführt werden (4). Neben dem E‐Mail, das für die initiale Eröffnung des Cases verwendet wurde, können weitere E‐Mails dem Case zugeordnet und dadurch zusammenhängend archiviert werden. In jedem Fall sorgt die Mail‐App dafür, dass wenn eine bereits übertragene Kommunikation fortgesetzt wird, diese Fortsetzung automatisch dem Case hinzugefügt und archiviert wird (5). Wie bis anhin kann in der Workbench nach relevanten Dokumenten gesucht werden und mit Hilfe des Digital‐Binder mit dem Case oder Teilen davon verknüpft werden (6). Im neu geschaffenen Reporting‐Cockpit (7) können die Mitarbeitenden historische und aktuelle Daten beispielsweise zu einem Kunden oder einer Branche auswerten und als Basis für ihre Entscheidungen nutzen. Um die kritisierte mangelnde Flexibilität des Offertprozesses zu beheben, wurde dieser in kleinere unabhängige «Mini‐Prozesse» zerlegt. Ähnlich einer Check‐Liste können die Mitarbeitenden nun die Reihenfolge einzelner Tasks flexibler wählen und bei Bedarf gewisse Schritte auslassen. Das System lässt die Mitarbeitenden nun so arbeiten, wie es der Markt, der Kunde oder der Regulator erfordert. Die Mitarbeitenden werden durch die Front‐End‐Integration der Funktionalität in Outlook nun in der digitalen Arbeitsumgebung unterstützt, in der sie am effizientesten arbeiten. Die Mitarbeitenden sind also nicht mehr gezwungen, verschiedenen Systemen zu folgen, um eine Funktionalität zu nutzen, sondern die Funktionalität folgt dem Nutzer. Vorhandene Medienbrüche wurden beseitigt und es steht nun ein vollständig integrierter durchgängiger Arbeitsprozess zur Verfügung. Ermöglicht wird diese Integration durch die BPM‐Plattform Appway, die die Bearbeitung der Cases und der dazugehörigen Informationen steuert.

Outlook ist das zentrale Element in der heutigen Kundenkorrespondenz. Mit der Integration von Outlook und der BPM‐Plattform Appway über eine Mail App konnten einzelne Schritte vom Prozess dorthin verlagert werden, wo der Benutzer tatsächlich seine Aufgaben wahrnimmt und somit eine wesentliche Verbesserung der User Experience erreicht werden (Marco Peyer, Head BPM & Service Operations, P&C Reinsurance Swiss Re).

(Adaptive) Case Management

Ein typisches Einsatzgebiet von Case‐Management‐Systemen ist die Koordination von Arbeiten in schwach strukturierten Prozessen. Insbesondere bei Prozessen, deren Verlauf nicht vollständig vorhersagbar ist und bei deren Ausführung die Mitarbeitenden selbst über die Notwendigkeit einzelner Arbeitsschritte sowie deren Reihenfolge entscheiden müssen, können Case‐Management‐Systeme einen wichtigen Beitrag leisten (Motahari‐Nezhad und Swenson 2013). Natürlich erlauben auch traditionelle Automatisierungen mittels BPM‐Systemen verschiedene Ausführungspfade, diese müssen aber entweder explizit modelliert oder durch das Erlauben von Ausnahme realisiert werden. Herkömmliche Case‐Management‐Systeme wurden jeweils für eine bestimmte Anwendungsdomäne wie beispielsweise das Spital‑, Justiz‐ oder Polizeiwesen entwickelt. In diesem Zusammenhang wird auch oft von sogenannten Production‐Case‐Management‐Systemen (PCM) gesprochen. Von einem Adaptive‐Case‐Management‐System kann gesprochen werden, falls das System Funktionen zur Verfügung stellt, um den Arbeitsprozess an die Bedürfnisse des Cases anzupassen (Swenson 2011). Mittlerweile wurde der Trend auch von der Object Management Group aufgegriffen, welche seit 2014 mit CMMN einen Standard für die Notation von Case‐Management‐Modellen unterhält (OMG 2014).

Das verbesserte System ist seit Herbst 2015 mit zunehmender Akzeptanz im Einsatz. Outlook ist nun wieder das einheitliche Front‐End für die elektronische Kommunikation mit dem Kunden und bietet mit der Mail App eine einfache, intuitive und ansprechende Integration des BPM‐Systems Appway. Die BPM‐Plattform erfüllt ihre Aufgabe als Rückgrat des Systems. Sie ermöglicht die flexible Bearbeitung der Cases, verteilt die Aufgaben an die richtigen Mitarbeitenden, bindet die Dokumentenverwaltung ein und entlastet den Benutzer zunehmend von Routineaufgaben wie beispielsweise der Archivierung.

Wie sich das neue Tool auf die Zufriedenheit der Kunden auswirkt, kann zum aktuellen Zeitpunkt noch nicht abschliessend beurteilt werden. Auch für die systematische Auswertung der Antwortzeit bei Kundenanfragen und anderer KPIs ist das System noch nicht lange genug im Einsatz. Zudem steht für das laufende Jahr noch das Rollout weiterer vielversprechender Neuerungen an, wie beispielsweise die halbautomatische Klassifizierung von Dokumenten, die den Nutzen des Systems weiter erhöhen werden.

3 Ausblick

Die Weiterentwicklungsmöglichkeiten des Systems sind äusserst vielseitig. Ein zentrales Anliegen wird es sein, die gesammelten Daten besser zu nutzen. Um Offertanfragen automatisch zu kategorisieren und zu priorisieren, könnten Grössen wie die Abschlusswahrscheinlichkeit oder die zu erwartende Rendite als Entscheidungsgrundlage herangezogen werden. Auch das Zusammenstellen des cross‐funktionalen Teams könnte, unter Berücksichtigung der erforderlichen Fachkenntnisse und der Verfügbarkeit der Mitarbeitenden, unterstützt werden. Angestrebt wird letztlich ein wissensbasiertes System, das proaktiv Informationen sammelt, aufbereitet und situationsabhängig bereitstellt, die für den jeweiligen Fall relevant sein könnten. Damit würde der Prozess der Wissensbereitstellung vom heutigen Pull‐Modus in einen Push‐Modus überführt (Abb. 6.5) und so die Vision von P&C IT realisiert.

Abb. 6.5
figure 5

Zukünftige Einsatzmöglichkeiten des Systems

Our Digital Operating platform enables handling more information to take decisions in less time while using our intelligence to build new value propositions for clients (e. g. loss prevention) leveraging new skills (Vision P&C IT, Swiss Re 2016).

4 Fazit

Die vorliegende Fallstudie von Swiss Re zeigt die Komplexität, die Systeme zur Unterstützung von wissens‐ und dokumentenzentrierten Prozessen in einem kollaborativen Umfeld zu bewältigen haben. Dabei geht es in erster Linie darum, das optimale Mass an Standardisierung und Flexibilisierung zu finden, um Wissensarbeiter von Routinearbeiten zu entlasten und in ihren Entscheidungen zu unterstützen.

Die beschriebene Digitalisierung des Offerterstellungsprozesses im Bereich P&C Reinsurance der Swiss Re, deckt ein breites Spektrum der im Rahmenwerk der Studie untersuchten strategischen und operativen Wirkungsfelder ab. Die wesentlichen Erkenntnisse sind in Abb. 6.6 gekennzeichnet und nachfolgend dargestellt.

Abb. 6.6
figure 6

Swiss Re Fallstudie – Kernaspekte im Kontext des Studienframeworks