![\"BPMN](\"https:\/\/promptify.cc\/wp-content\/uploads\/2026\/07\/img_6a54753b17967.png\")
<\/p>\n
Dieser Leitfaden beschreibt, was ich \u00fcber diesen entscheidenden Unterschied gelernt habe, warum er f\u00fcr eine saubere Prozessmodellierung von Bedeutung ist und wie die Trennung von \u201eDenken\u201c und \u201eRouting\u201c zu Diagrammen f\u00fchrt, die sowohl genauer sind als auch leichter f\u00fcr Stakeholder verst\u00e4ndlich sind.<\/p>\n
Der zentrale Erkenntnis: Gateways sind Router, keine Denker<\/h2>\n
Das Wichtigste, was man \u00fcber BPMN 2.0-Gateways verstehen muss, ist ihre funktionelle Rolle. Ein Gateway bewertet keine Bedingungen, wiegt keine Optionen ab und zieht keine Schl\u00fcsse. Es tut genau eine Sache:es leitet die Ablaufsteuerung entlang alternativer Pfade<\/strong>auf Basis von Informationen, die bereits festgelegt wurden.<\/p>\n Stellen Sie sich vor, es handelt sich um eine Ampel an einer Kreuzung. Die Ampel entscheidet nicht, ob Sie nach links abbiegen oder geradeaus fahren m\u00fcssen \u2014 Sie (der Fahrer) haben diese Entscheidung bereits getroffen, bevor Sie die Kreuzung erreicht haben. Die Ampel setzt lediglich die Route um, basierend auf Ihrer vorher festgelegten Richtung. In BPMN \u00fcbernimmt das Gateway dieselbe mechanische Rolle.<\/p>\n Diese Erkenntnis hat meine Herangehensweise an die Prozessmodellierung vollst\u00e4ndig ver\u00e4ndert. Statt zu fragen: \u201eWas sollte dieses Gateway entscheiden?\u201c, frage ich nun: \u201eWelche Aufgabe oder Aktivit\u00e4t hat das Ergebnis erzeugt, das dieses Gateway weiterleiten muss?\u201c<\/p>\n Sobald man akzeptiert, dass Gateways nur Router sind, stellt sich die n\u00e4chste Frage: Wo findet die eigentliche Entscheidungsfindung statt?<\/p>\n Die Antwort liegt fast immer in derAktivit\u00e4t oder Aufgabe, die unmittelbar vor dem Gateway steht<\/strong>. Hier findet die geistige Arbeit, die Bewertung oder die systemgesteuerte Logik statt. Das Gateway spiegelt lediglich das Ergebnis dieser Arbeit in der Ablaufstruktur des Diagramms wider.<\/p>\n Betrachten Sie einen Versandprozess, den ich f\u00fcr einen Logistikkunden modelliert habe. In der ersten Version des Diagramms stand ein Gateway mit der Beschriftung \u201eIst dies eine Sonderlieferung?\u201c \u2014 was den Eindruck erweckte, als w\u00fcrde das Gateway die Frage stellen.<\/p>\n Nach der Umstrukturierung sah das Diagramm folgenderma\u00dfen aus:<\/p>\n Ein Mitarbeiter f\u00fchrt eine Aufgabe aus, die ausdr\u00fccklich beschriftet ist\u201eEntscheiden, ob Normalversand oder Sonderlieferung\u201c<\/strong><\/p>\n<\/li>\n Das Ergebnis dieser Aufgabe (Normalversand gegen\u00fcber Sonderlieferung) wird anschlie\u00dfend an ein exklusives Gateway weitergeleitet<\/p>\n<\/li>\n Das Gateway leitet den Ablauf entlang eines der beiden Wege basierend auf diesem vorher bestimmten Ergebnis<\/p>\n<\/li>\n<\/ol>\n Der Unterschied ist subtil, aber von gro\u00dfer Bedeutung. Die Aufgabe ist der Ort der Bewertung \u2014 der Mitarbeiter pr\u00fcft die Paketma\u00dfe, den Wert, das Ziel und eventuelle besondere Handhabungsanforderungen. Das Gateway sagt lediglich: \u201eWenn das Ergebnis \u201aSonderlieferung\u2018 lautet, gehen Sie diesen Weg; andernfalls diesen.\u201c<\/p>\n Das Verst\u00e4ndnis des Unterschieds zwischen Aufgaben und Gateways erfordert Klarheit dar\u00fcber, was jedes Element darstellt:<\/p>\n Aufgaben stellen tats\u00e4chliche Arbeitspakete dar.<\/strong>Sie sind der Ort, an dem Dinge erledigt werden \u2014 wo jemand Informationen bewertet, eine Entscheidung trifft, eine Berechnung durchf\u00fchrt oder eine Aktion ausf\u00fchrt. Eine Aufgabe kann so einfach sein wie \u201eKundenadresse \u00fcberpr\u00fcfen\u201c oder so komplex wie \u201ePr\u00fcfung der Zulassung einer Nominierung anhand der Kriterien der Kommission.\u201c<\/p>\n Gateways stellen die Routing-Logik dar.<\/strong>Sie f\u00fchren keine Arbeit aus; sie steuern den Ablauf. Sie nehmen die Ausgabe einer vorhergehenden Aufgabe entgegen und leiten den Prozess-Token entlang der entsprechenden Verzweigung weiter. Der Gateway selbst verf\u00fcgt \u00fcber keine Intelligenz \u2013 er ist ein mechanisches Konstrukt.<\/p>\n Diese Trennung der Verantwortlichkeiten ist einer der Gr\u00fcnde, warum BPMN eine so leistungsstarke Modellierungssprache ist. Indem Arbeit und Routing getrennt bleiben, kommuniziert das Diagramm eindeutig sowohlwas<\/em>erledigt werden muss, als auchwie<\/em>der Prozess basierend auf den Ergebnissen verzweigt.<\/p>\n Sobald die Entscheidung in einer vorhergehenden Aufgabe getroffen wurde, setzt der Gateway diese Entscheidung durch spezifische Routingsmechanismen um. Am h\u00e4ufigsten verwendet wird derexklusive Gateway<\/strong>, der sicherstellt, dass nur eine der verf\u00fcgbaren Verzweigungen durchlaufen wird.<\/p>\n So funktioniert der Mechanismus in der Praxis:<\/p>\n Die vorhergehende Aufgabe erzeugt ein eindeutiges Ergebnis<\/p>\n<\/li>\n Der exklusive Gateway bewertet dieses Ergebnis anhand seiner bedingten Beschriftungen<\/p>\n<\/li>\n Genau ein ausgehender Sequenzfluss wird aktiviert<\/p>\n<\/li>\n Der Prozess-Token setzt entlang dieses einzigen Pfades fort<\/p>\n<\/li>\n<\/ul>\n Andere Gateway-Typen bearbeiten unterschiedliche Routingszenarien \u2013 parallele Gateways f\u00fcr gleichzeitige Pfade, inklusive Gateways f\u00fcr einen oder mehrere Zweige \u2013 aber das Prinzip bleibt gleich: Der Gateway leitet basierend auf Informationen, die an anderer Stelle festgelegt wurden, weiter.<\/p>\n Das Konzept des Gateways als Router wird noch wichtiger, wenn es um komplexe Prozesse geht, die mehrere Beteiligte und anspruchsvolle Entscheidungskriterien beinhalten.<\/p>\n Beim Modellieren eines Nominierungsworkflows f\u00fcr den Nobelpreis begegnete ich einem Szenario, bei dem der Issue List Manager Nominierungen \u00fcberpr\u00fcfen und feststellen musste, ob sie bestimmten Bereitschaftskriterien entsprachen, bevor der Prozess weitergehen konnte. Der entscheidende Einblick war, dass die Arbeit \u201e\u00fcberpr\u00fcfen und entscheiden\u201c in einer speziellen Aufgabe erfolgte, die dem Issue List Manager zugewiesen war. Der nachfolgende Gateway leitete lediglich den Prozess weiter \u2013 entweder zum n\u00e4chsten Schritt, wenn die Nominierung bereit war, oder beendete den Prozess, wenn sie es nicht war.<\/p>\n Der Gateway bewertete nicht die Qualit\u00e4t der Nominierung. Das tat der Issue List Manager. Der Gateway spiegelte lediglich diese Entscheidung im Prozessablauf wider.<\/p>\n Ebenso f\u00fchrt in E-Mail-basierten Abstimmungsworkflows die Person, die f\u00fcr die Sammlung und Ausz\u00e4hlung der Stimmen zust\u00e4ndig ist, die eigentliche Entscheidung dar\u00fcber durch, ob eine Quorum erreicht wurde oder ob ein Antrag angenommen wurde. Ein nachfolgender Gateway leitet dann entsprechend weiter. Die Trennung ist klar: Der Mensch denkt, der Gateway leitet.<\/p>\n Sie fragen sich vielleicht, ob diese Genauigkeit in der Praxis wirklich von Bedeutung ist. Schlie\u00dflich funktioniert das Diagramm in beiden F\u00e4llen \u2013 der Prozess flie\u00dft korrekt, egal ob Sie die Entscheidung dem Gateway oder der vorhergehenden Aufgabe zuschreiben.<\/p>\n Aber nach meiner Erfahrung gibt es mehrere konkrete Vorteile, wenn man dies richtig macht:<\/p>\n 1. Klare Verantwortlichkeit.<\/strong>Wenn die Entscheidung explizit in einer Aufgabe erfasst wird, ist offensichtlich, wer oder was f\u00fcr die Entscheidung verantwortlich ist. Sie k\u00f6nnen die Aufgabe einer bestimmten Rolle zuweisen, absch\u00e4tzen, wie lange sie dauern wird, und verfolgen, ob sie korrekt abgeschlossen wurde.<\/p>\n 2. Bessere Kommunikation mit Stakeholdern.<\/strong>Nicht-technische Stakeholder verstehen Aufgaben \u2013 sie stellen Arbeit dar, die Menschen erledigen. Wenn Sie ihnen eine Aufgabe mit der Bezeichnung \u201eBewertung und Genehmigung des Budgetantrags\u201c zeigen, verstehen sie sofort, was in diesem Schritt geschieht. Ein Gateway mit der Bezeichnung \u201eGenehmigt?\u201c ist unsch\u00e4rfer und ruft Fragen dar\u00fcber hervor, wer genau die Genehmigung erteilt.<\/p>\n 3. Einfachere Prozessverbesserung.<\/strong>Wenn Sie einen Prozess optimieren m\u00fcssen, m\u00fcssen Sie wissen, wo Entscheidungen getroffen werden. Wenn Entscheidungen innerhalb von Gateways versteckt sind, ist es schwieriger, Engp\u00e4sse, \u00fcberfl\u00fcssige Bewertungen oder M\u00f6glichkeiten zur Delegation oder Automatisierung zu erkennen.<\/p>\n 4. Genauere Automatisierung.<\/strong>Beim Implementieren eines BPMN-Diagramms in einer Workflowsystem-Engine ist dieser Unterschied technisch von Bedeutung. Aufgaben werden den Arbeitsauftr\u00e4gen zugeordnet; Gateways werden den Routing-Regeln zugeordnet. Die Verwechslung beider f\u00fchrt zu Implementierungsverwirrung.<\/p>\n Durch meine eigenen Versuche und Fehler sowie durch die Analyse von Diagrammen, die von anderen erstellt wurden, habe ich einige wiederkehrende Fehler im Zusammenhang mit diesem Unterschied zwischen Gateway und Entscheidung identifiziert:<\/p>\n Beschriftung von Gateways als Fragen.<\/strong>Ein Gateway mit der Bezeichnung \u201eIst die Zahlung g\u00fcltig?\u201c impliziert, dass das Gateway die Validierung durchf\u00fchrt. Stattdessen sollten Sie eine Aufgabe mit dem Namen \u201eZahlung validieren\u201c erstellen und das Gateway auf Basis des Ergebnisses weiterleiten lassen.<\/p>\n \u00dcberspringen der Entscheidungsaufgabe.<\/strong>Manchmal springen Modelle direkt von einer Informationsbeschaffungsaufgabe zu einem Gateway und nehmen implizit an, dass das Gateway selbst entscheiden wird, was zu tun ist. Doch wenn keine Aufgabe explizit die Bewertung durchf\u00fchrt, ist das Diagramm unvollst\u00e4ndig \u2013 es ist unklar, wer oder was die Entscheidung trifft.<\/p>\n \u00dcberlasten von Gateways mit Logik.<\/strong>Ein einzelnes Gateway mit komplexen bedingten Ausdr\u00fccken auf mehreren ausgehenden Fl\u00fcssen deutet oft darauf hin, dass die Entscheidungslogik in eine ordentliche Aufgabe mit klarem Ausgang aufgeteilt werden sollte, gefolgt von einfacherem Routing.<\/p>\n Der Unterschied zwischen Gateways und Entscheidungen in BPMN 2.0 ist eines jener grundlegenden Konzepte, das auf den ersten Blick geringf\u00fcgig erscheint, aber einen \u00fcberproportionalen Einfluss auf die Qualit\u00e4t Ihrer Prozessmodelle hat. Sobald ich verinnerlicht hatte, dass Gateways Router \u2013 nicht Entscheidungstr\u00e4ger \u2013 sind, wurden meine Diagramme \u00fcbersichtlicher, kommunikativer und einfacher umzusetzen.<\/p>\n Der zentrale Gedanke ist einfach, aber m\u00e4chtig:Die Entscheidung erfolgt in der Aufgabe, und das Gateway leitet lediglich basierend auf dem Ergebnis weiter.<\/strong>Durch die Aufrechterhaltung dieser Trennung erstellen Sie Diagramme, die genau widerspiegeln, wie die Arbeit tats\u00e4chlich erledigt wird, wer f\u00fcr was verantwortlich ist und wie der Prozess auf Basis realer Bewertungen verzweigt.<\/p>\n Unabh\u00e4ngig davon, ob Sie einen einfachen Versandprozess oder einen komplexen mehrstufigen Prozess wie die Nominierung f\u00fcr den Nobelpreis modellieren \u2013 die Anwendung dieses Prinzips hilft Ihnen dabei, BPMN-Diagramme zu erstellen, die sowohl technisch korrekt sind als auch tats\u00e4chlich n\u00fctzlich f\u00fcr die Personen, die den Prozess verstehen und umsetzen m\u00fcssen.<\/p>\n Einf\u00fchrung Als ich erstmals mit der Business Process Model and Notation (BPMN) 2.0 arbeitete, machte ich einen Fehler, der sich als \u00e4u\u00dferst verbreitet erwies: Ich behandelte Gateways als w\u00e4ren sie die Entscheidungstr\u00e4ger in einem Prozess. Schlie\u00dflich wirken diese diamantf\u00f6rmigen Symbole so, als w\u00fcrden sie fragen: \u201eWelchen Weg sollten wir nehmen?\u201c \u2014 daher ist es naheliegend,…<\/p>\n","protected":false},"author":9,"featured_media":25590,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"","_yoast_wpseo_metadesc":"","_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"fifu_image_url":"https:\/\/promptify.cc\/wp-content\/uploads\/2026\/07\/img_6a5474d21d11c.png","fifu_image_alt":"","footnotes":""},"categories":[308],"tags":[],"class_list":["post-25589","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bpmn"],"yoast_head":"\nWo die Entscheidung tats\u00e4chlich stattfindet<\/h2>\n
Ein praktisches Beispiel: Der Versandprozess<\/h3>\n
![\"BPMN:](\"https:\/\/promptify.cc\/wp-content\/uploads\/2026\/07\/img_6a5474d21d11c.png\")
<\/p>\n\n
Funktionelle Rollen: Aufgaben im Vergleich zu Gateways<\/h2>\n
Routingsmechanismen: Wie Gateways funktionieren<\/h2>\n
\n
Komplexe Bewertungen: Realit\u00e4tsnahe Szenarien<\/h2>\n
Der Nominierungsprozess f\u00fcr den Nobelpreis<\/h3>\n
E-Mail-Abstimmungsprozesse<\/h3>\n
Warum diese Unterscheidung wichtig ist<\/h2>\n
H\u00e4ufige Fehler, die vermieden werden sollten<\/h2>\n
Fazit<\/h2>\n
Quellen<\/h3>\n
\n