Ein digitaler Bestellprozess wirkt auf dem Papier oft simpel, bis Zahlung, Lager, Versand und Kundenservice zusammenspielen. Ein gutes BPMN-Beispiel macht sichtbar, wer welche Aufgabe übernimmt, wo Entscheidungen fallen und wie sich der Ablauf später in einer Webanwendung automatisieren lässt. Ich zeige einen vollständigen Online-Bestellprozess, erkläre die wichtigsten Symbole und ordne ein, wie BPMN mit modernen Frameworks und Workflow-Engines zusammenspielt.
Das wichtigste zum BPMN-Beispiel auf einen Blick
- BPMN übersetzt Geschäftsabläufe in eine einheitliche grafische Sprache.
- Der Beispielprozess zeigt eine Online-Bestellung von der Zahlung bis zum Versand.
- Gateways bilden Entscheidungen wie „Zahlung erfolgreich?“ ab.
- Sequenzflüsse verbinden Aufgaben innerhalb eines Prozesses, Nachrichtenflüsse verbinden beteiligte Teilnehmer.
- Für die Webentwicklung eignen sich Modellierer wie bpmn-js und Workflow-Plattformen wie Camunda.
[search_image] BPMN 2.0 Online-Bestellung Pool Lanes Gateway Beispiel
Was ein BPMN-Beispiel wirklich zeigen sollte
Business Process Model and Notation, kurz BPMN, beschreibt Abläufe mit standardisierten Ereignissen, Aufgaben, Verzweigungen und Verbindungen. Die Notation wird von der Object Management Group gepflegt und ist so angelegt, dass Fachabteilungen, Entwicklung und Prozessverantwortliche dasselbe Diagramm lesen können.
Für mich liegt der größte Nutzen nicht darin, möglichst viele Symbole unterzubringen. Ein brauchbares Modell beantwortet vor allem drei Fragen: Was passiert? Wer ist dafür verantwortlich? Und was geschieht, wenn der Normalfall nicht eintritt?
Ein BPMN-Diagramm besteht typischerweise aus einem Pool für einen Teilnehmer oder eine Organisation und mehreren Lanes für Rollen oder Abteilungen. Aufgaben werden als abgerundete Rechtecke dargestellt, Ereignisse als Kreise und Gateways als Rauten. Diese Grundausstattung reicht für viele verständliche Prozessmodelle bereits aus.
| BPMN-Element | Bedeutung | Beispiel im Online-Shop |
|---|---|---|
| Startereignis | Der Prozess beginnt | Bestellung wird abgeschickt |
| Task | Eine konkrete Aktivität | Zahlung autorisieren |
| Exklusives Gateway | Genau ein möglicher Pfad wird gewählt | Zahlung erfolgreich oder abgelehnt |
| Service Task | Eine Aufgabe wird automatisch durch ein System ausgeführt | Versandlabel erzeugen |
| Endereignis | Der Prozess oder ein Pfad endet | Bestellung versendet |
Ein häufiger Fehler besteht darin, BPMN wie ein technisches Ablaufdiagramm für jede einzelne Codezeile zu verwenden. Das macht das Modell unleserlich. Ich trenne deshalb zuerst den fachlichen Prozess von technischen Details und ergänze Implementierungsinformationen erst dort, wo sie für die Ausführung wirklich gebraucht werden.
Ein konkretes BPMN-Beispiel für eine Online-Bestellung
Betrachten wir einen Webshop, in dem ein Kunde ein Produkt bestellt. Beteiligt sind der Kunde, der Shop, der Zahlungsdienstleister und das Lager. Der Ablauf beginnt mit dem Absenden der Bestellung und endet entweder mit dem Versand oder mit einer Benachrichtigung über ein Problem.
Der normale Prozessablauf
- Bestellung empfangen: Der Shop nimmt die Bestellung aus dem Frontend entgegen.
- Bestelldaten prüfen: Adresse, Produktverfügbarkeit und Pflichtangaben werden kontrolliert.
- Zahlung autorisieren: Der Shop sendet eine Anfrage an den Zahlungsdienstleister.
- Zahlung bewerten: Ein exklusives Gateway entscheidet, ob die Zahlung erfolgreich war.
- Bestellung an das Lager übergeben: Bei erfolgreicher Zahlung wird ein Fulfillment-Auftrag erstellt.
- Ware kommissionieren: Das Lager stellt die bestellten Produkte zusammen.
- Versandlabel erzeugen: Das System übermittelt die Versanddaten an den Paketdienst.
- Versandbestätigung senden: Der Kunde erhält eine E-Mail oder eine Nachricht im Kundenkonto.
In vereinfachter Form sieht der logische Ablauf so aus:
Bestellung empfangen → Daten prüfen → Zahlung autorisieren → Zahlung erfolgreich? → Lagerauftrag erstellen → Ware versenden → Ende
Das Gateway ist hier entscheidend. Bei „Ja“ läuft der Prozess weiter. Bei „Nein“ wird eine alternative Aufgabe wie Zahlungsproblem melden ausgeführt. Der Prozess endet dann beispielsweise mit dem Status „Zahlung abgelehnt“, ohne dass ein Auftrag an das Lager gesendet wird.
Die Rollen in Pools und Lanes
Für eine verständliche Darstellung kann der Shop als Pool mit den Lanes „Shop-System“, „Zahlungsdienstleister“ und „Lager“ modelliert werden. Der Kunde kann als eigener Pool außerhalb des Shops erscheinen, weil er nicht Teil der internen Prozessausführung ist.
Innerhalb eines Pools wird der Ablauf mit einem Sequenzfluss verbunden. Zwischen zwei unabhängigen Pools verwendet man dagegen einen Nachrichtenfluss. Die Bestellung vom Kunden an den Shop und die Zahlungsanfrage vom Shop an den Zahlungsdienstleister sind deshalb Nachrichten, keine normalen internen Prozessschritte.
Diese Unterscheidung wirkt klein, verhindert aber später viele Missverständnisse. Besonders in verteilten Websystemen ist wichtig, ob eine Aktion unmittelbar intern weiterläuft oder ob eine externe Antwort abgewartet werden muss.
So wird aus dem Diagramm ein ausführbarer Webprozess
Ein BPMN-Modell kann lediglich dokumentieren oder tatsächlich als Grundlage für eine Workflow-Ausführung dienen. Im ersten Fall hilft es bei Analyse und Abstimmung. Im zweiten Fall werden Aufgaben, Zustände und Übergänge von einer Workflow-Engine verarbeitet.
Fachliche Aufgabe und technische Aufgabe trennen
„Zahlung prüfen“ ist zunächst eine fachliche Aufgabe. Für die Webentwicklung wird daraus beispielsweise ein Service Task, der einen API-Aufruf an Stripe, Adyen oder einen anderen Zahlungsdienstleister auslöst. Die konkrete Integration gehört in den Anwendungscode oder einen Worker, nicht in ein überladenes Diagramm.
Eine sinnvolle Zuordnung könnte so aussehen:
| Prozessschritt | Technische Umsetzung | Wichtige Rückmeldung |
|---|---|---|
| Bestellung empfangen | REST-Endpunkt oder Event aus dem Shop | Bestell-ID und Kundendaten |
| Zahlung autorisieren | Service Task mit Zahlungs-API | Autorisierungsstatus |
| Zahlung bewerten | Exklusives Gateway | Erfolgreich, abgelehnt oder unklar |
| Ware kommissionieren | Benutzeraufgabe im Lagerportal | Kommissioniert oder nicht verfügbar |
| Versandlabel erzeugen | Adapter zum Versanddienstleister | Trackingnummer |
Ich empfehle, jede automatische Aufgabe mit einer klaren technischen Verantwortung zu versehen. Ein Entwickler sollte erkennen können, ob ein Schritt durch einen REST-Service, eine Queue, einen Zeitgeber oder einen Menschen ausgelöst wird. Ohne diese Information bleibt das Modell zwar hübsch, hilft aber kaum beim Bauen.
Fehler und Wartezeiten sichtbar machen
Ein realistischer Bestellprozess kennt mehr als den grünen Happy Path. Die Zahlung kann abgelehnt werden, der Zahlungsdienstleister kann nicht antworten oder ein Artikel kann zwischen Bestellung und Kommissionierung ausverkauft sein.
Für solche Fälle eignen sich Fehlerereignisse, Nachrichtenereignisse und Timer. Wenn eine Zahlungsantwort höchstens 10 Minuten ausbleiben darf, kann ein Timer-Ereignis einen Prüf- oder Eskalationspfad starten. Das ist für die spätere Implementierung wesentlich, weil ein System sonst auf eine Antwort warten könnte, die nie eintrifft.
Auch Wiederholungen sollten bewusst modelliert werden. Ein API-Aufruf darf nicht automatisch fünfmal eine Zahlung auslösen. Bei externen Schnittstellen braucht es deshalb Idempotenz, also eine sichere Wiederholungslogik, bei der dieselbe Bestellung nicht mehrfach belastet wird.
Welche BPMN-Elemente im Alltag wirklich genügen
Die BPMN-Spezifikation bietet viele Ereignisarten, Aktivitäten und Gateway-Varianten. Für die meisten Webprojekte braucht man am Anfang jedoch nur eine kleine, konsistente Teilmenge. Zu viele Symbole erhöhen die Lernkosten und führen dazu, dass Fachanwender das Modell nicht mehr selbst pflegen.
Die wichtigsten Symbole für Einsteiger
- Start- und Endereignis: Sie markieren Anfang und Ende eines Prozesspfads.
- User Task: Ein Mensch erledigt eine Aufgabe in einem Portal oder einer Anwendung.
- Service Task: Ein System oder eine Schnittstelle führt die Aufgabe automatisch aus.
- Exklusives Gateway: Genau eine Bedingung wird erfüllt, etwa „bezahlt“ oder „abgelehnt“.
- Paralleles Gateway: Mehrere Pfade laufen gleichzeitig, zum Beispiel Rechnung erstellen und Lager informieren.
- Zwischenereignis: Der Prozess wartet auf eine Nachricht, einen Timer oder einen Fehler.
Ein paralleles Gateway ist nicht dasselbe wie eine einfache Verzweigung. Wenn nach erfolgreicher Zahlung gleichzeitig eine E-Mail versendet und ein Lagerauftrag erstellt werden soll, können beide Pfade parallel starten. Ein exklusives Gateway wäre hier falsch, weil es nur eine Alternative zulässt.
Wann ein einfaches Flussdiagramm besser ist
BPMN lohnt sich besonders, wenn mehrere Rollen, Systeme, Entscheidungen oder Wartezustände beteiligt sind. Für einen linearen Ablauf mit drei Schritten genügt oft ein schlichtes Flussdiagramm. Ich würde kein komplexes BPMN-Modell erstellen, nur weil das Verfahren professioneller klingt.
Die Grenze liegt dort, wo das Diagramm mehr erklärt werden muss, als es selbst verständlich macht. Ein Modell mit 20 bis 30 Aktivitäten auf einer Seite sollte in Teilprozesse zerlegt werden. So bleibt die Übersicht erhalten, während Details in sogenannten Call Activities oder separaten Diagrammen weitergeführt werden können.
BPMN in modernen Webprojekten einsetzen
In der Webentwicklung gibt es zwei typische Einsatzformen. Erstens wird BPMN als visuelle Dokumentation in einer Anwendung oder im internen Wiki genutzt. Zweitens dient das Modell als ausführbare Prozessdefinition, die eine Engine verwaltet und mit Frontend, Backend und externen Diensten verbindet.
Darstellung im Browser
Für die Anzeige und Bearbeitung von BPMN-Diagrammen im Browser ist bpmn-js eine verbreitete JavaScript-Bibliothek. Sie kann BPMN-Dateien rendern, bearbeiten und Ereignisse aus dem Diagramm an die Webanwendung weitergeben. In einem React-, Vue- oder Angular-Projekt lässt sich der Modellierer in der Regel als eigene UI-Komponente kapseln.
Wichtig ist die Trennung zwischen Diagramm und Geschäftslogik. Das Frontend sollte nicht selbst entscheiden, ob eine Zahlung gültig ist. Es zeigt den Prozessstatus an und bietet passende Aktionen an, während Backend und Workflow-Engine die fachlichen Regeln durchsetzen.
Lesen Sie auch: Evergreen Content in der Webentwicklung richtig planen
Ausführung mit Backend und Workflow-Engine
Eine typische Architektur besteht aus einem Frontend für Benutzeraufgaben, einem Backend für Geschäftslogik, einer Workflow-Engine für Zustände und einer Datenbank für Prozessvariablen. Externe Systeme werden über REST, Webhooks oder Messaging angebunden.
Ein möglicher Ablauf sieht so aus:
- Das Frontend sendet die Bestellung an das Backend.
- Das Backend startet eine neue Prozessinstanz.
- Die Engine ruft den Zahlungsservice auf.
- Das Ergebnis wird als Prozessvariable gespeichert.
- Das Gateway wählt den passenden Pfad.
- Das Frontend zeigt offene User Tasks im Lagerportal an.
Für kleine Teams ist ein vollständig ausführbarer BPMN-Prozess nicht automatisch die beste Wahl. Die zusätzliche Plattform braucht Monitoring, Fehlerbehandlung, Berechtigungen und Know-how. Bei wenigen, stabilen Abläufen kann eine gut strukturierte Anwendung mit Zustandsmodell einfacher sein. Sobald jedoch mehrere Teams und Systeme beteiligt sind, spielt BPMN seine Stärke bei Transparenz und Prozesssteuerung aus.
Typische Fehler bei einem BPMN-Modell vermeiden
Der häufigste Fehler ist ein Diagramm, das nur den Idealfall zeigt. In echten Webprozessen sind Ausnahmen keine Randnotiz. Eine fehlende Rückabwicklung, ein Timeout oder ein manueller Prüfpunkt kann später zu falschen Erwartungen zwischen Fachbereich und Entwicklung führen.
- Zu technische Diagramme: Datenbanktabellen und einzelne Methoden gehören meist nicht in das fachliche Prozessmodell.
- Unklare Rollen: Jede Aufgabe sollte einer Lane oder einem System eindeutig zugeordnet sein.
- Falsche Gateway-Logik: XOR, AND und ereignisbasierte Gateways haben unterschiedliche Bedeutungen.
- Fehlende Enden: Jeder Prozesspfad sollte nachvollziehbar enden, auch ein Fehlerpfad.
- Unpräzise Aufgaben: „Bestellung bearbeiten“ sagt weniger aus als „Adresse validieren“ oder „Versandlabel erzeugen“.
- Keine Prozessdaten: Für die Ausführung muss klar sein, welche ID, welcher Status oder welches Ergebnis weitergegeben wird.
Ein guter Praxistest ist eine kurze Lesung mit zwei Personen. Eine Person erklärt den Prozess anhand des Diagramms, die andere spielt Kunde, Shop und externe Dienste. Sobald jemand fragen muss, was bei einer Ablehnung oder einem Timeout passiert, ist das Modell noch nicht fertig.
Auch die Versionierung darf nicht fehlen. Ändert sich der Zahlungsablauf, sollte erkennbar bleiben, welche Bestellungen nach der alten und welche nach der neuen Prozessversion laufen. Gerade bei laufenden Bestellungen kann ein unkontrolliertes Überschreiben zu schwer nachvollziehbaren Zuständen führen.
Vom ersten Entwurf zur belastbaren Prozessautomatisierung
Beginne mit einem konkreten Geschäftsfall und maximal fünf bis sieben Kernschritten. Markiere danach Rollen, Entscheidungen und externe Nachrichten. Erst wenn dieser Ablauf verständlich ist, lohnt sich die Ergänzung von Fehlerereignissen, Timern und technischen Implementierungsdetails.
Mein wichtigster Rat lautet, das Diagramm gemeinsam mit den späteren Nutzern zu prüfen. Ein BPMN-Beispiel ist dann gelungen, wenn ein Entwickler daraus Schnittstellen und Zustände ableiten kann und ein Fachanwender den Prozess ohne Schulung in langen Spezifikationen wiedererkennt.
So bleibt BPMN mehr als eine hübsche Grafik. Richtig eingesetzt wird daraus eine gemeinsame Sprache für Webentwicklung, digitale Strategie und Automatisierung, mit der sich Abläufe verständlicher planen, sicherer implementieren und leichter weiterentwickeln lassen.
