Gateways - Prozessablauf steuern

In der Regel werden in einem Geschäftsprozess nicht immer alle Aufgaben ausgeführt. In den meisten Geschäftsszenarios sind Entscheidungen Teil des Prozesses, um das weitere Vorgehen in bestimmten Fällen zu steuern. Diese Szenarien wirken sich offensichtlich auf das Design und die Struktur Ihres Prozessmodells aus. Erstens bedeutet dies, dass wir innerhalb des Prozessmodells den Sequenzfluss in verschiedene Pfade aufteilen müssen.

In der vorherigen Lektion haben wir gelernt, wie Sie Ereignisse und Aufgaben verwenden, um unser erstes eigenes Prozessmodell zu erstellen. Wir haben ein Startereignis, das ein Bedürfnis, Hunger darstellte, mit mehreren Aktivitäten, dem Kauf, der Vorbereitung und dem Essen einer Mahlzeit verbunden, um das befriedigende Gefühl zu erreichen, nicht mehr hungrig zu sein.

Wäre es jedoch nicht noch befriedigender, eine Mahlzeit unserer Wahl zuzubereiten und zu essen?

Angenommen, wir haben verschiedene Lebensmittel zu Hause, um etwas Leckeres zu kochen. Getrieben vom Hunger, müssen wir jetzt darüber entscheiden, was wir essen wollen.

Das exklusive Gateway liest das Ergebnis unserer Entscheidung (Mahlzeit auswählen) aus, um uns zur nächsten Aufgabe zu führen. Der Prozessablauf wird in mehrere Prozessabläufe aufgeteilt, aber es kann jeweils nur ein Pfad ausgewählt werden.

Mit anderen Worten: Es handelt sich um eine Entweder-oder-Entscheidung.

Sie haben vielleicht bemerkt, dass in unserem vorherigen Beispiel ein wichtiger Faktor fehlte - wir haben nie gegessen, da der Prozess nach der Zubereitung unserer Mahlzeit beendet ist. Unser anfängliches Ziel (kein Hunger mehr) wurde nicht erfüllt. Genauer gesagt: Der Prozess ist nicht vollständig modelliert.

Fügen wir also die Aufgaben hinzu, um sicherzustellen, dass wir am Ende des Prozesses keinen Hunger mehr haben.

Unsere bisherige Lösung stellt zumindest sicher, dass wir unser Ziel erreichen, erhöhen aber die Komplexität unseres Prozesses wie folgt:

• Die Aufgabe „Essen" hängt nicht von den Mahlzeiten ab, sondern wendet sie auf alle verschiedenen Mahlzeiten an.
• Wir haben dasselbe Prozessziel (Endereignis) mehrmals für jede Verzweigung angelegt.

Um die oben genannten Probleme zu vermeiden, müssen wir eine Möglichkeit finden, alle aufgeteilten Branches mit dem ursprünglichen Prozessablauf zusammenzuführen. Glücklicherweise können wir das exklusive Gateway wieder verwenden, wie in der Abbildung oben unter Verwendung des exklusiven Gateways zum Merging (XOR-Join) gezeigt.

Wenn Sie mit ihm splitten, führen Sie es zusammen.

Exklusive Gateways:

• haben ein Aufteilungsverhalten, um basierend auf einer bestimmten Bedingung zur nächsten erforderlichen Aufgabe weiterzuleiten.
• haben ein Zusammenführungsverhalten, um verschiedene Branches im Prozess mit dem Hauptablauf zu verknüpfen.
• muss paarweise verwendet werden. Das heißt, wenn ein Prozessablauf mit einem XOR-Gateway in mehrere Branches aufgeteilt wurde, muss das Join-Gateway auch ein XOR-Gateway sein.
• Ausnahmen haben. Wenn die Sequenzflüsse zu verschiedenen Endereignissen gehen, muss ein Splitting-Gateway nicht zusammengeführt werden. Das bedeutet, dass die einzelnen Pfade in verschiedene Pfade verschoben werden und nicht mehr zusammengeführt werden müssen.

Exklusive Gateways sind keine Entscheidungen. Warum? Denn sie sind keine Aufgaben, sondern ein Steuerungselement zur Weiterleitung der nächsten Aufgabe, basierend auf dem Ergebnis einer zuvor getroffenen Entscheidung.

Das exklusive Gateway selbst ist keine Entscheidung.

Mahlzeit auswählen ist eine Aufgabe, die abgeschlossen werden muss, bevor einer der ausgehenden Pfade im XOR-Gateway ausgewählt werden kann.

Obwohl es in diesem Prozessbeispiel scheinbar eine Entscheidung gibt, gibt es in der Tat keine. Ein Gateway allein ist zustandslos, da es nur ein Instrument ist, um den nächsten Schritt auf der Grundlage von Informationen zu steuern. Im Gegensatz zu Aufgaben kann eine Person kein Gateway "besitzen" (verantwortlich sein).

Bezüglich des obigen Prozessbeispiels bedeutet dies Folgendes:

• Die eigentliche Entscheidung (Mahlzeit auswählen) fehlt und wird daher nie getroffen.
• Die Informationen einer ausgewählten Mahlzeit sind von Anfang an "einfach verfügbar", werden aber nicht im Rahmen des Prozesses ermittelt.
• Obwohl sich das XOR-Gateway in Tims Fahrspur befindet, ist er nicht für das „Routing" verantwortlich, da ein Gateway nur ein zustandsloses Instrument ist. Außerdem spielt es keine Rolle, in welcher Lane ein Gateway platziert ist. Es ist nur wichtig, wem die nächste Aufgabe zugeordnet ist.

Sehen wir uns an, wie der Prozess angewendet wird, wenn exklusive Gateways aufgeteilt und zusammengeführt werden.

Wie wir bei Aufgaben und Ereignissen gesehen haben, folgen Elemente in BPMN einer bestimmten Namenskonvention, um sie schnell und intuitiv zu verstehen.

XOR-Gateways und insbesondere Gateways, die Ergebnisse/Bedingungen in einem Prozess behandeln, haben ebenfalls Namenskonventionen. Diese sind:

1. Exklusive Gateways müssen mit einer Frage gekennzeichnet werden.
2. Die ausgehenden Bedingungen (Sequenzflüsse) müssen mit der Antwort auf die Frage gekennzeichnet werden.
3. Alle ausgehenden Bedingungen müssen sich gegenseitig ausschließen. Zum Beispiel ja/nein.
4. Zusammengeführte Gateways werden nie gekennzeichnet.

Aufgaben können parallel ausgeführt werden, was die Effizienz des gesamten Geschäftsprozesses erhöht.

Heute umfassen die meisten Geschäftsprozesse mehrere Aufgaben, die unabhängig voneinander von verschiedenen Abteilungen/Personen ausgeführt werden. Der Prozess kann erst nach einem bestimmten Punkt fortgesetzt werden, nachdem bestimmte Aufgaben ausgeführt wurden. Um ein solches Verhalten in Prozessen zu modellieren, können wir das parallele Gateway (auch UND-Gateway genannt) verwenden.

Im vorherigen Beispiel hatten wir nicht die Wahl, mehrere Gerichte gleichzeitig auszuwählen und zu essen. Was machen wir eigentlich, wenn wir einen Salat als Beilage wollen?

Um sicherzustellen, dass wir einen Salat UND ein Steak essen können, fügen wir unserem Prozess ein paralleles Tor hinzu.

Bei der Verwendung des UND-Gateways gibt es einige Überlegungen:

1. AND-Split: Wir müssen immer beides zubereiten und essen - es gibt keine Wahl mehr.
2. AND-Join: Wir können erst anfangen zu essen, nachdem beide vorbereitet wurden.

Das bereitgestellte Prozessbeispiel zeigt die Annotation des BPMN-Elements (Text) für die Aufgabe, mit der wir die Ausführungszeit dokumentiert haben. Textannotationen können jederzeit für jedes BPMN-Element verwendet werden, um hilfreiche Hinweise/Informationen bereitzustellen. Sie müssen jedoch eher selten verwendet werden, um das Prozessmodell nicht zu überlasten.

Die Anzahl der Ressourcen, die einen Prozess ausführen, wird immer dann entscheidend, wenn Aufgaben tatsächlich parallel ausgeführt werden müssen. Eine Person kann nicht mehrere Aufgaben gleichzeitig ausführen, auch wenn sie als solche modelliert wurde. Der Punkt besteht darin, dass bei der Zuordnung paralleler Aufgaben zu nur einer Zuständigkeit die Reihenfolge der Ausführung nicht wichtig ist. Verwenden wir eine visuellere Erläuterung:

Tim handelt allein:

• Die Zykluszeit kann nicht verkürzt werden, da Tim alles allein in einer sequentiellen Reihenfolge tun muss.
• Auch wenn Aufgaben parallel zugeordnet werden, kann Tim nicht gleichzeitig beides tun - aber er kann zumindest entscheiden, mit welcher Aufgabe er beginnen soll.

Tim wird unterstützt von Robert:

• Während Tim dafür sorgt, dass das Steak nicht verbrannt wird, bereitet Robert zwischenzeitlich den Salat vor.
• Beide Aufgaben müssen abgeschlossen sein, bevor beide gemeinsam mit dem Essen beginnen können.

Manchmal erfordern Geschäftsaufgaben Flexibilität, da es nicht ausreicht, nur eine Option zur Auswahl zu haben.

Stellen Sie sich vor, Sie arbeiten bei einem Telekommunikationsanbieter, bei dem der Kunde verschiedene Produkte gegen Aufpreis zum Hauptvertrag für Internet und Telefon hinzufügen kann. Diese können sein:

• ein Internetsicherheitspaket.
• einen zusätzlichen Router für eine bessere WLAN-Verbindung.
• einen zusätzlichen mobilen Hotspot, um von überall eine Verbindung herzustellen.

Der Geschäftsprozess sollte so konzipiert sein, dass alle diese Optionen ausgewählt werden können und die zugehörigen Geschäftsaufgaben basierend auf den ausgewählten Optionen ausgeführt werden. Sie können nicht obligatorisch sein, da nicht jeder Kunde alle drei Optionen jedes Mal zum Vertrag hinzufügen möchte. Sie können auch nicht exklusiv sein, da verschiedene Produkte immer kombiniert werden können.

Das Inklusive Gateway (auch OR Gateway genannt) ermöglicht die Modellierung der zuvor beschriebenen Situationen. Oder genauer gesagt, um Geschäftsszenarios zu modellieren, in denen verschiedene Optionen kombiniert werden können, und gleichzeitig sicherzustellen, dass mindestens eine Option ausgewählt wurde.

Dieses Gateway ist das flexibelste, da es sich als eine Mischung aus exklusivem und parallelem Gateway verhält.

Auf der Aufteilungsseite kann sie entweder nur einen ausgehenden Sequenzfluss (z.B. ein XOR) oder mehrere gleichzeitig (wie ein UND) auslösen. Es kann auch nur wenige von allen möglichen Bedingungen kombinieren - oder sogar alle. Dieser Aspekt der Flexibilität ist möglicherweise nur schwer zu verstehen, wenn man sich das ODER-Gateway in einem Prozessmodell ansieht. In bestimmten Szenarien kann es jedoch hilfreich sein, einen Satz verschachtelter XOR- und AND-Gateways zu ersetzen.

Auf der Seite der Zusammenführung kann das OR-Gateway entweder verschiedene Token synchronisieren (z.B. AND) oder nur einen Token weiterleiten, wenn es keine anderen gibt (wie ein XOR). Die Spezialität ist, dass sie nicht auf Token in ALLEN eingehenden Sequenzflüssen wartet (wie das AND tut), sondern nur auf die Token, die tatsächlich unterwegs sind.

Während wir für einige Prozesse im Voraus alle verantwortlichen Rollen und Personas kennen, können die Verantwortlichen für andere Prozesse je nach Situation variieren.

Betrachtet man den folgenden Prozess, können wir sagen:

• Alle Mitglieder wählen eine Mahlzeit zusammen (obwohl Tim dafür sorgt, dass sie alle als Haupttreiber dieser Aufgabe zusammenkommen).
• Beispiel Fall A: Sie sind sich alle einig, Nudeln und Salat zu haben. Das müssen Tim und Robert vorbereiten.
• Beispiel Fall B: Sie sind sich alle einig, Steak und Salat zu haben. Das müssen Sarah und Robert vorbereiten.
• Beispielfall C: Sie sind sich alle einig, nur Nudeln zu haben. Als Pasta-Experte kümmert sich Tim darum, ein köstliches Nudelgericht für die Gruppe zu kochen.
• Am Ende sorgt Tim dafür, dass sie alle zusammen essen.

Das folgende Video zeigt, wie die Token basierend auf einem bestimmten Fall (Steak und Salat) angelegt werden.

Jetzt ist es an der Zeit, sich gängige Fehler in der Praxis genauer anzusehen, die auftreten können, wenn die falsche Kombination von Gateways verwendet wurde.

Falsche Gateway-Kombinationen können zu unbeabsichtigten Prozessabläufen führen.

Wie kann es zu unbeabsichtigten Prozessabläufen kommen, wenn wir bereits gelernt haben, sie über Gateways zu steuern? Normalerweise geschieht dies nicht, wenn Sie die Regeln für das Aufteilen von Pfaden, das korrekte Zusammenführen von Flüssen und die Verwendung von Gateways immer paarweise berücksichtigen und der Namenskonvention folgen. Wir sind aber Menschen und lernen, indem wir Fehler machen, liegt in unserer Natur - vor allem dann, wenn komplexe Geschäftsprozesse modelliert werden müssen. Glücklicherweise zeigen wir Ihnen die gängigen Fallstricke und wie Sie diese vermeiden können.

Das Token-Konzept hilft uns bei der Analyse eines falschen Prozessverhaltens und bei der Korrektur von Prozessabläufen, sodass die Token nicht im Prozess hängen bleiben.

Deadlocks können auftreten, wenn ein paralleles Merging-Gateway darauf wartet, dass mehrere Token synchronisiert werden, aber mindestens ein Token nicht vorhanden ist. Klingt komisch? Sehen Sie sich das obige Prozessbeispiel an, um herauszufinden, wie dies (versehentlich) geschehen kann.

Erklärung:

• Das parallele Splitting-Gateway legt zwei Token an (grüner Fluss).
• Token 1 durchläuft "Prepare Shipment" und kommt am parallelen Merging-Gateway an (um synchronisiert zu werden). Token 2 durchläuft "Kundenstatus prüfen", "Premium-Mitgliedschaft anbieten" und kommt am parallelen Merging-Gateway an (um synchronisiert zu werden)

Problem: Das Gateway für die parallele Zusammenführung erwartet ein drittes Token (roter Fluss), da es immer auf ein Token bei jedem eingehenden Sequenzfluss wartet. Leider ist dieses Token nicht vorhanden, sodass der Prozess an dieser Stelle hängen bleibt (Deadlock).

Um das Problem zu beheben, müssen wir das fehlende exklusive Gateway hinzufügen, um die beiden Sequenzflüsse zu einem zusammenzuführen.

Mehrfachzusammenführungen sind nicht unbedingt ein Fehler in Bezug auf BPMN, aber sie erzeugen in der Regel ein unbeabsichtigtes Prozessverhalten. Sie können auftreten, wenn mehrere Tokens nicht synchronisiert werden (zu einem), d.h. wenn ein paralleles Merging-Gateway fehlt.

Erklärung:

• Das Parallel Splitting Gateway erzeugt zwei Token (Green Flow).
• Token 1 durchläuft "Shipment vorbereiten" und kommt am exklusiven Merging-Gateway an - und wird an "Send Order" weitergeleitet. Token 2 durchläuft "Kundenstatus prüfen", "Premium-Mitgliedschaft anbieten" und kommt am exklusiven Merging-Gateway an - und wird an "Bestellung senden" weitergeleitet.

Problem: Ohne Synchronisation der durch den parallelen Split erzeugten Tokens wird die Aufgabe "Auftrag senden" zweimal ausgeführt und sie erreichen auch zweimal das Endereignis.

Um das Problem zu beheben, müssen wir das fehlende parallele Gateway hinzufügen, um die beiden Token im Prozess zu einem zu synchronisieren. Um den Auftrag endgültig zu senden, wird das synchronisierte Token weitergeleitet.

Dies ist eine aktive Übung zur Prozessmodellierung, die in SAP Signavio Process Manager durchgeführt werden muss. Wenn Sie bereits eine Lizenz haben, können Sie sofort starten. Wenn nicht, können Sie sich auch für eine 30-tägige Testversion kostenlos registrieren und in drei Minuten starten.

Beachten Sie, dass alle drei Modellierungsübungen im Kurs optional sind. Die Übungen bieten Ihnen jedoch die Möglichkeit, Ihr Wissen anzuwenden und sich mit dem grafischen Editor von SAP Signavio Process Manager vertraut zu machen.

Sehen Sie sich den eLearning-Kurs SIG120 Einführung in SAP Signavio Process Manager an, falls noch nicht geschehen, um über alle erforderlichen Fähigkeiten zum Abschließen der Übungen mit dem grafischen Editor zu verfügen.

Sie können sich für eine 30-tägige Testversion registrieren und sich mit SAP Signavio Process Manager vertraut machen. Keine Kreditkarte/Zahlung erforderlich. Link: Registrieren

MyStore Inc. ist ein mittelständisches Versandunternehmen. Aufgrund der wachsenden Anzahl von Aufträgen hat die Geschäftsleitung entschieden, den Geschäftsprozess von Bestand bis Lieferung zu dokumentieren. Sie erwarten unter anderem eine Verbesserung des Onboardings neuer Mitarbeiter durch transparentes Wissen über interne Prozesse.

Wenn MyStore Inc. eine Bestellung erhält, gibt ein Mitarbeiter des Auftragsannahmeteams zunächst die Auftragsdaten ein. Anschließend erhält der Kunde eine Auftragsbestätigung. Ein Mitarbeiter aus dem Lagerteam prüft dann die Lieferpriorität für den Auftrag.

Wenn der Kunde einen Premiumstatus hat, wird die Ware für den Eiltransport vorbereitet, andernfalls für den regulären Standardversand.

Während alle Vorbereitungen für den Versand getroffen werden, wird die Rechnung vom Auftragsannahmeteam erstellt. Schließlich wird die Rechnung vom Auftragsannahmeteam an den Kunden gesendet, und der Auftrag wird vom Lagerteam versendet.

• Wandeln Sie die Beschreibung "Auftragsabwicklung" in ein konformes BPMN-2.0-Modell um.
• Verwenden Sie nur die Elemente, die Sie bereits gelernt haben, und modellieren Sie die Perspektive der MyStore Inc. Sie müssen noch keine externen Prozessteilnehmer einschließen.
• Geschätzter Zeitaufwand: ca. 45 Minuten.

Modellierungstipp 1: Mindestens ein XOR- und ein UND-Gateway sind erforderlich, um den Prozess zu modellieren.

Modellierungstipp 2: Betrachten Sie dieses leere Formmodell als Designausrichtung.

Wenn Sie der Meinung sind, dass Sie fertig sind, prüfen Sie Ihre Lösung erneut auf Syntax-, Semantik- und Namenskonventionsprobleme. Denken Sie außerdem an ein benutzerfreundliches oder lesbares Erscheinungsbild für Ihr Diagramm.

Wenn Sie fertig sind, zeigen Sie die Musterlösung an, und vergleichen Sie sie mit Ihrer eigenen.