1. Einleitung
Das Versicherungswesen unterliegt sich fortwährend ändernder Gegebenheiten und fordert den Marktteilnehmern stets ein hohes Maß an Engagement hinsichtlich der Optimierung und Flexibilisierung ihrer Unternehmensprozesse ab.
Dabei sind zahlreiche konzeptionelle Anforderungen auf die Schwerfälligkeit der Unternehmen bei der Umsetzung flexibler Prozesse zurückzuführen. Zudem werden Prozesse häufig nicht ausreichend überwacht, laufen suboptimal und sind nicht angemessen dokumentiert.
Verschiedene große Versicherungsgesellschaften haben dahingehend in den letzten Jahren einen großen Aufwand betrieben, eigene und ganzheitliche Konzepte zu entwickeln, um ihren Geschäftserfolg dadurch nachhaltig zu verbessern.
1.1. Problemstellung
Angesichts eines zunehmend dynamischer werdenden Versicherungsmarktes hinsichtlich des Wettbewerbs, aber auch eines divergenten Kundenverhaltens sind Versicherer gezwungen, ihre Prozesse permanent an die sich ändernden Gegebenheiten anzupassen. [1]
Die assona GmbH, eine mittelständische Versicherungsdienstleisterin und -maklerin mit dem Fokus auf Spezialversicherungen, stellt sich diesen Anforderungen in Anbetracht ihres eigenen Anspruchs, sich durch „innovative IT-Strukturen in Verbindung mit höchst flexiblen Prozessen“ [2] auszuzeichnen, jeden Tag erneut.
Sie arbeitet mit verschiedenen Versicherungsgesellschaften zusammen und versichert derzeit bereits zahlreiche elektronische und nicht elektronische Geräte u.a. gegen Diebstahl und Beschädigung.
Mit der sukzessiven Aufnahme neuer Produkte ins Portfolio der assona GmbH halten vermehrt auch sehr individuelle Prozesse in den nachgelagerten Service-Abläufen Einzug, wobei zunehmend auch eine wachsende Zahl verschiedenster Partner involviert ist.
Das betrifft insbesondere die Abläufe der Schadenbearbeitung. Hier sind von den Sachbearbeitern im
Schadenfall je nach gewähltem Produkt des Kunden zusätzliche Daten aufzunehmen und z.T. Entscheidungen zu treffen, die ggf. für andere Produkte gar nicht möglich sind.
Derzeit erhalten die Sachbearbeiter dabei bereits Unterstützung durch eine eigen-entwickelte Software zur
Vertrag- und Schadensachbearbeitung. Zudem gibt es ein Handbuch, in dem die jeweiligen Arbeitsschritte für die einzelnen Prozesse beschrieben sind. Die Software selbst macht nahezu keine Vorgaben hinsichtlich der
notwendigen Arbeitsabläufe bzw. deren Reihenfolge.
Service-Abläufe können auf diese Weise schwer überwacht werden, da nicht si-chergestellt werden kann, dass stets streng nach Handbuch gearbeitet wird. Zudem ist es sehr aufwändig, dieses Kompendium stets aktuell zu halten und gerade bei neuen Mitarbeitern geht viel Zeit bei dessen Studium verloren. Das gilt generell auch für alle anderen Mitarbeiter, sofern sich Abläufe ändern oder vollkommen neue hinzukommen.
Ein softwaregestütztes Management der Prozesse scheitert bei der assona GmbH bislang an mehreren Faktoren:
- Die Implementierung eines Workflow-Managements in die bestehende Software ist mit dem gewählten Softwareentwicklungskonzept der assona GmbH schwer umzusetzen.
- Das Know-How über die Prozesse liegt bei den Fachabteilungen. Ggf. müssten Dokumentationen und Handbücher an mehreren Stellen gepflegt werden, wobei die Gefahr von Inkonsistenzen besteht.
- Die Umsetzung von Änderungen sowie die Neuaufnahme von Prozessen müssten sich einem Release-Zyklus von 6 bis 8 Wochen unterordnen, worunter die Flexibilität leiden würde.
Besonders im Hinblick auf die mittelfristig weiter zunehmende Anzahl unterschiedlicher Prozessabläufe steht die assona GmbH vor der Herausforderung, diese auch weiterhin angemessen zu dokumentieren und effizient zu kommunizieren. Letzteres kann in Zukunft aller Vorrausicht nach nicht mehr mittels eines Handbuchs gewährleistet werden. Ein softwaregestütztes Prozess-Management würde auf Grundlage des aktuellen
Vorgehensmodells bei der Softwareentwicklung jedoch die Leistungsfähigkeit der assona GmbH in der Interaktion mit ihren Kunden verringern.
1.2. Zielsetzung
Ein Konzept eines softwaregestützten und leistungsfähigen Managements flexibler Prozesse ist für die assona GmbH demnach von hoher Relevanz und sie verbindet damit verschiedene Erwartungen.
Aus technischer Sicht wird erwartet, dass sich damit die einzelnen Prozessabläufe vom Release-Zyklus der Software zur Vertrags- und Schadensachbearbeitung weitgehend unabhängig implementieren lassen.
Die verschiedenen Fachabteilungen erwarten hingegen, dass dieses Vorgehen auch eine Erhöhung der Prozesstransparenz und -übersichtlichkeit sowie eine Verbesserung der Prozessdokumentation mit sich bringt.
Mittelfristig wird zudem davon ausgegangen, dass der zeitliche Aufwand für die Umsetzung einer Prozessänderung gemindert werden kann. Weniger Zeitaufwand bei der Recherche im Handbuch soll weiterhin in kürzere Bearbeitungszeiten durch den Sachbearbeiter resultieren, was sich wiederum in einer gesteigerten Kunden-zufriedenheit niederschlägt.
Um zukünftig die verschiedenen Fachabteilungen in den Entwicklungsprozess einzubeziehen, empfiehlt sich für die IT der assona GmbH eine Restrukturierung ihrer Softwareentwicklungsprozesse. Dabei sollen vermehrt die Ergebnisse aus der Pro-zessplanung der beteiligten Fachabteilungen in den Entwicklungsprozess einfließen, wobei besonders die Dokumentationen der Prozessabläufe im Fokus stehen.
Ziel der vorliegenden Arbeit ist es daher, der assona GmbH einen Weg aufzuzeigen, Prozess- und Softwareentwicklung einander anzunähern und dabei ungenutzte Optimierungs- und Kostensenkungspotenziale auszuschöpfen.
1.3. Vorgehensweise
Um die zuvor genannten Ziele zu erreichen, soll im Rahmen dieser Arbeit ein ent-sprechendes Konzept entwickelt werden, auf dessen Basis die assona GmbH eine Umgestaltung ihres Workflow-Managements vornehmen und zudem ihre Softwareentwicklungsprozesse optimieren und professionalisieren kann.
Nach einer kritischen Betrachtung grundlegender Softwareentwicklungskonzepte im 2. Kapitel wird der IT der assona GmbH ein Vorgehensmodell vorgeschlagen, das besser geeignet ist, Prozessdokumentationen direkt in die Softwareentwicklung einfließen zu lassen. Im Anschluss daran wird die Bedeutung solcher Dokumentationen und Modelle im Kontext der Management-Ebenen eines Unternehmens diskutiert, bevor deren iterativer Erstellungsprozess vorgestellt wird.
Im 3. Kapitel wird dann näher auf die Modellierung von Geschäftsprozessen eingegangen und erläutert, welche Chancen sich dadurch u.a. hinsichtlich der Automatisierung dieser Prozesse bieten. Auf dem Weg hin zu einem lauffähigen Prozess müssen dabei zunächst jedoch eine Reihe von Entscheidungen getroffen werden, die in diesem Kapitel detailliert betrachtet werden.
Die gewonnenen Erkenntnisse spiegeln sich in einem Praxisbeispiel (Kapitel 4) wieder, das in abgewandelter Form dem Alltag des Versicherungswesens entstammt. Es dient als Referenz für eine etwaige Umsetzung des erarbeiteten Konzepts eines softwaregestützten Prozessmanagements bei der assona GmbH.
Abschließend wird in Kapitel 5 betrachtet, inwiefern das entwickelte Konzept zur Erreichung der gesteckten Ziele geeignet ist und wie die assona GmbH damit ggf. verfahren kann.
2. Grundlagen
Ein Überblick über das derzeitige Vorgehen bei der Softwareentwicklung der assona GmbH sowie den komplementären Einsatz einer speziell auf Entwicklungsmodelle zugeschnittenen Methodik soll ein besseres Verständnis für die Ausgangsproblematik schaffen. Ein solcher Überblick soll nachfolgend gegeben werden.
Im Anschluss daran wird dann näher auf das Geschäftsprozessmanagement im Kontext der modellgetriebenen Entwicklung eingegangen. Dabei liegt der Fokus besonders auf der Modellierung der Geschäftsprozesse.
2.1. Softwareentwicklungskonzepte
Zur Veranschaulichung der Problematik des gewählten Softwareentwicklungskonzepts der IT der assona GmbH, hinsichtlich der Integration eines Workflow-Managements in die Software zur Vertrags- und Schadenbearbeitung, soll nachfolgend deren Entwicklungsmethodik vorgestellt werden.
Anschließend wird ein erster möglicher Lösungsansatz aufgezeigt, der helfen kann, Planungsergebnisse anderer Fachabteilungen für die IT nutzbar zu machen.
2.1.1. Feature Driven Development (FDD)
Bei der assona GmbH kommt die agile Softwareentwicklungsmethode FDD zum Einsatz. Sie wird bei der Fehlerbehebung sowie der Umsetzung neuer Anforderungen an die bestehende Software verwendet.
Bei der FDD stellen Features den Ausgangspunkt der Entwicklung dar. So genannte Feature Requests oder auch Tickets werden bei der assona GmbH durch die Fachabteilungen gestellt. Sie werden über ein Ticket-System verwaltet. Innerhalb eines Release-Zyklus werden diese dann je nach Priorität umgesetzt.
Das klassische Vorgehen bei FDD-Projekten veranschaulicht Abbildung 1[3]. Sie zeigt die fünf Prozessschritte der Umsetzung von Anforderungen.

Abbildung 1: FDD-Prozesse
1. Entwicklung eines Gesamtmodells
In dieser Phase werden „Inhalt und Umfang des zu entwickelnden Systems“ [4] definiert. Sie werden bei der assona GmbH durch die Leitung der IT-Abteilung anhand der Dringlichkeit der einzelnen Anforderungen bestimmt.
2. Erstellung einer Feature-Liste
Die verschiedenen Anforderungen werden durch die Fachabteilungen sowie die Leitung der IT-Abteilung in ein Ticket-System übertragen. Aus Jedem Feature resultiert dabei ein entsprechendes Ticket.
3. Planung der Features
Die einzelnen Tickets werden für das Software-Release gebündelt und jeweils mit einer Priorität und einem Fertigstellungstermin versehen. Zudem werden Abhängigkeiten zwischen den einzelnen Tickets hinterlegt, sodass meist schon dadurch vorgegeben ist, in welcher Reihenfolge diese bearbeitet werden müssen.
4. Entwurf eines Features
Je nach Zuständigkeit werden die Tickets an die Programmierer zur Bearbeitung verteilt.
5. Konstruktion eines Features
In dieser Phase werden die Features durch die Programmierer umgesetzt. Die Phasen Entwurf und Konstruktion werden jeweils nacheinander abgearbeitet und gehen so in einander über. [4]
2.1.2 Model Driven Development (MDD)
Eine Möglichkeit, Planungsergebnisse anderer Fachabteilungen für die IT nutzbar zu machen, ist die Erweiterung des Softwareentwicklungsverfahrens um einen modellgetriebenen Ansatz – dem Model Driven Development (MDD).
Das MDD zielt darauf ab, Funktionalität und Implementierung eines Systems voneinander zu trennen, was eine Abstrahierung der Systembeschreibung ermöglicht. [5] Dabei dienen im Gegensatz zu FDD nicht Features sondern Modelle als Grundlage für die Implementierung. [6]
Rempp, Akermann und Löffler zufolge versteht man dabei „die abstrahierte Abbildung eines Bereichs der Wirklichkeit in grafischen Notationen oder formalen Sprachen“ [7] als Modell.
Der Vorteil dieser Herangehensweise liegt darin, dass Modelle für alle Beteiligten leichter verständlich sind, da sie systemunabhängig und damit nicht so technisch sind. Dennoch dienen sie in der modellgetriebenen Softwareentwicklung sowohl als Dokumentation eines Systems als auch als Grundlage für dessen automatisierte Umsetzung. [8]
Das Vorgehen modellbasierter Softwareentwicklung stellt Abbildung 2[9] schematisch dar.
Dabei wird zunächst für einen fachlichen Geltungsbereich (Domäne) festgelegt, welche Objekte und Relationen ein Modell enthält. [7] Diese Beschreibung, das s.g. Metamodell, umfasst sowohl den Aufbau (Syntax) als auch die Bedeutung (Semantik) dessen, was in einem Modell dargestellt werden kann – die domänenspezifische Sprache. [7]
Unter Verwendung dieser Sprache können Diagramme mittels Transformation in Quellcode übersetzt werden, was ein hohes Potenzial an Automatisierung bei der Softwareentwicklung mit sich bringt. [10]
Abbildung 3[11] veranschaulicht eine solche Transformation anhand eines einfachen, plattformunabhängigen Modells (PIM), welches einen Kunden mit seinen wichtigen Charakteristika beschreibt. Auf der dargestellten Abstraktionsebene beschreibt das Modell wichtige Eigenschaften der Domäne mit Klassen und ihren Attributen, ohne dabei plattformspezifische Entscheidungen vorwegzunehmen. [12]

Abbildung 3: Beispiel für Code-Generierung
Ein solches Vorgehen wirkt sich positiv auf die Qualität und Wartbarkeit der zu entwickelnden Software aus und bringt zudem meist eine deutliche Produktivitätssteigerung mit sich. [10]
Für die assona GmbH empfiehlt sich eine Integration modellgetriebener Softwareentwicklung in das bestehende Softwareentwicklungskonzept, also eine hybride Lösung. Prozessabläufe, die ohnehin vor einer softwaretechnischen Umsetzung geplant werden, können auf Basis von Modellen umgesetzt werden. Ein solches Vorgehen setzt jedoch zwei Dinge voraus: [10]
- Es wird eine DSL zur Formulierung von Modellen benötigt.
- Zur Erzeugung von Programmen werden Generatoren, Transformatoren oder Interpreter benötigt. Diese Programme werden dann auf der Zielplattform ausgeführt.
Im Hinblick auf eine DSL ist in diesem Fall zu überlegen, ob es für die Modellierung von Prozessabläufen bzw. Geschäftsprozessen nicht bereits einen gängigen Standard gibt. Mit der Verwendung eines solchen Standards entfällt der Aufwand für die Entwicklung einer eigenen Sprache. Zudem können auf einen Standard zugeschnittene Transformatoren schneller entwickelt bzw. ebenfalls eine bereits existierende Standardlösung implementiert werden.
Auf diese Weise entfielen gleich zwei der möglichen Risiken, die ein solches Vorgehen mit sich bringen kann – die Entwicklung einer domänenspezifischen Sprache und entsprechender Generatoren, Transformatoren und Interpreter.
2.2. Geschäftsprozessmanagement
Für ein solches modellgetriebenes Vorgehen spricht zudem die ständige Notwendigkeit, Prozessabläufe zu hinterfragen, ggf. zu optimieren und so Kostensenkungspotenziale nutzbar zu machen. [13]
Das Prozessmanagement ist dabei „ein zentraler Bestandteil eines integrierten Konzeptes für das Geschäftsprozess- und Workflow-Management“[13] und dient Gadatsch zufolge „dem Abgleich mit der Unternehmensstrategie, der organisatorischen Gestaltung von Prozessen sowie deren technischer Umsetzung mit geeigneten Kommunikations- und Informationssystemen“[13].
Auf Grundlage dieser Definition beschreibt Gadatsch die Gestaltung des Konzepts eines Geschäftsprozess- und Workflow-Managements anhand der Management-Ebenen eines Unternehmens. Abbildung 4[14] veranschaulicht das Zusammenwirken der einzelnen Ebenen sowie die jeweils zugeordneten Aufgaben und Phasen hinsichtlich des Geschäftsprozess- und Workflow-Managements.

Abbildung 4: Geschäftsprozess- und Workflow-Management
Die fachlich-konzeptionelle Ebene liegt darunter und dient der Ableitung der Prozesse aus der entwickelten Strategie. [13] Das wiederum darunter liegende Workflow-Management auf der operativen Ebene bindet die Gestaltung des Anwendungssystems sowie der Organisation ein. [13] Hier findet die Umsetzung dessen statt, was zuvor auf den darüber liegenden Ebenen geplant und modelliert wurde.
2.3. BPM-Lebenszyklus
Das Geschäftsprozessmanagement ist als iterativer Prozess zu verstehen, der über alle Management-Ebenen in der in Abbildung 5[16] dargestellten Reihenfolge abläuft.

Abbildung 5: BPM-Lebenszyklus
Inhaltlich besteht jedoch weitgehend ein Konsens über dessen sechs Phasen: [17]
- Konzeption/Strategie
- Prozess-Design
- Prozess-Implementierung
- Prozess-Ausführung
- Prozess-Controlling
- Kontinuierlicher Verbesserungsprozess (KVP)
In Tabelle 1 werden die einzelnen Phasen im Folgenden kurz erläutert, um diese auch bei unterschiedlichen Bezeichnungen quellenübergreifend adaptieren zu können.
Tabelle 1: Beschreibung der Phasen des BPM-Lebenszyklus [16]
BPM-Phase | Beschreibung |
Konzeption/Strategie |
|
Prozess-Design |
|
Prozess-Implementierung |
|
Prozess-Ausführung |
|
Prozess-Controlling |
|
Kontinuierlicher Verbesserungsprozess |
|
3. Vom Modell zum lauffähigen Prozess
Um Geschäftsprozesse rechnergestützt verarbeiten zu können, werden diese mittels s.g. Geschäftsprozess- oder Workflow-Modelle dargestellt. [18]
Wie in Abschnitt 2.2 zuvor angedeutet, werden bei deren Erstellung alle drei Management-Ebenen eines Unternehmens einbezogen. Von der strategischen, über die fachlich-konzeptionelle bis hin zur operativen Ebene werden die Modelle dabei bis zur Gestaltung des Anwendungssystems immer konkreter und detaillierter.
Diese Prozessmodelle dienen übergreifend als Kommunikations- und Strukturmittel und müssen demnach auf allen Ebenen verständlich sein. [19] Damit ist jedoch nicht gemeint, dass auf allen Ebenen dieselben Notationsformen zum Einsatz kommen müssen.
Im Hinblick auf den o.g. MDD-Ansatz sollte jedoch schon im Rahmen des Prozess-Managements auf fachlich-konzeptioneller Ebene ein Format für eine automatisierte Verarbeitung verwendet werden.
3.1. Notationsformen
Für die Notation bzw. Dokumentation von Geschäftsprozessen finden in der Praxis unterschiedliche Notationsformen Verwendung. Deren Verbreitung innerhalb des deutschsprachigen, europäischen Raumes (DACH) wurde u.a. im Rahmen einer empirischen Studie der ZHAW Zürcher Hochschule für Angewandte Wissenschaften untersucht.
Die Studie ermöglicht „eine Aussage zum Status quo und der Entwicklung von BPM“[20] und sorgt zudem für belastbare Ergebnisse durch verschiedene Maßnahmen zur Qualitätssicherung der Inhalte. Diese Ergebnisse resultieren aus einer Online-Befragung, die zwischen dem 4. November 2010 und dem 1. Februar 2011 unter Organisationen mit BPM-Sachverstand durchgeführt wurde. [21]
Die Ergebnisse aus der Online-Befragung sind in Abbildung 6[22] grafisch aufbereitet worden. Zu erkennen sind dabei große Unterschiede hinsichtlich der Verwendung der einzelnen Notationsformen in den Organisationen.
Den Ergebnissen der Umfrage zufolge werden klassische Flussdiagramme zur Dokumentation von Geschäftsprozessen am häufigsten (63%) eingesetzt. [23]Dahinter folgen dann die BPMN (49%) sowie die EPK mit 30% und die UML mit 28% Verbreitung. [23]
Nachfolgend sollen diese vier in Organisationen am häufigsten eingesetzten Notationsformen genauer betrachtet und verglichen werden. Anschließend soll darauf aufbauend anhand definierter Kriterien eine Form ausgewählt werden, die sich am besten für die modellgetriebene Softwareentwicklung hinsichtlich des Managements flexibler Prozesse der assona GmbH eignet.
3.1.1. Flussdiagramm
Klassische Flussdiagramme sind der ZHAW-Studie zufolge auch heutzutage noch die meist verwendete Art, Geschäftsprozesse zu dokumentieren. [23] Sie sind unkompliziert, leicht zu erlernen und können mittels beliebiger Textverarbeitungsprogramme erstellt werden.
Diese Art der Ablaufplan-Erstellung fußt auf dem Standard ISO 5807:1985, in dem Symbole und Konventionen u.a. für Flussdiagramme beschrieben werden. [24]
Aufgrund der schwachen Formalisierung solcher Modelle, sind diese vom Verfasser nahezu frei zu gestalten. Das senkt zwar auf der einen Seite die Hürde beim Erlernen dieser Technik, macht es jedoch ohne zusätzliche Standards nahezu unmöglich, derartige Diagramme automatisiert zu verarbeiten.
3.1.2. BPMN
Die Business Process Modeling Notation (BPMN) in der aktuellen Version 2.0 zählt im Gegensatz zu den Flussdiagrammen nicht zu den datenflussorientierten, sondern zu den kontrollfluss- und diagrammbasierten Methoden der Prozessmodellierung. [25]
Bei der BPMN handelt es sich um einen weit verbreiteten Standard zur Modellierung von Prozessen, der durch die Object Management Group (OMG) gepflegt wird. [26] Die BPMN repräsentiert Geschäftsprozesse formal auf Grundlage einer grafischen Notation, die in einer umfangreichen und Natschläger zufolge z.T. widersprüchlichen Spezifikation beschrieben wird. [26]
Da dieser Spezifikation seit der Version 2.0 ein Metamodell zugrunde liegt, handelt es sich dabei auch formal um eine Modellierungssprache. [27] Diese richtet sich nicht nur an den Prozess-Analyst (fachlich-konzeptionelle Ebene), sondern auch an den Prozess-Ingenieur (operative Ebene).
Die BPMN zeichnet sich zudem durch eine große Toolunterstützung seitens zahlreicher internationaler Hersteller aus. Dadurch können zu starke Abhängigkeiten von einem bestimmten Hersteller vermieden werden.
3.1.3. EPK
Ereignisgesteuerte Prozessketten (EPK) sind ein essentieller Bestandteil des von Scheer entwickelten ARIS-Konzepts, als dessen Alternative sich inzwischen die o.g. BPMN der OMG etabliert hat. [28]
EPKs bilden in stets abwechselnden Ereignissen und Funktionen die Reihenfolge der Aktivitäten ab, in der ein Prozess abgearbeitet werden muss. [29] Dieser Umstand sorgt jedoch auch dafür, dass EPKs tendenziell deutlich umfangreicher sind als BPMN-Modelle.
Zudem ist es kritisch zu bewerten, dass ARIS im Allgemeinen und EPKs im Speziellen bis heute auf internationaler Ebene keine große Aufmerksamkeit genießen, wodurch letztlich auch die Unterstützung durch verschiedene Software-Hersteller stark eingeschränkt ist. [29]
3.1.4. UML
In der Softwareentwicklung ist die Unified Modeling Language (UML) schon seit den 1990er Jahren bekannt. Sie steht ebenfalls unter der Schirmherrschaft der OMG und beinhaltet verschiedene Diagrammtypen, die teilweise auch im ARIS-Konzept von Scheer zum Einsatz kommen.
Für die Modellierung von Prozessen ist hierbei jedoch vor allem das Aktivitätsdiagramm hervorzuheben. Dieser Notation liegt ein Metamodell zugrunde, womit es sich hierbei analog zur BPMN um eine Modellierungssprache handelt.
Im Vergleich zur BPMN ist der ZHAW-Studie für die UML ein etwa halb so großer Verbreitungsgrad zu entnehmen, was wohl mit der eher technischen Ausrichtung dieser Sprache zusammenhängt. Daher kann sie sich gerade auf der fachlich-konzeptionellen nicht durchsetzen.
3.1.5. Auswahl einer Notationsform
Auf Basis der zugrunde liegenden Fakten soll nachfolgend eine Form ausgewählt werden, die dem o.g. MDD-Ansatz hinsichtlich des Managements flexibler Prozesse der assona GmbH am ehesten entgegenkommt.
Als übersichtliche Entscheidungsgrundlage dienen dabei die in Tabelle 2 zusammengefassten Kriterien.
Tabelle 2: Entscheidungsgrundlage: Auswahl einer Notationsform [30]
Flussdiagramm | BPMN | EPK | UML | |
Verbreitungsgrad | 63% | 49% | 30% | 28% |
Standard | Ja (ISO 5807) |
Ja (BPMN 2.0) |
Quasi | Ja (UML 2) |
Offenes Format | Ja | Ja | Nein | Ja |
Modellierungssprache | Nein | Ja | Nein | Ja |
Ein wichtiger Faktor bei der Auswahl einer Notationsform ist zunächst deren Verbreitungsgrad lt. ZHAW-Studie. Dieser gibt bereits Aufschluss über ihre spätere Akzeptanz unter den Prozess-Architekten und –Ingenieuren.
Vor dem Hintergrund des MDD-Ansatzes aus Abschnitt 2.1.2 wird in diesem Zusammenhang jedoch auch nach einem industriell anerkannten Standard gesucht, der nach Möglichkeit nicht proprietärer Natur ist und zudem formal als Sprache gilt.
In der vorliegenden Übersicht werden diese Kriterien von der BPMN am ehesten erfüllt. Sie bietet zudem den Vorteil, dass bereits zahlreiche Hersteller integrierte Lösungen zum Design und zur direkten Ausführung derartiger Modelle, s.g. Business Process Management Suites (BPMS), anbieten. [29]
Dabei werden BPDs (BPMN-Diagramme) mit Hilfe von Process Engines lauffähig gemacht. Auf diese Process Engines wird im folgenden Abschnitt näher eingegangen.
3.2. Business Process Management Suites (BPMS)
BPM-Systeme oder auch -Suiten stellen die technische Grundvoraussetzung für ein erfolgreiches, softwaregestütztes Prozessmanagement dar. Sie bieten Prozessverantwortlichen ebenso wie -beteiligten Unterstützung bei dem Design, der Implementierung und der Ausführung von Prozessen.
Letzteres wird durch eine s.g. Process Engine ermöglicht, die Bestandteil einer BPMS ist.
3.2.1. Process Engines
In Abschnitt 2.1.2 wurde herausgestellt, dass für die modellgetriebene Softwareentwicklung neben einer domänenspezifischen Sprache (DSL) auch ein entsprechender Interpreter notwendig ist. Diesen stellt die s.g. Process Engine dar, die zur Ausführung des technischen Prozessmodells dient – analog zur regulären Quellcode-Interpretation. [31]
Abbildung 7[32] veranschaulicht die Funktionsweise einer solchen Process Engine. Zu beachten ist dabei jedoch, dass ein derartiges Prinzip nicht zwangsläufig auf eine vollständige Prozessautomatisierung abzielt. [33] Demnach kommt es hierbei regelmäßig zu Interaktionen mit den prozessbeteiligten Anwendern.
Die Process Engine ist der Dreh- und Angelpunkt automatisierter Prozessabläufe. [33] Sie arbeitet dabei das technische Prozessmodell in der vorgegebenen Reihenfolge ab und übernimmt damit die Prozesssteuerung. Realisiert wird diese mittels Benachrichtigungen der Prozessbeteiligten über anstehende Aufgaben, der Verarbeitung der aus der Erledigung dieser Aufgaben resultierenden Ergebnisse (Human Workflow Management) sowie der Orchestrierung von IT-Services. [31]
Wann genau Service-Aufrufe oder bestimmte Aufgaben stattfinden, ist im Prozessmodell definiert oder ergibt sich anhand der Ergebnisse einer Aufgabenerledigung bzw. eines Service-Aufrufes, wodurch die Einflussmöglichkeiten der Prozessbeteiligten auf den Prozessablauf gewahrt bleiben. [31]
Diese Einflussmöglichkeiten sind gerade im Versicherungswesen von hoher Relevanz, da es hier durchaus zu Einzelfallentscheidungen kommen kann, die im Standardprozess nicht vorgesehen sind. Das stetig wachsende Angebot an Spezialversicherungen sowie der enge Kontakt mit ihren Kunden fordern der assona GmbH stets ein hohes Maß an Flexibilität ab. Daher muss auch beim Einsatz einer Process Engine die Möglichkeit einer manuellen Prozesssteuerung erhalten bleiben.
Nachfolgend soll eine auf die assona GmbH zugeschnittene Übersicht der Hersteller von BPM-Suiten sowie deren Produkte erstellt werden, aus der im Anschluss ein System ausgewählt wird. Für die Auswahl einer solchen Suite ist dies notwendig, da es in diesen Segment bereits schwer fällt, den Überblick zu behalten.
3.2.2. Unterscheidung von BPM-Suiten
Im Vorfeld einer Sichtung solcher Produkte werden jedoch zunächst deren unterschiedliche Ausprägungen genauer betrachtet, um bei der späteren Selektion die Auswahl infrage kommender Systeme schärfer eingrenzen zu können.
Zu diesem Thema hat Brück bereits in einer 2011 durchgeführten Marktstudie eine Unterteilung der BPM-Werkzeuge in „Business Process Modeling and Analysis“ (BPMA) und „Business Process Management System“ (BPMS) vorgenommen, wobei BPMA-Funktionalitäten üblicherweise Bestandteile von BPM-System seien. [34]
Freund zufolge legen BPMA-Werkzeuge dabei ihren Fokus mehr auf das Prozessmanagement im organisatorischen Sinne und dienen der Dokumentation, Analyse und Simulation betrieblicher Abläufe. [35]
Zu BPMS ergänzt er deren Fokus auf die softwaretechnische Umsetzung der Prozesse und die Ausführung eines technischen Prozessmodells in einer Process Engine. [35]
Eine etwas differenziertere Unterscheidung der Systeme trifft Freund bei der Kategorisierung anhand der zugrunde liegenden Systemarchitektur sowie des Lizenzmodells. Die daraus resultierenden Kategorien „Pure Play BPMS“, „Embedded BPMS“, „SaaS BPMS“ und „Open-Source-BPMS“ werden in Tabelle 3 kurz vorgestellt und nachfolgend verglichen.
Tabelle 3: BPMS-Kategorien [36]
Kategorie | Beschreibung |
Pure Play BPMS |
|
Embedded BPMS |
|
SaaS BPMS |
|
Open-Source-BPMS |
|
Pure Play BPMS zeichnen sich vor allem durch den Hersteller-Support aus, erfordern allerdings auch proprietäres Know-How und eignen sich daher vor allem für Organisationen mittleren und großen Umfangs. [35]
Open-Source-BPMS auf der anderen Seite überzeugen vor allem durch ihre Flexibilität und Herstellerunabhängigkeit, setzen technisch jedoch meist ein Java-Umfeld sowie entsprechendes Know-How voraus, was diese Systeme vor allem für Organisationen mit eigener IT-Abteilung und entsprechendem Fachpersonal interessant macht. [35]
Während bei SaaS BPMS häufig der Datenschutz ein Ausschlusskriterium darstellt, sind es bei Embedded BPMS eher die Einschränkungen hinsichtlich der Integration eigener Systeme. [35]
Trotz dieser differenzierteren Unterscheidung der Systeme kritisiert Brück, „dass auch hierbei häufig keine eindeutige Aussage über die korrekte Zuordnung getroffen werden kann“[37] und kategorisiert diese in ihrer Marktstudie zusätzlich nach den Phasen des BPM-Lebenszyklus. Diese Kategorien sind in Tabelle 4 genannt und beschrieben.
Tabelle 4: BPMS-Kategorien anhand des BPM-Lebenszyklus [38]
Kategorie | Beschreibung |
BPMA/E |
|
Modeling |
|
GBPM |
|
Sonstige |
|
3.3. Auswahl einer BPMS
Schon im Jahr 2010 wurden für Gartners „Magic Quadrant for Business Process Management Suites“ 60 verschiedene Anbieter berücksichtigt. [39] Tendenziell kommen hier noch immer neue Produkte dazu, was einen direkten Vergleich aller unverhältnismäßig aufwendig gestaltet. Bestätigt wird dieser Trend durch die im Jahr 2011 von Brück durchgeführte Marktstudie, in der bereits 104 Systeme berücksichtigt wurden. [40]
Angesichts dieser rasant zunehmenden Zahl auf dem Markt erhältlicher BPM-Tools unterschiedlicher Hersteller stellen die zuvor erarbeiteten Unterscheidungsmerkmale sowie die o.g. Marktstudie eine ideale Ausgangsbasis für die Auswahl einer zur assona GmbH passenden Lösung dar.
3.3.1. Anforderungen
Die assona GmbH stellt zahlreiche Bedingungen hinsichtlich der Einführung einer BPMS, die es bei der Auswahl eines solchen Systems zu erfüllen gilt. Diese sind sowohl strategischer, fachlicher aber auch technischer Natur und dienen in erster Linie der Risikominimierung unter Berücksichtigung des bislang fehlenden Know-Hows beim Umgang mit diesem Konzept.
Es wird prinzipiell eine „out-of-the-box“-Lösung bevorzugt, die aufgrund datenschutzrechtlicher Bestimmungen innerhalb der eigenen Infrastruktur betrieben werden muss. Demnach kommen nur „Pure Play BPMS“ oder „Open-Source-BPMS“ infrage. Das setzt jedoch voraus, dass sich diese Systeme technisch in die vorhandene Infrastruktur integrieren lassen.
Technisch werden durch die IT nachfolgende Anforderungen gestellt:
- Zur einfacheren Software-Verteilung soll das System vollständig webbasiert arbeiten.
- Dazu muss das System im Linux/Java-Umfeld in einem Apache Tomcat Application Server betrieben werden.
- Das System bietet Standardschnittstellen wie REST oder SOAP zur Interaktion mit anderen IT-Systemen.
Aus fachlicher Sicht liegt der Fokus vor allem auf der Modellierung und damit auch der Dokumentation der einzelnen Prozesse.
Dem Management ist es zudem wichtig, dass das System auch in der Lage ist, die erstellten Prozessmodelle automatisiert ausführen zu können. Nur so könnten die Potenziale eines solchen Konzepts voll ausgeschöpft werden. Weiterhin soll das System auch Funktionen des Prozess-Controllings bieten, wobei der Fokus hierbei hauptsächlich auf dem Monitoring der Durchlaufzeiten liegt.
3.3.2. BPMS-Übersicht
Unter Berücksichtigung des o.g. Anforderungskatalogs wurden auf Basis der BPM-Marktstudie von Brück ein „Pure Play“- und zwei „Open-Source“-Varianten ausgewählt. Diese sind in Tabelle 5 im Kontext des BPM-Lebenszyklus gegenübergestellt.
Tabelle 5: BPMS-Übersicht [41]
Kategorie | Hersteller / Produkt | Konzeption / Strategie | Prozess-Design | Prozess-Implementierung | Prozess-Ausführung | Prozess-Controlling | KVP | Pure Play | Open-Source |
GBPM |
inubit AG BPM Suite |
X |
X |
X |
X |
X |
X |
X |
|
BPMA/E |
JBoss Community jBPM |
X |
X |
X |
X |
X |
|||
BPMA/E |
Activiti Community BPM Platform |
X |
X |
X |
X |
X |
Alle drei Suiten lassen aufgrund ihrer technischen Struktur einen hohen Integrationsgrad hinsichtlich der bestehenden IT-Systeme der assona GmbH erwarten. Eine genauere Unterscheidung findet nachfolgend im Rahmen eines analytischen Hierarchie-Prozesses (AHP) statt.
3.3.3. AHP: BPMS
Im Hinblick auf die funktionale Bewertung der drei o.g. Systeme wurden zunächst dem BPM-Lebenszyklus entsprechende Kriterien festgelegt und unterschiedlich gewichtet. Aus den zuvor gesammelten Anforderungen der assona GmbH lässt sich dabei ein deutlicher Fokus auf die Phasen „Prozess-Design“, „Prozess-Implementierung“ und „Prozess-Ausführung“ feststellen.
Abbildung 8 stellt die einzelnen Kriterien mit ihren jeweiligen Gewichten und Inhalten hierarchisch dar.

Abbildung 8: Gewichtete Bewertungskriterien [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]
Die nahtlose Übersetzung fachlicher in technische Prozessmodelle ist ebenso Bestandteil der „Prozess-Implementierung“ wie die Konnektivität, also die Bereitstellung von Standardschnittstellen zu anderen Systemen sowie Standardfunktionen wie z.B. dem Email-Versand. [43]
Im Kontext der „Prozess-Ausführung“ wird neben administrativen Funktionen, u.a. zur Steuerung der Process Engine, auch die Einbindung der Mitarbeiter bewertet. Letzteres beinhaltet sowohl die Mächtigkeit als auch die Usability der Benutzeroberfläche. [43] Die bestimmten Bewertungskriterien werden wie in Abbildung 8 ersichtlich gewichtet und in einem Ranking gegenübergestellt.
Wie Abbildung 9 verdeutlicht, hat die „Prozess-Implementierung“ damit den höchsten Stellenwert, gefolgt vom „Prozess-Design“ und der „Prozess-Ausführung“ auf Platz 2. Auf Platz 4 liegt das „Prozess-Controlling“ vor „Konzeption/Strategie“, da in dieser Betrachtung kein 3. Platz vergeben wurde.

Abbildung 9: AHP BPMS – Ranking der Kriterien [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]
Abbildung 10 bis Abbildung 14 stellen die Ergebnisse der Rankings grafisch dar und zeigen auf, wie sich die Systeme im jeweiligen Vergleich zueinander positionieren.

Abbildung 10: AHP BPMS – Ranking lt. Konzeption/Strategie [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]

Abbildung 11: AHP BPMS – Ranking lt. Prozess-Design [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]

Abbildung 12: AHP BPMS – Ranking lt. Prozess-Implementierung [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]

Abbildung 13: AHP BPMS – Ranking lt. Prozess-Ausführung [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]

Abbildung 14: AHP BPMS – Ranking lt. Prozess-Controlling [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]
Abgesehen vom „Prozess-Design“ gibt es bei den übrigen Kriterien keine nennenswerten Unterschiede zwischen den einzelnen Systemen. In diesem Bereich kann die quelloffene „Activiti Community BPM Platform“ ihre Stärken in der Prozess-Modellierung ausspielen.
Hierbei überzeugen vor allem der webbasierte „Activiti Modeler“ sowie der auf eclipse basierende „Activiti Designer“ bei der Erstellung BPMN 2.0 konformer Prozessmodelle u.a. durch ihre intuitive Bedienung.
Nach der Auswertung aller fünf Kriterien werden diese zusammenfassend in einem Gesamt-Ranking gegenüber gestellt. Abbildung 15 veranschaulicht das Ergebnis dieser Auswertung ohne Berücksichtigung etwaiger Kosten, wie z.B. Lizenzkosten oder Schulungsaufwände.

Abbildung 15: AHP – Ergebnis ohne Kosten [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]
Allerdings ist dieses Ergebnis in der Hinsicht kritisch zu bewerten, dass dieser vermeintlich große Vorsprung den beiden anderen Systemen gegenüber daher rührt, dass das System in dem Bereich „Konzeption/Strategie“ als einziges punkten kann. Dieses Kriterium stellt jedoch mit einer Gewichtung von 5% das mit Abstand am wenigsten relevante dar.
Demzufolge sollen im Anschluss auch die Kosten berücksichtig werden, die die Systeme mit sich bringen. Als einziges proprietäres System kann die „inubit AG BPM Suite“ den beiden Open-Source-Systemen gegenüber keinem Kostenvergleich standhalten. Zwar werden für alle Systeme Schulungsaufwände berücksichtigt, doch dürften marktübliche Lizenzgebühren den monetären Aufwand für die „inubit AG BPM Suite“ vervielfachen.
Mangels belastbarer Informationen hinsichtlich der tatsächlichen Höhe der Lizenzgebühren wird angenommen, dass diese ebenso hoch ausfallen, wie der Schulungsaufwand. Bei gleichem Schulungsaufwand für alle drei Systeme fallen die Gesamtkosten für die „inubit AG BPM Suite“ demnach doppelt so hoch aus, wie bei den anderen beiden.
Obwohl dieser Wert in der Realität wohl deutlich zu niedrig angesetzt ist, ergibt sich schon damit ein vollkommen anderes Bild bei der Bewertung der drei Systeme, wie Abbildung 16 verdeutlicht.

Abbildung 16: AHP – Ergebnis mit Kosten [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]
Unabhängig davon punktet sie zudem durch eine hohe Flexibilität hinsichtlich der Integration in verschiedene hardware- und softwaretechnische Umgebungen.
Sie wird damit der assona GmbH auch im Hinblick auf eine Risikominimierung bei der Umsetzung des erarbeiteten Konzepts eines softwaregestützten Prozessmanagements empfohlen. Zudem dient sie im nachfolgenden Praxisbeispiel als Mittel der Wahl bei der Referenzimplementierung eines beispielhaften Prozesses aus dem Versicherungskontext der assona GmbH.
4. Praxisbeispiel: Schadenbearbeitung
Die gewonnenen Erkenntnisse aus den vorhergehenden Kapiteln sollen nachfolgend auf ihre Praxistauglichkeit hin überprüft werden. Dabei wird anhand eines exemplarischen Schadenbearbeitungsprozesses aufgezeigt, wie sich das Konzept eines softwaregestützten Managements flexibler Prozesse auf Basis von BPMN bei der assona GmbH umsetzen lässt.
Zu diesem Zweck wird vorab eine exemplarische, softwaretechnische Infrastruktur geschaffen, die als Basis für die Umsetzung des Konzepts dient.
Dabei wird zunächst eine MySQL-Datenbank angelegt. Die Struktur dieser Datenbank zeigt Anhang 1. Auf Basis des mybatis Mapping-Frameworks wird die Datenzugriffsschicht der auf dem Spring-Framework beruhenden SOA-Komponente implementiert. In dieser werden, wie in Abbildung 19 dargestellt, Services zum Suchen und Speichern der Entitäten aber auch zur Kommunikation mit Partnern bereit gestellt.
Die implementierte SOA-Komponente wird im weiteren Verlauf dem Applikationskontext der „Activiti Community BPM Platform“ injiziert, sodass die in dieser BPMS ausgeführten Modelle auf die Services zugreifen können.
Vor der Modellierung und Ausführung des Beispiel-Prozesses soll dieser nachfolgend näher erläutert werden.
4.1. Erläuterung des Beispiel-Prozesses
Der Prozess beschreibt den exemplarischen Ablauf einer Schadenbearbeitung: Ein Kunde meldet sich bei der Versicherung, um einen Schaden zu melden und ggf. Leistungen der Versicherung in Anspruch zu nehmen.
Hierbei wird zunächst geprüft, ob der Kunde überhaupt versichert ist. Nur wenn diese Voraussetzung erfüllt ist, wird fortgefahren. Zu diesem Zweck werden vor der Erfassung der Schadensdaten noch die Kunden- und Gerätedaten überprüft und ggf. aktualisiert.
Der weitere Verlauf hängt sowohl vom Zustand des versicherten Geräts als auch vom Versicherungsumfang ab.
Bei Totalschäden wird nur dann ein Ersatzgerät gestellt, wenn diese Leistung bei Vertragsabschluss vereinbart worden ist. Bei Teilschäden hingegen wird je nach Größe des versicherten Geräts entweder vor Ort repariert (Großgerät) oder das Gerät zur Reparatur abgeholt.
Mit der Erteilung eines Service-Auftrags ist der Prozess abgeschlossen.
4.2. Umsetzung anhand des BPM-Lebenszyklus
Der Weg des Prozesses von dessen Planung bis zum Controlling wird anhand des BPM-Lebenszyklus beschrieben. Abschließend wird zudem eine mögliche Vorgehensweise aufgezeigt, wie sich die im Abschnitt 3.3 ausgewählte BPMS in die bestehende Infrastruktur der assona GmbH integrieren lässt.
Der im Abschnitt 2.3 beschriebene BPM-Lebenszyklus dient hierbei als Grundlage für die Umsetzung des Schadenbearbeitungsprozesses.
4.2.1. Prozess-Design
In dieser Phase des BPM-Lebenszyklus wird der Prozess durch die Fachabteilung in seinem Soll-Zustand modelliert. Abbildung 17 zeigt das Ergebnis dieser Modellierung: Den Ablauf des Schadenbearbeitungsprozesses als Flowchart.
Dieses fachliche Modell wird im weiteren Verlauf durch die IT-Abteilung u.a. um technische Details ergänzt, bevor es technisch umgesetzt wird.

Abbildung 17: Prozess der Schadenbearbeitung – Flowchart [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]
4.2.2. Prozess-Implementierung
Das fachliche Modell wird für die Ausführung in einer BPMS entsprechend den Anforderungen der IT-Abteilung angepasst. Dabei wird das Flowchart-Modell in ein BPMN 2.0 Modell überführt, welches in Abbildung 18 gezeigt wird.

Abbildung 18: Prozess der Schadenbearbeitung – BPMN 2.0 [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]

Abbildung 19: SOA-Übersicht / IT-Schnittstellen [backref name="bt_44_64_68_69_70_71_72_73_75_76_77_78_79" /]
4.2.3. Prozess-Ausführung
Das technische Prozess-Modell wird nach dessen Fertigstellung in die BPMS hochgeladen und dort ausgeführt. Im Hinblick auf den Schadenbearbeitungsprozess wird für jeden gemeldeten Schaden eine neue Prozessinstanz erzeugt.
Jede Instanz hat dabei Zugriff auf alle Ressourcen, die der BPMS zur Verfügung stehen.
4.2.4. Prozess-Controlling
Einer der großen Mehrwerte eines softwaregestützten Prozessmanagements ist die Erhöhung der Transparenz der Prozessabläufe und zudem auch eine effizientere Prozessanalyse. Hierbei kann bereits auf grundlegende Kennzahlen der BPMS, wie z.B. die Prozessdurchlaufzeit zugegriffen werden.
Das Prozess-Controlling gibt auf Grundlage der Prozessanalyse in jeder Iteration des BPM-Lebenszyklus den Anstoß für den kontinuierlichen Verbesserungsprozess.
4.3. Integration in bestehende IT-Infrastruktur
Nach der exemplarischen Implementierung eines Prozesses aus dem Versicherungskontext der assona GmbH soll nachfolgend betrachtet werden, wie sich eine BPMS in deren bestehende IT-Infrastruktur integrieren lässt.
Dabei lässt sich allgemein feststellen, dass Unternehmen, die bereits vor der Einführung einer BPMS den SOA-Ansatz verfolgt haben, hierbei klar im Vorteil sind.
4.3.1. Ist-Architektur: SOA
Auch bei der assona GmbH hat sich in den letzten Jahren zunehmend der Ansatz einer serviceorientierten Architektur (SOA) durchgesetzt. Diese basiert auf lose gekoppelten, stark kohäsiven Diensten, die miteinander interagieren. [45]
In diesem Kontext wird die eingangs erwähnte webbasierte Fachanwendung zur Vertrags- und Schadenbearbeitung der assona GmbH in einem Applikationsserver betrieben. Zudem stehen dort Webservices als Schnittstelle nach außen zur Verfügung. Das Zusammenspiel von Applikationsserver, Webanwendungen und anderen Diensten ist in Abbildung 20[46] schematisch dargestellt.

Abbildung 20: SOA-Architektur
Diese Art der Architektur ermöglicht über alle Schichten einer Software (Präsentation, Logik, Datenzugriff) hinweg einen standardisierten und sicheren Zugriff auf wiederverwendbare Funktionen. [47]
4.3.2. Soll-Architektur: SOA + BPMS
Die Vorteile dieses Paradigmas werden deutlich, wenn diese Dienste unabhängig davon entwickelten Systemen zugänglich gemacht werden sollen – in diesem Fall der „Activiti Community BPM Platform“ (BPMS), zur Ausführung des modellierten Prozesses der Schadenbearbeitung.
Hierbei kommt vor allem das Schichtenkonzept von SOA zum Tragen. In der Literatur werden zumeist vier Schichten unterschieden: Basiskomponenten, Orchestrierungskomponenten, Prozesskomponenten und Frontends. [48]
Während die Basiskomponenten Grundfunktionen in Form von Services bereitstellen, ermöglichen Orchestrierungskomponenten deren Steuerung und Zusammenspiel z.B. hinsichtlich der Ablaufsteuerung. [48]
In dem gewählten Ansatz werden Prozesskomponenten durch die BPMS selbst realisiert, wobei es sich dabei um Komponenten handelt, die den Ablauf eindeutig identifizierter Prozesse steuern. Das Frontend wird hierbei durch eine Webanwendung realisiert, die direkt auf die Prozesskomponenten zugreifen kann.
Abbildung 21[49] offenbart dabei bereits eine Besonderheit der gewählten BPM-Suite: Sie lässt sich nahtlos in demselben Applikationsserver betreiben, wie die anderen Webanwendungen der assona GmbH, da sie grundsätzlich auf der gleichen Architektur basiert.
Der s.g. „Activiti Explorer“ ist eine Webanwendung, über welche die Benutzer Zugriff auf die Process Engine haben, in der das technische Prozessmodell abgearbeitet wird. [50]Die Anwendung greift auf eine eigenständige Datenbank zu, in der alle prozessrelevanten Daten gehalten werden. Das sind bspw. Informationen zum Prozessstatus oder auch Messergebnisse für das Controlling.
Die Kommunikation mit anderen Diensten erfolgt wie bei den anderen Webanwendungen über Services, um welche der Applikationskontext durch das Hinzufügen der Core-Bibliothek erweitert wird. Auf diese Weise kann das Portal und damit auch jede Prozessinstanz mit den notwendigen Daten der Fachanwendung versorgt werden.
4.4. Kritische Betrachtung des Konzepts
So gut sich das Konzept des softwaregestützten Prozessmanagements unter Verwendung der „Activiti Community BPM Platform“ als BPMS und dem mitgelieferten „Activiti Explorer“ als Frontend in die IT-Infrastruktur der assona GmbH integrieren lässt, bietet es doch auch einiges an Diskussionsgrundlage.
So erweitern die Hersteller von BPMS den BPMN-Standard, um zusätzliche Funktionalitäten in ihre Systeme einzubauen (z.B. zur Erzeugung von Formularen) und sich so von anderen Herstellern absetzen zu können. [51] Damit führen sie jedoch den Kompatibilitätsgedanken, der hinter diesem Standard steht, ad absurdum. Eine Portierung der Prozessmodelle auf eine andere BPMS wird damit eher zur Migration.
Das gilt es für die assona GmbH zu beachten, wenn für den praktischen Betrieb der Funktionsumfang der „Activiti Community BPM Platform“ nicht ausreichend ist und sie sich die Frage stellt, ggf. doch die „inubit AG BPM Suite“ oder ein ähnliches System einzusetzen.
Ein weiterer kritisch zu bewertender Punkt betrifft die rasch zunehmende Komplexität der BPMN-Modelle durch die darin enthaltenen Geschäftsregeln (Business Rules), z.B. für die folgenden Bereiche: [52]
- Entscheidungspunkte im Kontrollfluss
- Vollständigkeitsprüfung von Formularen
- Prüfung der Datenkonsistenz
Hier sollte in der Praxis der Einsatz eines Business Rule Management Systems (BRMS) in Betracht gezogen werden. Durch den Einsatz eines solchen Systems lassen sich der Prozess selbst weiter flexibilisieren und zudem sowohl die Qualität also auch der Automatisierungsgrad bei der Entscheidungsfindung erhöhen. [53]
Somit lässt es sich auch besser und schneller auf sich verändernde Marktanforderungen reagieren, womit der Mehrwert des Konzepts eines softwaregestützten Prozessmanagement weiter zunimmt.
5. Schlussbetrachtung
Nachfolgend wird die vorliegende Arbeit hinsichtlich der Erreichung der eingangs gesteckten Ziele reflektiert. Es ging dabei in erster Linie darum, ein Konzept zu entwickeln, das der assona GmbH bei der Entwicklung und Einführung eines softwaregestützten Prozess-Managements als Grundlage dienen kann.
Die Ergebnisse dieser Konzept-Entwicklung werden im folgenden Abschnitt 5.1 kapitelweise zusammengefasst. In Abschnitt 5.2 wird danach die Quintessenz der vorliegenden Arbeit herauskristallisiert, bevor in Abschnitt 5.3 abschließend ein Ausblick auf weitere Fragestellungen bzw. künftige Entwicklungen gegeben wird.
5.1. Resümee
Einleitend wurde in Abschnitt 1 zunächst auf die zentrale Problemstellung eingegangen – die sukzessive steigende Anzahl an Prozessen bei der assona GmbH sowie den zunehmend schwieriger umzusetzenden Anforderungen hinsichtlich deren Flexibilität.
Nachdem in Abschnitt 2 herausgestellt wurde, dass für die Lösung dieses Problems auch die aktuellen Softwareentwicklungsprozesse der assona GmbH angepasst werden sollten, wurde zunächst die Thematik des Geschäftsprozessmanagements grundlegend umrissen. Anschließend wurde auf dessen strategische Bedeutung innerhalb des Unternehmens eingegangen.
Aufbauend auf diese Grundlagen wurde in Abschnitt 3 zunächst eine Modellierungssprache ausgewählt, die in erster Linie den Ansprüchen modellgetriebener Softwareentwicklung sowie den Bedürfnissen der Fachabteilungen bei der Modellierung von Prozessen gleichermaßen gerecht wird – die BPMN. Ihre breite Akzeptanz in Unternehmen war richtungsweisend für das zu entwickelnde Konzept eines softwaregestützten Prozessmanagements: Sie ist prädestiniert für den Einsatz einer BPMS. Daher wurde anhand verschiedener Kriterien und unter Berücksichtigung etwaiger Kosten mittels eines AHP eine BPMS ausgewählt.
Das Konzept, Geschäftsprozesse mittels BPMN zu modellieren und diese Modelle in einer BPMS auszuführen, wurde im Abschnitt 4 praktisch umgesetzt. Dabei wurde zum einen die praktische Relevanz des BPM-Lebenszyklus veranschaulicht. Zum anderen wurden die Vorteile einer serviceorientierten Architektur bei der Integration einer BPMS in die bestehende IT-Infrastruktur herausgestellt.
5.2. Fazit
Gerade in einem sich durch starken Wettbewerb auszeichnenden Wirtschaftsbereich wie dem Versicherungswesen sind flexible und effiziente Prozesse sowie deren stetige Verbesserung unabdingbar.
Ein softwaregestütztes Prozessmanagement auf Basis von BPMN und unter Verwendung einer BPMS kann bei einer entsprechenden Integration in die IT-Landschaft des Unternehmens eine grundlegende Unterstützung bieten. Allerdings kann ein solches Konzept nur dann seine Vorteile ausspielen, wenn das Geschäftsprozessmanagement in seiner strategischen Bedeutung für das Unternehmen erkannt und entsprechend in der Unternehmenskultur verankert wird.
Aber ein solches Vorgehen birgt natürlich auch Risiken. So ist bspw. der Initialaufwand für die Analyse und Modellierung der Geschäftsprozesse eines Unternehmens keinesfalls zu unterschätzen.
Jedoch stehen auch hier den Risiken entsprechende Chancen gegenüber. So können Schwachstellen in Prozessen nur dann aufgespürt und verbessert werden, wenn die genauen Prozessabläufe bekannt sind. Durch eine kontinuierliche Verbesserung der Geschäftsprozesse im Rahmen des BPM-Lebenszyklus sowie der Flexibilisierung der Prozesse durch ein softwaregestütztes Management lassen sich Chancenpotentiale ausschöpfen und die Wettbewerbsfähigkeit verbessern.
Neben der Erhöhung der Prozesstransparenz sowie der Prozessoptimierung und dem damit einhergehenden Potential einer Stärkung der Marktposition lassen sich zahlreiche weitere Unternehmensaspekte nennen, die von einem softwaregestützten Prozessmanagement profitieren können.
Nachfolgend sollen einige davon näher erläutert werden.
5.3. Ausblick
Auch wenn das im Rahmen dieser Arbeit entwickelte Konzept eines softwaregestützten Prozessmanagements primär auf die Bedürfnisse der assona GmbH ausgerichtet ist, so lassen sich doch zahlreiche generelle Anwendungsszenarien finden, in denen durch die Integration eines softwaregestützten Prozessmanagements ein Mehrwert generiert werden kann.
Dabei sind zunächst drei Arten der Integration zu betrachten:
- Koexistenz von Fachanwendung und BPMS
- Integration der Process Engine in die Fachanwendung
- Ablösung der Fachanwendung durch eine BPMS
Der erste Punkt, die Koexistenz von Fachanwendung und BPMS, beschreibt genau das Szenario aus Abschnitt 4. Hierbei können sowohl die Fachanwendung als auch die BPMS über Schnittstellen miteinander kommunizieren. Hinsichtlich der Prozessüberwachung lässt sich dadurch auch aus der Fachanwendung heraus auf den Prozessfortschritt zugreifen und Einfluss nehmen.
Für die assona GmbH von Interesse dürfte eine erweiterte Statuserfassung sein, die sich z.B. für die Schadenbearbeitung auf Grundlage einer BPMS implementieren lässt. In Verbindung mit den bereits erhobenen Daten zum jeweiligen Schaden lässt sich damit zudem detailliert ablesen, wo im Gesamtprozess man sich gerade befindet.
Ein weiteres für diese Art der Integration von BPMS und Fachanwendung vorstellbares Szenario ist die Umsetzung eines E-Learning-Konzepts, bei dem auf Grundlage der BPMS ein Wizard für die Fachanwendung implementiert wird. Der zeitliche Aufwand bei Schulungen kann dadurch gerade im Hinblick auf neue Mitarbeiter deutlich minimiert werden, da während der Anlernphase kein zweiter Mitarbeiter permanent involviert sein muss.
Neben der Koexistenz von Fachanwendung und BPMS ist als zweite Möglichkeit die direkte Integration der Process Engine in die Fachanwendung denkbar. Im Falle der „Activiti Community BPM Platform“ handelt es sich dabei um eine SOA-Komponente, die der Anwendung als Bibliothek hinzugefügt werden kann.
Der große Vorteil an diesem Szenario liegt in der uneingeschränkten Gestaltungsfreiheit bei der Entwicklung der Fachanwendung.
Im Gegensatz dazu steht die dritte Möglichkeit – die Ablösung der Fachanwendung durch die BPMS. Hierbei ist man jedoch vollständig vom darunter liegenden System abhängig. Die Risiken und Chancen eines solchen Vorgehens sind dabei allerdings stets individuell zu betrachten.
Fußnoten
- [1]Vgl. Radisch, M. et al. (2011), S. 189.↩
- [2]assona GmbH (2010), o.S.↩
- [3]Quelle: Eigene Darstellung. In Anlehnung an: it-agile GmbH (2012), o.S.↩
- [4]it-agile GmbH (2012), o.S.↩
- [5]Vgl. Rempp, G. et al. (2011), S. 13.↩
- [6]Vgl. Müller, J. (2011), S. 7.↩
- [7]Vgl. Rempp, G. et al. (2011), S. 18.↩
- [8]Vgl. Stahl, T. et al. (2007), S. 3.↩
- [9]Quelle: Eigene Darstellung. In Anlehnung an: Rempp, G. et al. (2011), S. 19.↩
- [10]Vgl. Stahl, T. et al. (2007), S. 4.↩
- [11]Quelle: Eigene Darstellung. In Anlehnung an: Brown, A. W. et al. (2005), S. 9.↩
- [12]Vgl. Brown, A. W. et al. (2005), S. 8.↩
- [13]Vgl. Gadatsch, A. (2010), S. 1.↩
- [14]Quelle: Eigene Darstellung. In Anlehnung an: Gadatsch, A. (2010), S. 2.↩
- [15]Vgl. Müller, J. (2011), S. 9.↩
- [16]Quelle: Eigene Darstellung. In Anlehnung an: Graf von Bündingen, G., Schlaf, S. (2011), S. 83; Slama, D., Nelius, R. (2011), S. 15.↩
- [17]Vgl. Graf von Bündingen, G., Schlaf, S. (2011), S. 83; Slama, D., Nelius, R. (2011), S. 15; Brück, S. (2011), S. 5.↩
- [18]Vgl. Müller, J. (2011), S. 8.↩
- [19]Vgl. Slama, D., Nelius, R. (2011), S. 81.↩
- [20]Minonne, C. et al. (2011), S. 8.↩
- [21]Vgl. Minonne, C. et al. (2011), S. 9.↩
- [22]Quelle: Eigene Darstellung. In Anlehnung an: Minonne, C. et al. (2011), S. 30.↩
- [23]Vgl. Minonne, C. et al. (2011), S. 30.↩
- [24]Vgl. ISO (2010), o.S.↩
- [25]Vgl. Slama, D., Nelius, R. (2011), S. 85.↩
- [26]Vgl. Natschläger, C. (2011), S. 1.↩
- [27]Vgl. Müller, J. (2011), S. 11.↩
- [28]Vgl. Slama, D., Nelius, R. (2011), S. 87f.↩
- [29]Vgl. Slama, D., Nelius, R. (2011), S. 91.↩
- [30]Quelle: Eigene Darstellung.↩
- [31]Vgl. Freund, J. et al. (2010), S. 7.↩
- [32]Quelle: Eigene Darstellung. In Anlehnung an: Freund, J. et al. (2010), S. 7.↩
- [33]Vgl. Freund, J. et al. (2010), S. 6.↩
- [34]Vgl. Brück, S. (2011), S. 3.↩
- [35]Vgl. Freund, J. (2010), S. 15.↩
- [36]Quelle: Eigene Darstellung. In Anlehnung an: Freund, J. (2010), S. 15.↩
- [37]Brück, S. (2011), S. 4f.↩
- [38]Quelle: Eigene Darstellung. In Anlehnung an: Brück, S. (2011), S. 5.↩
- [39]Vgl. Sinur, J., Hill, J. B., Gartner (2010), o.S.↩
- [40]Vgl. Brück, S. (2011), S. 21.↩
- [41]Quelle: Eigene Darstellung. In Anlehnung an: Brück, S. (2011), S. 7-15.↩
- [42]Vgl. Hohwiller, J., Schlegel, D. (2011), S. 4.↩
- [43]Vgl. Hohwiller, J., Schlegel, D. (2011), S. 7.↩
- [44]inubit AG (2011), S. 5.↩
- [45]Vgl. Schröpfer, C. (2010), S. 1↩
- [46]Quelle: Eigene Darstellung. In Anlehnung an: Schröpfer, C. (2010), S. 25.↩
- [47]Vgl. Schröpfer, C. (2010), S. 21↩
- [48]Vgl. Slama, D., Nelius, R. (2011), S. 46↩
- [49]Quelle: Eigene Darstellung. In Anlehnung an: Schröpfer, C. (2010), S. 25; Allweyer, T. (2011), S. 221.↩
- [50]Vgl. Activiti Community (2011), o.S.↩
- [51]Vgl. Slama, D., Nelius, R. (2011), S. 36.↩
- [52]Slama, D., Nelius, R. (2011), S. 132.↩
- [53]Vgl. Slama, D., Nelius, R. (2011), S. 133.↩
Anhang

Anhang 1: ERD – Beispielanwendung zur Vertrags- und Schadenbearbeitung (Quelle: Eigene Darstellung.)
Abkürzungsverzeichnis
BPMN | Business Process (Model and Notation / Modeling Notation) |
BPM | Business Process Management |
BPMA | Business Process Modeling and Analysis |
BPMA/E | BPMA + Execution |
GBPM | Ganzheitliches BPM |
BPMS | Business Process Management (Suite / System) |
BRMS | Business Rule Management System |
BPD | Business Process Diagram |
FDD | Feature Driven Development |
MDD | Model Driven Development |
DSL | Domain Specific Language |
PIM | Platform Independent Model |
PSM | Platform Specific Model |
DACH | Deutschland (D), Österreich (A), Schweiz (CH) |
ISO | International Organization for Standardization |
OMG | Object Management Group |
ARIS | Architektur Integrierter Informationssysteme |
KVP | Kontinuierlicher Verbesserungsprozess |
REST | Representational State Transfer |
SaaS | Software as a Service |
DB | Database |
DBCP | Database Connection Pool |
SOA | Serviceorientierte Architektur |
Literaturverzeichnis
Monographien
- Brück, S. (2011): Business Process Management-Werkzeuge – Marktübersicht, Analyse und Historie des BPM Marktes, München 2011, ISBN: 978-3-640-97466-5
- Freund, J., Rücker, B., Henninger, T. (2010): Praxishandbuch BPMN, München/Wien 2010, ISBN: 978-3-446-41768-7
- Gadatsch, A. (2010): Grundkurs Geschäftsprozess-Management Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker, 6. Aufl., Wiesbaden 2010, ISBN: 978-3-8348-0762-5
- Minonne, C., Colicchio, C., Litzke, M., Keller, T. (2011): Business Process Management 2011: Status Quo und Zukunft, Zürich 2011, ISBN: 978-3-7281-3402-8
- Müller, J. (2011): Strukturbasierte Verifikation von BPMN-Modellen, Wiesbaden 2011, ISBN: 978-3-8348-1571-2
- Rempp, G., Akermann, M., Löffler, M., Lehmann, J. (2011): Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis, Berlin/Heidelberg 2011, ISBN: 978-3-642-14469-1
- Schröpfer, C. (2010): Das SOA-Management-Framework, Berlin 2010, ISBN: 978-3-940019-98-1
- Slama, D., Nelius, R. (2011): Enterprise BPM Erfolgsrezepte für unternehmensweites Prozessmanagement, Heidelberg 2011, ISBN: 978-3-89864-687-1
- Stahl, T., Völter, M., Efftinge, S., Haase, A. (2007): Modellgetriebene Softwareentwicklung Techniken, Engineering, Management, 2. Aufl., Heidelberg 2007, ISBN: 978-3-89864-448-8
Sammelwerke
- Allweyer, T. (2011): BPM-Round-Trip: Wunsch oder Wirklichkeit?, in: Komus, A. (Hrsg.): BPM Best Practice Wie führende Unternehmen ihre Geschäftsprozesse managen, Berlin/Heidelberg 2011, S. 219-234, ISBN: 978-3-642-16724-9
- Brown, A. W., Conallen, J., Tropeano, D. (2005): Introduction: Models, Modeling, and Model-Driven Architecture (MDA), in: Beydeda, S., Book, M., Gruhn, V. (Hrsg.): Model-Driven Software Development, Berlin/Heidelberg 2005, S. 1-16, ISBN: 978-3-540-25613-7
- Graf von Bündingen, G., Schlaf, S. (2011): BPM-Methoden und –Tools als Basis für wirtschaftliche und compliancegerechte Abläufe im E.ON-Energie-Konzern, in: Komus, A. (Hrsg.): BPM Best Practice Wie führende Unternehmen ihre Geschäftsprozesse managen, Berlin/Heidelberg 2011, S. 77-89, ISBN: 978-3-642-16724-9
- Natschläger, C. (2011): Towards a BPMN 2.0 Ontology, in: Dijkman, R., Hofstetter, J., Koehler, J. (Hrsg.): Business Process Model and Notation Third International Workshop, BPMN 2011 Lucerne, Switzerland, November 2011 Proceedings, Berlin/Heidelberg 2011, S. 1-15, ISBN: 978-3-642-25159-7
- Radisch, M., Rehse, D., Junges, J. (2011): AGIL: Nachhaltige Verbesserung des Geschäftserfolges durch ganzheitliches Geschäftsprozessmanagement, in: Komus, A. (Hrsg.): BPM Best Practice Wie führende Unternehmen ihre Geschäftsprozesse managen, Berlin/Heidelberg 2011, S. 189-204, ISBN: 978-3-642-16724-9
Zeitschriften
- Freund, J. (2010): Wie Sie im BPM-Dschungel eine passende Lösung finden in: Computerwoche o.J., 2010, Nr. 33-34/10, S. 14-17
Internetquellen
- Activiti Community (2011): Activiti Components.
URL: http://www.activiti.org/components.html, Abruf am 19.02.2012 - assona GmbH (2010): Unternehmensprofil assona.
URL: https://www.assona.com/de/vsw/unternehmen/profil.jsp, Abruf am 17.02.2012 - Hohwiller, J., Schlegel, D. (2011): Funktionale Aspekte bei der BPM-Produktauswahl.
URL: http://www.de.capgemini.com/insights/publikationen/funktionale-aspekte-bei-der-bpmproduktauswahl/?d=0A3E4A83-272D-10E0-64A1-90808DD23B94, Abruf am 16.02.2012 - inubit AG (2011): inubit Suite 6 erweitert BPM.
URL: https://www.inubit.com/fileadmin/user_upload/inubit-suite/inubit_Suite_6.pdf, Abruf am 16.02.2012 - ISO (2010): ISO 5807:1985 – Information processing — Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts.
URL: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=11955, Abruf am 16.02.2012 - it-agile GmbH (2012): it-agile: Was ist FDD?.
URL: http://www.it-agile.de/fdd.html, Abruf am 16.02.2012 - Sinur, J., Hill, J. B., Gartner (2010): Magic Quadrant for Business Process Management Suites.
URL: http://www.gartner.com/technology/media-products/reprints/oracle/article161/article161.html, Abruf am 16.02.2012