Prozessautomatisierung mit BPMN E-Book

Thomas Allweyer

• Herausgeber: BoD - Books on Demand
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 207

Beschreibung

Systeme zur Orchestrierung von Ende-zu-Ende-Geschäftsprozessen, auch bekannt als Workflow- oder Business-Process-Management-Systeme (BPMS), bilden das Herzstück der Prozessautomatisierung. Anhand zahlreicher Beispielprozesse lernen Sie, wie ein solches System funktioniert und wie man ausführbare Prozesse entwickelt. Dazu werden die folgenden Aspekte ausführlich dargestellt: - Modellierung des Ablaufs mit dem Modellierungsstandard BPMN - Verarbeitung und Speicherung von Daten in Prozessen - Festlegung und Zuordnung der Bearbeiterinnen und Bearbeiter - Gestaltung und Einbindung von Benutzungsdialogen - Zusammenspiel mehrerer Prozesse und Systeme - Einbindung von Entscheidungsregeln nach dem Standard DMN - Verknüpfung mit Robotic-Process-Automation (RPA) Die vorgestellten Beispiele können von der Webseite zum Buch heruntergeladen und mit der kostenlosen Open-Source-Version des Systems "Bonita" ausgeführt werden. Die im Buch vermittelten Grundlagen sind allgemeingültig und unabhängig von einem bestimmten Softwareprodukt anwendbar.

Leseprobe

Inhalt

1 Über dieses Buch

2 Einführendes Beispiel

2.1 Ein einfacher Angebotserstellungsprozess

2.2 Möglichkeiten zur IT-Unterstützung

2.3 Grundprinzip eines BPMS

2.4 Notwendige Informationen für die Prozessausführung

2.5 Der Beispielprozess Schritt für Schritt

2.5.1 Das ausführbare Prozessmodell

2.5.2 Rollen, Benutzerinnen und Benutzer

2.5.3 Daten

2.5.4 Dialoge

2.5.5 Verzweigung

2.5.6 Automatisierte Aktivitäten und Anbindung von Drittsystemen

2.6 Prozessausführung

2.7 Management von Prozessen und Prozessinstanzen

3 Sequenzfluss

3.1 Exklusiver Gateway

3.2 Paralleler Gateway

3.3 Inklusiver Gateway

3.4 Komplexer Gateway

3.5 Unterprozess und Aufrufaktivität

3.6 Schleifen- und Mehrfachaktivität

3.7 Kollaboration mehrerer Prozesse

3.8 Ereignisbasierte Entscheidung

3.9 Wiederverwendung von Prozessen mithilfe von Kollaborationen

3.10 Mehrfachteilnahme

3.11 Start eines Prozesses durch eine Bedingung

3.12 Ausnahmen und Fehlerbehandlungen

3.12.1 Angeheftetes Zwischenereignis

3.12.2 Fehlerereignis

3.12.3 Ereignis-Unterprozess

3.12.4 Kompensation und Transaktion

3.13 Nicht-unterbrechendes Ereignis

3.14 Signal

3.15 Weitere Kontrollfluss-Muster

4 Daten

4.1 Daten über Prozesse und ihre Ausführung

4.2 Prozessvariablen

4.3 Daten über Geschäftsobjekte

4.3.1 Speicherung in einer separaten Datenbank

4.3.2 Business-Variablen

4.4 Problemstellungen bei der Speicherung von Geschäftsobjekten

4.4.1 Konsistenz von Daten und Zuständen in Prozess und Datenbank

4.4.2 Prozesse in Abhängigkeit von der Art der Datenpflege schneiden

5 Organisation und Rollen

5.1 Organisationsstruktur

5.2 Akteurinnen und Akteure im Prozess

5.3 Verschiedene Fälle der Auswahl von Bearbeiterinnen und Bearbeitern

5.3.1 Bearbeitung durch die Prozessinitiatorin oder den Prozessinitiator

5.3.2 Bearbeitung durch beliebige Mitglieder einer Gruppe

5.3.3 Bearbeitung wie bei einem vorhergehenden Task

5.3.4 Zuordnungen bei mehrfach ausgeführten Tasks

5.3.5 Vieraugenprinzip

5.3.6 Vorgesetzte dynamisch ermitteln

5.3.7 Bearbeiterinnen und Bearbeiter im Prozess festlegen

6 Benutzungsoberfläche

6.1 Prozesslisten, Tasklisten und Dialoge

6.2 Weitere Aspekte

7 Integration anderer Systeme

7.1 Einführung

7.1.1 REST

7.1.2 Zugriff über die Benutzungsoberfläche

7.1.3 Synchrone und asynchrone Kommunikation

7.1.4 Abarbeitung von Aufgabenvorräten

7.1.5 Behandlung von Fehlern und Ausnahmen

7.1.6 Trennung von fachlichen Prozessen und Integrationsprozessen

7.1.7 Sicherheit und Berechtigungen

7.2 Regeln und Prozesse

7.2.1 Implementierungsmöglichkeiten für Entscheidungsregeln

7.2.2 Aufruf einer Decision-Engine

7.3 Robotic-Process-Automation und BPMS

7.3.1 Prozess-Start durch RPA-Bot mit Übergabe von Excel-Daten

7.3.2 Datentransfer durch einen am Prozess beteiligten RPA-Bot

7.4 Beispiel einer Business-to-Business-Kollaboration

7.4.1 Kommunikation mit einem anderen BPMS mittels REST

7.4.2 Kommunikation über Message-Queues

7.4.3 Notwendige Vereinbarungen zwischen den Partnern

Literatur

Index

Über den Autor

1 Über dieses Buch

Wer sich mit der Frage beschäftigt, wie Geschäftsprozesse ganz oder teilweise automatisiert werden können, stößt früher oder später auf Workflow- oder Business-Process-Management-Systeme (BPMS). Deren Grundidee ist schon Jahrzehnte alt: Grafische Prozessmodelle werden auf einen Server geladen und von einer Process-Engine ausgeführt.

Zwangsläufig stößt man in diesem Zusammenhang auch auf BPMN („Business-Process-Model-and-Notation“). Die meisten BPMS verwenden BPMN als Standardnotation für die Modellierung ausführbarer Prozesse.

Neben den Business-Process-Management-Systemen, die im Mittelpunkt dieses Buches stehen, gibt es noch zahlreiche weitere Konzepte und Technologien, die einen Bezug zu Geschäftsprozessen haben. Schließlich hat fast jeder betriebliche Einsatz von IT auf die eine oder andere Weise mit den Abläufen des Unternehmens zu tun. So muss z. B. auch bei der Programmierung von Individualsoftware oder der Einführung von Standardsoftware sichergestellt werden, dass die Funktionalitäten den Anforderungen der Prozesse entsprechen.

Große Aufmerksamkeit haben in den letzten Jahren die beiden Themen „Process-Mining“ und „Robotic-Process-Automation“ erfahren. Beim Process-Mining geht es darum, die elektronischen Spuren auszuwerten, die die Abläufe in den verwendeten IT-Systemen hinterlassen. Daraus wird automatisch rekonstruiert, wie die Prozesse im Einzelnen abgelaufen sind. Auf dieser Basis können Schwachstellen identifiziert und Verbesserungsmöglichkeiten entwickelt werden.

Ziel der Robotic-Process-Automation (RPA) ist es, Routinetätigkeiten zu automatisieren, die bisher von Menschen ausgeführt wurden. Dabei greifen Software-Bots auf die Benutzungsoberflächen der eingesetzten IT-Systeme zu, wie es auch menschliche Benutzerinnen und Benutzer tun. Bei RPA geht es also nicht um die Automatisierung kompletter Ende-zu-Ende-Prozesse, sondern um die Automatisierung einzelner Arbeitsschritte.

Weitere aktuelle Themen sind das „Adaptive-Case-Management“ zur Unterstützung individueller, wenig vorhersehbarer Prozesse sowie das „Decision-Management“ zur Spezifikation komplexer Regelwerke, die in den Prozessen ausgewertet werden können.

Nicht zuletzt spielt im Zusammenhang mit der Prozessautomatisierung auch das Thema Künstliche Intelligenz eine immer wichtigere Rolle, beispielsweise bei der Analyse von Prozessdaten oder der Optimierung von Prozessabläufen. Hier sind in naher Zukunft viele spannende Entwicklungen zu erwarten.

Einigen dieser Themen werden Sie auch in diesem Buch begegnen. Z. B. wird in Abschnitt 7.2.2 ein Beispiel für das Zusammenspiel von Decision-Management und automatisierten Prozessen gezeigt. Und in Abschnitt 7.3 wird beschrieben, wie BPMS und RPA zusammenwirken können.

Wenn Sie sich einen umfassenden Überblick über die verschiedenen Konzepte, Standards und Technologien verschaffen möchten, die im Umfeld der Geschäftsprozesse eine wichtige Rolle spielen, empfehle ich Ihnen mein Buch „Technologien für Geschäftsprozesse“ [Al23].

Bei all den faszinierenden neuen Entwicklungen ist und bleibt die Ende-zu-Ende-Automatisierung von Geschäftsprozessen mithilfe von BPMN-Modellen und Process-Engines ein ganz zentrales Thema. BPMS bilden in vielen Unternehmen das Rückgrat der gesamten Automatisierung und Digitalisierung.

Wenn Sie genauer wissen und verstehen wollen, wie diese Systeme funktionieren, ist das vorliegende Buch das richtige für Sie. Und weil man am besten begreift, was man selbst ausprobiert, können Sie die vorgestellten Beispiele mit kostenlos verfügbarer Software zur Ausführung bringen.

Die ausführbaren Prozesse in diesem Buch wurden mit dem BPMS „Bonita“ entwickelt. Die Open-Source-Edition dieses Systems kann kostenfrei genutzt werden. Sie lässt sich mit geringem Aufwand auf einem handelsüblichen Computer mit einem der gängigen Betriebssysteme installieren. Der Einstieg ist recht einfach und intuitiv. Bonita eignet sich daher sehr gut für die ersten Schritte mit einem BPMS. Gleichzeitig handelt es sich um ein vollwertiges System, das in vielen Firmen im produktiven Einsatz ist.

Mit der Verwendung von Bonita soll keine generelle Empfehlung für dieses System ausgesprochen werden. So wurde eine ganze Reihe von Eigenschaften nicht untersucht, die für einen produktiven Einsatz wichtig sind, wie z. B. Performance, Skalierbarkeit oder Sicherheit.

Grundsätzlich können die meisten Beispiele in gleicher oder ähnlicher Form auch mit anderen BPMS durchgeführt werden. Da die meisten BPMS die standardisierte Notation BPMN verwenden, können die Prozessmodelle auf andere Systeme übertragen werden.

Allerdings gibt es auch wesentliche Aspekte, für die kein etablierter Standard existiert, wie z. B. die Datenhaltung, Rollenkonzepte oder die Benutzungsoberfläche. Sie sind in den verschiedenen BPMS unterschiedlich realisiert. Daher ist die Übertragung der Beispiele auf ein anderes System doch mit einigem Aufwand verbunden.

Auch wenn die konkrete Umsetzung dieser Aspekte am Beispiel von Bonita gezeigt wird, sind die zugrunde liegenden Fragestellungen und Lösungsansätze für die Arbeit mit anderen Systemen genauso relevant. Diese Systeme bieten ebenfalls Möglichkeiten zur Datenhaltung, zur Definition und Anbindung von Benutzungsdialogen etc. Insofern sind die in diesem Buch beschriebenen Realisierungsmöglichkeiten auch dann von Nutzen, wenn später mit einem anderen BPMS gearbeitet wird.

Für einige Beispiele, bei denen es um das Zusammenspiel mit verschiedenen Arten anderer Systeme geht, kommen weitere Softwaresysteme zum Einsatz – die alle ebenfalls kostenlos genutzt werden können. Details dazu werden in den jeweiligen Kapiteln erläutert.

Ansonsten wurden alle Beispiele mit der Open-Source-Edition von Bonita entwickelt. Sie können von der Website zum Buch heruntergeladen werden:

www.kurze-prozesse.de/automatisierungsbuch

Zu vielen der im vorliegenden Buch besprochenen Beispielprozesse stehen dort auch Videos zur Verfügung.

Bei der Entwicklung der in diesem Buch vorgestellten Beispiele wurde festgestellt, dass zumindest in der kostenlosen Open-Source-Edition von Bonita eine Reihe wünschenswerter Features nicht vorhanden ist. Aus didaktischer Sicht ist dies manchmal sogar ein Vorteil. Wenn man sich etwa überlegen muss, wie man das Verhalten eines nicht unterstützten Modellierungskonstrukts auf anderem Wege erreichen kann, lernt man oft viel mehr, als wenn man einfach einen vorgefertigten Modellierungsbaustein verwendet.

Das Buch richtet sich an Einsteigerinnen und Einsteiger. Dennoch wird ein gewisses Grundwissen über Informatik vorausgesetzt. Sie sollten beispielsweise wissen, was eine Variable ist, oder wofür man eine Datenbank verwendet. An einigen Stellen ist es notwendig, Programmcode zu nutzen. Bonita sieht dafür die Sprache Groovy vor, es kann aber auch Java verwendet werden. Kenntnisse in Java oder Groovy sind daher von Vorteil, aber für das Verständnis des Buches nicht unbedingt erforderlich. Möchte man jedoch die auf der Website verfügbaren Beispiele selbst weiterentwickeln und eigene Prozesse automatisieren, dann lohnt es sich, zumindest grundlegende Kenntnisse einer dieser Programmiersprachen zu erwerben.

Viele der vorgestellten Beispiele entstanden im Rahmen einer Lehrveranstaltung, die für internationale Studentinnen und Studenten angeboten wird. Daher sind die Bezeichnungen in den Modellen englisch. Im beschreibenden Text werden jeweils die deutschen Übersetzungen angegeben, sodass alle Beispiele auch ohne Englischkenntnisse verständlich sind.

2 Einführendes Beispiel

2.1 Ein einfacher Angebotserstellungsprozess

Abbildung 1 zeigt einen einfachen Prozess zur Angebotserstellung. An diesem Beispiel wird im Folgenden die grundlegende Arbeitsweise eines Business-Process-Management-Systems (BPMS) illustriert.

Es sind zwei Rollen beteiligt: „Sales Admin“ (Verkäuferin oder Verkäufer) und „Technical Sales Engineer“ (Technische Vertriebsmitarbeiterin oder -mitarbeiter). Die Verkäuferin bzw. der Verkäufer startet den Prozess und trägt zunächst die Inhalte einer vorliegenden Anfrage ein. Ist die Anfrage erfasst („Inquiry captured“), so arbeitet die technische Vertriebsmitarbeiterin bzw. der technische Vertriebsmitarbeiter das Angebot inhaltlich aus („Prepare proposal“). Dann kalkuliert die Verkäuferin oder der Verkäufer den Preis des Angebots („Price proposal“).

Der anschließende exklusive Gateway, der durch eine Raute mit einem „X“ dargestellt wird, verzweigt zu drei alternativen Fällen: Wenn das Angebot komplett („Complete“) ist, wird es versandt („Send proposal“). Hat sich hingegen herausgestellt, dass die angefragte Leistung nicht machbar ist („Not feasible“), so verschickt das System eine Absage („Send refusal“). In beiden Fällen ist der Prozess danach beendet.

Die dritte Möglichkeit besteht darin, dass eine Überarbeitung erforderlich ist („Rework required“). Dann überarbeitet die technische Vertriebsmitarbeiterin bzw. der technische Vertriebsmitarbeiter das Angebot („Rework proposal“), und es geht wieder mit dem Kalkulieren des Angebots weiter.

Ein solcher Angebotserstellungsprozess findet sich in Firmen mit etwas komplexeren technischen Produkten. So muss bei einem Hersteller von Unternehmenssoftware zunächst eine Expertin oder ein Experte die für den jeweiligen speziellen Fall erforderlichen Software-Komponenten und Lizenzen zusammenstellen, bevor auf dieser Grundlage ein Preis kalkuliert werden kann.

Abbildung 1: Ein einfacher Angebotserstellungsprozess

Die Darstellung gemäß BPMN („Business-Process-Model-and-Notation“) dürfte mithilfe der obigen Beschreibung leicht verständlich sein. Im vorliegenden Buch werden erklärungsbedürftige BPMN-Konstrukte bei ihrem ersten Auftreten kurz erläutert. Eine Einführung in den kompletten BPMN-Standard findet sich in meinem Buch „BPMN 2.0“ [Al20].

2.2 Möglichkeiten zur IT-Unterstützung

Es gibt verschiedene Möglichkeiten, wie eine IT-Unterstützung für diesen Prozess aussehen kann. Im einfachsten Fall kommen lediglich Office-Programme zum Einsatz. Häufig werden Standardsoftwaresysteme verwendet, z. B. für ERP (Enterprise-Resource-Planning) oder CRM (Customer-Relationship-Management). Für speziellere Prozesse, für die es keine geeignete Standardsoftware gibt, wird meist Individualsoftware programmiert.

Oft werden in einem Prozess auch mehrere verschiedene Systeme genutzt. Dann müssen Daten zwischen diesen Systemen ausgetauscht werden. Dies geschieht entweder über Schnittstellen oder in vielen Fällen nach wie vor von Hand. Um solch einen manuellen Datenaustausch und weitere Routinetätigkeiten zu automatisieren, setzen Unternehmen vermehrt auf RPA (Robotic-Process-Automation). Dabei werden die Routinetätigkeiten von Software-Bots übernommen, die wie menschliche Benutzerinnen und Benutzer mit den grafischen Benutzungsoberflächen der Systeme arbeiten.

All diese Möglichkeiten zur Unterstützung von Geschäftsprozessen weisen Defizite auf, wenn es darum geht, Gesamtprozesse von Anfang bis Ende zu steuern und einen Überblick über den Prozessablauf zu gewinnen.

So beruhen viele Prozesse einfach darauf, dass die Mitarbeiterinnen und Mitarbeiter Vorgänge weiterleiten. Oft ist noch nicht einmal der Prozess in seiner Gänze bekannt. Auch in Standardsoftwaresystemen werden viele Prozesse nicht aktiv gesteuert. Dort, wo es vom System gesteuerte Prozesse gibt, sind die Ablaufreihenfolgen vielfach hart einprogrammiert und lassen sich nicht so einfach verändern. In selbst entwickelter Individualsoftware finden sich ebenfalls solche fest einprogrammierten Prozesse.

Da es bei den genannten Systemen meist auch nicht so einfach ist, einen Überblick über die durchgeführten Prozesse zu bekommen, setzen immer mehr Unternehmen „Process-Mining“ ein. Dabei werden die „Spuren“ ausgewertet, die die Prozesse in den verschiedenen Systemen hinterlassen, z. B. in Form von Log-Daten oder elektronischen Belegen. Hieraus werden die tatsächlich erfolgten Prozessabläufe rekonstruiert. Damit gewinnt man eine hohe Transparenz und nützliche Informationen, doch die Steuerung der Prozesse erfolgt auf anderem Wege.

Die genannten Defizite können mithilfe von Business-Process-Management-Systemen behoben werden. Diese Systeme, die auch als Workflow-Management-Systeme, Business-Process-Automation-Tools oder Orchestrierungsplattformen bezeichnet werden, bilden den Gegenstand dieses Buches. Ihnen ist gemein, dass sie als zentrale Komponente eine „Process-Engine“ enthalten, die umfangreiche und komplexe Prozesse steuern kann.

Im Folgenden wird die Bezeichnung Business-Process-Management-System verwendet, abgekürzt BPMS.

Die Nutzung eines BPMS schließt nicht aus, dass auch andere Systeme innerhalb der Prozesse zum Einsatz kommen. So rufen BPMS häufig Funktionen von Standardsoftwaresystemen oder von Individualsoftware auf und tauschen Daten mit ihnen aus.

Es gibt auch Standardsoftwaresysteme mit integrierten Komponenten zur Prozesssteuerung. Diese Komponenten funktionieren nach demselben Prinzip wie eigenständige BPMS.

Nicht zuletzt bieten manche Process-Mining-Systeme die Möglichkeit, Prozesse in Echtzeit zu analysieren und bei Bedarf steuernd einzugreifen – häufig unterstützt durch Künstliche Intelligenz. Damit verfügen solche Systeme ebenfalls über die Fähigkeit, Prozesse zu steuern. Auch hierfür bilden die im Folgenden beschriebenen Konzepte eines BPMS eine wesentliche Grundlage.

2.3 Grundprinzip eines BPMS

Ohne bereits in die technischen Details zu gehen, wird zunächst beschrieben, wie ein BPMS grundsätzlich funktioniert.

In Abbildung 2 sind die wichtigsten Komponenten eines BPMS zu sehen. Im Zentrum steht eine Process-Engine, die für die Abarbeitung der Prozesse zuständig ist. Zunächst muss aber der jeweilige Ablauf modelliert werden – typischerweise in Form eines BPMN-Modells, wie das in Abbildung 1. Die Process-Engine benötigt aber noch mehr Informationen als nur die im grafischen Modell enthaltene Ablaufreihenfolge. Es muss unter anderem auch definiert werden, welche Daten bearbeitet und welche Dialoge für die einzelnen Aktivitäten aufgerufen werden sollen. Eine komplette Prozessdefinition besteht aus einem Prozessmodell, das mit einer Reihe von Zusatzinformationen angereichert ist. Ein solches angereichertes Modell wird in der Modellierungs- und Entwicklungsumgebung des betreffenden BPMS erstellt. Abbildung 3 zeigt das „Bonita-Studio“.

Die fertiggestellte Prozessdefinition wird auf den Process-Engine-Server hochgeladen. Anschließend ist der Prozess zur Ausführung bereit.

Abbildung 2: Wichtige Komponenten eines BPMS

Die an dem Prozess Beteiligten greifen über ein Prozessportal auf das BPMS zu. Hier können sie einerseits die Prozessbearbeitung starten, andererseits die einzelnen Tasks (Arbeitsschritte) innerhalb der Prozesse durchführen. Jedes Mal, wenn ein Task beendet ist, leitet die Process-Engine den Vorgang an die nächste Person weiter. Zudem kann die Process-Engine automatisierte Services aufrufen.

Ein Prozess kann sehr oft durchgeführt werden. So wird der Angebotserstellungsprozess jedes Mal neu gestartet, wenn eine Kundenanfrage eintrifft. In der Process-Engine wird hierfür jeweils eine neue Prozessinstanz angelegt. Eine Instanz des Angebotserstellungsprozesses enthält alle Informationen, die mit der Erstellung eines bestimmten Angebots zusammenhängen. Die einzelnen Prozessinstanzen werden unabhängig voneinander abgearbeitet und können jeweils einen anderen Bearbeitungsstand haben.

In Abbildung 4 sind drei Instanzen dieses Prozesses gestartet worden. Jede Prozessinstanz enthält eine Reihe von Daten. Hierbei kann es sich um Daten handeln, die von der Process-Engine automatisch erfasst werden, wie z. B. der Startzeitpunkt oder wer den Prozess gestartet hat. Zur Unterscheidung erhält jede Prozessinstanz eine eindeutige Nummer als Identifizierer. Außerdem wird jeweils gespeichert, an welcher Stelle sich die Prozessbearbeitung gerade befindet.

Weitere Daten werden von den Prozessbeteiligten eingegeben oder von aufgerufenen Services an die Prozessinstanz übergeben.

Abbildung 3: Modellierungs- und Entwicklungsumgebung „Bonita-Studio“

Abbildung 4: Prozessdefinition und Prozessinstanzen

Abbildung 5: Taskliste im Bonita-Prozessportal

In Abbildung 5 ist das Bonita-Portal zu sehen, das die Prozessbeteiligten nutzen. Eingeloggt ist die Verkäuferin Anna Davis. Angezeigt wird ihre „Task list“ („Aufgabenliste“ oder „Taskliste“). Ähnlich wie im Posteingang eines E-Mail-Programmes werden hier die gerade anstehenden Tasks (Arbeitsschritte) aufgelistet, die die eingeloggte Benutzerin in den laufenden Prozessinstanzen durchführen kann.

Die Einträge in dieser Liste werden von der Process-Engine gemäß dem Prozessmodell aus Abbildung 1 erstellt. Wurde in einer Prozessinstanz der Schritt „Prepare proposal“ („Angebot ausarbeiten“) fertiggestellt, so erzeugt die Process-Engine in den Tasklisten der Verkäuferinnen und Verkäufer jeweils einen Eintrag für den nächsten Task „Price proposal“ („Angebot kalkulieren“). In Abbildung 5 enthält die Taskliste mehrere Einträge für diesen Task. Jeder Eintrag gehört zu einer anderen Prozessinstanz – erkennbar an der unter „Case“ („Fall“) eingetragenen Nummer. Prozessinstanzen werden in Bonita auch als Fälle bezeichnet.

Über den Button „Take“ („Übernehmen“), kann die Verkäuferin den Task in Bearbeitung nehmen und den Dialog öffnen, mit dem sie die Aufgabe durchführt (Abbildung 6). Dieser Dialog, der für diesen Beispielprozess sehr einfach gehalten ist, enthält bereits einige Daten, die in vorangegangenen Tasks erfasst wurden.

Die Verkäuferin kann nun den Preis und weitere Angaben ergänzen und schließlich über die Schaltflächen am unteren Rand bestimmen, wie weiter verfahren werden soll: Sie kann das Angebot absenden („Send proposal“), es zurückweisen („Reject proposal“) oder den Vorgang zur Überarbeitung zurückgeben („Send proposal back for rework“). Im Modell aus Abbildung 1 folgt auf diesen Task eine Verzweigung. Je nachdem, welche Schaltfläche gedrückt wurde, wird an dieser Verzweigung ein anderer Ausgang gewählt.

Abbildung 6: Dialog für den Arbeitsschritt „Angebot kalkulieren“

Neben dem Portal für die gewöhnlichen Prozessbeteiligten gibt es auch eine Ansicht für die Administration. Dort kann man beispielsweise Prozessdefinitionen hochladen, Prozessinstanzen nachverfolgen, Rollen sowie Benutzerinnen und Benutzer verwalten.

In dem Administrationsportal in Abbildung 7 sind alle Prozesse aufgelistet, die momentan auf der Process-Engine zur Verfügung stehen und ausgeführt werden können. Neben dem bereits betrachteten Angebotserstellungsprozess („Create Proposal“) finden sich dort beispielsweise Prozesse für die Bewertung von Projekten („Assess Project Proposal“) oder für Bestellungen aus dem Lager („Order from Warehouse“).

Abbildung 7: Administrationsportal

2.4 Notwendige Informationen für die Prozessausführung

Es wurde bereits erwähnt, dass für die Ausführung eines Prozesses nicht nur das Prozessmodell erforderlich ist, sondern noch eine Reihe weiterer Angaben gebraucht werden. Häufig benötigte Informationen sind (vgl. Abbildung 8):

Rollen und Organisation:

Für jeden nicht komplett automatisierten Task muss bestimmt werden, wer ihn durchführt. Hierzu werden keine konkreten Mitarbeiterinnen oder Mitarbeiter angegeben, sondern Rollen, wie z. B. „Einkäuferin“ bzw. „Einkäufer“ oder „Vertriebsmitarbeiterin“ bzw. „Vertriebsmitarbeiter“. Durch die Zuordnung zu Organisationseinheiten oder Gruppen wird bestimmt, welche Rollen die einzelnen Personen einnehmen können.

Kapitel 5

befasst sich ausführlich mit den verschiedenen Möglichkeiten der Zuordnung von Benutzerinnen und Benutzern.

Dialoge:

Die am Prozess Beteiligten bearbeiten die einzelnen Tasks mithilfe von Benutzungsdialogen, in die sie jeweils die erforderlichen Daten eingeben. Für jeden Task mit Benutzerinnen- oder Benutzerinteraktion muss daher ein entsprechender Dialog definiert werden. Dieser enthält die in dem Arbeitsschritt benötigten Eingabefelder, Schaltflächen usw. Weiterhin sind etwa gültige Eingabeformate festzulegen, damit das System überprüfen kann, ob z. B. eine eingegebene E-Mail-Adresse oder eine Kontonummer korrekt aufgebaut ist. Oftmals sind auch Berechnungen oder andere automatisierte Funktionen in einen Dialog zu integrieren. So sollte bei der Eingabe einer Bestellung der angezeigte Gesamtpreis ständig aktualisiert werden. Mehr zu Dialogen und der Gestaltung der Benutzungsoberfläche findet sich in

Kapitel 6

.

Abbildung 8: Zusatzinformationen, die für die Ausführung eines Prozesses benötigt werden

Daten:

Es muss festgelegt werden, welche Daten und Informationen in dem Prozess verarbeitet werden. Damit die in den Dialogen eingegebenen oder z. B. aus anderen Systemen ausgelesenen Daten im gesamten Prozess verwendet werden können, müssen sie in Variablen gespeichert werden. Eine Prozessvariable kann je nach Datentyp einen einfachen Wert enthalten, wie einen Text oder eine Zahl – oder eine komplexe Datenstruktur, wie z. B. ein Angebot mit mehreren Angebotspositionen. Die in den Prozessvariablen gespeicherten Werte stehen anschließend den im weiteren Verlauf durchgeführten Aktivitäten zur Verfügung. Sollen die Daten auch über die einzelne Prozessinstanz hinaus verfügbar sein, müssen sie in einer Datenbank gespeichert werden. Das Thema Daten und Informationen wird in

Kapitel 4

vertieft.

Daten-Mappings:

Insbesondere dann, wenn man in einem Prozess Daten aus unterschiedlichen externen Systemen verarbeitet, ist es notwendig, „Mappings“, d. h. Zuordnungen zwischen den unterschiedlichen Datenstrukturen zu definieren. Oft sind auch Umwandlungen zwischen verschiedenen Datentypen nötig.

Beispielsweise könnten in einem Prozess Bestellungen aus einem System ausgelesen und später in einem anderen System gespeichert werden. Das erste System verwendet für die Bestellmenge ein Attribut. Dieses Attribut enthält die bestellte Menge als ganze Zahl. Das zweite System kann auch mit ganz anderen Mengeneinheiten umgehen. Es verwendet daher zwei Attribute: „Menge“ und „Mengeneinheit“. Die Menge wird dabei als Dezimalzahl mit zwei Nachkommastellen angegeben. Für die Mengeneinheit wird ein Text verwendet, wobei vorgegebene Kürzel zu nutzen sind. In diesem Beispiel muss daher ein Mapping definiert werden, das beispielsweise die Angabe

Stückzahl: 23

des ersten Systems in die Attributwerte

Menge: 23.00 Mengeneinheit: „Stueck“

des zweiten Systems umwandelt. Bei einem solchen Mapping muss es sich nicht ausschließlich um reine Zuordnungen und Typkonvertierungen handeln. Es können z. B. auch Umrechnungen erforderlich sein.

Daten-Mappings werden unter anderem beim Aufruf anderer Prozesse (Abschnitt 3.5), beim Versand von Nachrichten an andere Prozesse (Abschnitt 3.7) und beim Aufruf externer Services (Kapitel 7) durchgeführt.

Regeln:

Regeln bestimmen beispielsweise, welcher Pfad bei einer Verzweigung gewählt wird. In simplen Fällen wird hierbei nur ein einzelnes Attribut überprüft, z. B. „genehmigt==true“ oder „summe>5 000“. Verzweigungsregeln können aber auch sehr komplex sein und viele einfache Bedingungen miteinander verknüpfen. Zudem spielen Regeln nicht nur an Verzweigungen eine Rolle, sondern auch innerhalb von Tasks. So muss etwa ein Task zur Berechnung eines Fahrpreises ein komplexes Regelwerk auswerten, das Fahrstrecke, Datum, Kundenkarten, Alter usw. berücksichtigt.

Abschnitt 7.2

beschreibt, wie man solche komplexen Geschäftsregeln definieren und auswerten kann.

Externe Systeme:

In vielen Geschäftsprozessen werden Daten und Funktionen ganz unterschiedlicher Softwaresysteme verwendet. Um ein externes System einzubinden, muss dieses über eine geeignete Schnittstelle verfügen. Viele BPMS enthalten bereits sogenannte Konnektoren oder Adapter für häufig verwendete Systeme, wie z. B. E-Mail-Server, relationale Datenbanken, SAP- oder andere ERP-Systeme.

Oft nutzen diese Schnittstellen verbreitete Internet-Standards gemäß dem REST-Architekturstil. Ein System, das eine REST-Schnittstelle anbietet, kann oftmals auch dann angebunden werden, wenn das BPMS keinen systemspezifischen Konnektor bereitstellt.

Verfügt ein anzubindendes System über keine Standard-Schnittstelle, so muss ggf. ein neuer Konnektor dafür programmiert werden.

In jedem Fall müssen die Verbindungsdaten zu dem betreffenden System, die aufgerufenen Funktionen und die auszutauschenden Daten angegeben und die entsprechenden Daten-Mappings festgelegt werden.

Mehr zur Anbindung von Drittsystemen findet sich in Kapitel 7.

Automatisierte Funktionen:

Vom System ausgeführte Tasks führen etwa Berechnungen oder Veränderungen von Daten durch. Diese Algorithmen müssen ebenfalls spezifiziert werden. Typischerweise programmiert man sie in einer herkömmlichen Programmiersprache. Entweder werden solche Funktionen direkt vom BPMS ausgeführt, oder sie laufen in einer eigenen Umgebung und werden wie ein externes System angebunden, z. B. mittels REST-Aufrufen.

Nicht immer ist es erforderlich, all diese Informationen manuell zu erfassen. Einige lassen sich auch automatisch erzeugen. So können manche Entwicklungswerkzeuge Benutzungsdialoge generieren, mit denen man die Daten anzeigen und bearbeiten kann, die für den Prozess festgelegt wurden. Hierbei wird auch die Zuordnung zwischen den Eingabefeldern und den Datenelementen automatisch vorgenommen.

Je spezieller und individueller aber die Anforderungen sind, desto mehr wird man die entsprechenden Inhalte selbst entwickeln bzw. vom System erzeugte Elemente anpassen und weiterentwickeln. So mag ein automatisch generierter Dialog zwar prinzipiell funktionieren. Doch wenn etwa die Benutzerführung im Sinne einer einfachen Bedienbarkeit optimiert werden soll, wenn bestimmte Bedienelemente gewünscht oder Informationen in spezieller Weise visualisiert werden sollen, wird man meist nicht umhinkommen, den entsprechenden Dialog individuell zu entwickeln. Viele BPMS verfügen hierzu über „UI-Builder“, also grafische Werkzeuge, die die Entwicklung der grafischen Benutzungsoberfläche („User-Interface“, UI) vereinfachen.

Dennoch ist die Entwicklung individueller Dialoge auch bei Nutzung eines solchen Werkzeugs mit einem entsprechenden Aufwand verbunden.

Bei der Einführung eines BPMS sollte man daher nicht nur darauf achten, wie komfortabel die Prozessmodellierung funktioniert. Mindestens genauso wichtig ist es, wie man die beschriebenen Zusatzinformationen erfassen und bearbeiten kann. Die reine Prozessmodellierung macht nur einen Teil der gesamten Prozessentwicklung aus.

Da viele der aufgeführten Aspekte von System zu System ganz unterschiedlich umgesetzt sind, wird es auf absehbare Zeit auch nicht so einfach möglich sein, einen Prozess von einem BPMS zu einem anderen zu portieren. Zwar gibt es ein Standardformat zum Austausch von BPMN-Modellen, doch sind darin keine Geschäftsregeln, Rollenmodelle, Benutzungsdialoge oder Ähnliches enthalten.

2.5 Der Beispielprozess Schritt für Schritt

2.5.1 Das ausführbare Prozessmodell

Im Folgenden wird die Umsetzung des Beispielprozesses genauer beschrieben. Dabei werden alle oben genannten Aspekte erläutert, die für die Ausführung erforderlich sind. Abbildung 9 zeigt noch einmal das ausführbare Prozessmodell aus Abbildung 1, das in Abschnitt 2.1 beschrieben wurde.

Der grundlegende Ablauf lässt sich anhand des grafischen Modells recht gut nachvollziehen. Etwas ungewöhnlich mag die Modellierung des Prozessbeginns erscheinen. Der Prozess beginnt mit dem Startereignis „Inquiry captured“ („Anfrage erfasst“). Wo und wie findet aber das Erfassen der Anfrage statt? Es würde näher liegen, den Prozess so zu modellieren, dass nach einem Startereignis die Erfassung als erster Task durchgeführt wird.

In Bonita wird beim Start eines Prozesses durch eine Person zunächst aber immer ein „Instanziierungsdialog“ angezeigt. Darin kann man die für den Start des Prozesses benötigten Daten eintragen. Erst wenn dieser Dialog abgeschlossen ist, legt Bonita eine Prozessinstanz an. Für den Beispielprozess wurde ein Dialog zum Erfassen einer Anfrage definiert und dem Prozess als Instanziierungsdialog zugeordnet.

Würde man „Anfrage erfassen“ separat als Task modellieren, so wäre trotzdem ein Instanziierungsdialog erforderlich. Man müsste zunächst diesen – eigentlich nicht benötigten und daher leeren – initialen Dialog schließen und könnte dann erst die Anfrage erfassen. Insofern ist es für die Prozessbeteiligten günstiger, die Erfassung mithilfe des Instanziierungsdialogs zu erledigen – auch wenn man den Prozessbeginn bei rein fachlicher Betrachtung anders modelliert hätte.

Abbildung 9: Das ausführbare Prozessmodell aus Abbildung 1

2.5.2 Rollen, Benutzerinnen und Benutzer

Bei den Tasks, die mit einem kleinen Personensymbol versehenen sind, handelt es sich um User-Tasks, also um Arbeitsschritte, die von Benutzerinnen oder Benutzern durchgeführt werden. Wer dies für einen bestimmten Task tun kann, wird in dem Beispiel durch die Lanes (Bahnen) festgelegt.