Daten- und Prozessmodellierung für Versicherer: Konzepte für moderne IT in Bestandsführung und Schadenmanagement

Von Frank Urlaß

Mit diesem Buch unterstützt Frank Urlaß Versicherungsunternehmen bei der Entwicklung von effizienten, marktgerechten und aufsichtskonformen IT-Landschaften. Mit den vorgestellten Konzepten können sowohl veraltete Hostsysteme modernisiert als auch durch Zukäufe und Fusionen unübersichtlich gewordene Systeme entschlackt werden. Dazu werden in den ersten drei Kapiteln des Buches zunächst ausführlich die theoretischen Grundlagen für die Komplexe Daten- und Prozessmodellierung entwickelt. Jeweils anschließend folgt die Beschreibung der praktischen Ausgestaltungen der Daten- und der Prozessmodelle. Diese Teile werden im nächsten Kapitel durch eine Beschreibung abgeschlossen, in der gezeigt wird, wie das Daten- und das Prozessmodell zusammenwirken und sich wechselseitig bedingen und ergänzen. Nach der Beschreibung eines Vorgehensmodells für einen potenziellen Anwender, der die vorgestellten Konzepte als Vorlage für seine eigene Entwicklung verwenden möchte, folgen in zwei weiteren Kapiteln ein Modell zur fachlichen und technischen Weiterentwicklung der neuen IT sowie die Beschreibung des Preismodells. In zwei Anhängen werden abschließend zunächst eine Liste der Plausibilitäten für die meisten der eingabefähigen Attribute im Datenmodell und danach eine Beschreibung ausgewählter Geschäftsregeln für das Prozessmodell angefügt. 

• Sprache: Deutsch
• Herausgeber: Springer Gabler
• Erscheinungsdatum: 9. Okt. 2019
• ISBN: 9783658263294

Buchvorschau

Frank Urlaß

Daten- und Prozessmodellierung für Versicherer

Konzepte für moderne IT in Bestandsführung und Schadenmanagement

../images/481317_1_De_BookFrontmatter_Figa_HTML.png

Frank Urlaß

Asskura-Consulting GmbH, Köln, Deutschland

ISBN 978-3-658-26328-7e-ISBN 978-3-658-26329-4

https://doi.org/10.1007/978-3-658-26329-4

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten.

Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral.

Springer Gabler ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature.

Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Inhaltsverzeichnis

1 Einleitung 1

1.​1 Die ideale Welt der IT 1

1.​2 Beschreibung und Abgrenzung der Thematik 1

1.​2.​1 Die große Herausforderung für die Versicherer 1

1.​2.​2 Situationsberich​t 2

1.​2.​3 Wie ist es dazu gekommen?​ 3

1.​2.​4 Wie geht es weiter?​ Was ist zu tun?​ 6

1.​2.​5 Daten- und Prozessmodell von Asskura als neue Basis 8

1.​2.​6 Zu erreichende Ziele 9

1.​2.​7 SOA als neues Organisationspar​adigma 9

1.​2.​7.​1 Das Asskura-Modell als serviceorientier​te Architektur 9

1.​2.​7.​2 Grundlegende Eigenschaften einer SOA 10

1.​2.​7.​3 Vorteile einer SOA für die Aufbau- und Ablauforganisati​on 11

1.​2.​8 Über den Autor 12

Literatur 12

2 Datenmodell 13

2.​1 Einführung in die Datenmodellierun​g 13

2.​1.​1 Grundlagen der Datenmodellierun​g 13

2.​1.​2 Methoden der Datenmodellierun​g 14

2.​1.​3 Nachteile der seriellen Datenspeicherung​ 15

2.​1.​4 Zugriff auf die erfassten Informationen 15

2.​1.​5 Inhaltliche Gliederung eines Dokuments 15

2.​1.​6 Der Faktor „Kosten" für die Datenspeicherung​ 16

2.​1.​7 Änderung der Speicherschemata​ von Informationen 16

2.​2 Der Weg zu einem umfassenden Domänentableau 17

2.​2.​1 Annäherung an ein allgemein gültiges Gliederungsschem​a 17

2.​2.​2 Verteilung der Informationen auf Datendomänen 19

2.​2.​3 Gliederung der Domänen/​Teildomänen in Entitäten 20

2.​2.​4 Zusammenstellung​ der Entitäten zu Datendiagrammen 20

2.​3 Datenhaltung bei Versicherern 21

2.​3.​1 Beschreibung des Datenraums von Versicherungsunt​ernehmen 21

2.​3.​2 Grafisch aufbereitetes Tableau der Datendomänen 23

2.​3.​3 Konsequenzen der Abhängigkeitsgra​phen für die Projektorganisat​ion 24

2.​3.​4 Signalfarben im Tableau der Datendomänen 25

2.​3.​5 Untergliederung der Datendomänen in Datendiagramme 27

2.​3.​6 Beschreibung der Entitäten in den Datendomänen 30

2.​3.​7 Beschreibung der Attribute einer Entitäten 31

2.​3.​7.​1 Liste der Attribute einer Entität 31

2.​3.​7.​2 Klassifizierung eines Eingabefelds als Kann- oder Mussfeld 32

2.​3.​7.​3 Formale Feldprüfung 32

2.​3.​7.​4 Technischer Name und Datentyp 35

2.​3.​7.​5 Enumerationen zu einem Attribut mit Aufzählungstyp 35

2.​4 Erzeugen von DDL-Strukturen 37

2.​5 Beispiel für eine objektorientiert​e Versicherungsdat​enstruktur 38

2.​6 Übersicht über die Datendomänen eines Versicherers 45

2.​6.​1 Außendienst 46

2.​6.​2 Berechtigung (Berechtigungsprü​fung) 51

2.​6.​3 Briefschreibung 56

2.​6.​4 Buchung 59

2.​6.​5 Exkasso 62

2.​6.​6 Inkasso 66

2.​6.​7 Kfz-Kennzeichen 70

2.​6.​8 Partner 72

2.​6.​9 Produkt 77

2.​6.​10 Provision 84

2.​6.​11 Prozess (Gericht) 87

2.​6.​12 Rückversicherung​ 90

2.​6.​13 Schaden 95

2.​6.​14 Versicherung 106

2.​6.​15 Vertrag 128

2.​6.​16 Vorgangsakte 132

2.​6.​17 Zeitpunkt 135

2.​6.​18 Zuständigkeit 138

2.​7 Mengengerüst Datenmodell 141

3 Prozessmodell 143

3.​1 Definition Prozess 143

3.​2 Probleme mit den Geschäftsprozess​en 143

3.​3 Drei Säulen der Informationsvera​rbeitung 144

3.​4 Methoden der Geschäftsprozess​modellierung 145

3.​4.​1 Grundfragen der Prozessmodellier​ung 145

3.​4.​2 Visualisierung der Prozesse (Visio/​EPK/​BPEL) 146

3.​4.​3 Granualisierung der Prozesse 147

3.​4.​4 Prozessmodellier​ung mit BPMN 148

3.​4.​5 Dialog- und Batchprozesse 149

3.​5 Der Weg zu einer einheitlichen Prozesslandkarte​ 150

3.​5.​1 Der (dornige) Weg dorthin 150

3.​5.​2 Bestimmungsfakto​ren einer unternehmensüber​greifenden Prozesslandkarte​ 151

3.​5.​2.​1 Empirischer Ansatz 152

3.​5.​2.​2 Analytischer Ansatz 152

3.​5.​3 Beschreibung einer Prozesssequenz 153

3.​5.​4 Gliederung einer Prozesssequenz 155

3.​5.​5 Versicherungstec​hnische End-to-End-Prozesse 155

3.​6 Orte oder Stellen zum Aufspüren der End-to-End-Prozesse 156

3.​6.​1 Versicherungspro​dukt entwickeln 156

3.​6.​2 Versicherungspro​dukt verkaufen 157

3.​6.​3 Schadensersatzan​spruch bearbeiten 157

3.​6.​4 Risiko diversifizieren 158

3.​6.​5 Partnerbestand pflegen 159

3.​6.​6 Geldverkehr vorbereiten und abwickeln 160

3.​6.​7 Gerichtsprozesse​ erfassen 161

3.​6.​8 Vorlagen, Bedingungen, Richtlinien bearbeiten 161

3.​6.​9 Fällige Vorgänge bearbeiten 161

3.​6.​10 Sachbearbeiter-Berechtigungen verwalten 162

3.​6.​11 Verkaufsorganisa​tion verwalten 162

3.​6.​12 Öffentliche Informationen auswerten 163

3.​6.​13 Statistische Auswertungen erstellen 163

3.​6.​14 Informationen zum/​vom GDV bearbeiten 164

3.​7 Theorie und Praxis der Versicherungspro​zesse 164

3.​7.​1 Entwicklung einer Prozesslandkarte​ 164

3.​7.​2 Erläuterung des Modellierungspri​nzips an einem Beispiel 168

3.​7.​2.​1 Partner in Partner-DB suchen 168

3.​7.​2.​2 Partner zum XX-Beteiligten zuordnen 169

3.​7.​2.​3 Beziehungen zwischen Partnern herstellen 169

3.​7.​2.​4 EMA-Anfrage zum Partner erfassen 169

3.​7.​2.​5 Partner mit Partner-Kontakt zusammenführen 170

3.​7.​2.​6 Weitere Bearbeitungen zum Partner durchführen 170

3.​7.​2.​7 Partnerbestand bereinigen 170

3.​7.​2.​7.​1 Namensänderungen​ zu vorhandener Adresse bearbeiten 171

3.​7.​2.​7.​2 Adress-Doublette erkennen 171

3.​7.​2.​7.​3 Assoziationsbezi​ehungen zwischen den Entitäten 173

3.​7.​3 Kernpunkte einer Prozesstheorie für Erstversicherung​sunternehmen 174

3.​7.​4 Von der Prozessdomäne zur Prozesssequenz 175

3.​8 Beschreibung der Services innerhalb einer Prozesssequenz 177

3.​8.​1 Elemente einer Prozesssequenz 177

3.​8.​2 Anwendung der Prozesstheorie auf ein Versicherungsunt​ernehmen 181

3.​8.​3 Übersicht über die Prozessdomänen einer Versicherung 182

3.​8.​4 Versicherungspor​tefeuille überprüfen 182

3.​8.​4.​1 Der Markt für Versicherungen im 21.​ Jahrhundert 182

3.​8.​4.​2 Verbesserung der Marktbeobachtung​ 182

3.​8.​4.​3 Dokumentation der Ergebnisse 183

3.​8.​4.​4 Festlegung der Vertriebskanäle 183

3.​8.​4.​5 Modellierung und Verwaltung der Versicherungspro​dukte in der IT 184

3.​8.​5 Versicherungspro​dukt entwickeln 185

3.​8.​5.​1 Gewünschtes Produkt bestimmen 185

3.​8.​5.​2 Produktart speziell modellieren 187

3.​8.​5.​3 Versicherungsspa​rte zur speziellen Produktart zuordnen 188

3.​8.​5.​4 Eigenes Produktportefeui​lle untersuchen 192

3.​8.​5.​5 As-If-Rechnung für Versicherungspro​dukte durchführen 192

3.​8.​6 Versicherungspro​dukt verkaufen 193

3.​8.​6.​1 Versicherungsver​trag bearbeiten 194

3.​8.​6.​2 Vertragsbeteilig​ten bearbeiten 196

3.​8.​7 Versicherungspro​dukt bearbeiten 200

3.​8.​7.​1 Versicherung allgemein bearbeiten 200

3.​8.​7.​2 Versicherung Sparte bearbeiten 204

3.​8.​7.​2.​1 Versicherung Auslandskranken bearbeiten 204

3.​8.​7.​2.​2 Versicherung Betriebsunterbre​chung bearbeiten 207

3.​8.​7.​2.​3 Versicherung Dienstreisekasko​ bearbeiten 209

3.​8.​7.​2.​4 Versicherung Extended Coverage modellieren 210

3.​8.​7.​2.​5 Versicherung ED modellieren 212

3.​8.​7.​2.​6 Versicherung Feuer bearbeiten 214

3.​8.​7.​2.​7 Versicherung Glas bearbeiten 216

3.​8.​7.​2.​8 Versicherung Haftpflicht bearbeiten 218

3.​8.​7.​2.​9 Versicherung Hagel bearbeiten 225

3.​8.​7.​2.​10 Versicherung Handel und Handwerk bearbeiten 226

3.​8.​7.​2.​11 Versicherung Hausrat bearbeiten 228

3.​8.​7.​2.​12 Versicherung Kaution bearbeiten 231

3.​8.​7.​2.​13 Versicherung Kraftfahrt bearbeiten 233

3.​8.​7.​2.​14 Versicherung Krankenhaustageg​eld bearbeiten 242

3.​8.​7.​2.​15 Versicherung Krankentagegeld bearbeiten 244

3.​8.​7.​2.​16 Versicherung Kranken-Gruppenversicher​ung bearbeiten 247

3.​8.​7.​2.​17 Versicherung Kranken-Vollversicherung​ bearbeiten 248

3.​8.​7.​2.​18 Versicherung Kranken-Zusatzversicheru​ng bearbeiten 256

3.​8.​7.​2.​19 Versicherung Kurversicherung bearbeiten 263

3.​8.​7.​2.​20 Versicherung Pflege bearbeiten 265

3.​8.​7.​2.​21 Versicherung Leben bearbeiten 268

3.​8.​7.​2.​22 Versicherung Leitungswasser bearbeiten 272

3.​8.​7.​2.​23 Versicherung Luftfahrt bearbeiten 272

3.​8.​7.​2.​24 Versicherung Rechtsschutz bearbeiten 274

3.​8.​7.​2.​25 Versicherung Sturm bearbeiten 277

3.​8.​7.​2.​26 Versicherung Technische-Versicherung bearbeiten 278

3.​8.​7.​2.​27 Versicherung Tierversicherung​ bearbeiten 282

3.​8.​7.​2.​28 Versicherung Transport bearbeiten 283

3.​8.​7.​2.​29 Versicherung Unfall bearbeiten 287

3.​8.​7.​2.​30 Versicherung Verkehrsservice bearbeiten 291

3.​8.​7.​2.​31 Versicherung Vertrauensschade​n bearbeiten 293

3.​8.​7.​2.​32 Versicherung Warenkredit bearbeiten 295

3.​8.​7.​2.​33 Versicherung Wohngebäude bearbeiten 297

3.​8.​7.​3 Versichertes Objekt Sache entwickeln 299

3.​8.​7.​3.​1 Versichertes Objekt Sache-allgemein bearbeiten 300

3.​8.​7.​3.​2 Versichertes Objekt Gebäude-Bau bearbeiten 301

3.​8.​7.​3.​3 Versichertes Objekt Gebäude-Inhalt bearbeiten 303

3.​8.​7.​3.​4 Versichertes Objekt Gewerbe bearbeiten 304

3.​8.​7.​4 Versicherungsbei​trag ermitteln 306

3.​8.​7.​4.​1 Vorbedingung 306

3.​8.​7.​4.​2 Versichertes Objekt Beitragsermittlu​ng 307

3.​8.​7.​4.​3 Versichertes Objekt Beitragsberechnu​ng 307

3.​8.​7.​4.​4 Aufteilung des Beitrags nach Eigen- und Fremdanteil 308

3.​8.​7.​4.​5 Versichertes Objekt Beitrag gebucht 308

3.​8.​7.​4.​6 Forderung oder Stundung 308

3.​8.​7.​4.​7 Die Prozesssequenzen​ im Detail 309

3.​8.​7.​4.​8 Übersicht über den Beitragsrechenke​rn 311

3.​8.​7.​5 Versicherungspro​vision ermitteln 313

3.​8.​7.​6 Versicherungsver​trag ausfertigen 314

3.​8.​7.​7 Versicherungsver​trag stornieren 315

3.​8.​7.​8 Vertragsangebot (Probeantrag) erfassen/​erstellen 315

3.​8.​8 Risiko diversifizieren 315

3.​8.​8.​1 RV-Ordnung erfassen 315

3.​8.​8.​2 RV-Verträge erfassen 316

3.​8.​8.​3 Abrechnungsschem​a zur RV-Ordnung zuordnen 318

3.​8.​8.​4 Verträge im Mitversicherungs​geschäft erfassen 321

3.​8.​8.​5 Schäden im Mitversicherungs​geschäft erfassen 322

3.​8.​9 Schadenersatzans​pruch bearbeiten 323

3.​8.​9.​1 Schadenersatzans​pruch erfassen 323

3.​8.​9.​2 Schadenaufwand erfassen 327

3.​8.​9.​3 Schadenleistung weiterverarbeite​n 331

3.​8.​9.​4 Schadenaufwand verrechnen 333

3.​8.​9.​5 Schadenvorgänge freigeben 336

3.​8.​9.​6 Schadenleistung regressieren 337

3.​8.​9.​7 Geldeingang zur Schadenteilakte erfassen 340

3.​8.​9.​8 Schadenleistung umbuchen 340

3.​8.​9.​9 Schadenrente bearbeiten 341

3.​8.​9.​10 Gerichtsprozess im Schaden erfassen 343

3.​8.​9.​11 Sonstige Bearbeitungen zum Schaden durchführen 344

3.​8.​9.​12 Sonstige Bearbeitungen zur Schadenteilakte durchführen 349

3.​8.​10 Partnerbestand pflegen 352

3.​8.​10.​1 Partner in Partner-DB suchen 353

3.​8.​10.​2 Partner bearbeiten 354

3.​8.​10.​3 Beziehungen zwischen Partnern herstellen 354

3.​8.​10.​4 EMA-Anfrage zum Partner erfassen 355

3.​8.​10.​5 Partner mit Partner-Kontakt zusammenführen 356

3.​8.​10.​6 Sonstige Bearbeitungen zum Partner durchführen 357

3.​8.​10.​7 Partnerbestand bereinigen 359

3.​8.​11 Geldverkehr bearbeiten 359

3.​8.​11.​1 Liquiditätsdispo​sition bearbeiten 360

3.​8.​11.​2 Mahngebühren erfassen 360

3.​8.​11.​3 Ratenzahlungen bearbeiten 361

3.​8.​11.​4 Laufende Geldeingänge kanalisieren 361

3.​8.​11.​5 Begebene Schecks sperren 364

3.​8.​12 Gerichtsprozesse​ erfassen 364

3.​8.​12.​1 Gerichtsprozess einleiten 364

3.​8.​12.​2 Grunddaten eines Gerichtsprozesse​s erfassen 365

3.​8.​12.​3 Laufenden Gerichtsprozess bearbeiten 366

3.​8.​13 Bedingungen, Richtlinien, Vorlagen bearbeiten 367

3.​8.​13.​1 Vorgaben zur Versicherungsbea​rbeitung erfassen 367

3.​8.​13.​2 Richtlinien Bewertung für Schäden erfassen 368

3.​8.​13.​3 Textkonserven als Vorlage erfassen 369

3.​8.​13.​3.​1 Fachliche Briefdomäne auswählen 369

3.​8.​13.​3.​2 Textvorlage in der Domäne Versicherung erfassen 370

3.​8.​13.​3.​3 Textvorlage in der Domäne Schaden erfassen 371

3.​8.​13.​3.​4 Textvorlage in der Domäne Inkasso erfassen 373

3.​8.​13.​3.​5 Textvorlage in der Domäne Exkasso erfassen 373

3.​8.​13.​3.​6 Textvorlage in der Domäne Personal erfassen 374

3.​8.​13.​4 Textkonserve zur Briefschreibung bereitstellen 375

3.​8.​13.​4.​1 Textvorlage in der Domäne Versicherung bereitstellen 375

3.​8.​13.​4.​2 Textvorlage in der Domäne Schaden bereitstellen 375

3.​8.​13.​4.​3 Textvorlage in der Domäne Inkasso bereitstellen 377

3.​8.​13.​4.​4 Textvorlage in der Domäne Exkasso bereitstellen 378

3.​8.​13.​4.​5 Textvorlage in der Domäne Personal bereitstellen 378

3.​8.​13.​5 Vorhandenen Brief als Vorlage verwenden 379

3.​8.​13.​5.​1 Briefdomäne auswählen 379

3.​8.​13.​5.​2 Textvorlage auswählen 380

3.​8.​14 Fällige Vorgänge bearbeiten 382

3.​8.​14.​1 Periodische Termine bearbeiten 382

3.​8.​14.​2 Aperiodische Termine bearbeiten 387

3.​8.​15 Sachbearbeiter-Berechtigungen verwalten 387

3.​8.​15.​1 Stellenprofile einrichten/​pflegen 387

3.​8.​15.​2 Neuen Sachbearbeiter im Berechtigungssys​tem erfassen 389

3.​8.​15.​3 Stellenzuordnung​en eines Sachbearbeiters beenden 390

3.​8.​15.​4 Anmeldeprozedur für den Sachbearbeiter entwickeln 390

3.​8.​15.​5 Sachbearbeiter im System anmelden 393

3.​8.​15.​6 Vorgangsakte zum Sachbearbeiter prüfen 394

3.​8.​16 Verkaufsorganisa​tion verwalten 396

3.​8.​16.​1 Außendienstagent​uren bearbeiten 396

3.​8.​16.​2 Außendienstbetei​ligte erfassen 397

3.​8.​16.​3 Außendienstvertr​iebswege bearbeiten 399

3.​8.​16.​4 Verkaufserfolg messen 399

3.​8.​17 Öffentliche Informationen auswerten 401

3.​8.​17.​1 Öffentliche Informationen auswerten 401

3.​8.​17.​2 Informationen anderer Institutionen bearbeiten 402

3.​8.​17.​3 Internetportale Dritter auswerten 403

3.​8.​18 Statistiken erstellen 403

3.​8.​18.​1 Aperiodische Auswertungen beschreiben 403

3.​8.​18.​2 Periodische Auswertungen beschreiben 403

3.​8.​18.​3 Kundenqualität untersuchen 404

3.​8.​19 Informationen von dem/​an den GDV bearbeiten 406

3.​8.​19.​1 Auffälligkeiten von dem/​an den GDV-HIS bearbeiten 406

3.​8.​20 Mengengerüst Prozessmodell 407

3.​8.​21 Anwendung der Prozesstheorie auf ein Versicherungsunt​ernehmen 407

3.​8.​22 Erzeugen von XML-Files 410

4 Zusammenwirken von Daten- und Prozessmodell 413

4.​1 Beziehungen zwischen Daten-und Prozessmodell 413

4.​2 Unterstützung der Prozessmodellier​ung durch die UML 413

4.​3 Unterstützung der Datenmodellierun​g durch die End-to-End-Prozesse 414

4.​4 Vorzüge einer von SOA geprägten IT-Organisation 416

4.​4.​1 Definition SOA aus dem SOA-Manifesto 416

4.​4.​2 Die Charakteristika einer SOA-Organisation 416

4.​4.​3 Gründe für die Umstellung auf eine SOA-Organisation 418

4.​4.​4 Konsequenzen für das Unternehmen 419

4.​4.​5 Weitere Themen in einer von SOA geprägten IT-Organisation 420

4.​4.​5.​1 SOA-Security 420

4.​4.​5.​2 SOA-Governance 420

4.​4.​5.​3 SOA-Ownership 420

4.​4.​5.​4 Geringere IT-Kosten unter SOA 421

5 Vorgehensmodell zur Entwicklung einer neuen IT 423

5.​1 Ist-Situation der Altbestände 423

5.​2 Struktur eines neuen IT-Systems 423

5.​3 Bearbeitungsschr​itte im Vorgehensmodell 426

5.​3.​1 Schritt 01:​ Einrichtung eines Steuerungsgremiu​ms 426

5.​3.​2 Schritt 02:​ Einsetzung einer internen Arbeitsgruppe 426

5.​3.​3 Schritt 03:​ Sparxx-Systems einbeziehen 426

5.​3.​4 Schritt 04:​ Dokumentation aller Datensätze/​Dateien im Ist-Zustand 427

5.​3.​5 Schritt 05:​ Dokumentation der Attribute im Ist-Zustand 428

5.​3.​6 Schritt 06:​ Laden des Asskura-Datenmodells auf einer Datenbank 429

5.​3.​7 Schritt 07:​ Adaption des Asskura-Datenmodells durch den Anwender 430

5.​3.​8 Schritt 08:​ Prüfung der Datendomänen 430

5.​3.​9 Schritt 09:​ Prüfung der Datendiagramme 431

5.​3.​10 Schritt 10:​ Prüfung der Entitäten 432

5.​3.​11 Schritt 11:​ Prüfung und Abgleich der Attribute 433

5.​3.​12 Schritt 12:​ Konsolidierung der Ergebnisse 434

5.​3.​13 Schritt 13:​ Entwicklung eines User-Interfaces 434

5.​3.​14 Schritt 14:​ Auswirkungen auf die BPMN-Prozesssequenzen​ 434

5.​3.​15 Schritt 15:​ Anpassung der BPMN-Prozesssequenzen​ 435

5.​3.​16 Schritt 16:​ Orchestrierung der Geschäftsprozess​e 436

5.​3.​17 Schritt 17:​ Installation der neuen Datenbank 438

5.​4 Vorteile, IT-Projekte mit dem Asskura-Modell zu managen 439

5.​4.​1 Vorteil 1:​ Auf den Unterschied konzentrieren 439

5.​4.​2 Vorteil 2:​ Optimierung der Geschäftsprozess​e 439

5.​4.​3 Vorteil 3:​ Agilität und Reaktion auf neue Anforderungen 440

5.​4.​4 Vorteil 4:​ Mehr Transparenz in den Anwendungen 440

5.​4.​5 Vorteil 5:​ Das Rad muss nicht immer wieder neu erfunden werden 440

5.​4.​6 Vorteil 6:​ Das Asskura-Modell als Kommunikationsmi​ttel 441

6 Weiterentwicklun​gsmodell der neuen IT 443

6.​1 Die zukünftig zu lösenden Aufgaben 443

6.​2 Aufnahme neuer versicherbarer Risiken 444

6.​3 Erfüllung der Herausforderunge​n von Solvency II 450

6.​3.​1 Die drei Säulen von Solvency II 450

6.​3.​2 Verwendung des Standard- oder Entwicklung eines Individualmodell​s?​ 451

6.​3.​3 Einrichtung eines Data-Warehouses 452

6.​3.​3.​1 Erzeugen der Struktur des Data-Warehouses (Schritt 1) 452

6.​3.​3.​2 Erzeugen von DDL’s (Schritt 2) 453

6.​3.​3.​3 Verknüpfung zwischen Data-Warehouse und den produktiven Systemen (Schritt 3) 453

6.​3.​3.​4 Behandlung der verbleibenden Restmengen (Schritt 4) 453

6.​3.​3.​5 Einrichten von Data-Marts für jede zu erzeugende Auswertung (Schritt 6) 454

6.​4 Prozessgestaltun​g ‚on the fly‘ 454

6.​4.​1 Wofür steht der Begriff ‚on the fly‘?​ 454

6.​4.​2 Gliederung der Prozesssequenzen​ 456

6.​5 Mehrsprachigkeit​ im Modell und in der Anwendung 458

6.​6 Agilität sicherstellen 459

6.​7 Eintauchen in ‚Big Data‘ 460

6.​8 Abwehr von Cyber-Crime 461

6.​9 Mehr Datensicherheit durch neuartige Verschlüsselung 464

6.​10 Einsatz der Blockchain-Technologie 464

6.​11 Brancheninitiati​ve Prozessoptimieru​ng (Bipro) 466

6.​12 Eingehen auf die Erfahrungen der Anwender 467

6.​13 Herausforderunge​n der Digitalisierung 468

6.​13.​1 Drei Gesichter der Digitalisierung 468

6.​13.​2 Problem des Sicherheit im Datenverkehr 469

6.​13.​3 Eine mögliche Lösung des Sicherheitsprobl​ems 470

6.​13.​4 Kompensation der Mehrkosten 472

Literatur 472

7 Asskura-Preismodell 473

7.​1 Ermittlung des Grundpreises 473

7.​2 Aufteilung des Grundpreises auf Versicherungsspa​rten 474

7.​3 Beratung durch Asskura 475

7.​4 Keine Wartungspauschal​e 476

7.​5 Preisnachlass auf den Grundpreis 476

7.​6 Nutzen aus dem Einsatz des Modells 477

7.​7 Objektive und subjektive Widerstände 479

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019

F. UrlaßDaten- und Prozessmodellierung für Versichererhttps://doi.org/10.1007/978-3-658-26329-4_1

1. Einleitung

Frank Urlaß¹ 

(1)

Asskura-Consulting GmbH, Köln, Deutschland

1.1 Die ideale Welt der IT

Nach einem langen Arbeitstag saßen ein IT-Chef und sein erfahrenster Mitarbeiter zusammen und sprachen über die Weiterentwicklung der IT-Anwendungen in der Zukunft. Dabei stellte der IT-Chef die Frage: „Wenn wir uns in einer idealen Welt befänden, wie sollten wir uns verhalten, um uns auf die Herausforderungen der Zukunft einzustellen? Wie sollten wir vorgehen?"

Der Mitarbeiter überlegte lange und kam schließlich zu dieser Antwort: „In einer solchen idealen Welt gibt es nur noch eine einheitliche Datenbasis ohne Redundanzen. Dies gilt sowohl in Bezug auf die Anwendungen und Daten als auch auf die Prozesse. Alle Anwendungskomponenten gelangen konsolidiert auf dieser einheitlichen Datenbasis zur Ausführung. Die Organisation der Daten und Prozesse liegt in einer Form vor, dass allfällige Änderungswünsche problemlos und zeitnah umgesetzt werden können. Und vor allem: Die Anbindung der Außenwelt über das Internet einschließlich der dabei zu lösenden Probleme für die Sicherheit und Integrität unserer sensiblen geschäftlichen Daten ist über qualitätsgesicherte interne und externe Services gewährleistet. Und schließlich: Die laufenden Kosten für die Weiterentwicklung, die Wartung und den Betrieb der IT sind sehr viel geringer als derzeit."

1.2 Beschreibung und Abgrenzung der Thematik

1.2.1 Die große Herausforderung für die Versicherer

Die zentralen Bestandsführungssysteme für die Vertragsverwaltung, das Schadenmanagement und alle weiteren für deren Betrieb benötigten IT-Komponenten sind bei fast allen Gesellschaften in der Regel 20 Jahre alt und älter.

Die Programmdokumentationen dafür existieren nicht mehr oder sind nicht mehr auffindbar. Die Menschen, die diese Systeme entworfen, entwickelt und zuerst betreut haben, sind inzwischen im Ruhestand. Diese alten Anwendungen sind in der Regel noch hostbasiert und in Cobol geschrieben. Wer versteht das noch? Wer kann damit noch umgehen?

Durch Fusionen und Aufkäufe sind bei vielen Versicherern im Lauf der letzten 20 Jahre diverse, häufig höchst unterschiedliche Bestandssysteme nebeneinander in den Einsatz gelangt. Diese müssen alle gewartet und am Leben gehalten werden. Auch die Arbeit in den Rechenzentren wird dadurch immer aufwendiger, unübersichtlicher und fehleranfälliger.

1.2.2 Situationsbericht

Diese Situation wird von diversen Personen immer wieder thematisiert und veröffentlicht.

So schreibt zum Beispiel Markus Unterberger in einem Beitrag in der Zeitschrift ‚Versicherungswirtschaft‘ vom Januar 2018 (vgl. Unterberger 2018, S. 22): „Lange Durchlaufzeiten, lange Abstimmungsphasen und viele Kompromisse innerhalb der Produkte stehen bei den Versicherern an der Tagesordnung. Die Unternehmen geraten zunehmend unter Druck, ihre IT-Koordination grundlegend zu sanieren. Es gilt, einzelne Prozesse sowie neue Produkte und Verträge in einem System abzubilden und zu verarbeiten. Doch das ist leichter gesagt als getan."

„IT-Koordination hat eine Sandwich-Position inne, da sie zwischen den Produktgebern, Vertrieben und der IT-Entwicklung agiert. Früher zeichnete sie sich durch eine Aufnahme von Fakten aus, die sich jedoch hin zu einer beratenden Rolle mit komplexen Projektmanagement-Aufgaben entwickelt hat".

„Mittlerweile entwickelt sich das Projektmanagement immer mehr in Richtung agiles Projektmanagement. Vorbilder, die eine Customer Journey erfolgreich begleiten, können Amazon und auch Paketdienste wie DHL darstellen. Diese Unternehmen sind mitten in der Digitalisierung, sie haben jedoch einen Vorteil gegenüber der Versicherungswirtschaft: In der Regel kommt der Kunde hier über einen Kanal. Trotzdem haben diese Unternehmen es geschafft spartenübergreifend zu arbeiten. Der Nachteil der Versicherungsgesellschaft besteht darin, dass der Kunde hier nicht nur über einen Kanal kommt, sondern über mehrere Kanäle".

„Er meldet sich also erst per Telefon, geht dann aber persönlich zum Innendienst, um etwas zu fragen und schließlich schreibt er noch eine E-Mail. Die Herausforderung liegt nun darin, dass der Kunde immer die Möglichkeit hat an jedem Touchpoint seine Frage abzusetzen, ohne dass er seine Geschichte nochmal erzählt", erklärt Holger Strecker von der Allianz Deutschland.

„Neben Methodenkompetenz und analytischer Stärke kommt es auch auf die Fähigkeit an, die beste Lösung für Kunden und Unternehmen zur Entscheidung zu bringen und diese umzusetzen", fügt Allianz-Kollege Andreas Herbst hinzu. „Die kundenzentrierte und spartenübergreifende Orientierung ist allerdings eine Eigenschaft, die so im Kopf der Mitarbeiter noch nicht verankert ist.

Stattdessen fragen sich Mitarbeiter immer noch häufig, weshalb nun alles digitalisiert werden muss, wenn die Nutzerzahlen nicht so hoch sind, die Einführung aber erhebliche Kosten verursacht? Der Kunde schließt sein Produkt doch viel lieber persönlich ab, als alles digital zu lösen."

„Wenn jetzt nicht der Schritt in Richtung Digitalisierung gewagt wird, wird man in Zukunft den Anschluss verloren haben, warnt Volker Neve von der Provinzial Nordwest. „Die Komplexität der Versicherungswirtschaft hat also auch Einfluss auf das breite Digitalisierungsangebot, das bis jetzt noch nicht in jeder Situation vom Kunden wahrgenommen werden kann. Und er fährt fort:

„Was heißt für uns agil? Das ist eine Frage, die sich die Versicherungswirtschaft stellen muss, um die richtigen Schritte nach vorne zu machen. Agiles Projektmanagement ist derzeit ein Begriff, der häufig verwendet wird. Aber noch längst nicht alle verstehen ihn. Das liegt besonders an den alten Systemen, die in den letzten 20 Jahren nicht erneuert wurden, wodurch ein Neuanfang schwierig scheint."

Die Folgen dieser Entwicklung sind bekannt.

In etlichen Versicherungsanwendungen werden auch heute noch heterogene Systemlandschaften für die unterschiedlichen Anwendungskomponenten angetroffen. Dies führt zu Daten- und Prozessredundanzen, die unterschiedliche Interpretationen und Fehlinformationen in der inner- und außerbetrieblichen Kommunikation zur Folge haben können.

Um die Versicherungsprodukte zu entwickeln, zu verwalten und die verkauften Produkte zu speichern, haben eine Reihe von Versicherungen auf Lösungen mit sogenannten ‚Produktmaschinen‘ zugegriffen. Diese bilden in der Regel keine technische Einheit mit den Verwaltungssystemen für die Verträge und Schäden, sondern wurden ‚von außen angeflanscht‘.

Wenn die Beiträge in den verschiedenen Spartenanwendungen auf unterschiedlichen Plattformen ermittelt werden, kann dies zu unterschiedlichen Ergebnissen mit sehr unangenehmen Konsequenzen führen. Ein einheitlicher Zugriff aus allen beteiligten Komponenten auf einen einheitlichen Rechenkern für alle Beitragsermittlungsprozesse, die in jeder Situation das richtige Ergebnis anzeigen, ist nur bei den wenigsten Gesellschaften zu finden.

Wenn die Schnittstellen zwischen dem Laptop im Außendienst, der Call-Center-Software und den Hostanwendungen im Backend auch heute noch nicht automatisch ablaufen, sondern noch ganz oder teilweise manuell abgewickelt werden müssen, ist auch dies ein Zeichen dafür, dass eine grundsätzlich neue Lösung für dieses Problem gefunden werden muss.

1.2.3 Wie ist es dazu gekommen?

In den letzten 25 Jahren hat es in der Verwaltung der zentralen IT-Bestände bei fast allen Versicherern nur wenige grundlegende Veränderungen gegeben. Diese Beobachtung kann mit Hilfe einiger wesentlicher Punkte begründet werden:

Im Jahr 1998 haben die Versicherer erkannt, dass sie ihre Host-Bestände für den Jahrtausendwechsel präparieren mussten. Die Angabe der Jahreszahlen, die in den alten Systemen in der Regel aus Platzgründen nur zweistellig gespeichert waren, musste um die Jahrhundertangabe auf vier Stellen erweitert werden. Das hat bis in das Jahr 2000 hinein alle verfügbaren Kräfte gebunden. Die Transformation gelang. Die IT-Bestandssysteme wurden in dieser Zeit jedoch nicht weiterentwickelt.

Im Jahr 2001 standen die Versicherer vor einer ganz ähnlichen Herausforderung. Durch politische Entscheidung wurde es notwendig, sämtliche Betragsfelder (auch in die historischen Bestände hinein!) auf den Euro umzurechnen und umzustellen. Auch wenn dies von den Gesellschaften überall bewältigt wurde, blieb bis in das Jahr 2002 hinein daneben kein zeitlicher Raum mehr für Neu- oder Weiterentwicklungen der vorhandenen IT-Systeme.

In den Jahren 2003 bis 2004 baute sich ausgehend von den USA eine dramatische Börsenblase auf. Da die Versicherer ihre Reserven und Rücklagen traditionell in börsennotierten Papieren hielten, führte dies bei den Vorständen aus Gründen der Vorsicht dazu, dass alle Pläne für Neu- oder Weiterentwicklungen in den IT-Anwendungen in dieser Zeitphase vorläufig auf Eis gelegt wurden.

Der eigentliche Gau trat dann aber (erst schleichend, dann immer dramatischer) ab dem Jahr 2005 ein: Die Notwendigkeit nach Kommunikation über das Internet wurde immer drängender. Die Forderung nach Digitalisierung wurde von allen Medien aufgegriffen. Nur wer sich dieser Herausforderung stellte und sich immer noch stellt, kann erfolgreich überleben. Alle IT-Kräfte waren mit der Lösung dieser Aufgaben gebunden. Für die Modernisierung der alten Host-Systeme blieb daneben keine Zeit.

Ausgehend vom Zusammenbruch der amerikanischen Bank Lehman Brothers kam es im Jahr 2008 zu den nächsten schweren Turbulenzen an den Finanzmärkten. Wieder kamen die Versicherer nicht dazu, sich um die Neuordnung ihrer inzwischen etwa zehn Jahre alten IT-Systeme zu kümmern.

In den vergangenen Jahren hat manch ein Versicherungsunternehmen einen Zusammenschluss mit einem anderen erlebt oder erlitten. Mit einer solchen Fusion sind in der Regel auch neue oder andersartige IT-Lösungen ins Haus gekommen. Nicht jeder Versicherer hat es zeitnah geschafft, diese Verschiedenheit zu konsolidieren. Eine Bereinigung in den Altsystemen hat häufig nicht in ausreichendem Umfang stattgefunden. Es gibt nach wie vor Versicherungskonzerne, die mehrere inhaltlich gleiche aber formal unterschiedliche Spartensysteme nebeneinander betreiben.

Mit dem Aufkommen von tragbaren PCs entstand die Notwendigkeit, intelligente vertriebsunterstützende Systeme dezentral für den Außendienst zur Verfügung zu stellen. Die Anbindung dieser Systeme, insbesondere der laufende Datentransfer von dort in die zentralen Host-Systeme, ist bis heute noch nicht bei allen Versicherern zu einem konsolidierten und zufriedenstellenden Abschluss gebracht worden.

Außerdem ist in den letzten zehn Jahren eine Entwicklung zu beobachten, die die IT-Landschaft bei vielen Versicherern noch einmal zusätzlich komplexer und komplizierter gemacht hat. Die Kommunikation mit den Kunden, den Interessenten, den Mitarbeitern im Vertrieb, den externen Dienstleistern und mit anderen Institutionen im Umfeld des Unternehmens werden inzwischen in zunehmendem Maße über das Internet abgewickelt. Daten werden über diese Schnittstelle ausgetauscht. Ein Versicherer, der dieser Herausforderung nicht rasch durch die Bereitstellung von Portalen begegnete, hatte im Wettbewerb plötzlich große Probleme. Häufig blieb gar nicht die Zeit, dafür eine konsolidierte und mit den Backend-Systemen kompatible Lösung bereitzustellen.

Durch diese Entwicklungen stand manch ein IT-Chef vor einem großen Problem: die Sicherstellung gleicher Ergebnisse bei der Beitragsberechnung in unterschiedlichen Systemen (PCs der Außendienstler, Client-Server-Lösung für das Callcenter und zentrale Host-Systeme für die ‚normale‘ Sachbearbeitung).

Es sind aber nicht nur die hier beschriebenen unternehmensinternen Gründe, die dazu geführt haben, dass die Stabilisierung des Neugeschäfts immer schwieriger wurde und wird. Auch im Markt haben sich in den letzten Jahren neue Strukturen und Formen des Angebots entwickelt, durch die die potenziellen Kunden immer besser informiert sind, bevor sie ein Gespräch über den Neuabschluss einer Versicherung oder die Änderung einer vorhandenen Geschäftsbeziehung suchen. Gemeint sind hier die vielfältigen Möglichkeiten, sich vor einem solchen Gespräch über Vergleichsportale schlau zu machen.

Bald wurde es allen Verantwortlichen klar, dass es sich hierbei um eine sehr kritische Entwicklung handelt. Öffnet man seine Datenbestände für eine direkte Kommunikation mit Kunden, Maklern, Vermittlern, anderen Versicherern, Dienstleistern usw. nach außen, öffnet man diese gleichzeitig auch ungewollt für sehr erfindungsreiche kriminelle Elemente (Stichwort ‚Cyber-Crime‘). In Folge dieser Erkenntnisse haben die Versicherer ihre IT-Bestände in der Regel zunächst einmal konsequent abgeschottet. An eine Weiterentwicklung der Alt-Systeme war wieder nicht zu denken.

Schließlich wurde und wird mancher Versicherer immer häufiger mit einem Phänomen konfrontiert, bei dem er nicht weiß, wie er sich verhalten soll: Die potenziellen Kunden sind durch die Auswertung der vielen verschiedenen Angebots- und Vergleichsportale im Internet in einem Maße über die Angebote der verschiedenen Versicherungsunternehmen informiert, wie es dies bisher noch nicht gegeben hat. Um bei diesen Herausforderungen den Anschluss im Markt nicht zu verlieren und die eigenen Daten zu schützen, entstanden ‚Girlanden‘ und ‚Balkone‘ um die vorhandenen Altbestände herum. Die IT wurde nicht zeitgemäß besser, sondern immer komplexer, immer schwieriger zu warten und damit auch anfälliger für Fehler.

Es liegt nahe, dass auch in diesen Zeiten (und hier befinden wir uns fast in der Gegenwart) an eine Weiterentwicklung der Altsysteme nicht zu denken war. Hier blieb es wie seit Jahren beim alten Stand. Für eine Neuordnung der inzwischen schon sehr alten Bestandssysteme fehlten die Zeit, die Entschlossenheit, der Mut und bald auch das Know-how.

Hinzu kamen neue Anforderungen aus der Politik und von der Aufsicht, die umgesetzt werden mussten. Dazu gehörten beispielsweise die Einführung von IDD und IDDS-2 oder des SEPA-Zahlungsverkehrs, was spätestens Ende August 2014 abgeschlossen sein musste.

Danach mussten sich die Versicherer rüsten, um die Anforderungen von Solvency II ab Januar 2016 zu erfüllen. Hier sind die Inhalte der zentralen IT-Kernsysteme betroffen. Es besteht also Handlungsbedarf, diese gründlich neu zu ordnen. Geschehen ist aber so gut wie nichts.

Schließlich steht die Versicherungswirtschaft vor einer weiteren Herausforderung, die nicht nur die Kommunikation nach außen, sondern unmittelbar auch den Bestand der in den Datenbanken gespeicherten Informationen betrifft: die Forderung nach der digitalen Transformation der Versicherungsbranche.

Es gibt sicher keine IT-Anwendungslandschaft bei einem konkreten Versicherer, die alle hier skizzierten Schwachstellen aufweist. Die Ist-Situation sieht überall anders aus. Aber überall findet man Teile oder einzelne Aspekte, die mit den hier aufgezeigten Problemen zutreffend beschrieben sind.

Als Fazit kann man feststellen, dass es bei fast allen Versicherungsunternehmen in den rund 20 Jahren zwischen 1999 und 2018 kaum Weiterentwicklungen bei den zentralen IT-Systemen gegeben hat. Sowohl die Daten als auch die Prozesse sind in hohem Maße veraltet und heute nicht mehr ‚State of the Art‘.

1.2.4 Wie geht es weiter? Was ist zu tun?

In den veröffentlichten Äußerungen von wirklichen Sachkennern mehren sich die Stimmen, die immer intensiver anmahnen, dass die Versicherer das Problem der Erneuerung ihren zentralen Bestandssysteme nach zwanzig und mehr Jahren nicht mehr länger aufschieben können.

Auch der interne Leidensdruck in den Gesellschaften wird immer größer. Es setzt sich schmerzhafte die Erkenntnis durch, dass die alten Host-Bestände in eine zeitgemäße Form überführt werden müssen.

Dafür muss eine neue Enterprise-Architect-Plattform errichtet oder erworben und eingeführt werden, auf der eine neue IT-Landschaft erstellt werden kann.

Da es unverzichtbar ist, dass eine solche neue Lösung inhaltlich nahtlos die vorhandenen Bestände einschließlich ihrer Historien fortschreiben bzw. weiterführen muss, muss untersucht und dokumentiert werden, an welchen Stellen in welchen Dateien welche Informationen in den Altsystemen gespeichert vorliegen und wie diese auf ein neues System überführt werden können.

Um diese neue Lösung in einer zeitgemäßen Form zu entwickeln, sollte diese auf der Basis eines zeitgemäßen, redundanzfreien, objektorientiert gestalteten Daten- und Prozessmodells geschaffen werden.

Die neuen Prozesse sollten so konzipiert werden, dass sie ‚on the fly‘ an die gegenwärtigen und alle zukünftigen Anforderungen angepasst werden können. Als Grundlage dafür sollte ein geeignetes, agil einsetzbares Prozessmodell genutzt werden.

Die dort abgebildeten Prozesse müssen auch ‚Ausflüge‘ oder ‚Umwege‘ außerhalb des Unternehmens zulassen, ohne dass diese unterbrochen werden.

Um diesen Prozess abzusichern, sollte diese Transformation auf der Basis eines bewährten Vorgehensmodells ausgeführt werden.

Die neuen Anwendungen sollten wegen der Reduktion der Komplexität im laufenden Betrieb nicht mehr als 50 Prozent der bisher dafür benötigten Aufwendungen kosten.

Die hier beschriebenen Gedanken kann man zusammenfassend so darstellen:

Es gibt sicher keine IT-Anwendungslandschaft, die alle hier skizzierten Schwachstellen aufweist. Die Ist-Situation sieht bei jedem Versicherer anders aus. Aber überall findet man Teile oder einzelne Aspekte, die mit den hier aufgezeigten Problemen zutreffend beschrieben sind.

Offensichtlich besteht in den Versicherungsunternehmen ein elementarer Bedarf,

die zentralen IT-Systeme zu konsolidieren,

die Verwaltungssysteme für Produktentwicklung, Versicherungsvertragsverwaltung und Schadenmanagement auf eine zeitgemäße Basis zu stellen,

die Kosten für die Entwicklung und der Betrieb der IT signifikant zu senken,

die Auswüchse in den vorhandenen Anwendungen zu beschneiden,

die verfügbaren Anwendungen agiler und flexibler zu machen und

auf Anforderungen und Wünsche rascher reagieren zu können.

Natürlich besteht auch immer der Wunsch, die Aufwendungen für die Wartung und Weiterentwicklung der IT-Systeme in finanzieller, personeller und zeitlicher Hinsicht zu reduzieren.

Auf die Frage, wie diese Anforderungen in Zukunft gelöst werden können, gibt es keine einfache Antwort. Eines ist jedoch in jedem Fall hilfreich: Die Versicherer müssen sich auf neue Konzepte stützen, die ihnen helfen, diese Ziele zu erreichen. Dabei stehen zwei Ansätze im Vordergrund:

Die IT-Entwicklung für die nächsten Projekte sollte sich an den Regeln für serviceorientierte Architekturen (SOA) orientieren.

Die Informationsverwaltung sollte durch den Einsatz und auf der Basis eines übergreifenden und nach den Regeln der Objektorientierung gestalteten einheitlichen Daten- und Prozessmodells konsolidiert werden.

Wird eine solche Aufgabe begonnen, muss ein Projekt organisiert werden, das professionell geführt wird und den Vorstand unmittelbar mit einschließt. Da ein solches Projekt von erheblichem Umfang und beachtlicher Dauer ist, müssen die Projektfortschritte laufend und detailliert dokumentiert sowie im ganzen Unternehmen regelmäßig kommuniziert und diskutiert werden.

Darüber hinaus muss das Projektteam für Rückfragen aus den Fachabteilungen über den jeweiligen Stand der einzelnen Projektschritte jederzeit zur Verfügung stehen. Dieses Diskussionsforum muss explizit organisiert werden.

Zu diesen Gedanken passt eine Meldung, die vor einiger Zeit in der Öffentlichkeit bekannt wurde. Die ‚Vienna Insurance Group‘ hat berichtet dass sie im dritten Quartal 2015 eine Wertberichtigung auf ihre IT-Systeme von über 195 Mio. Euro vorgenommen habe. Zur Begründung wird angegeben, dass aufgrund einer Analyse mit hoher Wahrscheinlichkeit davon auszugehen sei, dass bestimmte IT-Systeme bzw. Programmteile nicht mehr vollumfassend die erforderlichen und nötigen Anforderungen erfüllen würden. Dies betreffe die Anforderungen sowohl in fachlicher als auch in technischer Hinsicht (vgl. o. V. 2015).

1.2.5 Daten- und Prozessmodell von Asskura als neue Basis

Um die aufgezeigte Problematik zu bewältigen, sollte sich ein Anwender Hilfe von außen holen. Eine Möglichkeit dafür ist, auf das Asskura-Daten- und Prozessmodell zurückzugreifen. Es umfasst alle Sparten, die von privaten Erstversicherungsunternehmen betrieben werden, also Komposit-, private Kranken-, Lebens- und Rechtsschutzversicherungen.

Diese Abgrenzung besagt, dass zwei weitere Arten von Versicherungsunternehmen nicht Gegenstand des Asskura-Daten- und Prozessmodell und damit auch nicht Gegenstand der hier vorgestellten Lösungen sein werden: Unternehmen, die die aktiven Rückversicherung betreiben und Versicherer, die nicht privat, sondern öffentlich-rechtlich organisiert sind, wie die gesetzlichen Kranken-, Pflege-, Renten-, Unfall- und sonstigen öffentlich-rechtlichen Versicherungen.

Als weitere Abgrenzung gilt, dass im Asskura-Modell nur die versicherungstechnischen Komponenten eines privaten Erstversicherungsunternehmens beschrieben werden. Letztere grenzen sich von den nichtversicherungstechnischen Komponenten wie die für die allgemeinen Verwaltungsfunktionen, das Rechnungs- und Personalwesen und der Kapital- und Vermögensverwaltung ab. Letztere sind nicht Gegenstände der hier genachten Ausführungen.

Positiv ausgedrückt umfasst das Asskura-Modell alle Daten und Prozesse, die die verschiedenen Fachbereiche benötigen, um ihre Arbeit zu erledigen:

Versicherungsprodukte entwickeln,

diese im Markt verkaufen und im Bestand verwalten,

daraufhin erhobene Schadensersatzansprüche bearbeiten,

die gezeichneten Risiken nach den hauseigenen Annahmeregeln diversifizieren,

den Partnerbestand pflegen,

die vielfältigen Bedingungen, Richtlinien und Vorlagen bearbeiten,

die Sachbearbeiter-Berechtigungen verwalten,

die Verkaufsorganisation einrichten und pflegen,

alle erforderlichen öffentliche Informationen auswerten,

die benötigten Statistiken erstellen sowie

die Informationen vom und zum GDV bearbeiten.

Durch das Domänenkonzept und die Redundanzfreiheit, die bei der Entwicklung des Asskura-Modells die maßgeblichen Gestaltungsregeln waren, lässt sich jede Anforderung für eine neue Anwendung problemlos der zutreffenden Domäne zuordnen. So lässt sich beispielsweise beschreiben, an welcher Stelle im Gesamtsystem die Produktentwicklung durchgeführt und wo die Verwaltung der verkauften Produkte stattfindet usw. Auf dem gleichem Weg lassen sich beispielsweise die Komponenten Vertrags-, Produkt- und Versicherungsverwaltung oder die Schadenbestandsführung einordnen, voneinander abgrenzen und in Beziehung zueinander setzen.

1.2.6 Zu erreichende Ziele

Mit dem Einsatz des Daten- und Prozessmodells von Asskura wird der Anwender in die Lage versetzt, seine zentralen IT-Systeme auf einen Stand zu bringen, der den Anforderungen der heutigen Zeit genügt.

Die Form, die Technik, der Aufbau und die Durchführung der Datenhaltung und der Prozessgestaltung sind danach so organisiert, dass damit alle heutigen Anforderungen an die Agilität und Flexibilität der neuen IT-Anwendungen und auch die aus der Digitalisierung zeitnah, kostengünstig und fehlerfrei erfüllt werden können.

Es werden sichere Portale für den Vertrieb, für die Kunden, für die Versicherungspartner und für alle anderen berechtigten Personen und Institutionen bereitgestellt.

Es wird eine Vorgehensweise beschrieben, die sicherstellt, dass die digitale Transformation gelingt.

Die Regeln für das Zusammenspiel von Service-Provider und Service-Consumer werden unmissverständlich vermittelt.

Es wird aufgezeigt, wie Angriffe von außen durch Hacker abgewendet werden, wenn das Geschäftsmodell in Bezug auf den digitalen Wandel nach den beschriebenen Regeln erweitert worden ist.

Es wird beschrieben, wie die Führungskräfte und die Mitarbeiter neben dem laufenden Tagesgeschäft die Entwicklung in die neue digitale Welt schaffen.

Es wird erläutert, wie die IT zukunftsfest gemacht wird, welche Hilfen von außen dabei zur Verfügung stehen und wo diese zu finden sind.

Man kann auch sagen: Es wird eine anwenderspezifischen Individuallösung entwickelt, die auf einer bewährten Basislösung beruht. Auf einer weitgehend fachlich ausformulierten Plattform kann aufgrund des objektorientierten Designs eine perfekte individuelle Lösung entwickelt werden. Und dies gelingt mit der Mannschaft, die bereits heute im Haus des Anwenders vorhanden ist.

1.2.7 SOA als neues Organisationsparadigma

1.2.7.1 Das Asskura-Modell als serviceorientierte Architektur

Der Begriff ‚serviceorientierte Architektur‘ (SOA) steht für ein Architekturprinzip, das alle heute bekannten Anforderungen an eine zeitgemäße Organisation erfüllt.

Die Bezeichnung ‚SOA‘ wurde kurz vor der Jahrtausendwende erstmals von der Firma Gardner eingeführt und verwendet. Nach OASIS (2006) ist ‚SOA ein Paradigma für die Strukturierung und die Nutzung verteilter Funktionalität, die von unterschiedlichen Anwendern genutzt wird oder genutzt werden kann‘.

SOA ist ein Kind von UML und BPMN.

Am besten nähert man sich der Erklärung von SOA an, wenn man den Sinn der zwei Wortteile ‚Architektur‘ und ‚Service‘ betrachtet:

Eine Architektur ist ein Bauplan oder eine Konstruktionszeichnung. Sie setzt sich aus grafischen Elementen zusammen und zeigt die Beziehungen zwischen diesen Elementen auf. Sie stellt in der Entwicklung das statische Element dar.

Ein Service ist die Beschreibung einer Leistung, die von einem Service-Provider (dem Lieferanten der Leistung) für einen Service-Consumer (den Nutzer dieser Leistung) erbracht wird. Sie stellt in der Entwicklung das dynamische Element dar.

Das Asskura-Modell ist die explizite Beschreibung einer solchen serviceorientierten Architektur (SOA). Sie wurde als einheitliches Konstrukt für alle Formen der Versicherungstechnik von Erstversicherungsunternehmen gestaltet. Man spricht hier auch von einer‚ Enterprise-Architektur‘.

Auf das Asskura-Modell anwendet heißt das, dass es sich dabei um eine große und vielschichtige SOA handelt. Dabei beschreiben das Asskura-Datenmodell die statische Architektur und das Asskura-Prozessmodell die dynamischen Services.

1.2.7.2 Grundlegende Eigenschaften einer SOA

Das Asskura-Modell bzw. die auf der Basis dieses Modells entstehende Anwendungslandschaft besitzt alle Eigenschaften einer SOA. Sie weist alle Elemente von Agilität und Flexibilität auf.

Dies wird durch folgende Eigenschaften belegt:

In einer SOA werden die großen und komplexen Systeme in Anwendungsfrontends und Services zerlegt.

Die hohe Granularität der Services bewirkt, dass das gesamte System besser verstanden wird.

Eine SOA kann auch ohne genaue Kenntnisse der angewendeten Technologie begriffen werden.

Eine SOA ermöglicht die Wiederverwendbarkeit vorhandener Komponenten.

Jeder Service ist für sich dokumentiert. Dies unterstützt die Verständlichkeit der SOA und ihrer einzelnen Elemente.

Das Organisationsprinzip von SOA ermöglicht es, dass die Elemente einer SOA ebenfalls verteilt in das Unternehmen implementiert werden können. In einer SOA werden die Technologie, die Prozesse, die Geschäftsregeln und die Daten voneinander entkoppelt. Wenn eine dieser Komponenten veraltet, kann sie durch eine neue oder aktuelle ersetzt werden, ohne dass dadurch die anderen Komponenten in ihrem Kern berührt werden.

Eine SOA bietet Richtlinien für die Schnittstellendefinitionen und vereinfacht die Arbeit, sie zu realisieren. Das Projektmanagement