Klassische Versicherer sind im Vergleich zu technologieaffinen Newcomern zu wenig agil. Angesichts des immer schnelleren technologischen und gesellschaftlichen Wandels stellt dies für sie mittelfristig eine beträchtliche Gefahr dar. Wir stellen die organisatorischen Aspekte eines Betriebsmodells für intrinsisch reaktionsfähige Versicherer vor.

1. synpulse26 | Digital Transformation
Ein Betriebsmodell für
Versicherer im digitalen
Zeitalter (Teil 1)
Klassische Versicherer sind im Vergleich zu technologieaffinen Newcomern zu wenig agil.
Angesichts des immer schnelleren technologischen und gesellschaftlichen Wandels stellt
dies für sie mittelfristig eine beträchtliche Gefahr dar. Wir stellen die organisatorischen
Aspekte eines Betriebsmodells für intrinsisch reaktionsfähige Versicherer vor.
Autoren: Dr. Dominik Langer | Dr. Andreas Wicht
Das Rad des technologischen, gesellschaftlichen und ökono-
mischen Wandels dreht sich immer schneller. Für Versicherer
wird es schwerer, zukünftige Entwicklungen abzuschätzen,
denn die Vorwarnzeit für nötige Anpassungen schrumpft
stetig. Um sich diesen Bedingungen anpassen zu können, be-
nötigen Versicherer ein Betriebsmodell, das sie möglichst
reaktionsfähig macht.
Immer mehr Industrien werden von Firmen mit einem rein
digitalen Geschäftsmodell dominiert. Meist handelt es sich
dabei um eher junge Unternehmen, welche traditionelle Un-
ternehmen erfolgreich unter Druck gesetzt oder aus dem
Markt gedrängt haben. Dass solche Veränderungen sehr
rasch geschehen können, zeigen Beispiele wie Amazon, Uber,
Netflix oder Spotify. Diese haben zwar ihre jeweilige Branche
neu definiert, sind aber eigentlich Softwarefirmen und ge-
stalten die Entwicklung neuer Technologien aktiv mit. Denn
mit bloßem Einsatz von Standardsoftware oder komplettem
Outsourcing der Softwareentwicklung kann die Marktführer-
schaft mit einem digitalen Geschäftsmodell weder erworben
noch erhalten werden.
Wenn wir die zunehmende Anzahl an InsurTech-Start-ups als
Indikator nehmen, zeigt sich, dass Versicherer ebenfalls von
den o.g. Entwicklungen betroffen sind. Zusätzlich haben ge-
wisse Internetgiganten aufgrund ihrer Datenschätze das Po-
tenzial, zu Konkurrenten klassischer Versicherer zu werden.
Organisatorische Hindernisse der
Reaktionsfähigkeit
Klassische Versicherer verfügen über eine Reihe von Eigen-
schaften, welche ihre Reaktionsfähigkeit behindern. Als Maß
für die Reaktionsfähigkeit sehen wir dabei die Durchlaufzeit,
d.h. die Zeit zwischen der Erkenntnis, dass eine bestimmte
Änderung notwendig ist, bis zum Testen ihrer Umsetzung am
Markt.
Klassische Versicherer sind i.d.R. Matrixorganisationen, d.h.,
einer starren Hierarchie von Organisationseinheiten sind
temporäre Projektteams überlagert. Sowohl die Organisati-
onseinheiten der Linie als auch die Teams größerer Projekte
sind dabei meist auf eine bestimmte Aktivität spezialisiert.
Im Falle der IT wären dies beispielsweise Businessanalyse,

2. synpulse Digital Transformation | 27
Entwicklung, Testing, Releasemanagement und Betrieb. Aus
dieser organisatorischen Trennung ergeben sich Brüche ent-
lang der Projekt-Value-Chain und damit ein relativ hoher Auf-
wand für die Übergabe eines Arbeitsgegenstandes von einem
Team ans nächste. Als Konsequenz davon sammeln Teams
ihre Arbeitsgegenstände bis zu einem gewissen Ausmaß an,
bevor sie diese weitergeben. Übergaben oder Rückfragen
finden also nicht so kontinuierlich statt, wie dies innerhalb
eines Teams der Fall wäre, sondern werden stark gebündelt.
Mit zunehmender Bündelgröße steigt die Durchlaufzeit und
damit sinkt die Reaktionsfähigkeit.
Eine besonders deutliche und damit folgenreiche Ausprä-
gung dieses Prinzips ist die organisatorische Trennung zwi-
schen der IT-Abteilung und den Businesseinheiten ( 1A).
Diese Kluft kann zwar durch agile Projektmethoden ein Stück
weit verringert, aber längst nicht geschlossen werden. Die
Kluft zwischen Businesseinheiten bzw. IT-Entwicklung auf
der einen Seite und IT-Betrieb auf der anderen Seite wird hin-
gegen auch durch agile Projektmethoden nicht kleiner.
Durch die komplexen Abhängigkeiten in der hierarchischen
Organisation eines Versicherers fehlt es Mitarbeitern an Au-
tonomie, die für rasche Entscheidungen notwendig wäre. Es
müssen oftmals mehrere Hierarchielevel sowie auch andere
Bereiche mit in die Entscheidungsfindung einbezogen werden.
Der typische Mitarbeiter eines klassischen Versicherers ist in
der Regel hoch spezialisiert und bei der Rekrutierung neuer
Mitarbeiter wird Wert auf brancheninterne Erfahrung gelegt.
Mitarbeiter in den IT-Abteilungen haben hauptsächlich Er-
fahrung mit vergleichsweise alten Legacy-Technologien.
Nicht selten lässt sich daher beobachten, dass Mitarbeiter
Veränderungen ablehnen, um etablierte Einfluss- oder
Machtsphären zu schützen.
Die hier erläuterten organisatorischen Eigenschaften sind
mitverantwortlich dafür, dass klassische Versicherer nur auf
wenige Releasezyklen pro Jahr kommen, während manche
moderne Technologieunternehmen mehrere Hundert pro
Tag erreichen. Für Letztere ist die potenzielle Untergrenze für
die Durchlaufzeit also um Größenordnungen niedriger.
Ein komponentenorientiertes Betriebsmodell
Im Folgenden stellen wir die organisatorischen Aspekte ei-
nes Betriebsmodells für einen reaktionsfähigen Versicherer
im digitalen Zeitalter vor. In der nächsten Ausgabe von «The
Magazine» werden wir die technologischen Aspekte näher
beleuchten.
Wir gehen davon aus, dass in einer digitalen Welt die Unter-
nehmen selbst nach und nach zu Software werden. Durch
Menschen werden nur noch jene Funktionen erbracht wer-
den, welche durch Software bzw. Maschinen nicht bzw. noch
nicht genügend gut oder kostengünstig erbracht werden
können. Die Zahl dieser noch nicht automatisierten Funktio-
nen wird mit zunehmendem technologischem Fortschritt je-
doch weiter abnehmen und möglicherweise letztlich gegen
null streben. Wir schließen daraus, dass unser Betriebsmo-
dell auf Prinzipien der Softwarearchitektur beruhen muss.
Lose gekoppelte Komponenten
Das Unternehmen ist in Komponenten organisiert, welche
unterschiedliche Businessfunktionalitäten repräsentieren.
Jede Komponente stellt eine wohldefinierte Softwareschnitt-
stelle zur Verfügung. Die Leistungen einer Komponente kön-
nen ausschließlich über diese Schnittstelle genutzt werden
( 1C-D). Dadurch ergibt sich ein geringerer Grad an Abhän-
gigkeit der Komponenten untereinander, sodass Änderun-
gen der einzelnen Komponenten einfacher durchgeführt
werden können. Jeff Bezos, Gründer von Amazon, verordne-
te seinem Unternehmen diesen Ansatz bereits im Jahr 2002
und legte damit das Fundament für den nach wie vor mit
Abstand größten Cloud-Anbieter der Welt: Amazon Web-
services (AWS).
Schlanke, funktionsübergreifende Teams
Jede Komponente verfügt über die notwendigen Ressour-
cen, um ihre Services zu entwerfen, zu implementieren und
zu betreiben ( 1B-D). Diese Ressourcen sind als schlankes,
funktionsübergreifendes Team organisiert und arbeiten im
selben Büro, um eine möglichst reibungsfreie Zusammenar-
beit zu ermöglichen. Entwicklung und Betrieb der Software
erfolgt also durch dasselbe Team (sog. DevOps-Ansatz). Dies
ist die geschäftsrelevante Mission des Teams, welche diesem
den Sinn gibt, wie er für intrinsische Motivation der Teammit-
glieder notwendig ist. Amazon stellte zur Steigerung seiner
Agilität bereits im Jahr 2000 auf schlanke «Two Pizza Teams»
um, d.h. auf Teams, die maximal so groß sind, dass sie noch
mit zwei Pizzas verpflegt werden können. Spotify wiederum
ist organisiert in sogenannte «Squads», kleine funktions-
übergreifende Teams mit jeweils einer langfristigen Mission
und eigenem Product Owner, welche für ihr Releasemanage-
ment selbst verantwortlich sind.

3. synpulse28 | Digital Transformation
Autonome Komponenten
Jede Komponente agiert als eigenes Profitcenter und ist frei,
sich intern so zu organisieren, wie sie möchte, solange sie die
in ihrer Schnittstelle definierten Services gemäß Service-
Level-Agreement erbringt. Diese Autonomie ist eine weitere
wichtige Voraussetzung für die nötige intrinsische Motivation
der Mitarbeiter im Komponententeam. Die Kosten für die
Nutzung ihrer Services verrechnen Komponenten an die auf-
rufenden Komponenten. Umgekehrt sind Komponenten frei,
als Subkomponenten auch externe Anbieter zu nutzen, so-
dass ein Wettbewerbsfaktor resultiert ( 1D). Aufrufende
Komponenten oder eigens dafür geschaffene Audit- bzw.
Controlling-Komponenten testen mittels entsprechender
Testdatensätze, ob andere Komponenten ihre Leistung ge-
mäß spezifizierter Qualität erbringen. So kann verhindert
werden, dass einzelne Komponenten Qualität zugunsten von
Profit bewusst niedriger halten als versprochen.
Maximale Automatisierung als Ziel
Operative Mitarbeiter, welche manuelle Arbeiten des Versi-
cherungsgeschäfts verrichten, sind gekapselt. Aufträge auf-
grund von Serviceaufrufen auf der Komponentenschnitt-
stelle werden an sie weitergeleitet, sofern sie noch nicht
durch die Software selbst erbracht werden können ( 1C).
Das Komponententeam ist an den Kostenreduktionen finan-
ziell beteiligt und daher motiviert, die Weitergabe von
Aufgaben an die operativen Mitarbeiter ständig zu verringern
und eine vollständige Automatisierung anzustreben ( 1D).
APIs als Innovationsmotor
Serviceschnittstellen sind von Beginn weg so zu gestalten,
dasssienichtnurinnerhalbdesUnternehmensgenutztwerden
können, sondern als APIs (Application Programming Interfa-
ces) auch externen Nutzern zur Verfügung gestellt werden.
APIs können so neue Kundensegmente erschließen, Produkte
1: Transformation eines traditionellen Versicherungsunternehmens in ein komponentenbasiertes digitales Unternehmen
(exemplarische Darstellung)
Quelle: Synpulse
B) Stufe 1
D) Stufe 3 C) Stufe 2
A) Heute
Vertrieb
Business Ops Business Ops
IT Dev & Ops
IT Dev & Ops
Underwriting
Antrag
IT-Abteilung
Dev & Ops
Antrag
IT Dev & Ops
Antrag
Business Ops
Antrag
Externer
Anbieter
Legende
Dev: Entwicklung (Development)
Ops: Betrieb (Operations)
UI: Benutzerschnittstellen (User Interface)
API: Application Programming Interfaces
Dev & Ops
Offerte
IT Dev & Ops
Offerte
Business Ops
Offerte
Dev & Ops
Vertrag
IT Dev & Ops
Vertrag
Business Ops
Vertrag
Vertrieb
Business Ops Business Ops IT Dev & Ops
Underwriting IT-Abteilung
UI
UI UI UI
API
API API API API API
API
API
Logik/Daten Logik/Daten Logik/Daten Logik/Daten Logik/Daten
Logik/Daten
Logik/Daten
Businessapplikation
Businessapplikation

4. synpulse Digital Transformation | 29
Dr. Dominik Langer
Manager (Topic Expert)
dominik.langer@synpulse.com
Dr. Andreas Wicht
Senior Consultant
andreas.wicht@synpulse.com
Autoren
erweitern und ganze Partnerökosysteme ermöglichen. Da-
durch, dass sie die Reichweite existierender Dienstleistungen
erweitern oder sogar selbst neue Einnahmequellen darstel-
len, wirken sie sich direkt auf den Umsatz aus. Ein weiterer
Vorteil ist, dass mittels APIs Innovation sozusagen ausgela-
gert werden kann: Start-ups und private Entwickler können
basierend auf APIs eigene Anwendungen entwickeln.
Die Umsetzung
Die notwendigen Veränderungen sind tiefgreifend und die
Frage zum optimalen Vorgehen im Sinne des Transformati-
onsprozesses stellt sich zwangsläufig. Grundsätzlich können
zwei Ansätze unterschieden werden. Beim ersten Ansatz
wird das neue Betriebsmodell Schritt für Schritt umgesetzt.
Beim zweiten wird ein neues Unternehmen gegründet und
von Anfang an entsprechend dem neuen Betriebsmodell auf-
gebaut. Der Kundenbestand des alten Unternehmens wird
schließlich in das neue überführt und das alte Unternehmen
stillgelegt.
Beim ersten Ansatz besteht die reale Gefahr, dass die Trans-
formation in der bestehenden Organisation verwässert,
während beim zweiten Ansatz sozusagen auf der grünen Wie-
se angefangen werden kann. Jedoch ist beim zweiten Ansatz
ein Nutzen erst dann zu erwarten, wenn alle minimal
notwendigen Komponenten in Betrieb gehen können. Beim
ersten Ansatz kann bereits vorher ein spürbarer Nutzen
realisiert werden. Beim zweiten Ansatz kann dies auf einer
absoluten Zeitskala allerdings trotzdem früher der Fall sein.
So hat beispielsweise der junge Krankenversicherer Oscar
Health seine IT-Infrastruktur mittels cloud-basierter Kompo-
nenten in nur drei Monaten aufgebaut, während die Einfüh-
rung eines neuen Kernsystems bei einem traditionellen
Versicherer in der Regel ein Vielfaches länger dauert.
Wenn der erste Ansatz verwendet wird, muss in jedem Fall
schrittweise vorgegangen werden ( 1). Zuerst ist eine
Architektur aus atomaren Businessfunktionalitäten zu ent-
werfen, die als einzelne Komponenten realisiert werden sol-
len. Mittels einer Roadmap wird anschließend geplant, in
welcher Reihenfolge sie umgesetzt werden sollen. Bei der
Realisierung einer Komponente ist ein geeignetes funktions-
übergreifendes Team zusammenzustellen. Dieses Team er-
stellt für seine Komponente eine Software mit API, welches
Serviceaufrufe selbstständig, durch Andocken an Legacyap-
plikationen oder durch Weiterleiten an eine traditionelle Orga-
nisationseinheit bearbeitet. Das Team optimiert seine Kompo-
nente dann kontinuierlich, indem die Abhängigkeiten von
traditionellen Organisationseinheiten reduziert werden, v.a.
durch Automatisierung und Auslagerung an externe Anbieter.
Beim zweiten Ansatz unterscheidet sich das Vorgehen nur in-
sofern, als dass keine Legacyapplikationen oder traditionel-
len Organisationseinheiten einzubeziehen sind.
Fazit
Aus den Erfahrungen zahlreicher Digitalisierungsprojekte
kommen wir zum Schluss, dass klassische Versicherer heute
(noch) nicht in der Lage sind, sich rasch genug auf eine sich
immer schneller ändernde Umwelt und Marktbedingungen
einzustellen. Gleichzeitig nehmen wir wahr, dass neue Unter-
nehmen in den Markt drängen mit dem Potenzial, die klassi-
schen Geschäftsmodelle zu verdrängen. Wenn sich die Markt-
präsenz dieser neuen InsurTech-Unternehmen negativ in den
Quartalszahlen eines konventionellen Versicherers nieder-
schlägt, wird es für Letzteren womöglich schon zu spät sein.
Wir sehen daher die dringende Notwendigkeit, bereits heute
Möglichkeiten einer fundamentalen Transformation in ein
intrinsisch agiles Versicherungsunternehmen auszuloten und
früh genug entsprechend zu handeln.