Konzeption eines softwaregestützten Managements flexibler Prozesse des Versicherungswesens auf Basis von BPMN

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:

1. Die Implementierung eines Workflow-Managements in die bestehende Software ist mit dem gewählten Softwareentwicklungskonzept der assona GmbH schwer umzusetzen.
2. 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.
3. 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.

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.

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.

Bei der assona GmbH stellt jedes Software-Release im FDD-Sinne ein Projekt dar. Die o.g. Prozessschritte werden demnach gemäß dem Modell in abgewandelter Form umgesetzt.

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]

Die abstrakt beschriebene Klasse Customer wird unter Verwendung des J2EE-Code-Generators UML2EJB zu einer Java-Klasse Customer transformiert. An dieser Stelle könnten über spezielle Transformatoren verschiedene Zielformate wie z.B. XML ausgegeben werden.

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]

1. Es wird eine DSL zur Formulierung von Modellen benötigt.
2. 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.

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.

Die sich durch kritische Erfolgsfaktoren auszeichnenden Geschäftsfelder eines Unternehmens werden auf der strategischen Ebene betrachtet, in deren Aufgabenbereich die Entwicklung einer Unternehmensstrategie fällt. ^[15]

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.

Das Geschäftsprozessmanagement ist als iterativer Prozess zu verstehen, der über alle Management-Ebenen in der in Abbildung 5^[16] dargestellten Reihenfolge abläuft.

Die Abbildung stellt den s.g. BPM-Lebenszyklus dar und veranschaulicht, welche Phasen in diesem durchlaufen werden. In der Literatur finden sich nur selten genau übereinstimmende Beschreibungen dieses Zyklus.

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	Definition von Erfolgsfaktoren; Erstellung einer Prozesslandkarte; Festlegung von Standards und Methoden
Prozess-Design	Modellierung des Ist- und Soll-Prozesses; Definition der Prozessziele sowie der Verantwortlichkeiten; Bestimmen von Schnittstellen zu IT-Systemen Ergebnis: Fachliches Modell
Prozess-Implementierung	Anpassung an die IT-Systeme und Schnittstellen der Organisation Ergebnis: Technisches Modell
Prozess-Ausführung	Betrieb des Prozesses in der integrierten Umgebung bestehend aus BPMS und anderen Systemen der Organisation
Prozess-Controlling	Analyse von Schwachstellen im Prozess; Performance-Analyse; Vergleich des Soll- mit dem Ist-Prozess
Kontinuierlicher Verbesserungsprozess	Veränderungen planen und Verbesserungspotentiale ausschöpfen

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.

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.

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.

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.

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]

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.

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.

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.

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.

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	Eigenständige Systeme, die über Schnittstellen mit bereits vorhandenen Anwendungen interagieren; häufig werden diese innerhalb einer SOA betrieben Beispiel: Oracle BPM Suite
Embedded BPMS	i.d.R. keine eigenständigen Systeme, sondern Workflow-Steuerungskomponenten innerhalb eines Softwaresystems Beispiel: Alfresco ECM
SaaS BPMS	BPMS als Software as a Service; bislang noch relativ selten Beispiel: Cordys Process Factory
Open-Source-BPMS	Quelloffene Alternative zu „Pure Play BPMS“ und „Embedded BPMS“ Beispiel: Activiti BPM Platform

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	BPM-Tools mit dem Fokus auf Modellierung, Ausführung und Analyse von Geschäftsprozessen
Modeling	BPM-Tools mit dem Fokus auf Modellierung von Geschäftsprozessen
GBPM	BPM-Tools mit vollständiger technischer Unterstützung über den gesamten BPM-Lebenszyklus hinweg
Sonstige	BPM-Tools mit sonstigem Fokus

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.

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.

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.

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.

Eines der entscheidendsten Kriterien ist auch für Hohwiller und Schlegel die Modellierung der Prozesse mittels Web- oder Desktop-Client, die in das Kriterium „Prozess-Design“ einfließt. ^[42]

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.

Aufbauend auf dieser Gewichtung der einzelnen Kriterien wird im weiteren Verlauf jeweils ein Ranking für jedes Kriterium erstellt.

Abbildung 10 bis Abbildung 14 stellen die Ergebnisse der Rankings grafisch dar und zeigen auf, wie sich die Systeme im jeweiligen Vergleich zueinander positionieren.

Wenig überraschend ist dabei, dass die „inubit AG BPM Suite“ als einziges ganzheitliches BPM-Tool auch jenseits der o.g. Top-3-Kriterien überzeugen kann. Das System hat den Anspruch „durchgängige Standardsoftware für Business Process Management“^[44] zu sein und bietet daher u.a. Unterstützung bei der Abbildung von Ressourcen über Organigramme.

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.

Das Ergebnis scheint auf den ersten Blick völlig eindeutig: Die „inubit AG BPM Suite“ ist der funktionalen Bewertung zufolge bestens für die praktische Umsetzung eines softwaregestützten Prozessmanagements bei der assona GmbH geeignet.

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.

Die „Activiti Community BPM Platform“ kann nun ihre Stärken in den drei relevantesten Kategorien „Prozess-Design“, „Prozess-Implementierung“ und „Prozess-Ausführung“ ausspielen.

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.

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.

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.

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.

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.

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.

Auffällig ist an diesem technischen Modell besonders der hohe Detaillierungsgrad, z.B. hinsichtlich neu hinzugekommener Zwischenschritte. Zudem lässt sich gut erkennen, dass das Modell auf die zugrundeliegende Service-Architektur zugeschnitten ist. Abbildung 19 zeigt, dass es für alle Service-Tasks eine entsprechende Service-Methode gibt.

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.

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.

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.

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.

Jede Anwendung betreibt in einem eigenständigen Kontext identische Services, die auf einer eigenentwickelten Core-Bibliothek basieren. Diese von den Anwendungen orchestrierten Dienste greifen über ein logisches Bussystem auf weitere Schnittstellen und Services zu.

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]

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.

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.

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.

Anhang

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