Umsetzung

Zusammenfassung

Die bisherigen Ausführungen haben mit der Spezifikation effektiver und effizienter Prozesse die Grundlagen gelegt für deren Implementierung. Im Anschluss an diese vorbereitenden Aktivitäten befassen wir uns in der Folge mit der Umsetzung der Prozessspezifikation in einer Ausführungsumgebung und der Abwicklung von Prozessinstanzen im Echtbetrieb. Die Umsetzung einer Prozessbeschreibung in einen ausführbaren Prozess umfasst die Aktivitätsbündel der organisatorischen Implementierung, der IT-Implementierung und des Betriebs mit dem Monitoring.

Die bisherigen Ausführungen haben mit der Spezifikation effektiver und effizienter Prozesse die Grundlagen gelegt für deren Implementierung. Im Anschluss an diese vorbereitenden Aktivitäten befassen wir uns in der Folge mit der Umsetzung der Prozessspezifikation in einer Ausführungsumgebung und der Abwicklung von Prozessinstanzen im Echtbetrieb. Die Umsetzung einer Prozessbeschreibung in einen ausführbaren Prozess umfasst die Aktivitätsbündel der organisatorischen Implementierung, der IT-Implementierung und des Betriebs mit dem Monitoring. Abb. 6.1 zeigt die Einordung dieser Aktivitäten in das Prozessmanagementmodell.

Abb. 6.1

Einordnung der Umsetzung in das Prozessmanagementmodell

In den folgenden Abschnitten werden, ausgehend von Überlegungen zur Dokumentation der erarbeiteten Prozessspezifikation, ausgewählte Methoden für die Aktivitätsbündel der organisatorischen und IT-Implementierung sowie für den Betrieb und das Monitoring von Prozessen vorgestellt.

Die Aktivitäten des Prozessmanagementmodells bieten den konzeptionellen Rahmen für die Umsetzung des Geschäftsprozessmanagements in ein Handlungssystem. Wie bereits in den vorangestellten Kapiteln diskutiert, stellen die Phasen zwar ein gewisses Ordnungskriterium dar, können aber grundsätzlich in beliebiger Reihenfolge durchlaufen werden. Jede der Phasen beinhaltet dabei ein Bündel an Aktivitäten, die typischerweise in ihr angewendet werden. Jeder Geschäftsprozess befindet sich in einem bestimmten Augenblick in einer bestimmten Phase – oder in anderen Worten, in einem bestimmten Zustand: er ist modelliert, er ist in Kraft gesetzt, er wird ausgeführt, er wird analysiert. Das Lebenszyklusmodell definiert damit einen Phasen- oder Zustandsraum für Geschäftsprozesse.

6.1 Prozessdokumentation

Da die Geschäftsprozesse eines Unternehmens definieren, wie Produkte und Dienstleistungen entwickelt, hergestellt und geliefert werden, ist es zweckmäßig eine Prozessdokumentation zu erstellen. Diese sollte naturgemäß allen Mitarbeitern zentral zur Verfügung gestellt werden. Die Dokumentation muss spätestens zu Beginn der Umsetzung (Implementierung) vorliegen. Die Geschäftsprozessdokumentation ist das Ergebnis der Aktivitätsbündel während der Vorbereitung.

Heutzutage bietet sich dazu die Form digitaler Dokumente an. Die Bereitstellung erfolgt dabei idealerweise über ein üblicherweise vorhandenes Intranet; damit kann auch in groben Zügen eine einfache Zugriffskontrolle gestaltet werden. Die Dokumente selbst können beispielsweise nicht veränderbare PDF-Dateien (eventuell auch digital signiert), oder HTML-Dateien, die über einen Browser betrachtet werden können, sein.

Für kleinere Organisationen und Unternehmen reicht es zumeist aus, wenn für die Erstellung und Wartung der Prozessdokumentation die üblicherweise verwendete Bürosoftware genutzt wird. Für umfangreichere Sammlungen erscheint die Nutzung spezifischer Software, sogenannter Business Prozess Management Systeme (BPMS), überlegenswert. Jedenfalls muss die gewählte Form die Menschen, die damit arbeiten, und die darauf aufbauenden Managementsysteme bestmöglich unterstützen. Auch sollten die Dokumente eine eindeutige Bezeichnung, eine Versionsnummer und ein Datum beinhalten. Soll eine Textverarbeitung benutzt werden, empfiehlt sich eine Formatvorlage, um ein einheitliches Erscheinungsbild und ebensolche Strukturen vorzugeben. Des Weiteren empfiehlt sich eine Liste mit allen Dokumenten inklusive Historie, um einen allgemeinen Überblick zur Verfügung zu stellen.

Verantwortlich für die Aktualität und Vollständigkeit einer Prozessdokumentation ist der Prozesseigner bzw. Prozesskoordinator. Das Prozess-Office gibt vor, was eine Prozessdokumentation beinhalten soll und stellt entsprechende Vorlagen und Erklärungen bereit. Falls ein dediziertes IT-System (BPMS) genutzt werden soll, kann die Schulung aller Mitarbeiter – abhängig davon, welche Rolle sie einnehmen – eindringlich angeraten werden. Im Sinne eines geplanten Veränderungsprozesses (Change Management), sollten die Mitarbeiter in angemessener Form auch in den Auswahl- oder Entwicklungsprozess eingebunden werden.

Folgende Inhalte einer Prozessdokumentation haben sich grosso modo bewährt; selbstverständlich sind nicht immer alle Punkte für jeden Geschäftsprozess relevant und können bei Bedarf auch weitere Punkte ergänzt werden:

• Ziel des Prozesses – ein kurzer beschreibender Text, in dem der Bezug des Prozesses zu übergeordneten Unternehmenszielen erläutert wird (Strategiebeitrag).

• Auslöser des Prozesses – Angabe, durch welches Ereignis eine Prozessinstanz gestartet wird und wer dieses Ereignis erzeugen kann.

• Input – Auflistung und Beschreibung der Informationen, Dokumente und auch physikalischen Artefakte, die als Input benötigt werden und von wem sie bereitgestellt werden.

• Output – Auflistung und Beschreibung der Informationen, Dokumente und physikalischen Artefakte, die vom Prozess erzeugt werden; eventuell auch Qualitätskriterien pro Kunde.

• Gültigkeitsbereich und organisatorische Rahmenbedingungen – gegebenenfalls Abgrenzung zu anderen Geschäftsprozessen, oder organisatorische Einschränkung (z. B. nur gültig für den Geschäftsbereich Großkunden).

• Definition der Begriffe und Abkürzungen – im Dokument verwendete Abkürzungen; Tipp: wenn man diese auch gleich in einem unternehmensweiten Verzeichnis konsolidiert sammelt, erhält man ein Glossar der wichtigsten Begriffe in einem Unternehmen, sowie einheitliche Definitionen in allen Prozessdokumentationen.

• Übersichtsbeschreibung des Prozessmodells – textuelle Darstellung der Handelnden/Rollen und der Prozessschritte.

• Prozessmodell – Ein Prozessmodell (visuelle Darstellung), erstellt in einer vereinbarten Modellierungssprache; für die Erstellung der Prozessmodelle sollte es einheitliche Regelungen geben, um einen Wildwuchs zu vermeiden (z. B. bezüglich Farben und Beschriftung von Notationselementen).

• Technische Rahmenbedingungen – Auflistung und Beschreibung technischer Hilfsmittel, die im Prozess benötigt werden. Darstellung der informationstechnischen Unterstützung bzw. Abhängigkeiten, z. B. der Verweis auf bestimmte Module eines ERP-Systems.

• Feedback Mechanismen – Darstellung, wie Prozessbeteiligte Probleme bei der Ausführung (z. B. falsch oder nicht ausreichend modellierte Logik) artikulieren oder Verbesserungsvorschläge einbringen können. Dies sollte eine im Geschäftsprozessmanagement implementierte Standardprozedur sein.

• Ausnahmen – eventuelle Ausnahmen vom Prozessmodell, d. h. Aktivitäten, die nicht im Prozessmodell berücksichtigt werden, da entsprechende Fälle nur selten vorkommen.

• Schnittstellen mit anderen Prozessen – eine Darstellung, in welchen anderen Geschäftsprozessen der Output eines Prozesses benötigt wird (definiert damit den Prozesskunden bzw. dessen Erwartung).

• Kennzahlen ( PPI ) – Liste, Definition und Erklärung der vorgesehenen Prozesskennzahlen.

• Leistungsmessungen – Darstellung, wie und wann die Kennzahlen zu messen und zu berechnen sind. Verweis auf eventuell verfügbare andere Dokumente.

• Berichtswesen – Darstellung, in welcher Form und wann die Prozesskennzahlen an wen zu berichten sind; Verweis auf eventuell verfügbare andere Dokumente.

• Eskalationen – Definition von Prozeduren, die anlaufen sollen, sobald der Toleranzbereich von Kennzahlen verletzt wird.

• Audits und Compliance – Verweis auf entsprechende Richtlinien. Falls einzelne Aktivitäten in einem Geschäftsprozess aus Gründen der Compliance aufgenommen wurden, sollte dies dokumentiert werden, damit diese nicht im Rahmen einer Effizienzverbesserung eliminiert werden. Es empfiehlt sich, solche Aktivitäten in einer visualisierten Darstellung farblich zu markieren. Ferner hat sich in der Praxis als hilfreich erwiesen, (tabellarisch) zu dokumentieren, in welchen Geschäftsprozessen die Einhaltung bestimmter Normen und Gesetze notwendig ist. Ähnliche Überlegungen gelten für externe (z. B. Qualitätsnormen) oder interne Audits (z. B. Risikoanalysen).

6.2 Verknüpfung von Elementen der Unternehmensarchitektur

6.2.1 Überblick

Wie in Kap. 1 und 2 angesprochen, sind Geschäftsprozesse Teil der Unternehmensarchitektur. Unternehmensarchitekturen gehen auf die internen Aspekte und Strukturen eines Unternehmens ein. Sie sind im Wesentlichen Modelle der Interna eines Unternehmens und umfassen nicht nur organisatorische, sondern auch technische Aspekte, insbesondere die eingesetzte IT. Bei der Umsetzung der Prozessmodelle gilt es nun deren Bezug zu den vorhandenen Ressourcen herzustellen. Abb. 6.2 zeigt die einzelnen Stufen vom Prozessmodell zur ausführenden Prozessinstanz.

Abb. 6.2

Vom Prozessmodell zur Prozessausführung

In einem Prozessmodell werden die Handelnden, die Handlungen, deren Reihenfolgen und die Objekte, auf denen die Handlungen ausgeführt werden, beschrieben. Handlungen (Aktionen, Aktivitäten) können von Menschen, Softwaresystemen, physikalischen Systemen oder einer Kombination aus diesen Grundtypen von Handelnden ausgeführt werden. Wir bezeichnen sie als Aufgabenträger. So kann ein Software-System die Aktion „Berechnung des Steuersatzes“ automatisch erledigen, während ein Mensch in Kombination mit einem Programm die Aktivität „Erfassen der Bestellung“ ausführt. Der Mensch tippt dabei die Bestelldaten über eine Bildschirmmaske ein. Die Software prüft die eingegebenen Daten auf Plausibilität und speichert sie ab.

Tätigkeiten können aber auch ausschließlich manuell ausgeführt werden, etwa wenn ein Lagerarbeiter einen Kommissionierungsauftrag auf Papier bekommt, diesen ausführt, auf dem Auftrag als ausgeführt kennzeichnet, und an den Lagermeister zurückgibt. Bei der Erstellung eines Prozessmodells ist oft noch nicht bekannt, welche Typen von Handelnden welche Aktionen ausführen. Deshalb kann es sinnvoll sein, zu Beginn einer Prozessbeschreibung davon zu abstrahieren, in dem man abstrakte Handelnde einführt. Eine Modellierungssprache sollte erlauben, solche Abstraktionen zu verwenden. Dies bedeutet, es muss bei der Definition der Prozesslogik noch keine Aussage gemacht werden, durch welchen Typ ein Akteur realisiert wird. In S-BPM repräsentieren die Subjekte abstrakte Handelnde. In BPMN können Pools oder Swim Lanes als abstrakte Handelnde interpretiert werden, während man in EPKs dafür Rollen verwenden kann.

In der Beschreibung der Ablauflogik eines Prozesses werden auch die einzelnen Aktivitäten noch unabhängig von ihrer Realisierung beschrieben. Beispielsweise wird bei einer Aktion „Erstellen eines Kommissionierungsauftrags“ nicht festgelegt, ob hier der Bearbeiter ein Papierformular oder eine Bildschirmmaske ausfüllt, oder ob ein Software-System diesen vollautomatisch erzeugt. Bei Aktionen wird also nicht beschrieben, mit welchen Mitteln etwas geschieht, sondern nur was geschieht.

Dies steht natürlich in Zusammenhang mit dem Implementierungstyp für den Handelnden als Aufgabenträgertyp. Sobald festgelegt wird, welche Typen von Handelnden den einzelnen Aktionen zugewiesen werden, ist auch die Art der Realisierung einer Aktivität definiert. Darüber hinaus ist zu definieren, auf welchem logischen oder physischen Objekt eine Aktion ausgeführt wird. Logische Objekte sind Datenstrukturen, deren Daten durch die Aktivitäten manipuliert werden. Papierformulare stellen eine Mischung zwischen logischen und physischen Objekten dar, während ein Werkstück, auf dem die Aktion „Entgraten“ stattfindet, ein rein physisches Objekt ist. Es besteht also ein enger Zusammenhang zwischen dem Aufgabenträgertyp, den Aktionen und den zugehörigen Objekten, auf oder mit denen die Akteure Handlungen ausführen.

Ein Prozessmodell kann in verschiedenen Bereichen einer Organisation zum Einsatz kommen. Die Prozesslogik wird dann in den jeweiligen Bereichen unverändert übernommen. Es kann allerdings nötig sein, die einzelnen Handelnden und Handlungen unterschiedlich zu implementieren. So können in einer Umgebung bestimmte Handlungen von Menschen und in einer anderen die gleiche Aktivität von Software-Systemen ausgeführt werden. Wir bezeichnen solche verschiedenen Verwendungsumgebungen für ein Prozessmodell im Folgenden als Kontext. Für ein Prozessmodell kann es also variierende Kontexte geben, in denen die Realisierungstypen für Akteure und Aktionen voneinander abweichen können.

In BPMN kann der Modellierer für jeden Task separat festlegen, ob es sich um einen sogenannten Human Task, Service Task oder User Task handelt. User Tasks führen Menschen zusammen mit Software aus, wie z. B. das Ausfüllen eines Kommissionierungsauftrags am Bildschirm. Dies bedeutet, dass die Beschreibung des Implementierungstyps in BPMN einen Teil der Prozesslogik darstellt. Da in BPMN Pools und Swim Lanes als Handelnde interpretiert werden können, muss darauf geachtet werden, dass keine Widersprüche mit dem Implementierungstyp von Tasks innerhalb z. B. eines Pool entstehen. Legt der Designer beispielsweise fest, dass ein Pool nur durch Menschen ausgeführt wird, kann dieser Pool keine Service oder User Tasks enthalten. Da in BPMN die Definition des Implementierungstyps Bestandteil des Ablaufmodells ist, muss unter Umständen für jeden Kontext ein eigenes Prozessmodell erstellt werden.

In S-BPM werden Handelnde nicht einzelnen Aktivitäten zugeordnet, sondern der Typ des Handelnden einem gesamten Subjekt. Diese Zuordnung ist in S-BPM nicht Teil der Prozesslogik, sondern erfolgt je Prozess in einer separaten zweispaltigen Tabelle. In der linken Spalte findet sich der Subjektname und in der rechten der Implementierungstyp. Gibt es für ein Ablaufmodell mehrere Kontexte, so wird für jeden von ihnen eine eigene Zuordnungstabelle erstellt.

Die Zuordnung des Implementierungstyps bildet den Übergang zwischen der Prozesslogik und deren Implementierung. Anschließend muss noch definiert werden, welche Personen, Softwaresysteme und physikalische Systeme die Handelnden repräsentieren, und wie die einzelnen Aktionen konkret realisiert werden. In den folgenden Unterkapiteln werden diese Aspekte detailliert beschrieben.

6.2.2 Menschen und Organisation

Für jeden Kontext gilt es für alle Handlungen, an denen Menschen beteiligt sind, die jeweiligen Aufgaben- oder Handlungsträger, und damit konkret die ausführenden Personen oder Organisationseinheiten festzulegen.

In Unternehmen und Verwaltungen gibt es Personen mit unterschiedlicher Ausbildung, Qualifikationen, Vorlieben und Interessen. Es gibt Kaufleute, Entwickler, Handwerker usw., welche die anfallenden Tätigkeiten erledigen. Organisationen kann man daher auch als strukturierte Ressourcenpools bezeichnen. Je nach Art und Umfang der Aufgaben bildet die Organisation Einheiten, in denen die jeweiligen Spezialisten dafür zusammengefasst werden. So existieren Abteilungen für den Einkauf mit Beschaffungsexperten, oder Entwicklungsabteilungen, die aus mehreren Entwicklungsingenieuren und sonstigen Fachleuten gebildet werden. Der Bezug zwischen den Personen und Organisationen in der Aufbauorganisation zu den abstrakten Handelnden in den Prozessen kann statisch oder dynamisch hergestellt werden.

Statische Zuordnung

Im einfachsten Fall gibt die bereits erwähnte zweispaltige Tabelle Aufschluss darüber, welchem im Prozess definierten Akteur (Spalte 1) welche Personen oder Organisationen bzw. Organisationseinheiten zugeordnet sind (Spalte 2). Die zweite Spalte kann auch eine Organisation bzw. Organisationseinheit enthalten. Dann sind ihre Mitglieder dem abstrakten Handelnden zugeordnet. Damit wird erreicht, dass bei Krankheit oder Urlaub eine beliebige Person aus der Organisation die im Prozess anfallenden Aufgaben übernehmen kann. Außerdem lässt sich so auch die Arbeitslast verteilen, wenn Handlungen aus mehreren Prozessabläufen (Prozessinstanzen) abgearbeitet werden müssen.

Bei BPMN können Pools, Swim Lanes und einzelne Aktionen separat einem Ausführenden zugeordnet werden. Hier ist darauf zu achten, dass bei der Verwendung aller Zuordnungsmöglichkeiten keine Inkonsistenzen entstehen. Wenn ein Software-System eine Swim Lane als Handelnder ausführt und in dieser Swim Lane eine Human Task liegt, so ist nicht klar, was dies bedeutet. Für das BPMN-basierte Werkzeug von Bonitasoft [1] wurden deshalb Actors eingeführt. Sie sind Platzhalter für Aufgabenträger, denen dann, ähnlich den Subjekten in der Subjektorientierung, konkret Handelnde zugeordnet werden.

Bei S-BPM wird jeweils ein komplettes Subjekt in die Organisation eingebettet, d. h. die Zuordnung gilt dann für alle Aktionen in einem Subjekt.

Dynamische Zuordnung

In vielen Prozessen kann die Zuordnung der Handelnden aus dem Prozess zu Personen und Organisationen nicht statisch festgelegt werden. So kann bei einem Geschäftsreiseantrag der Bearbeiter davon abhängen, ob es sich um eine Inlands- oder Auslandsreise handelt. Während die Ablauflogik in beiden Fällen gleich sein kann, unterscheiden sich möglicherweise die ausführenden Personen, beispielsweise, weil ein Mitarbeiter besondere Expertise für internationale Reisen mit Visaangelegenheiten besitzt.

In solchen Fällen ist es sinnvoll, die handelnden Personen oder Organisationseinheiten erst beim Ablauf der Prozesslogik beispielsweise in Abhängigkeit von Datenwerten in Geschäftsobjekten (hier im Reiseantrag) zu ermitteln und zuzuordnen.

Für eine flexible, dynamische Zuordnung der Bearbeiter sind in der Regel Tabellen nicht mehr ausreichend, sondern es sind programmiersprachliche Konstrukte notwendig. Lavall et al. [2] zeigen, wie eine solche Sprache verwendet werden kann, um subjektorientierte Prozessmodelle in Organisationen einzubetten. Da in BPMN die Zuordnung der Bearbeiter über Pools, Lanes und Tasks möglich ist, gestaltet sich die Beschreibung der Zuordnung dort als sehr komplex. Verschiedene BPMN-basierte Werkzeuge wie Bonita [3] oder Activiti [4] integrieren Prozesse in die Organisation durch Programmierung in Java bzw. XML.

6.2.3 Physikalische Infrastruktur

Insbesondere in Fertigungsprozessen sind physikalische Systeme als Handelnde beteiligt. So können einer Maschine Rohteile über ein Transportsystem zugeführt werden, die Maschine bearbeitet die Rohteile und die bearbeiteten Teile werden zum nächsten Bearbeitungsschritt weiter transportiert. Wird eine solche Maschine als Subjekt oder Pool betrachtet, so werden die zugeführten Teile als zu empfangende und die abtransportierten Teile als zu sendende Nachrichten modelliert. Der Modellierer stellt den Bearbeitungsschritt als einzelnen Task in einem Subjekt oder Pool dar.

6.2.4 IT-Infrastruktur

Digitalisierung in der Wirtschaft bedeutet, Prozesse mit möglichst umfassender Unterstützung durch Software-Systeme umzusetzen. In entsprechenden Szenarien erledigen weitgehend Computer oder Maschinen die Tätigkeiten, menschliche Eingriffe werden soweit möglich und sinnvoll reduziert. Wesentliche Aspekte dabei sind:

• Die Steuerung des Prozessablaufs:

  Die im Prozessablauf beschriebenen Handlungsfolgen werden automatisch durch Computerprogramme gesteuert.

• Die Ausführung von Handlungen:

  Handlungen auf Datenobjekten können oft vollautomatisch durch entsprechende Computerprogramme ausgeführt werden.

Software-Systeme sind das Mittel zur Zusammenführung der verschiedenen Handlungstypen. So bindet beispielsweise eine Process Engine bei der Steuerung des Prozessablaufs die menschlichen und maschinellen Bearbeiter zur Laufzeit situationsgerecht in die Abarbeitung von Instanzen ein.

In den folgenden Ausführungen wird auf die Steuerung des Prozessablaufs und die Manipulation der zugehörigen Geschäftsobjekte durch Informationstechnologie eingegangen, jedoch noch ohne die Einbindung von Menschen oder physikalischen Systemen als Aufgabenträger näher zu betrachten. Diese ist Gegenstand von Abschn. 6.2.5.

Ablauf

Die Prozesslogik entspricht der Ablauflogik eines Computerprogramms. Die automatische vollständige Ausführung der Prozesslogik durch ein Computerprogramm ist nur bei stark strukturierten Prozessen möglich. Alle denkbaren Ablaufmöglichkeiten müssen abgedeckt sein. Es sind keine menschlichen Eingriffe vorgesehen. Um zu vermeiden, dass die beschriebene Prozesslogik von der Ausführungslogik des Computerprogramms abweicht, ist es hilfreich, wenn das Computerprogramm automatisch aus der Beschreibung der Prozesslogik abgeleitet werden kann. Dafür müssen folgende Voraussetzungen vorliegen:

• Die Syntax und Semantik der Sprache, in der die Prozesslogik beschrieben ist, muss präzise definiert sein.

• Die Beschreibung des Prozessablaufs muss in elektronischer Form vorliegen.

• Es muss ein Umsetzungsprogramm vorliegen, das die elektronische Form der Beschreibung der Prozesslogik liest und daraus, basierend auf der präzisen Semantik der Prozessbeschreibungssprache, ein Computerprogramm in einer geeigneten Programmiersprache erzeugt.

Die Bedeutung bereits heute weit verbreiteter verteilter Systeme nimmt mit der Entwicklung von Cloud und Edge Computing weiter zu. Dies kann bedeuten, dass auch Teile eines voll automatisierten Prozesses in einem verteilten System auf verschiedenen Rechnerknoten zur Ausführung kommen sollen. Da diese auf unterschiedlichen Technologien basieren können, müssen unter Umständen entsprechende Varianten für die automatische Umsetzung einer Ablaufbeschreibung in ein Computerprogramm verfügbar sein.

So können einzelne Subjekte einer S-BPM Beschreibung eines Prozesses auf unterschiedlichen Rechnerknoten eines verteilten Systems ablaufen. Dies kann bedeuten, dass der Programmcode für jedes Subjekt separat generiert werden muss. Vermeiden lässt sich dies, wenn der generierte Zielcode auf möglichst allen Knotentypen des verteilten Systems zur Verfügung steht, und dieses Zielsystem über ein Framework verfügt, durch das die auf verschiedenen Knoten laufenden Programmteile zusammenarbeiten können. Die Software-Komponenten synchronisieren ihre Zusammenarbeit in der Regel durch den Austausch von Nachrichten. Eine Programmiersprache, die dies ermöglicht, ist z. B. Java mit dem Framework AKKA, das den Nachrichtenaustausch über Rechnergrenzen hinweg erlaubt, auch ausgehend von S-BPM-Modellen [5].

In BPMN können einzelne Pools prinzipiell auf verschiedenen Rechnerknoten ausgeführt werden. Dies setzt voraus, dass eine Kommunikation zwischen den Pools über Rechnergrenzen hinweg möglich ist. Eine Recherche nach Möglichkeiten einer entsprechenden Codegenerierung für BPMN-Modelle im Frühjahr 2018 brachte keine Ergebnisse.

Aktivitäten und Daten

Bei vollständig digitalisierten Prozessen führen Computersysteme auch die im Prozessablauf enthaltenen Aktivitäten aus. Dies kann mittels Funktionen oder Services geschehen, die bereits in existierenden Anwendungsprogrammen verfügbar sind, und nur an den geeigneten Stellen in das Programm, das den Prozessablauf realisiert, eingefügt bzw. aufgerufen werden.

Für die Integration neu entwickelter Software für Aktivitäten kommen häufig Technologien zum Einsatz wie Web Services, REST-Schnittstellen oder einfache APIs. Datenbankzugriffe zur direkten Manipulation von Daten können abhängig von den Schnittstellen der verwendeten Datenbanksysteme analog eingebunden werden.

Bei der Verwendung von S-BPM gehören Daten zu einem Subjekt. Es ist nicht erlaubt, dass mehrere Subjekte auf gemeinsame Daten zugreifen. Möchten mehrere Subjekte die gleichen Daten z. B. in einer Datenbank nutzen, so muss diese in ein Subjekt ‚eingepackt‘ werden. Dieses Subjekt nimmt dann die entsprechenden Anfragen von den anderen Subjekten entgegen, führt die gewünschte Aktion aus und schickt das Ergebnis an das anfordernde Subjekt zurück.

Aktivitäten zusammen mit ihren Daten werden in der Software-Technologie als Klassen bezeichnet. Mehrere solcher Klassen können zu Services zusammengeschlossen werden. In der IT wird dann von einer Service-orientierten Architektur gesprochen. Die Services werden entsprechend der Ablauflogik des Prozesses aufgerufen. Tasks in BPMN können durch Services realisiert werden. Analog dazu können die Funktionen innerhalb eines Subjekts implementiert werden.

Ein aktuelles Konzept zur Strukturierung von Software-Systemen sind Microservices [6]. Microservices beschreiben eine Architektur, bei der einzelne kleine fachliche Software-Bausteine unabhängig voneinander und, bei Bedarf, auf verschiedenen technischen Plattformen programmiert, getestet, abgenommen und bereitgestellt werden. Durch ihr Zusammenspiel über von der Programmiersprache unabhängige Schnittstellen lässt sich komplexe Anwendungssoftware realisieren. Dabei kommunizieren Microservices meist durch den Austausch asynchroner Nachrichten. Dies entspricht auch dem Konzept des Reactive Programming [7], dessen wesentliche Eigenschaft die Kopplung von Programmbausteinen durch asynchrone Nachrichten ist.

In BPMN können Pools als Microservices implementiert werden, falls alle Tasks in einem Pool vom gleichen Aufgabenträger ausgeführt werden.

Bei S-BPM sind Subjekte immer einem Aufgabenträger zugeordnet und kommunizieren über den asynchronen Austausch von Nachrichten. Deshalb entspricht ein subjektorientiert beschriebener Prozess mit Blick auf die IT-Architektur einer Microservice-orientierten Struktur, die den Anforderungen des Reactive Programming genügt.

6.2.5 Kombinationen von Aufgabenträgern

Tasks werden häufig nicht von einem einzigen Aufgabenträgertyp ausgeführt. Mit der zunehmenden Digitalisierung werden beispielsweise die Aufgaben, die ausschließlich Menschen ausführen, immer seltener. So erhält heute ein Lagerarbeiter seine Kommissionierungsaufträge häufig über ein Tablet, das mit einem IT-System verbunden ist. Nachdem er die Waren zusammengestellt hat, bestätigt er dies auch auf dem Tablet. Damit ist die Kommissionierungsaufgabe abgeschlossen. Das IT-System aktualisiert die Daten und stößt die Folgeaufgabe wie z. B. die Vorbereitung der Versanddokumente automatisch an. Die Kommissionierungsaufgabe wird also durch Mensch und IT als Typen von Aufgabenträgern ausgeführt, eine Kombination, die man in Geschäftsprozessen sehr häufig findet. Die IT übernimmt dabei zumindest die Steuerung der Prozesslogik und die Verwaltung der Daten, während Menschen Eingaben tätigen oder Maschinen bedienen.

Von Kleinrechnern mit entsprechender Software gesteuerte Maschinen lösen zunehmend Maschinen als rein mechanische Aufgabenträger ab. Diese eingebetteten Systeme (Embedded Systems) steuern die Mechanik und wickeln die Kommunikation mit anderen Maschinen oder übergeordneten Geschäftsanwendungen ab. Die Kommunikation mit anderen intelligenten Maschinen wird als horizontale Kommunikation und mit Geschäftsanwendungen als vertikale Kommunikation bezeichnet. Letztere verknüpft Produktionssysteme mit Geschäftsprozessen und ist ein wesentlicher Bestandteil der Industrie 4.0 Initiative.

In den folgenden Abschnitten wird nun detaillierter beschrieben wie die verschiedenen Aufgabenträger in die Implementierung der Prozessablauflogik integriert werden.

Kombination Mensch-IT

Die Kombination von Mensch und IT bei der Ausführung von Geschäftsprozessen ist der Kern deren Digitalisierung. Die IT übernimmt dabei zumindest die Steuerung der Prozesslogik, d. h. sie veranlasst entsprechend der Prozesslogik, dass die vorgesehenen Aufgaben von den jeweiligen Aufgabenträgern erledigt werden. Zusätzlich können Aufgaben von der IT direkt als Aufgabenträger ausgeführt werden, ohne dass Menschen eingebunden werden müssen. Kann eine Aufgabe nur durch menschliche Unterstützung erledigt werden, fordert die für die Ablauflogik zuständige Software über eine entsprechende Benutzungsschnittstelle den zuständigen menschlichen Aufgabenträger dazu auf. Dies kann zur Eingabe von Daten sein, aber auch zur Rückmeldung, dass der Benutzer eine manuelle Aktion ausgeführt hat.

IT-Systeme als Steuerungssoftware und als Handlungsträger für Aktivitäten übernehmen in der Regel auch die Speicherung der während einer Prozessausführung anfallenden Daten, sowohl Inhalte von Geschäftsobjekten, als auch Metadaten wie Zeitstempel für Beginn und Ende von Instanzen und Ausführungsschritten.

Eine umfassende Plattform zur Implementierung von Geschäftsprozessen, die Menschen und IT-Lösungen ausführen, wird als Workflow-Management-System bezeichnet. Die Workflow Management Coalition (WfMC) hat dafür ein Referenzmodell entwickelt. Abb. 6.3 zeigt die darin vorgesehenen Komponenten und Schnittstellen [8].

Abb. 6.3

Referenzmodell für Workflow-Management-Systeme (WFMS)

Die Schnittstellen zwischen den einzelnen Komponenten sind wie folgt definiert:

• Prozessdefinition (Schnittstelle 1)

  Schnittstelle zwischen Prozessdefinition, Modellierungswerkzeugen und der Workflow Engine (Ausführungsumgebung)

• Benutzungsschnittstelle (Schnittstelle 2)

  APIs für Clients, um Dienste von der Workflow Engine anzufordern, damit der Prozessfortschritt und die Aktionen kontrolliert werden können.

• Applikations-Schnittstelle (Schnittstelle 3)

  APIs, die der Workflow Engine erlauben, Applikationen aufzurufen und zu nutzen.

• Workflow-Management-System-Schnittstelle (Schnittstelle 4)

  Standard-Schnittstelle für den Austausch mit anderen Workflow-Systemen

• Administration und Monitoring (Schnittstelle 5)

  Schnittstelle für Werkzeuge zur Kontrolle der Prozesse und zur Überwachung

Die wesentlichen Komponenten im Referenzsystem der WfMC sind der Workflow Enactment¹ Service und die Workflow Engine. Die Aktionen und ihre Reihenfolge werden in der Prozessdefinition festgelegt und durch die Workflow Engine gesteuert.

In einem Unternehmen laufen in der Regel mehrere Instanzen eines Geschäftsprozesses gleichzeitig ab. Eine Prozessinstanz entsteht, wenn die Ausführung eines Geschäftsprozesses durch das dafür definierte Ereignis angestoßen wird. Prozessinstanzen folgen der einheitlichen Prozessbeschreibung, werden aber unabhängig voneinander ausgeführt.

Beispielsweise können zwei verschiedene Kunden eine Bestellung tätigen. Jeder dieser individuellen Kundenaufträge erzeugt eine eigenständig abzuwickelnde Instanz des Geschäftsprozesses „Auftragsbearbeitung“.

Das Management der einzelnen Instanzen übernimmt das Workflow Enactment System mithilfe von Workflow Engines. Eine Workflow Engine stellt die Ausführungsumgebung für eine Workflow-Instanz zur Verfügung. Ihre wesentlichen Aufgaben sind:

• Einordnung der Instanz in das organisatorische Umfeld

• Interpretation der Prozessdefinition

• Kontrolle der Prozessinstanzen

• Navigation zwischen sequenziellen oder parallelen Prozessaktivitäten

• Interpretation von Prozessdaten

• Identifikation der Benutzungsschnittstellen

• Verknüpfung mit anderen Programmen/Anwendungssystemen

• Verknüpfung mit anderen Workflowsystemen

• Übergeordnete Kontrollfunktion

Ein Workflow Enactment Service ist ein Dienst, der eine oder mehrere Workflow Engines startet, verwaltet und ausführt. Über Applikationsschnittstellen greifen Workflow-Systeme auf Funktionen von Anwendungssystemen zu, die in einem Prozess vorgesehene Aufgaben ausführen.

Ein Worklist Handler ist eine Komponente, welche die Benutzer in einen Prozess einbindet. Er kann Teil eines Workflow-Management-Systems sein, oder von einem Workflow-Experten definiert und programmiert werden. Durch den Worklist Handler wissen die beteiligten Aufgabenträger, in welcher Prozessinstanz sie welche Aufgaben zu erledigen haben.

Damit Benutzer bei der Bearbeitung von Prozessinstanzen eine einheitliche Arbeitsoberfläche haben, können Workflow-Funktionen in andere gebräuchliche Anwendungen eingebettet werden, beispielsweise in ein E-Mail-Programm. Für eine solche Integration muss zwischen dem Workflow Enactment Service und den anderen Anwendungen ein Kommunikationsmechanismus bestehen.

Die Referenzarchitektur sieht auch eine Schnittstelle für Administration und Monitoring vor. Dort anknüpfende Software dient der Überwachung des gleichzeitigen Ablaufs verschiedener Instanzen von mehreren Geschäftsprozessen. Dieses Monitoring bezieht sich zum einen auf die fachliche Ebene der Abwicklung der Geschäftsfälle, beispielsweise mit der Erfassung und Auswertung von Antwort- und Bearbeitungszeiten (vgl. Abschn. 6.3.3). Zum anderen sind auf der technischen Ebene die verwendeten IT-Systeme zu überwachen, etwa bezüglich Last- und Fehlverhalten.

Die meisten derzeit am Markt angebotenen Workflow-Systeme unterstützen nur die Prozessorchestrierung, d. h. einen einzigen Kontrollfluss von Aufgaben. Für BPMN bedeutet dies, dass ein Workflow-System nur die Funktionen in einem Pool ausführen kann. Werden in einer BPMN-basierten Prozessbeschreibung mehrere Pools verwendet, ist für jeden Pool eine eigene Workflow Engine nötig. Diese Workflow Engines müssen dann in der Regel durch Programmierung über die Schnittstelle 4 verbunden werden. Insbesondere wenn ein Prozess auf einer verteilten Infrastruktur ausgeführt werden soll, können solche Strukturen aufwendig und kostenintensiv werden, da viele Softwarehersteller Lizenzgebühren für jede installierte Instanz der Workflow Engine berechnen. Damit steigen neben den technischen Schwierigkeiten auch die Kosten.

Subjektorientierte Prozessbeschreibungen sind Prozesschoreografien, d. h. die Subjekte werden unabhängig voneinander parallel ausgeführt, ohne dass es eine zentrale Steuerung für alle Subjekte gibt. Zur Koordination ihrer einzelnen Tätigkeiten tauschen die Subjekte asynchron Nachrichten aus. Eine Ausführungsumgebung für subjektorientiert definierte Prozesse ist deshalb genau genommen ein sogenanntes Multiworkflow-System. Darin entspricht jedes Subjekt einer Orchestrierung, die von einem eigenen Workflow-System ausgeführt wird. Den asynchronen Nachrichtenaustausch zwischen mehreren Workflow-Systemen wird im subjektorientierten Prozessmanagement mithilfe des Input-Pool-Konzepts realisiert. Für S-BPM wurde eine Reihe von Multiworkflow-Systemen entwickelt [9].

Kombination Physik-IT: Cyber Physical Systems

In einem Prozess können Handelnde auch Maschinen sein, welche Aufgaben, rein mechanisch oder elektrisch gesteuert, vollautomatisch ohne menschliches Eingreifen erledigen.

Die Maschinensteuerung erfolgt mechanisch, elektromechanische oder, bei den bereits angesprochenen Embedded Systems, zunehmend rechner- und softwarebasiert. Sensoren kontrollieren den physikalischen Zustand von Maschine inkl. Umgebungsbedingungen, und Aktoren wie Stellmotoren, Schalter, Regler usw. greifen in den Betrieb der Maschine ein. Die Steuer-Software bestimmt weitgehend das Geschehen auf und an den intelligenten Maschinen sowie deren vertikale und horizontale Kommunikation mit anderen Systemen.

Maschinen kommunizieren untereinander nicht nur durch den Austausch von Daten, sondern auch durch das Weiterleiten und Empfangen von physikalischen Artefakten. Die Nachricht „Zu entgratendes Werkstück“ kann dadurch realisiert sein, dass ein Werkstück von einer spanabhebenden Fertigungsmaschine automatisch weitertransportiert wird zu einer Maschine, die Kanten entgratet. Parallel dazu können bei der Entgratungsmaschine zusätzlich Nachrichten eintreffen, die eine nähere Beschreibung des Werkstücks enthalten sowie die Art der Entgratung spezifizieren.

Kombinationen aus physikalischen und informationstechnischen Komponenten werden als Cyber Physical Systems (CPS) bezeichnet. Da sie Produktions- und Geschäftsprozesse zusammenführen sind sie von besondere Bedeutung für Industrie 4.0 -Anwendungen.

In BPMN kann der Modellierer einen Task, der von einer Kombination aus Mensch und IT ausgeführt wird, als Service Task modellieren, und eine intelligente Maschine als eigenen Prozess in einem Pool beschreiben. Gibt es eine entsprechende Anzahl von Maschinen, die in einer komplexen Fertigungssituation zusammenarbeiten, so kann die Verwendung von zahlreichen Pools in BPMN zu Darstellungsproblemen führen. Der Grund liegt in der horizontalen Anordnung der Pools, sodass bei einer größeren Anzahl die Nachrichtenkanten zwangsläufig Pools kreuzen müssen, was Unübersichtlichkeit bewirkt. In S-BPM wird eine Maschine dagegen immer als Subjekt modelliert, da erst bei der Implementierung entschieden wird, durch welche Art von Aufgabenträger das Subjekt ausgeführt wird.

Wird in einem Prozess ein physikalischer Aufgabenträger verwendet, kann es von diesem Prozess nicht beliebig viele parallele Instanzen geben. Eine physikalische Einheit kann nicht logisch aufgespalten werden, wie dies bei Aufgabenträgern der IT oder Menschen möglich ist. Auf diese Thematik werden wir im Abschn. 6.3.2 näher eingehen.

Kombination Mensch-Physik-IT

Auch beim Einsatz intelligenter Maschinen gibt es Szenarien, bei denen der Mensch bestimmte Aufgaben ausführt. Beispielsweise erhält eine Maschine das Werkstück über ein Transportsystem und die dazugehörigen Informationen als Nachricht. Die Maschine und ein Bediener führen die vorgesehenen Aufgaben gemäß den Angaben in den Begleitinformationen zusammen aus. Der Bediener bestätigt die Erledigung seiner Arbeiten über eine Benutzungsschnittstelle. Anschließend wird das Werkstück abtransportiert, und die aktualisierten Begleitinformationen wird an weitere involvierte Handelnde übermittelt.

In solchen Situationen ist es das Bestreben, den Anteil der menschlichen Arbeit weiter zu reduzieren und durch ausgefeiltere Mechanik oder verbesserte Embedded Systems zu ersetzen. Dabei muss es nicht zwingend notwendig sein, die Prozesslogik zu verändern.

6.3 Betrieb und Monitoring

6.3.1 Inbetriebnahme

Nach der Festlegung der Aufgabenträger und der Implementierung(sunterstützung) der Handlungen gilt es den Prozess in Betrieb zu nehmen.

Dazu müssen die Aufgabenträger vorbereitet werden, indem die physikalische und informationstechnische Infrastruktur aufgebaut und die menschlichen Aufgabenträger geschult werden. Informationstechnische Aufgabenträger werden mit den jeweiligen Programmen geladen und die Mechanik von Maschinen entsprechend eingestellt.

Bei der Inbetriebnahme ist es wichtig, die Verknüpfung mit anderen Prozessen herzustellen. In einem Unternehmen sind Prozesse in ein zusammenhängendes Netzwerk von Prozessen eingebunden. Es sollte keine isolierten Prozesse geben. Wird z. B. ein neuer Prozess Versandvorbereitung eingeführt, muss dieser verknüpft sein mit dem Prozess Auftragsannahme. Bei kommunikationsorientierten Prozessbeschreibungen geschieht dies einfach durch den Austausch von Nachrichten. Ein andere Möglichkeit sind gemeinsame Daten, d. h. Prozesse schreiben Daten, die andere Prozesse benötigen in eine gemeinsam genutzte Datenbank.

Nach den Vorbereitungsarbeiten sollte der Prozess als Gesamtkonstrukt getestet werden. Vorteilhaft dazu wäre eine Testumgebung, die ein möglichst realistisches Abbild der Einsatzumgebung darstellt. Allerdings ist diese Wunschsituation aus Kostengründen nicht oft gegeben.

Unabhängig davon empfiehlt es sich den Prozess Schritt für Schritt einzuführen. Dabei ist von Vorteil, wenn ein Prozess als ein lose gekoppeltes System von kommunizierenden Aufgabenträgern beschrieben und umgesetzt wurde. Die einzelnen Handlungsstränge für die Handlungsträger können Schritt für Schritt in Betrieb genommen werden. Da sie durch den asynchronen Nachrichtenaustausch nur lose miteinander gekoppelt sind, kann man andere Aufgabenträger zunächst einfach simulieren. Bei BPMN wird somit Pool für Pool in Betrieb genommen. Sind die Pools allerdings sehr komplex mit mehreren Swim Lanes, gestaltet sich die Inbetriebnahme ebenfalls als komplex. Bei der Verwendung von S-BPM kann ein System durch das schrittweise Hinzunehmen der einzelnen Subjekte aufgebaut werden.

Werden in BPMN nicht mehrere Pools verwendet, d. h. ein Prozess wird rein kontrollflussorientiert definiert und implementiert, kann dieser auch nur insgesamt in Betrieb genommen werden.

Bei Choreografien, d. h. bei der Verwendung von Subjekten bzw. mehrerer Pools kann der Prozess ausgeführt werden, obwohl z. B. bei einem Pool die Software noch fehlerhaft ist. Die an diesen Pool gesendeten Nachrichten können ersatzweise von Menschen entgegengenommen, bearbeitet und das Ergebnis als Nachricht zurückgesendet werden. Die anderen Pools nehmen die beschriebene Ablauflogik wahr (beobachtbares Verhalten), die aber noch nicht in der endgültigen Form implementiert ist.

6.3.2 Prozessinstanzen

Die konkrete Ausführung eines Prozesses wird als Prozessinstanz bezeichnet. Eine Prozessinstanz entsteht, wenn das Startereignis eintritt. Dies kann der Anruf eines Kunden sein, der ein Produkt bestellen möchte. In diesem Fall kreiert ein Telefonverkäufer explizit eine Instanz indem er den digitalen Bestellvorgang startet und die notwendigen Daten eingibt. Bei Bestellungen in einem Online-Shop erfasst der Kunde die Auftragsdaten selbst und erzeugt eine Instanz, sobald er den Kauf bestätigt. Anschließend durchläuft eine Instanz in beiden Fällen die gemäß der definierten Prozesslogik vorgesehenen Bearbeitungsschritte und -stellen.

Da in einem Unternehmen normalerweise zu einem bestimmten Zeitpunkt mehrere Bestellungen vorliegen, existieren gleichzeitig mehrere voneinander unabhängige Prozessinstanzen, die sich in verschiedenen Bearbeitungsstadien befinden. Mitarbeiter eines Unternehmens sind in der Regel in mehrere Prozessinstanzen eingebunden und führen darin jeweils die für sie vorgesehenen Aufgaben aus. Sie teilen sozusagen jeder Prozessinstanz eine Zeitscheibe ihrer Arbeitszeit zu. Analog geschieht dies bei IT-Systemen. Sowohl die Kapazität der Ressource Mensch als auch der IT-Systeme kann also in Zeitscheiben aufgeteilt werden, um mehrere Instanzen von gleichen oder unterschiedlichen Prozessen zu bearbeiten.

Bei physikalischen oder cyber-physikalischen Systemen ist dies nicht so ohne weiteres möglich. Ein solches System kann zu einem Zeitpunkt nur in genau einer Instanz involviert sein. Eine Maschine kann nicht mehrfach instanziiert werden, sie ist eben nur einmal vorhanden. Erst wenn eine Maschine eine Aufgabe oder Aufgabenfolge in einer Prozessinstanz vollständig abgeschlossen hat kann sie für eine andere Prozessinstanz tätig werden. Zu einem bestimmten Zeitpunkt ist ein physikalisches System deshalb genau einer Prozessinstanz zugeordnet.

Dieser Sachverhalt ist wichtig, wenn Prozesse, die problemlos instanziiert werden können, da sie keine physikalischen Aufgabenträger enthalten, mit Prozessen verknüpft werden, die physikalische Komponenten enthalten. Ein Fertigungssystem besteht nahezu vollständig aus physikalischen oder cyber-physikalischen Aufgabenträgern. Diese Prozesse werden zu Beginn instanziiert. Diese eine Instanz besteht dann bis die Fertigung abgeschaltet wird. Ein physikalischer Aufgabenträger kann nicht eine Zeitscheibe für eine Prozessinstanz 1 arbeiten, dann etwas für eine Prozess 2 tun, um danach wieder für die Prozessinstanz 1 weiterzuarbeiten. Die Aktionen eines physikalischen Aufgabenträgers für verschiedenen Prozessinstanzen wären nicht unabhängig voneinander. Soll beispielsweise ein Ventil für die Prozessinstanz 1 halb geöffnet werden und danach für die Prozessinstanz 2 ganz geöffnet werden dann wird natürlich auch für die Prozessinstanz 1 das Ventil ganz geöffnet, was aber nicht sein soll.

Wird in BPMN eine Maschine einem Task zugeordnet und kann der zugeordnete Pool mehrfach instanziiert werden, so muss die Maschine zur Laufzeit immer einer einzelnen Instanz zugeordnet werden. Die Maschine muss immer wissen, für welche Instanz sie tätig ist, um die richtigen Begleitdaten aus dem allen Instanzen gemeinsamen Speicher zu holen, um dann aus dem Werkstückbehälter das zu bearbeitende Werkstück zu entnehmen.

Bei S-BPM ist die Maschine dem entsprechenden Subjekt zugeordnet. Dieses empfängt das Werkstück und die Begleitdaten als Nachricht. Die Begleitdaten enthalten auch eine Identifikation der zugehörigen übergeordneten Prozessinstanz, in der Regel die Auftragsnummer. Damit weiß die Maschine, für welche Prozessinstanz sie nun arbeitet. Die Nachricht, mit der eine Maschine ihre Arbeit für beendet erklärt, geht an eine Subjektinstanz in der beauftragenden Prozessinstanz.

6.3.3 Monitoring

Prozessbeteiligte führen im Tagesgeschäft Geschäftsprozesse gemäß des modellierten Designs in der bei der Umsetzung geschaffenen Umgebung aus Personal- und technischen Ressourcen aus (vgl. Abschn. 6.2).

Jeder anfallende Geschäftsvorfall durchläuft als Instanz diese Ausführungsumgebung. Dabei zeichnen Transaktionssysteme wie Enterprise-Resource-Planning-Anwendungen (ERP) oder Workflow Engines das Verhalten der Instanz in Form von Einträgen in einem Log File (Event Log, Audit Log) auf. Ein Log-Datensatz enthält u. a. eine eindeutige Vorgangsidentifikation, Teilschrittidentifikation und Zeitstempel für Beginn und Ende. So entstehen Rohdaten für die Berechnung von Prozesskennzahlen (Process Performance Indicators, PPIs).

Verlässliche Managementinformation auf Basis solcher Kennzahlen ist die Voraussetzung für eine kontinuierliche Anpassung der Prozessgestaltung im Hinblick auf höhere Zielerreichungsgrade. Die periodische Ex-post-Auswertung über eine Vielzahl von Instanzen über längere Zeiträume wie Wochen, Monate, Quartale etc. dient dabei vorwiegend der Erkennung struktureller Verbesserungspotenziale, beispielsweise bezüglich planmäßigem Personaleinsatz, Ablauflogik oder Grad der IT-Abdeckung. Dieses traditionelle Monitoring und Reporting folgt dem Konzept der Business Intelligence mit dem Prinzip „Store and analyze“ und den Methoden des Data und Process Mining. Daraus resultierende Veränderungen sind eher mittel- und langfristiger Natur.

Um auch den steigenden Echtzeitanforderungen Rechnung zu tragen, wird das traditionelle Prozessmonitoring deshalb mittlerweile ergänzt durch das Business Activity Monitoring (BAM), welches ereignisgetrieben nahezu in Echtzeit Daten auswertet, zeitnah Ergebnisse meldet und damit kurzfristige, instanzbezogene Maßnahmen ermöglicht [10]. Beispiel wäre die bevorzugte weitere Bearbeitung der Bestellinstanz eines A-Kunden, wenn das System erkennt und meldet, dass diese an einem Messpunkt hinter dem dort üblichen Bearbeitungsfortschritt hinterherhinkt und deshalb der zugesagte Liefertermin nicht zu halten ist (predictive analysis).

BAM nutzt das Konzept des Complex Event Processing (CEP) mit dem Prinzip „Stream and analyze“ und Stream-Mining-Methoden. Dies bedeutet, dass das System im Strom von aufgezeichneten einzelnen Vorkommnissen (z. B. gesetzte Zeitstempel, passierte Messpunkte) permanent nach Mustern für komplexe Ereignisse sucht, die erst durch die Verknüpfung der einzelnen Ereignisse Relevanz für bestimmte Zwecke erlangen. Typisches Beispiel ist die Erfassung zweier Transaktionen mit derselben Kreditkarte in Hamburg und New York. Diese einfachen Einzelereignisse (low level events) werden im Ereignisstrom als normale Vorgänge registriert. Das CEP-System kombiniert sie erst zu einem komplexen Ereignis (complex event), wenn beide Transaktionen innerhalb eines kurzen Zeitraum stattfinden, im Beispiel etwa 3 h. In diesem Fall würde ein Ereignismuster aus geografischem und Zeitabstand zur Klassifikation als komplexer Event „angenommener Kreditkartenmissbrauch“ führen.

Business Activity Monitoring soll permanent und gleichzeitig eine Vielzahl von Datenquellen überwachen. Zu den Erzeugern von Ereignisdaten gehören Anwendungen, die Prozessinstanzen verarbeiten (z. B. ERP, CRM, Workflow Engines) sowie andere Informationen von innerhalb oder außerhalb des Unternehmens liefern (z. B. Umgebungsbedingungen, Wetter- und Verkehrsdaten). Zunehmend zählen dazu auch (Sensor)Daten, die smarte Geräten und Einrichtungen im Internet of Things produzieren. BAM analysiert und aggregiert die Datenflut mithilfe definierter Regeln und übermittelt Ergebnisse an berechtigte und interessierte Empfänger.

Abb. 6.4 stellt das traditionelle und das komplementäre Business Activity Monitoring nebeneinander. Als Vergleichsmerkmal dienen die in der linken Spalte aufgeführten Aktivitäten [10].

Abb. 6.4

Eigenschaften von traditionellem und Business Activity Monitoring

Zeitpunkt und Art der Verwertung der aufgezeichneten/registrierten Daten hängen von der Ausgestaltung des Monitoring und Reporting gemäß der Anwenderanforderungen ab. Beim Pull-Prinzip ruft der Anwender die von ihm gewünschte Auswertung zu einem beliebigen Zeitpunkt ab. Nach dem Push-Prinzip erzeugt das System zeitgesteuert z. B. täglich, wöchentlich, monatlich, quartalsweise zu festgelegten Zeiten Auswertungen und informiert den vordefinierten Empfängerkreis davon. Beim Überschreiten von Grenzwerten oder Toleranzschwellen für Process Performance Indicators einzelner Instanzen zur Laufzeit können, ebenfalls per Push, Alarmmeldungen an Verantwortliche übermittelt oder andere Vorgänge gestartet werden, z. B. ein umfangreicher Eskalationsprozess mit Korrekturmaßnahmen für den betreffenden Fall.

Als Präsentationsform für die Auswertungen dominieren Management Cockpits mit Instrumententafeln (Dashboards). Dort finden sich meist Darstellungen in Form von Tachometern, Ampeln und Balken- oder Kreisdiagrammen. Für platzsparende Anzeigen mit hoher Informationsdichte kommen auch Wortgrafiken wie Sparklines oder Bullet Graphs zum Einsatz. Beispiele für Auswertungen und ihre Darstellung sind:

• Durchlaufzeit von laufenden und abgeschlossenen Instanzen. Der Status wird in Ampelfarben ausgedrückt, je nach Abweichung von definierten Sollwerten bzw. Toleranzbereichen (vgl. Abb. 6.5).

  Abb. 6.5

  

  Instanzbericht (Übersicht)

• Durchlaufzeit einer laufenden Instanz (absoluter Wert und Vergleich mit Durchschnitt, chronologischer Ablauf und Dauer der Einzelschritte der Prozessbeteiligten (vgl. Abb. 6.6).

  Abb. 6.6

  

  Instanzbericht (Einzelne Instanz)

• Abfolge der Prozessschritte einer laufenden Instanz mit Zeitstempeln für den Abschluss eines Schritts, d. h. für den Übergang von einem Zustand in den nächsten (vgl. Abb. 6.7).

  Abb. 6.7

  

  Instanzbericht (aktueller Bearbeitungsstand)

• Anzahl von Instanzen eines Prozesses pro Zeiteinheit, minimale, durchschnittliche und maximale Bearbeitungszeit pro Prozessbeteiligtem und -schritt (vgl. Abb. 6.8).

  Abb. 6.8

  

  Prozessbericht

6.3.4 Process Mining

Eine spezielle Form der Auswertung von Prozessdaten stellt das Process Mining dar. Dabei werden Log Files genutzt, um aus den Transaktionsdaten zentraler IT-Systeme (u. a. ERP, CRM und SCM) prozessbezogene Informationen zu extrahieren und so den tatsächlichen Prozessablauf visuell rekonstruieren und analysieren zu können. Dadurch können Erkenntnisse über das wirkliche Verhalten von abgewickelten Prozessinstanzen gewonnen werden [11]. Häufig analysierte Unternehmensprozesse sind: Einkauf, Verkauf, Kreditoren-/Debitorenbuchhaltung, Ticketing-Systeme (z. B. im IT-Service Management).

Ein Event Log enthält sequenziell aufgezeichnete Ereignisse (trace) mit Attributen wie Fallnummer (caseID), Aktivität (activity), Zeitstempel (timestamp), ausführender Einheit (resource) und bearbeitete Geschäftsobjekte (data elements). Je nach Prozess können weitere Informationen dazu kommen, wie z. B. der Name eines Kunden oder Lieferanten, Bestellmenge und -wert, Liefermenge etc. In Abb. 6.9 ist ausschnittsweise ein Beispiel für ein Event Log dargestellt.

Abb. 6.9

Ausschnitt aus Event Log (Abbildung übernommen mit Genehmigung der Celonis SE)

Mit Bezug solcher Protokolldaten für die Prozessausführung zu Prozessmodellen lassen sich drei wesentliche Arten von Process Mining identifizieren [11]:

• Entdeckung (Discovery): dabei rekonstruieren Algorithmen aus den Log-Daten ohne weitere Informationen den tatsächlichen Prozessablauf und dessen vielfältige Varianten. Damit lassen sich bereits gelebte, aber noch nicht dokumentierte Prozesse formal beschreiben.

• Konformität (Conformance): dabei vergleichen Algorithmen ein vorhandenes, gültiges Prozessmodell mit dem tatsächlichen Ablauf wie er aus den Log-Daten abgeleitet wird. Festgestellte Abweichungen können Anhaltspunkte für Optimierungen liefern und Missbrauch oder Verstöße gegen Compliance-Regeln aufdecken.

• Erweiterung (Enhancement): hier werden bestehende Modelle an die Realität der Vorgangsbearbeitung angepasst (Repair) oder dem Modell weitere Perspektiven wie Zeitdauern hinzugefügt (Extension).

Insbesondere die Überprüfung der Konformität sollte möglichst zur Laufzeit von Instanzen im Rahmen des Business Activity Monitoring durchgeführt werden, um Verstöße zeitnah zu entdecken und deren Folgen mildern zu können (z. B. Stoppen einer Überweisung bei Unregelmäßigkeiten bei der Zahlungsfreigabe).

Das folgende Beispiel ist der Process-Mining Lösung der Celonis SE (www.celonis.com) entnommen. Es zeigt ausgewählte Mining-Ergebnisse für einen Bestellabwicklungsprozess (Purchase to-Pay), der mit einem ERP-System abgewickelt wird. Die Analyse des dazugehörigen Event Logs für einen bestimmten Zeitraum hat folgende Information hervorgebracht (vgl. Abb. 6.10):

Abb. 6.10

Übersicht über Prozessvarianten (rechts) und Happy Path (links) (Screenshot des Celonis Viewer/Variant Explorer mit Genehmigung der Celonis SE)

• 279.020 Instanzen des Prozesses mit einem Nettobestellwert von 539.180.072 €

• 107.688 Instanzen folgten dem normalen Ablauf des Prozesses (Happy Path), beginnend mit dem Erstellen einer Bestellanforderung und endend mit der Verbuchung der Rechnung (siehe Fallnummer 10.002 in Abb. 6.9). Die durchschnittliche Durchlaufzeit beträgt 27 Tage Diese Prozessvariante 1 deckt 39 % aller Instanzen ab, daneben existieren 527 andere Varianten.

Erweitert man den Betrachtungsraum beispielsweise auf die sieben am häufigsten vorkommenden Prozessvarianten, sieht man, dass damit 83 % aller Instanzen abgedeckt sind. Im Prozessgraphen sind jetzt auch die sieben Pfade mit den dazugehörigen Häufigkeiten sichtbar (vgl. Abb. 6.11). Alternativ können auch die durchschnittlichen Dauern der Wege und Zustandsübergänge angezeigt werden. Bezüglich des Ablaufs fällt außerdem auf, dass eine nicht geringe Zahl von Instanzen (18.938) mit dem Scan der Rechnung beginnt und erst dann eine Bestellung im System angelegt wird (siehe Fallnummer 10.003 in Abb. 6.9). Dies ist ein Indiz für sog. Maverick Buying, d. h. die Beschaffung von Fachabteilungen am Einkauf vorbei. Diesem i. d. R. unerwünschten Prozessverhalten kann im nächsten Schritt gezielt nachgegangen werden, um dessen Ursachen zu beseitigen.

Abb. 6.11

Anzeige der sieben häufigsten Prozessvarianten (Screenshot des Celonis Viewer/Variant Explorer mit Genehmigung der Celonis SE)

Mit der Einblendung zusätzlicher Informationen lassen sich Prozesse tiefergehend untersuchen. Abb. 6.12 gibt beispielsweise Auskunft über die auf Monate verteilte Anzahl von Bestellungsinstanzen mit den jeweiligen Wertangaben sowie deren Verteilung auf Lieferanten.

Abb. 6.12

Einblendung zusätzlicher Information (Screenshot des Celonis Viewer/Analysis mit Genehmigung der Celonis SE)

Die vorgestellten Analysen betreffen nur einen kleinen Ausschnitt der vielfältigen Nutzungsmöglichkeiten der Celonis-Umgebung. So können die Anwender über die vom System vorgesehenen Auswertungen hinaus auf Basis ihrer individuellen Datenmodelle eigene Auswertungen durch Rückgriff auf eine Vielzahl vorhandener Analysekomponenten (wie verschiedene Diagrammtypen, Prozesskennzahlen und OLAP-Tabellen) definieren. Außerdem erlaubt die Software die Ausführung eigener Prozessauswertungen mithilfe der Process Query Language (PQL).

Zusätzliche Funktionen erlauben etwa die Analyse der Konformität des tatsächlichen mit dem im Modell vorgesehenen Ablauf (Konformität) oder die parallele Visualisierung und damit die Gegenüberstellung unterschiedlicher Verhalten desselben Prozesses beispielsweise in zwei Niederlassungen (Benchmarking).

Die Zukunft des Process Mining liegt in der Kombination der Prozessanalyse mit intelligenten Algorithmen. So integriert beispielsweise die Celonis Proactive Insights Engine (Pi) Machine Learning und Artificial Intelligence Techniken, und identifiziert für den Nutzer automatisch Schwachstellen im Prozess sowie deren Ursachen [12]. Darauf aufbauend erhält der Nutzer zudem intelligente Empfehlungen zur Prozessverbesserung.

6.3.5 Kontinuierliche Wartung

Ziel von Monitoring, Auswertung und Reporting des Prozessverhaltens ist es, Managementinformation zum Prozessverhalten zu erzeugen und bereitzustellen. Die Adressaten können diese analysieren, Ursachen für Abweichungen von Zielwerten erforschen und kurz-, mittel- und langfristige Handlungsbedarfe und Maßnahmen zur Restrukturierung daraus ableiten.

Die folgenden Ausführungen erläutern typische Veränderungen der Prozessgestaltung, welche sich positiv auf das Prozessverhalten im Sinne einer Optimierung auswirken sollen. Wir beziehen uns dabei exemplarisch auf das Kreditantragsbeispiel aus Abschn. 4.2.2.

• Parallelisieren und überlappte Ausführung . Logisch und technisch voneinander unabhängige Aktivitäten können ganz oder teilweise gleichzeitig und von verschiedenen Aufgabenträgern ausgeführt werden. Zwar kann die Zahl unterschiedlicher Aktivitäten durch die Aufspaltung ansteigen, die Parallelisierung bewirkt aber oft eine Prozessbeschleunigung. So könnte ein Prüfschritt bei der Kreditantragsbearbeitung in die dann parallel vorgenommene Bonitätsprüfung des Kunden und Werthaltigkeitsprüfung des Finanzierungsobjekts zerlegt werden.

• Zusammenfassen von Aktivitäten. Zusammenfassen als Gegenteil von Aufspaltung bedeutet, dass ursprünglich getrennt und von verschiedenen Aufgabenträgern bearbeitete Aktivitäten nun durch einen Aufgabenträger ausgeführt werden. Diese Reintegration von Aufgaben führt Arbeitsteilung zurück und verringert dadurch beispielsweise Schnittstellen. Die Zahl der Aktivitäten in einem Geschäftsprozess und seiner Darstellung nimmt durch die Zusammenfassung ab und die Anordnungsbeziehungen zwischen den Aktivitäten des Geschäftsprozesses ändern sich. Im Kreditantragsprozess könnte die Zusammenfassung der beiden Prüfschritte wieder sinnvoll sein, wenn die weiter unten beschriebene Automatisierung der Kundenbonitätsprüfung den Zeitgewinn durch Parallelisierung relativiert.

• Änderung der Reihenfolge. Die Anordnungsbeziehungen zwischen den Aktivitäten, oder zwischen Gruppen oder Bündeln von Aktivitäten, können eventuell vertauscht werden, was zeitliche, kostenmäßige oder kapazitätsmäßige Vorteile haben kann. Beim Kreditantragsbeispiel sollte die Prüfung der Bonität der Bewertung des Finanzierungsobjekts vorgezogen werden, denn letztere ist hinfällig bzw. der ganze Prozess endet, wenn der Interessent nicht kreditwürdig ist. Eine Sequenz der Prüfungen steht im Gegensatz zu der Parallelisierungsoption. Um eine Entscheidung für eine der Varianten zu treffen, wäre die Information hilfreich, wie oft ein Antrag wegen mangelnder Bonität abgelehnt wird und damit im Falle der parallelen Objektprüfung Ressourcen verschwendet werden.

• Elimination von Aktivitäten . Verbale Diskussionen, Process Mining, Pfadanalyse und Simulationsexperimente geben Hinweise auf nicht benötigte Aktivitäten (tote Pfade), sehr selten ausgeführte Aktivitäten, auf Aktivitäten, bei denen kaum eine Wertschöpfung erzielt wird oder die unwirtschaftlich sind. Die Zahl der Aktivitäten eines Prozesses nimmt durch die Elimination ab und die Struktur der Anordnungsbeziehungen ändert sich. Beispiel für eine Elimination wenig wertschöpfender Aktivtäten könnte das in Abschn. 4.2.8.2 angesprochene Weglassen der zusätzlichen Genehmigung eines Kreditantrags über 200.000 € durch die Abteilungsleitung sein.

• Elimination oder Reduzierung von Zyklen. Wenn Geschäftstransaktionen Zyklen von Aktivitäten mehrfach durchlaufen, verlängert dies gewöhnlich die Durchlaufzeiten der Prozesse und führt oft zu Wartezeiten bei der Ausführung. Mit der Pfadanalyse können solche Zyklen identifiziert und lokalisiert und möglicherweise durch Änderung der Prozessgestaltung eliminiert werden. Bei der Kreditantragsbearbeitung kann es beispielsweise immer wieder zu Nachfragen der Sachbearbeiter beim Interessenten kommen, weil Informationen zur Beurteilung des Finanzierungsvorhabens fehlen. Sieht das elektronische Antragsformular Mussfelder und Anhänge für entsprechende Angaben vor, kann die Steuerung die Abgabe verhindern, so lange Information fehlt. Damit ist zwar nicht sichergestellt, dass der Antragsteller die richtige Information vollständig und valide übermittelt, aber die Wahrscheinlichkeit dafür steigt und Rückfrageschleifen dürften seltener nötig sein.

• Insourcing und Outsourcing. Unter Umständen ist es sinnvoll, in sich geschlossene Geschäftsprozesse oder einzelne Teile nicht in der eigenen Organisation, sondern von spezialisierten externen Dienstleistern ausführen zu lassen, welche dies z. B. aufgrund von Größenvorteilen (Economies of Scale) kostengünstiger und/oder schneller können. Damit lassen sich oft eigene Fixkosten durch variable Kosten für die Inanspruchnahme der Leistungen des Partners ersetzen. Beispielsweise könnte die Bank anstatt eigene Sachverständige für die Immobilienbewertung zu beschäftigen fallweise ein Architekturbüro damit beauftragen. Bei entsprechenden Voraussetzungen kann auch der umgekehrte Weg Vorteile bringen, etwa, wenn bisher ausgelagerte Aktivitäten z. B. wegen des Wegfalls von Schnittstellen und Transaktionskosten intern wirtschaftlicher organisierbar sind.

• Automatisieren. Der technische Fortschritt eröffnet Möglichkeiten, manuelle Arbeitsschritte von IT-Anwendungen und Maschinen (z. B. Roboter) zu unterstützen oder komplett automatisiert ausführen zu lassen. Dies ist insbesondere für zeitintensive, wenig motivierende und fehlerträchtige Tätigkeiten relevant. Zur Realisierung von Automatisierungsoptionen gilt es, die Entwicklung und den Markt für entsprechende Technologien dauerhaft zu beobachten, um passende Lösungsbausteine identifizieren und diese in Prozessanpassungen einbeziehen zu können. Als Beispiel kann der parametrisierbare Webservice der SCHUFA für die Auskunft über Kunden dienen, dessen Integration nicht nur Automatisierung fördert, sondern auch ein Beispiel für teilweises Outsourcing darstellt.

• Reduktion von Schnittstellen . Arbeitsteilige Prozessabwicklung weist naturgemäß Schnittstellen auf organisatorischer und technischer Ebene auf. Sie involviert verschiedene Organisationseinheiten und externe Partner, die oft mit uneinheitlichen IT-Systemen und Arbeitsmitteln mitunter an verschiedene Medien gebundene Zwischenergebnisse erzeugen und austauschen. Folgen sind Medienbrüche und damit verbundene Doppelarbeit, Übertragungsfehler, Zeitverluste, Kosten usw. Eine Verringerung der Schnittstellen wirkt diesen Nachteilen entgegen. Sie lässt sich durch organisatorische Veränderungen wie die Reintegration oder Eliminierung von Aktivitäten und die Änderung der Zuordnung von Aufgaben zu Aufgabenträgern erzielen. Auf der technischen Ebene helfen integrierte IT-Systeme wie Enterprise-Resource-Planning-Software und Workflow-Anwendungen. Beim Kreditantragsbeispiel hat die teilweise Verlagerung der Unterschriftenkompetenz auf die Sachbearbeitungsebene deren Aufgabenzuschnitt und denjenigen der Abteilungsleitung verändert. Als Konsequenz konnten ein Ablaufzweig eliminiert und die dazugehörigen Schnittstellen reduziert werden.

Zu beachten ist, dass viele der genannten Optimierungsansätze interdependent sind, und deshalb immer Auswirkungen einer Maßnahme auf andere Faktoren der Gestaltung zu berücksichtigen sind. So kann beispielsweise das Outsourcing von Prozessteilen die Anzahl der Schnittstellen erhöhen und Aufwand für das Dienstleistungsmanagement verursachen. Diese Effekte wirken den Vorteilen der Auslagerung entgegen, sodass stets eine Abwägung nötig ist.