1

Prozessmodellierung 2.0

Inhalt

Die dritte Säule der Informationsverarbeitung ....................................................... 2

Methoden der Geschäftsprozessmodellierung ...................................................... 2

Grundfragen der Prozessmodellierung .................................................................... 2

Visualisierung der Prozesse (Visio / EPK / BPEL) ................................................... 3

Granualisierung der Prozesse ................................................................................. 3

Prozessmodellierung mit BPMN .............................................................................. 4

Dialog- und Batchprozesse ..................................................................................... 4

Der Weg zu einer einheitlichen Versicherungs-Prozesslandkarte ....................... 5

Der (dornige) Weg dorthin ....................................................................................... 5

Bestimmungsfaktoren einer unternehmensübergreifenden Prozesslandkarte ........ 6

Versicherungstechnische End-to-End-Prozesse ..................................................... 7

Ausmaß einer Prozesssequenz............................................................................... 8

Die Theorie der Versicherungsprozesse ................................................................ 9

Entwicklung der Prozesslandkarte ......................................................................... 9

Graphik der Prozesslandkarte ............................................................................... 10

Von der Prozessdomäne zur Prozesssequenz...................................................... 11

Erkenntnisse im Verlauf der Entwicklung von Prozessmodellierung 2.0 .......... 16

2

Die dritte Säule der Informationsverarbeitung Um den Stellenwert der Prozessmodellierung für Versicherungsunternehmen in der aktuellen Situation richtig einschätzen zu können, macht es Sinn, zunächst einmal einen Blick zurück zu werfen und die Frage zu stellen, wie alles begann. Das Thema ‚Prozessmodellierung‘ ist in den Versicherungsunternehmen so alt wie die IT im Dialogbetrieb. Mit der Ablösung der Belegerfassung Anfang der 70-er Jahre des vergangenen Jahrhunderts begann zunächst eine mehr statische Phase, als die Bildschirme nur zu Auskunftszwecken zur Verfügung standen. Aber bereits wenige Jahre später wurde das Frontend intelligent. Dem Sachbearbeiter wurde die Möglichkeit eingeräumt, auch (die Bestände ändernde) Daten zu erfassen und sich damit vom Papier als Eingabemedium zu verabschieden. Damit begann die Zeit der Prozessmodellierung als wichtige neue Aufgabe der IT. Sie entwickelte sich neben der Daten- bzw. Informationsmodellierung und neben dem Rechenzentrums-Betrieb, als der operativen Zentrale der IT, als dritte zentrale Säule im Bereich der Informationsverarbeitung und -verwaltung eines jeden Versicherungsunternehmens.

Methoden der Geschäftsprozessmodellierung

Grundfragen der Prozessmodellierung

Seitdem sich Menschen mit dem Thema der Modellierung der Geschäftsprozesse befassen, steht eine Form der Prozessentwicklung und -gestaltung ganz im Vordergrund: die graphische Darstellung der Prozesse. Die Gründe dafür sind, dass durch eine solche Visualisierung die Übersichtlichkeit und Verständlichkeit der Prozesse in hohem Maße unterstützt wird. Auch verbessert eine solche Darstellung die Möglichkeit, einen neuen oder geänderten Prozessablauf einem Dritten leichter verständlich zu erklären. Eine der Kernfragen, die bereits ganz am Anfang dieser Phase beantwortet werden musste, lautete:

Bestimmen die erkannten und festgelegten Prozessschritte den Arbeitsablauf oder ist es eher umgekehrt, dass die natürlichen Gegebenheiten im Fortschritt der Bearbeitung darüber entscheiden, wie ein bestimmter Prozess dokumentiert werden soll? bzw.

Sind es bestimmte jeweils zu erreichende Arbeitsergebnisse, mit denen der Prozessverlauf Schritt für Schritt dokumentiert wird oder werden die im Ablauf nacheinander zu erledigenden Arbeiten oder Tätigkeiten beschrieben, die zusammengenommen am Schluss das gewünschte Arbeitsergebnis hervorbringen? bzw.

Besteht eine Prozessbeschreibung aus der Summe der Ergebnisse der einzelnen Arbeitsschritte, die im Prozessverlauf Schritt für Schritt erreicht werden sollen oder besteht sie aus der Beschreibung der zu erledigen Arbeiten, die am Ende dazu führen, dass sich das angestrebte Ergebnis auch tatsächlich wie gewünscht einstellt? bzw. noch kürzer:

Erfolgt die Prozessbeschreibung entlang der Knoten oder entlang der Graphen des Prozesses?

3

Visualisierung der Prozesse (Visio / EPK / BPEL)

Egal, welchen dieser Wege man einschlug, am Anfang aller dieser Bemühungen, Geschäftsprozesse zu beschreiben, stand die stillschweigende aber auch unbestrittene Übereinkunft, dass der Königsweg zur Prozessmodellierung über die graphische Darstellung führt. Dabei hat man ganz zu Beginn entweder horizontal oder vertikal freihändig gezeichnet. Das erste ernstzunehmende Tool, mit denen Geschäftsprozesse modelliert werden konnten, war Visio, ein Produkt aus dem Office-Paket von Microsoft. Aufgrund seiner Herkunft war (und ist) es prädestiniert dafür, dass es kompatibel mit den anderen Office-Produkten eingesetzt bzw. verwendet werden konnte. Bei diesem Tool steht unterstützt durch vorgefertigte Graphikelemente noch die Arbeit des Zeichnens im Vordergrund. Anfang der 90-er Jahre entwickelte dann Prof. August-Wilhelm Scheer an der Universität des Saarlands ein Prozess-Modellierungstool, das unter dem Namen ‚Aris-Toolset‘ in den letzten 20 Jahren die Prozessmodellierung beherrschte und zurzeit von der Software AG in Darmstadt betreut wird. Schon die Zusatzbezeichnung ‚Ereignisgesteuerte Prozesskette (EPK)‘ für dieses Tool zeigt an, dass die Verknüpfung von Ereignissen, die in einem Prozess auftreten, das Wesen dieser Modellierung ausmachen. Kurz nach der Jahrtausendwende brachte IBM mit WS-BPEL (Web Services Business Process Execution Language) dann ein Tool heraus, mit dem ähnlich wie bei der EPK von IDS-Scheer Ereignisse, die im Verlauf eines Prozesses bearbeitet werden sollten mit ihren ausführenden Akteuren im Ablauf beschrieben werden. Der Mehrwert dieses Tools lag und liegt darin, dass von hier aus der Einstieg in die programmtechnische Umsetzung der modellierten Prozesse unterstützt wird, wobei Web-Services die entscheidende Rolle spielen.

Granualisierung der Prozesse

Alle diese Ansätze haben eines gemeinsam: In ihnen wird ein Geschäftsprozess zwischen einem definierten Anfang und einem ebenso definierten Ende beschrieben. Wie lang bzw. wie umfangreich sich ein solcher Prozess ausdehnt, war und ist dem Bearbeiter überlassen. Es gibt keine Regeln, zum Beispiel über den Umfang oder die optimale Anzahl der einzelnen Schritte, in einem so modellierten Prozess. Das hat zur Folge, dass in dem Bemühen, möglichst vollständig zu sein, häufig sehr umfangreiche oder ‚lange‘ Prozesse und auch Prozessketten modelliert wurden. Scherzhafterweise spricht man auch von ‚Spaghetti-Prozessen‘. Die Folge davon ist, dass viele dieser Arbeiten heute als ‚Schrank-Ware‘ ein mehr stiefmütterliches Dasein fristen und nur noch zu Demo-Zwecken hin und wieder herausgeholt werden. Um Prozesse handhabbar zu machen, um sie nicht nur leichter zu verstehen, sondern auch einfacher programmtechnisch umsetzen zu können, müssen sie in überschaubare logisch begründete Abschnitte aufgeteilt oder zerlegt werden, die lose miteinander verbunden einen Geschäftsprozess ausmachen. Dafür bildete sich später der Begriff der ‚Orchestrierung‘ heraus.

4

Vor allem muss gerade in Zeiten von Solvency-II jeder modellierte und realisierte Prozess mit dem geringstmöglichen Aufwand an neue Anforderungen angepasst werden können. Die überragenden Stichworte lauten hier Agilität und Flexibilität. Nur wenn es einem Versicherer gelingt, neue Anforderungen in kürzester Zeit in seinen IT-Prozessen abbilden zu können, wird er zukünftig den Herausforderungen im Wettbewerb standhalten. Diese Flexibilität macht sich auf der eine Seite an der Art der Gliederung und Zusammenstellung der Daten in ihren Domänen, vor allem aber an der Methode der Prozessmodellierung fest. Diese Ziele waren weder mit den Mitteln von EPK noch mit BPEL erreichbar. Dafür musste eine neue Methode ersonnen und in Gebrauch genommen werden.

Prozessmodellierung mit BPMN

BPMN steht für ‘Business Process Model and Notation’. Die Methode wurde ab 2001 durch den IBM-Mitarbeiter Stephen A. White erarbeitet, 2004 von der Business Process Management Initiative (BPMI) veröffentlicht und im Juni 2005 durch die Object Management Group (OMG) zur weiteren Pflege übernommen. BPMN ist das derzeit am weitesten verbreitete Modellierungstool für Geschäftsprozesse. Auch hierbei handelt es sich um eine graphische Notation. Es werden vor allem fünf Formen von Modellierungselementen mit unterschiedlichen Varianten verwendet:

Die Aktivitäten,

die Events,

die Gateways,

die Sequence- und

die Message-Flows. Werden in einem modellierten Prozess mehr als eine Person als Actor angesprochen, können diese zusätzlich in unterschiedlichen Swimlanes untergebracht werden. Mit der Veröffentlichung der Version 2.0 im März 2011 zeigt BPMN erste Schritte zu einer XMI- Kompatibilität auf, die es in kurzer Zeit ermöglichen soll, BPMN-Prozesse durch eine Form von Reverse Engineering bis zur Code-Generierung voranzutreiben. Wenn dieses Ziel erreicht werden kann, dürfte sich BPMN als das führende Prozessmodellierungstool etablieren. Asskura hat die Prozesssequenzen in ihrem Prozessmodell auf der Plattform ‚Enterprise Architect‘ der Firme Sparx Systems mit der Version BPMN 2.0 modelliert.

Dialog- und Batchprozesse

Wenn man von Geschäftsprozessen spricht, denkt man primär an die Dialogprozesse, die von einem Sachbearbeiter initiiert und abgeschlossen werden. In Zeiten, in denen in der Diskussion in den Versicherungsgesellschaften immer häufiger über die ‚Industrialisierung‘ der Geschäftsprozesse nachgedacht wird, wird die Anzahl der Prozesse, die zum Beispiel über ein Terminsystem oder durch Anstöße von außen (vom Kunden, vom Anspruchsteller, von einem Anwalt oder von einem sonstigen Dienstleister usw.) angestoßen werden und danach ohne Eingriff eines Sachbearbeiters im Batch ablaufen, immer zahlreicher.

5

Auch diese Batch-Prozesse müssen nach denselben Regeln modelliert werden, wie die zunächst diskutierten Dialog-Prozesse.

Der Weg zu einer einheitlichen Versicherungs-Prozesslandkarte

Der (dornige) Weg dorthin

Erhält ein fachlich qualifizierter externer Berater die Aufgabe, alle Geschäftsprozesse, die von den Sachbearbeitern in einem Versicherungsunternehmen ausgeführt werden, systematisch zusammenzutragen und zu dokumentieren, wird er sich in einem ersten Schritt der Ist-Aufnahme ansehen, welche Prozesse die Sachbearbeiter ausführen. Im zweiten Schritt wird er ein passendes Tool auswählen, um die aufgenommenen Prozesse zu dokumentieren und in einem dritten Schritt wird er das Ergebnis kritisch daraufhin untersuchen, wie er Verbesserungsmöglichkeiten an den Prozessen auffinden und vorschlagen kann. Wird derselbe Berater in einem anderen Versicherungsunternehmen mit derselben Aufgabe betraut und vergleicht man am Ende die beiden Ergebnisse, wird man feststellen, dass in der zweiten Untersuchung ein ganz anderes Ergebnis herausgekommen ist, als in der ersten. Die Prozesse bei zwei verschiedenen Versicherern sind offensichtlich unterschiedlich. Woran liegt das? Wie soll man auf diesem Weg zu einer einheitlichen Versicherungs-Prozesslandkarte kommen? Die Gründe für diese unterschiedlichen Ergebnisse liegen aber auf der Hand. Wir haben sie bereits in unserem achten Newsletter beschrieben, den wir am 15.10.2015 unter dem Titel ‚Grundstrukturen eines versicherungsfachlichen Prozessmodells‘ veröffentlich haben. Die Gründe lauten:

Handelt es sich um ein kleines oder mittleres Unternehmen, ist die Spezialisierung der Mitarbeiter nicht so stark ausgeprägt, wie bei den großen Versicherern. Die Prozesse in kleinen oder mittleren Unternehmen sind in der Regel viel kompakter und komplexer, als bei großen Versicherern.

Das gleiche gilt, wenn ein Versicherer nur regional aufgestellt ist oder sein Geschäft in der gesamten Republik oder aber auch darüber hinaus betreibt. Jede dieser beiden Formen erfordert unterschiedliche Prozesse.

Ist ein Versicherer zentralisiert aufgestellt und hat er in der Fläche im Markt nur Vertriebsstützpunkte, sehen die bei ihm ablaufenden Prozesse ganz anders aus, als bei einem Versicherer, der die Verwaltung der Versicherungsverträge und das Schadenmanagement ganz oder zum Teil auch in dezentrale Geschäftsstellen ausgelagert hat.

Wenn der Außendienst ‚vor Ort‘ das Recht hat, für neue Risiken Deckungszusagen abzugeben und/oder gemeldete Schäden ganz oder teilweise bereits ‚vor Ort‘ zu regulieren oder zumindest Regulierungszusagen zu erteilen, sind die Prozesse von denen verschieden, in denen die Außendienst-Mitarbeiter diese Kompetenzen nicht haben.

Ist ein Versicherer dezentral aufgestellt, ist die Gestaltung der Geschäftsprozesse auch davon abhängig, welche Aufgaben mit welchen Zuständigkeiten von den Geschäftsstellen und welche zentral bearbeitet

6

werden (Bestandsführung, Schadenbearbeitung, Inkasso usw.). Je nach beobachtetem Erfolg (oder Misserfolg) wird diese Verteilung im Zeitablauf mal in die eine, mal in die andere Richtung verändert. Das muss über die vorhandenen Prozesse jeweils abgebildet werden können.

Bei den VU’s ist Im Zeitablauf regelmäßig eine wellenförmige Entwicklung zu beobachten: Phasen einer spartenorientierten werden von Phasen einer kundenorientierten Ausrichtung der Mitarbeiter abgelöst und umgekehrt. Jede dieser Phasen wird durch unterschiedliche Ausprägungen der Geschäftsprozesse charakterisiert und führt zu deren Veränderung.

Sei es in den Selbsteinschätzungen der Mitarbeiter begründet oder durch Vorlieben von Vorgesetzten ausgelöst: das Ausmaß der Delegation von Entscheidungskompetenzen und Verantwortung ist von Unternehmen zu Unternehmen unterschiedlich und führt zwangsläufig auch zu unterschiedlich ausgeprägten Prozessen.

Bemüht sich ein Versicherer mit mehr oder weniger großem Erfolg, die laufenden Geschäftsprozesse gemäß industriellen Fertigungsverfahren zu reorganisieren, sind dafür ganz eigene Prozesse im Unternehmen einzuführen. Diese sind mit dem vorhandenen Prozessmodell in der Regel nicht zu bewältigen.

Eines macht diese Übersicht für alle Versicherer deutlich: Es muss möglich sein, die Geschäftsprozesse, die die Sachbearbeiter ausführen, agil und flexibel an diese sich ständig ändernden Bedingungen anzupassen.

Bestimmungsfaktoren einer unternehmensübergreifenden Prozesslandkarte

Auf der Suche nach dem Weg, wie man die Gemeinsamkeiten für eine Prozessmodellierung für alle unterschiedlichen Versicherer findet, muss man sich offensichtlich von der Beobachtung eines einzelnen Versicherungsunternehmens lösen. Auf der anderen Seiten kann festgestellt werden, dass es solche übergreifend anwendungsfähigen Strukturen geben muss, denn eines ist bei allen Versicherern gleich: Sie entwickeln, verkaufen und verwalten alle dasselbe Produkt, nämlich Versicherungsschutz für die unterschiedlichsten versicherten Objekte in den verschiedensten Versicherungssparten in den von den Kunden gewünschten Umfängen. Wenn man nach solchen Bestimmungsfaktoren sucht, kommt man am ehesten zum Ziel, wenn man danach sucht, was alle diese Versicherer beherrschen müssen. Das sind auf der einen Seite die sogenannten End-to-End-Prozesse. Diese müssen alle Versicherer mit ihren Prozessen, in welcher Form und Ausprägung auch immer, bearbeiten können. Diese End-to-End-Prozesse müssen auf der anderen Seite in eine Ordnung gebracht werden, die auf jeden Versicherer angewandt werden kann. Das Grundschema für eine solche Darstellung ist die Unterscheidung nach fachlichen und technischen Kernprozessen sowie technischen Hilfsprozessen. Als nächstes ist darunter eine Ebene der Teilprozesse 1. Ordnung, darunter eine Ebene der Teilprozesse 2. Ordnung und darunter als tiefste Ebene die der

7

Prozesssequenzen, als kleinste Abschnitte eines jeden Geschäftsprozesses, anzuordnen.

Versicherungstechnische End-to-End-Prozesse

‚End-to-End‘ sind die Prozesse, die • durch einen Anlass von außen oder (zum Beispiel durch den Eintritt eines

Termins oder durch die Willensentscheidung einer einzelnen Person) im Unternehmen selbst ohne unmittelbaren Bezug zu einem vorauslaufenden Prozess ausgelöst werden (mittelbare Bezüge gibt es schon),

• in der Regel einen neuen Zustand in einem der Datenbestände des Versicherers herbeiführen,

• von einem oder mehreren Mitarbeitern des Versicherers aufgenommen, • über eine oder mehrere Bearbeitungsstufen hinweg ausgeführt und • soweit zu Ende bearbeitet werden, dass der auslösende Anlass oder Anstoß

damit erledigt ist und zu den Akten gelegt werden kann. Wenn man gemäß dieser Definition die Versicherungsprozesse untersucht, kann man (in alphabetischer Reihenfolge) die 26 nachstehend aufgeführten End-to-End-Prozesse erkennen (bei weiterem Nachdenken können es auch noch ein paar mehr werden):

1. Adressdoubletten im Adressbestand ermitteln und bereinigen 2. Angebote für ein Versicherungsprodukt zielgruppengerecht entwickeln 3. Anforderungen der Aufsicht erfüllen 4. Anforderungen des Managements erfüllen 5. Auffällige Vorkommnisse an das HIS melden 6. Auffällige Vorkommnisse vom HIS bearbeiten 7. Beteiligungsgeschäft erfassen 8. Dokumentenvorlagen verwalten (z.B. Textkonserven erfassen) 9. Gemeldete Geldeingänge bearbeiten 10. Gerichtsprozesse erfassen 11. Inkasso verwalten (z.B. Mahnfristen und Mahngebühren eingeben) 12. Liquiditätsdisposition unterstützen (z.B. Kontolimite einpflegen) 13. Passive Rückversicherungen abschließen 14. Partner im Adressbestand erfassen und ändern 15. Sachbearbeiter im Zugangssystem erfassen und pflegen 16. Schadenbearbeitung managen (z.B. Bewertungs-Richtlinien erfassen) 17. Schadenereignisse erfassen 18. Schadensersatzforderungen bearbeiten 19. Terminvorlagen bearbeiten 20. Freizugebende Vorgänge freigeben 21. Vergleichsportale auf Versicherungsangebote überprüfen 22. Verkaufsorganisation (angestellt und frei) verwalten 23. Veröffentlichte Meinung (Presse, Funk, Fernsehen) auswerten 24. Versicherungsbearbeitung managen (z.B. Annahmerichtlinien erfassen) 25. Versicherungsbetrieb einrichten 26. Versicherungsprodukte entwickeln, verwalten und verkaufen

Über diese Prozesse wird das gesamte Versicherungsgeschäft abgewickelt. Es ist deutlich erkennbar, dass es sich dabei um Prozesse sehr unterschiedlichen Umfangs handelt. Aber: Jeder Teilprozess, der in einem Versicherungsunternehmen

8

ausgeführt wird, ist entweder einer dieser End-to-End-Prozesse oder ein Ausschnitt oder ein Teil von einem solchen.

Ausmaß einer Prozesssequenz

Wenn an anderer Stelle dieses Artikels etwas sarkastische von den in der Vergangenheit häufig anzutreffenden ‚Spaghetti-Prozessen‘ gesprochen wurde, stellt sich die Frage, wie umfangreich diese kleinsten Abschnitte von Geschäftsprozesses, eben die Prozesssequenzen, in einem Prozessmodell sein sollten, das in die heutige Zeit passt. Dafür lassen sich keine festen Regeln aufstellen. Es gibt aber einige Hinweise, die dem Modellierer helfen, erfolgreich zum Ziel zu gelangen:

Eine Prozesssequenz umfasst alle Prozessschritte in chronologischer Reihenfolge, die, bestimmt durch die Fachlichkeit, die kleinste Einheit darstellen, um einen merkbaren, ggf. auch messbaren, fachlichen Prozessfortschritt zu erreichen.

Die Prozessschritte, die in einer solchen Prozesssequenz zusammengefasst werden, müssen fachlich unmittelbar zusammengehören.

Soll in einer Prozesssequenz ein Prozessschritt eingebunden werden, der in einem anderen fachlichen Zusammenhang auch als eigenständige Prozesssequenz benötigt wird, muss dieser in jedem Fall separat modelliert werden.

Die Prozesssequenzen müssen mit ihrem Start- und ihrem End-Event so ‚geschnitten‘ werden, dass sie im Verlauf eines Geschäftsprozesses nahtlos aneinander gereiht bzw. orchestriert werden können.

Eine optimale Lösung ist dann erreicht, wenn die Zusammenstellung (die Orchestrierung) der Prozesssequenzen im Verlauf eines Geschäftsprozesses ‚on the fly‘ erfolgen kann.

Diese Aussagen sollen an einigen Beispielen erläutert werden: Prozesssequenz ‚Eine natürliche Person zu einem Partner zuordnen‘ besteht aus folgenden Prozessschritten:

Gewünschte Entität ‚Partner‘ aufsuchen

Prüfen, ob die Entität ‚natürliche Person‘ bereits zugeordnet ist

Ggf. eine neue Entität ‚natürliche Person‘ zuordnen oder eine vorhandene inhaltlich ändern bzw. austauschen

Ggf. die Sprache der natürlichen Person auswählen und zuordnen

Ggf. den Beruf der natürlichen Person auswählen und zuordnen

Ggf. die Staatsangehörigkeit der natürlichen Person auswählen und zuordnen Prozesssequenz ‚Eine Kundenbeziehung zwischen verschiedenen Partnern herstellen‘ besteht aus folgenden Prozessschritten:

Gewünschte Entität ‚Art der Kundenbeziehung‘ aufsuchen

Die Entität des ersten gewünschten Partners aufsuchen und zuordnen

Die Entität des zweiten gewünschten Partners aufsuchen und zuordnen

Ggf. die Entitäten von weiteren gewünschten Partnern aufsuchen und zuordnen

9

Prozesssequenz ‚Postanschrift zum Partnern bearbeiten‘ besteht aus folgenden Prozessschritten:

Gewünschte Entität ‚Partner‘ aufsuchen

Gewünschte Entität ‚Postanschrift‘ zum Partner aufsuchen und neu erfassen oder ändern

Die Theorie der Versicherungsprozesse

Entwicklung der Prozesslandkarte

Ausgehend von den Grundsätzen,

dass alle von den Sachbearbeitern ausführbaren und ausgeführten Geschäftsprozesse einen definierten Startpunkt im Unternehmen haben,

dass sich nach dem Durchlaufen ihre Beendigung ebenfalls dort befinden,

dass ein solcher Prozess nicht ausschließlich innerhalb des Unternehmens ablaufen muss, sondern durchaus auch Prozesssequenzen außerhalb des Unternehmens durchlaufen kann,

kann man eine Prozesslandkarte entwerfen, in der alle diese Start- und Endpunkte auf der höchsten Abstraktionsebene verdichtet abgebildet werden. Um die Prozesslandkarte zu strukturieren, wird ausgehend von den End-to-End-Prozessen der richtige oder logisch zutreffende Einstiegspunkt gesucht. Dafür wird zunächst auf der Ebene der Prozessdomänen folgende Untergliederung vorgenommen:

Fachliche Kernprozesse, Technische Kernprozesse und

Technische Hilfsprozesse Als weitere Untergliederung der fachlichen Kernprozesse bietet sich folgende Einteilung an: Versicherungsprodukt entwickeln (01) Versicherungsprodukt verkaufen (02) Schadensersatzanspruch bearbeiten (03) und Risiko diversifizieren (04) Als weitere Untergliederung auf der Ebene der technischen Kernprozesse bietet sich folgende Einteilung an: Partnerbestand pflegen (11) Geldverkehr bearbeiten (12) Gerichtsprozesse erfassen (13) Bedingungen, Richtlinien, Vorlagen bearbeiten (14) und Fällige Vorgänge bearbeiten (15) Als weitere Untergliederung auf der Ebene der technischen Hilfsprozesse bietet sich folgende Einteilung an: Sachbearbeiter-Berechtigungen verwalten (21) Verkaufsorganisation verwalten (22) Öffentliche Informationen auswerten (23) Statistiken erstellen (24) und Informationen vom GdV bearbeiten (25)

10

Wenn man die beschriebenen End-to-End-Prozesse in ein solches Schema der Prozessdomänen einordnet, kommt man zu folgendem Bild: 01 Versicherungsprodukt entwickeln:

Angebote für ein Versicherungsprodukt zielgruppengerecht entwickeln Vergleichsportale auf Versicherungsangebote überprüfen

02 Versicherungsprodukte verkaufen: Versicherungsprodukte entwickeln, verwalten und verkaufen 03 Schadensersatzansprüche bearbeiten: Schadensereignisse erfassen Schadensersatzforderungen bearbeiten 04 Risiken diversifizieren: Beteiligungsgeschäft erfassen Passive Rückversicherungen abschließen 11 Partnerbestand pflegen:

Partner im Adressbestand erfassen und ändern Adressdoubletten im Adressbestand erkennen und bereinigen

12 Geldverkehr bearbeiten Gemeldete Geldeingänge bearbeiten Inkasso verwalten Liquiditätsdisposition unterstützen 13 Gerichtsprozesse erfassen Gerichtsprozesse erfassen 14 Bedingungen, Richtlinien, Vorlagen bearbeiten Dokumentenvorlagen verwalten Schadenbearbeitung managen Versicherungsbearbeitung managen 15 Fällige Vorgänge bearbeiten Terminvorlagen bearbeiten Freizugebende Vorgänge freigeben 21 Sachbearbeiter-Berechtigungen verwalten: Versicherungsbetrieb einrichten Sachbearbeiter im Zugangssystem erfassen und pflegen 22 Verkaufsorganisation verwalten: Verkaufsorganisation (angestellt und frei) verwalten 23 Öffentliche Informationen auswerten: Veröffentlichte Meinung (Presse, Funk Fernsehen) auswerten 24 Statistiken erstellen: Anforderungen des Managements erfüllen Anforderungen der Aufsicht erfüllen 25 Informationen vom GdV bearbeiten Auffälligkeiten vom HIS bearbeiten Auffälligkeiten an das HIS melden

Graphik der Prozesslandkarte

11

Abbildung 1: Prozesslandkarte (Oberste Ebene)

Von der Prozessdomäne zur Prozesssequenz

Jede der insgesamt 14 Prozessdomänen kann in drei bzw. vier Ebenen weiter untergliedert werden. Erste Ebene: Fachliche und Technische Kern- und Hilfsprozesse Zweite Ebene: Teilprozesse 1. Ordnung

Dritte Ebene: Teilprozesse 2. Ordnung

Diese Ebene tritt bei sehr vielschichtigen und hoch differenzierten Kernprozessen auf. In vielen Fällen erfolgt auf dieser Ebene die Unterscheidung zwischen gleichartigen Teilprozessen 1. Ordnung in den verschiedenen Versicherungs- zweigen bzw. Schadensparten. Vierte Ebene: Prozesssequenzen

Auf dieser untersten Ebene werden aus den einzelnen Prozessschritten heraus die Beziehungen zu den Daten- und Logikelementen des Daten- oder Informations-Modells

hergestellt. Hier sind die datenzentrierten und die logikzentrierten Basisservices angesiedelt

Diese Untergliederung sieht zum Beispiel bei der fachlichen Hilfsdomäne ‚Partnerbestand pflegen‘ wie folgt aus: 11 Partnerbestand pflegen

12

Auf dieser Gliederungsebene werden die Prozesssequenzen ('Services') beschrieben, die zur Modellierung ('Orchestrierung') der Geschäftsprozesse benötigt werden, die für die Partnerverwaltung erforderlich sind, bzw. aus ihr heraus angestoßen werden.

11-01 Partner in Partner-DB suchen

In allen Versicherungsprozessen wird der Sachbearbeiter mit den unterschiedlichsten natürlichen und nicht-natürlichen Personen konfrontiert. Dabei ergibt sich immer wieder die Aufgabe festzustellen, ob eine solche Person bereits im Partner-Bestand des Anwenders vorkommt oder nicht. Um dies festzustellen, muss sie im Partner- Bestand gesucht werden. Dafür gilt: Eine bestimmte Instanz zur Entität Partner kann im Partner-Bestand auf mannigfaltige Art und Weise gesucht werden. Die wichtigsten Suchfunktionen sind:

Suche über den Namen des Partners

Suche über die Anschrift des Partners

Suche über das Partner-Profil des Partners Die für die verschiedenen Suchwege erforderlichen Prozesssequenzen werden in

diesem Kapitel beschrieben.

11- 02 Partner zum XX-Beteiligten zuordnen

Aus allen Anwendungskomponenten heraus werden Partner als natürliche oder nichtnatürliche Personen in den verschiedensten Rollen über die unterschiedlichsten Prozesse zugeordnet. Die Partner-Verwaltung im Modell sollte so gestaltet werden, dass jeder dieser 'XX-

Beteiligten' mit seinem Namen bereits in der Domäne der jeweiligen Anwendungskomponente in einer Schnittstellen-Entität oder -Klasse erfasst werden

kann. Wie darüber hinaus die Zuordnung zur eigentlichen Partner-Domäne als optionale oder zwangsläufige Fortsetzung der Geschäftsprozesse gestaltet wird, muss jeder Anwender selbst entscheiden. Derartige Schnittstellen-Entitäten bzw. -Klassen sind:

Vertrags-Beteiligte

Schadens-Beteiligte

Außendienst-Beteiligte

Prozess-Beteiligte

Bank-Beteiligte

RV-Ordnung-Beteiligte

Mitversicherungs-Beteiligte

Personal-Beteiligte

11-03 Beziehungen zwischen Partnern herstellen

Häufig stehen bestimmte Partner mit anderen Partnern in einer privaten oder geschäftlichen Beziehung zueinander, die für den Anwender aus vielerlei Gründen (Kundenbeziehung, Akquisition, Bereinigung, Kulanz usw.) von Bedeutung ist oder werden kann. In diesen Teilprozessen wird beschrieben, wie zwei unterschiedliche Instanzen der Entität Partner durch eine entsprechende Assoziation miteinander in Verbindung gebracht werden.

11-04 EMA-Anfrage zum Partner erfassen

Eine der häufigsten Anlässe, eine Anfrage an das Einwohnermeldeamt (EMA) zu richten, ist, dass es bei einem Brief an einen Partner zu einem Postrückläufer gekommen und dabei die neue Anschrift nicht bekannt gegeben worden ist. In diesen Fällen kann es helfen, dass das für die alte Adresse zuständigen

Einwohnermeldeamt mit der Anfrage angeschrieben wird, ob dort die neue Adresse bekannt ist. Bei berechtigten derartigen Anfragen geben diese Ämter gegen eine

13

bestimmte Gebühr Auskunft. Das Problem bei diesen Anfragen ist, dass es in der Bundesrepublik etwa 6.000 Einwohnermeldeämter gibt, die ihre Auskünfte zu unterschiedlichen Gebührensätzen und nach unterschiedlichen Rechercheverfahren (Formular, Brief, Scheck, Überweisung, telefonische Anfrage usw.) abgeben. Unter diesem Gliederungspunkt werden die verschiedenen Prozesssequenzen beschrieben, um die unterschiedlichen Anfragetypen bei den Einwohnermeldeämtern zu erzeugen.

11-05 Partner mit Partner-Kontakt zusammenführen

Immer dann, wenn ein Kontakt zu einem Partner hergestellt wird, ist es erforderlich, dass dieser Partner-Kontakt dokumentiert wird. Dabei muss durch entsprechende Programmlogik sichergestellt werden, dass wirklich jeder Kontakt festgehalten wird, damit ein zutreffendes Kontakt-Profil entsteht. Dieser Teilprozess muss in jeden Geschäftsprozess eingebunden werden, bei dem auch eine Instanz der Entität Partner bearbeitet wird. Zusätzlich kann diese Prozesssequenz zugleich auch Gegenstand eines eigenständig aufgerufenen und durchgeführten Geschäftsprozesses sein.

11-06 Sonstige Bearbeitung zum Partner durchführen

Um einen Partner für den Anwender bearbeitungsfähig zu machen, muss er mit einer Reihe von zusätzlichen Informationen in Beziehung gebracht werden. Dazu gehören:

seine Bankverbindung

seine Postanschrift

der Weg der Postzustellung

seine Telekommunikationsangaben

seine EMail-Adresse und

ggf. seine Betriebsstätte. Diese und alle weiteren Aktivitäten werden unter dem Begriff 'Sonstige Bearbeitungen zum Partner‘ in diesem Gliederungspunkt zusammengefasst.

11-07 Partnerbestand bereinigen

Der Partnerbestand eines Anwenders ist keine statische Ansammlung von Informationen. Er unterliegt der ständigen Veränderung, die sich aus der Verwaltung von partnerbezogenen Daten ergibt. Derartige Veränderungen sind beispielsweise:

Partner-Doubletten erkennen und zusammenlegen

Mitteilungen über Namensänderungen bearbeiten

Mitteilungen über das Ausscheiden von Partnern bearbeiten

usw. Alle diese Vorgänge können über Prozesssequenzen bearbeitet werden, die unter diesem Gliederungspunkt zusammengefasst sind.

11-07-01 Namensänderungen zu vorhandener Adresse bearbeiten

Der häufigste Anlass für eine Namensänderung ist das Eingehen einer Heirat durch einen Partner mit der Folge einer Namensänderung. Der Partner bleibt dabei derselbe. Alle seine vorhandenen Geschäftsbeziehungen müssen unter dem neuen Namen fortgeführt werden. In dieser Prozesssequenz wird beschrieben, wie ein solcher Namenswechsel vollzogen wird.

11-07-02 Adress-Doublette erkennen

Bedingt durch die Schwierigkeit, die Namen von Partnern eindeutig und unmissverständlich zu formulieren, kommt es immer wieder vor, dass sich in einem Partner-Bestand Doubletten einstellen. Dies gilt insbesondere für

14

die immer zahlreicher auftretenden Namen nichtdeutscher Herkunft. Dafür gibt es bestimmte Software-Bausteine, die käuflich erworben und in die bestehende IT eingefügt werden können, mit denen derartige Doubletten erkannt und aufgedeckt werden. In dieser Prozesssequenz wird beschrieben, wie Partner-Doubletten erkannt werden.

Abbildung 2: Prozesssequenz Adress-Doubletten erkennen

11-07-03 Adress-Doubletten zusammenlegen

Bedingt durch die Schwierigkeit, die Namen von Partnern eindeutig und unmissverständlich zu formulieren, kommt es immer wieder vor, dass sich in einem Partner-Adressbestand Doubletten ergeben. Dies gilt insbesondere für die immer zahlreicher auftretenden Namen nichtdeutscher Herkunft. Dafür gibt es bestimmte Software-Bausteine, die käuflich erworben und in die bestehende IT eingefügt werden können, mit denen derartige Doubletten erkannt und aufgedeckt werden. In dieser Prozesssequenz wird beschrieben, wie erkannte Partner-Doubletten zusammengelegt werden.

Abbildung 3: Prozesssequenz Adress-Doubletten zusammenlegen

15

Start-Event: Zusammenlegen von Adress-Doubletten starten Mit diesem Prozessschritt wird die Zusammenlegung von Adressdoubletten nach Prüfung durch den Sachbearbeiter gestartet.

Erste Aktivität: Service 'Instanzen zur Prozesssequenz aus DB holen' Zu Beginn dieser Prozesssequenz werden die Instanzen zu den benötigten Entitäten aus der Datenbank geholt.

Zweite Aktivität: Entität Partner ohne Inhalt anzeigen Dem Sachbearbeiter liegt die Liste der in einem Batchlauf erkannten und danach dokumentierten wahrscheinlichen Doubletten im Partner-Adressbestand vor. Um die erste auf dieser Liste stehende Instanz zur Entität Partner aufzusuchen, erhält der Sachbearbeiter in dieser Prozesssequenz eine Instanz zur Entität Partner mit leeren Erfassungsfeldern. Nach Auswahl von Partner_Person_Art und nach Eingabe von Name_1_Partner und Name_2_Partner wird geprüft, ob es bereits Instanzen zu Partner mit diesen Angaben gibt. Ist das der Fall, werden diese (ggf. tabellarisch) angezeigt. Will der Sachbearbeiter eine dieser Instanzen auch in der laufenden Prozesssequenz verwenden, gibt er dies durch eine entsprechende Eingabe bekannt. Im anderen Fall erhält er eine Fehlermeldung. Es darf in dieser Prozesssequenz keine neue Instanz Partner angelegt werden. Hat der Sachbearbeiter diese Auswahl getroffen, werden ihm zusätzlich zu der gewünschten die weiteren Instanzen zur Entität Partner angezeigt, die mit der ausgewählten über die Assoziation 'Partner ist wahrscheinliche Doublette zu Partner' verbunden sind. Danach trifft der Sachbearbeiter die Entscheidung, welche Version der bearbeiteten Instanzen zur Entität Partner er zur Bearbeitung weiter behalten will. Alle anderen werden aus der Datenbank eliminiert. Dabei werden alle Beziehungen, die die zu löschenden Kandidaten zu Instanzen von anderen Entitäten unterhält (Datendomänen Vertrag, Schaden, RV-Ordnung, Bank, Prozess, Außendienst usw. aber auch weitere Entitäten aus der Domäne Partnerverwaltung selbst), auf den verbleibenden Kandidaten umgehängt.

Gateway: EMA-Anfrage zur Adress-Doubelte starten? Hat der Sachbearbeiter durch eine entsprechende Eingabe zum Ausdruck gebracht, dass er in der laufenden Prozesssequenz zu einer der bearbeiteten Instanzen von Partner eine Anfrage beim Einwohnermeldeamt richten möchte, erhält er als nächstes eine Instanz zur Entität P_EMA_Anfrage mit leeren Erfassungsfeldern. Ansonsten wird die Prozesssequenz mit dem nächsten Prozessschritt fortgesetzt.

Ggf. dritte Aktivität: Entität EMA_Anfrage ohne Inhalt anzeigen Hat der Sachbearbeiter angegeben, dass er eine Anfrage an ein Einwohnermeldeamt richten möchte, erhält er zunächst eine Instanz zur Entität P_EMA_Anfrage mit leeren Erfassungsfeldern. Nach Eingabe von Einw_Meldeamt_Nr und nach Auswahl von Einw_Meldeamt_Art wird geprüft, ob es bereits Instanzen zu P_EMA_Anfrage mit diesen Angaben gibt. Ist das der Fall, werden diese (ggf. tabellarisch) angezeigt. Will der Sachbearbeiter eine dieser Instanzen auch in der laufenden Prozesssequenz nutzen, gibt er dies durch eine entsprechende Eingabe bekannt. Im anderen Fall erfasst er eine neue Instanz zu P_EMA_Anfrage und ordnet diese zu.

Vierte Aktivität: Service 'Instanzen zur Prozesssequenz in DB zurückschreiben' Am Ende dieser Prozesssequenz werden die Instanzen der bearbeiteten Entitäten in die Datenbank zurückgeschrieben. .

End-Event: Adress-Doubletten zusammengelegt Mit diesem Prozessschritt wird die Zusammenlegung von Adressdoubletten nach Prüfung durch den Sachbearbeiter erfolgreich beendet.

16

Erkenntnisse im Verlauf der Entwicklung von Prozessmodellierung 2.0 Erste Erkenntnis: Bei der Aufnahme der vorhandenen Prozesse muss aufgeschrieben werden, was ist, nicht was sein sollte. Dabei hilft auch kein Modellierungstool weiter. Zweite Erkenntnis: Die Arbeit darf sich nicht um das Ausfüllen eines Tools drehen. Es geht um die Inhalte. Dritte Erkenntnis: Die in der Theorie überall anzutreffenden Spaghetti-Prozesse müssen kleinteilig aufgebrochen werden. Vierte Erkenntnis: Es muss eine Methode gefunden werden, mit der die Geschäftsprozesse permanent und ohne großen Aufwand an neue Gegebenheiten und Bedingungen angepasst werden können. Neue oder geänderte Prozesse bzw. Prozesssequenzen müssen ohne große Probleme in das neu entwickelte Prozessmodell eingearbeitet werden können.