Die besten BPMN-Beispiele für reale Geschäftsprozesse

Die meisten Menschen, die nach BPMN-Beispielen suchen, wollen dasselbe: ein Diagramm, das sie tatsächlich morgen nutzen können, keine Lehrbuchillustration dazu, wie ein Gateway-Symbol aussieht. Das Problem ist, dass die meisten veröffentlichten Beispiele genau daran scheitern. Entweder sind sie zu abstrakt, um sie ohne kompletten Neustart anzupassen, oder sie sind so eng an ein Tool gebunden, dass eine Übertragung an einen anderen Ort einen vollständigen Neuaufbau erfordert.

Das ist das eigentliche Auswahlproblem. Nicht „Welches BPMN-Diagramm sieht am vollständigsten aus?“, sondern „Welches Beispiel kann ich tatsächlich öffnen, bearbeiten und einem Entwickler übergeben oder durch eine Engine ausführen, ohne einen ganzen Tag zu verlieren?“ Bearbeitbarkeit und Tool-Neutralität sind wichtiger als optische Perfektion. Dieser Artikel basiert auf dieser Aussage – und ja, vernünftige Menschen können anderer Meinung sein. Genau deshalb lohnt es sich, sie zu verteidigen.

Wo die meisten Suchen nach BPMN-Beispielen falsch abbiegen

• Einsteiger benötigen Beispiele mit einem einzelnen Pool und wenigen Gateways; fortgeschrittene Modellierer benötigen ausführbares BPMN-2.0-XML, keine Screenshots.
• Bearbeitbarkeit schlägt Diagrammkomplexität – eine wiederverwendbare Datei ist einem schönen Bild immer überlegen.
• Der häufigste Fehler bei der Wiederverwendung: Sie greifen zu einer Tool-gebundenen Vorlage und stellen fest, dass sie sich in keinem anderen Modellierer öffnen lässt.
• Der Prozesstyp sollte die Auswahl eines Beispiels bestimmen, nicht die Bekanntheit einer Tool-Marke.

Was ein BPMN-Beispiel tatsächlich nützlich macht

Es gibt eine Version dieser Frage, die häufig schlecht beantwortet wird. Jemand fragt nach guten Beispielen für die Business Process Model and Notation, erhält eine Galerie statischer PNGs und verbringt am Ende trotzdem zwei Tage mit dem Neuaufbau. Das Bild sah korrekt aus. Es ließ sich nur nicht bearbeiten.

Ein wirklich nützliches BPMN-Beispiel erfüllt drei Kriterien. Erstens folgt es dem BPMN-Standard eng genug, um in jedem standardkonformen Modellierer lesbar zu sein – und nicht einer proprietären Interpretation dessen, was die Symbole „bedeuten sollten“. Zweitens liegt es in einem bearbeitbaren Format vor: idealerweise als BPMN-2.0-XML-Datei, die Sie öffnen können, statt als gesperrte Vorlage, für deren Anpassung ein kostenpflichtiges Konto nötig ist. Drittens bildet es einen realen Prozesstyp ab, der etwas ähnelt, das Ihr Team tatsächlich ausführt.

Der BPMN-Standard, aktuell in Version 2.0 und gepflegt von der Object Management Group, wird von IBM als globaler Standard für die Modellierung von Geschäftsprozessen und als grundlegender Bestandteil der BPM-Praxis beschrieben. Dieses Gewicht ist relevant: Wenn Sie ein Beispiel aus einer Quelle übernehmen, die dem Standard folgt, kann es ohne Übersetzungsprobleme zwischen Tools, Teams und Automatisierungs-Engines wechseln. Wenn Sie es aus einer Quelle übernehmen, die die Notation aus optischen Gründen verbiegt, übernehmen Sie all diese Abweichungen als versteckte technische Schulden.

Die Auswahlkriterien, die tatsächlich zählen, in dieser Reihenfolge: Lässt es sich in Ihrem Modellierer öffnen? Folgt es OMG-konformer Notation? Modelliert es einen Prozesstyp, der Ihrem ausreichend ähnlich ist, sodass die Anpassung Stunden statt Tage dauert? Die Komplexität des Diagramms liegt mit großem Abstand auf Platz vier.

BPMN-2.0-Grundlagen der Notation, die Sie zum Lesen der Beispiele brauchen

Sie benötigen keine Zertifizierung, um ein BPMN-Diagramm zu lesen. Aber Sie sollten fünf Elemente erkennen können, bevor die folgenden Beispiele sinnvoll werden.

Ereignisse markieren, wo etwas passiert. Ein Kreis ist die Grundform. Ein einfacher Kreis ist ein Startereignis – das Element, das den Prozess auslöst. Ein Kreis mit dickem Rand ist ein Endereignis. Kreise mit Symbolen im Inneren, etwa Umschlägen, Uhren oder Blitzen, sind Zwischenereignisse, die während des Ablaufs auftreten.

Aufgaben sind Rechtecke. Sie repräsentieren eine Arbeitseinheit: „Rechnung prüfen“, „Bestätigungs-E-Mail senden“, „Ticket zuweisen“. Markierungen für Aufgabentypen in der oberen linken Ecke unterscheiden Benutzeraufgaben (Personensymbol), Serviceaufgaben (Zahnrad), Empfangsaufgaben (Umschlag) und weitere Typen.

Gateways sind Rauten. Ein X darin bedeutet exklusiv: Ein Pfad wird fortgesetzt, die anderen nicht. Ein + bedeutet parallel: Alle Pfade werden gleichzeitig fortgesetzt. Eine Pentagonform weist auf ein ereignisbasiertes Gateway hin – mehr dazu später.

Pools und Lanes legen fest, wer was macht. Ein Pool ist der Container für einen gesamten Teilnehmer, etwa ein Unternehmen oder ein System. Lanes darin teilen die Arbeit nach Rolle oder Abteilung auf. Sequenzflüsse (durchgezogene Pfeile) verbinden Elemente innerhalb eines Pools. Nachrichtenflüsse (gestrichelte Pfeile) verlaufen zwischen Pools.

Ein Symbolsatz, der in verschiedenen Tools konsistent lesbar ist, zeigt, dass die Notation ihre Aufgabe erfüllt. Wenn das nicht der Fall ist, sehen Sie eine proprietäre Variante.

Warum die meisten BPMN-Diagrammbeispiele beim Wiederverwenden scheitern

Hier ist das Fehlermuster, das ich immer wieder sehe. Jemand findet über eine Google-Bildersuche ein sauberes BPMN-Diagramm, macht einen Screenshot und beginnt, es nachzumodellieren. Drei Stunden später stellt diese Person fest, dass das Gateway-Verhalten im Beispiel nicht der BPMN-Spezifikation entspricht – der ursprüngliche Autor hat es so gezeichnet, weil es sauberer aussah, nicht weil es korrekt war. Der Sequenzfluss, der scheinbar beide Pfade gleichzeitig fortsetzt, ist in Wirklichkeit mehrdeutig, und die eingesetzte Prozess-Engine interpretiert ihn anders.

Die andere Variante: Jemand findet eine Vorlage in einem Diagramm-Tool, passt sie an und versucht dann, sie als BPMN-2.0-XML-Datei zu exportieren. Das Tool exportiert etwas. Aber das XML validiert nicht als standardkonform, was bedeutet, dass es sich nicht sauber in Camunda, Flowable oder eine andere Prozess-Engine importieren lässt. Die Vorlage war immer ein visuelles Artefakt, kein Prozessmodell.

Die Unterscheidung ist heute noch wichtiger, da die Geschäftsprozessautomatisierung in Richtung ausführbarer End-to-End-Prozessmodelle statt reiner Dokumentationsartefakte entwickelt wird. Die Tool-neutrale herunterladbare BPMN-Datei – echtes XML, das gegen die BPMN-Spezifikation validiert und sich in jedem konformen Modellierer öffnen lässt – löst ein Problem, das statische Bilder und proprietäre Vorlagen schlicht nicht lösen. Tool-gebundene Prozessmodelle sehen in einer Präsentation gut aus. Sie erzeugen Reibung, sobald jemand versucht, sie auszuführen.

Dort beginnt das Ticket normalerweise.

So wählen Sie ein BPMN-Beispiel nach Anwendungsfall und Kenntnisstand aus

Das richtige Beispiel hängt fast vollständig davon ab, was Sie damit erreichen möchten. Hier ist eine Entscheidungsliste nach Situation.

• Einsteiger, die einen visuellen Ausgangspunkt benötigen

  Beginnen Sie mit einer im Browser bearbeitbaren Vorlage von HEFLO oder Lucidchart. Ein einzelner Pool, zwei oder drei Lanes, minimale Gateways. Das Ziel ist, die Notation durch das Lesen eines realen Prozesses zu verstehen, nicht etwas Ausführbares zu erstellen. Der Detaillierungsgrad sollte niedrig genug sein, damit das Diagramm auf einen Bildschirm passt.

• Business-Analysten, die OMG-konforme Modelle für Stakeholder-Reviews benötigen

  Nutzen Sie die Bibliothek von Trisotech oder die öffentlichen Beispiele von Camunda. Sie sind ausdrücklich auf die Einhaltung des OMG-Standards ausgelegt, was wichtig ist, wenn das Modell eine Prüfung durch ein Standardisierungsgremium bestehen oder zwischen Organisationen weitergegeben werden muss. Business-Analysten, die aus nicht konformen Quellen übernehmen, erzeugen Nacharbeit für die Entwickler, die das Modell anschließend erhalten.

• Entwickler, die ausführbare BPMN-Prozessmodelle benötigen

  Das Repository von Camunda ist hier die direkt nützlichste Quelle. Die Beispiele sind für die Ausführung in der Camunda-Prozess-Engine konzipiert, enthalten korrekte Markierungen für Aufgabentypen und Gateway-Konfigurationen, und das XML validiert. Wenn das Prozessdesign später über eine Workflow-Engine laufen soll, beginnen Sie mit einem ausführbaren Beispiel.

• Business-Anwender, die etwas ohne Einrichtungsaufwand bearbeiten müssen

  HEFLO und Lucidchart bieten beide browserbasierte Vorlagenbibliotheken, die keine Installation eines Modellierers erfordern. Der Kompromiss: Die Vorlagen sind praktisch, können aber zur besseren Lesbarkeit Teile der Notation vereinfachen. Das ist relevant, wenn das Modell später eine Compliance-Prüfung bestehen muss.

• Forscher oder Lehrende, die einen Korpus von BPMN-Prozessmodellen benötigen

  Die GitHub-Sammlung BPMN-for-Research stellt Hunderte Modelle im Standard-XML-Format bereit, die für die akademische Nutzung kuratiert wurden. Tool-neutral, herunterladbar und vielfältig genug, um die meisten Prozesskategorien abzudecken. Nicht glamourös, aber für diesen Anwendungsfall die richtige Antwort.

BPMN-Beispiele im Vergleich: Bearbeitbarkeit, Konformität und Eignung für den Anwendungsfall

Die folgende Tabelle umfasst die neun Optionen, die in verfügbarer Forschung dokumentiert sind. Zellen mit „Nicht bestätigt“ weisen auf tatsächlich fehlende quellenbasierte Daten hin, nicht auf Auslassungen. Insbesondere Preismodelle ändern sich häufig genug, dass Sie die aktuellen Tarife direkt bei jedem Anbieter prüfen sollten.

Ein praktischer Hinweis, bevor wir fortfahren: „Object-Management-Group-konform“ und „sieht OMG-konform aus“ sind nicht dasselbe. Visuelle Ähnlichkeit mit korrekter Notation garantiert nicht, dass das zugrunde liegende XML validiert. Prüfen Sie heruntergeladene Dateien mit einem BPMN-Validator, bevor Sie eine Workflow-Engine darauf setzen.

Die besten BPMN-Diagrammbeispiele nach Prozesstyp

Die Tool-Marke ist die falsche Achse für die Auswahl eines BPMN-Beispiels. Der Prozesstyp ist die richtige. Ein BPMN für einen Einstellungsprozess und ein BPMN für Rechnungsfreigaben unterscheiden sich strukturell, und die falsche Vorlage für Ihre Prozesskategorie zu übernehmen, kostet mehr Zeit als mit einer einfacheren Grundlage zu beginnen. Im Folgenden werden Praxisbeispiele nach den Prozessmustern organisiert, die sie darstellen – mit Hinweisen, wo Sie bearbeitbare Versionen erhalten.

BPMN-Beispiele für Auftragsabwicklung und Batch-Verarbeitung

In der Auftragsverarbeitung zeigt sich der Nutzen der Multi-Pool-Fähigkeit von BPMN besonders deutlich. Ein realer Auftrags-Workflow erstreckt sich über mindestens zwei Pools: den kundenorientierten Pool für Auftragserteilung, Bestätigung und Benachrichtigung sowie den Fulfillment-Pool für Bestandsprüfung, Lager und Versand. Nachrichtenflüsse zwischen diesen Pools übernehmen die Übergaben, und ein exklusives Gateway innerhalb des Fulfillment-Pools verzweigt danach, ob Bestand verfügbar ist. Dadurch wird entweder die direkte Abwicklung oder ein Sequenzfluss für Rückstände ausgelöst.

„Processing a Batch of Orders from a Marketplace“ von Camunda ist für dieses Muster das nützlichste BPMN-Ausgangsbeispiel. Es zeigt Schleifenverarbeitung für Batch-Iterationen, Gateway-Verzweigungen für Fulfillment-Entscheidungen und Nachrichtenflüsse zwischen Pools – alles innerhalb eines einzigen Diagramms. Jede Prozessinstanz im Batch verhält sich identisch, was das Modell wiederverwendbar statt spezifisch für einen einzelnen Fall macht.

Die Vorlage für die Auftragsabwicklung von HEFLO ist ein klarerer Ausgangspunkt, wenn Ihr Team nicht sofort ausführbares BPMN benötigt. Der Workflow wird in einem einzelnen Pool mit Lanes für Kunde, Vertrieb und Lager zusammengefasst. Das erleichtert die Lesbarkeit in einem Stakeholder-Review, verzichtet aber auf die strikte Trennung durch Nachrichtenflüsse. Für Dokumentationszwecke ist das oft die richtige Entscheidung. Für die Ausführung sollten Sie zu Camunda zurückkehren.

Ein Einrichtungsfehler, den ich regelmäßig sehe: Teams modellieren nur den Happy Path und lassen die Gateway-Verzweigungen unbeschriftet. In der Produktion bedeutet ein unbeschrifteter ausgehender Sequenzfluss eines exklusiven Gateways, dass niemand weiß, welche Bedingung dorthin führt. Beschriften Sie jede Verzweigung. Selbst „Standard“ ist besser als leer.

Freigabe-Workflows und das Vier-Augen-Prinzip in BPMN

Das Vier-Augen-Prinzip ist genau das, wonach es klingt: Zwei unabhängige Prüfer müssen freigeben, bevor ein Prozess weiterläuft. In BPMN bedeutet dies zwei aufeinanderfolgende Benutzeraufgaben, die über ein Gateway verbunden sind. Die zweite Aufgabe darf erst beginnen, nachdem der erste Genehmiger seinen Schritt abgeschlossen hat und der Sequenzfluss ein exklusives Gateway passiert, das die erste Entscheidung prüft.

Dieses Muster ist relevant für Geschäftsprozesse mit finanziellen Freigaben, Compliance-Abzeichnungen oder Änderungen an sensiblen Daten. Das Beispiel „Four Eyes“ von Camunda modelliert dies ausdrücklich: zwei Freigabe-Benutzeraufgaben in Folge, mit ausgehenden Sequenzflüssen von jedem Gateway, die mit „Genehmigt“ und „Abgelehnt“ beschriftet sind. Der abgelehnte Pfad führt typischerweise zurück oder endet mit einem Fehler-Endereignis. Der genehmigte Pfad führt zur nächsten Geschäftsaktivität.

Das Beispiel für Geschäftsregeln von Camunda erweitert dies, indem es zeigt, wie Entscheidungen im Prozessfluss an eine Geschäftsregel-Engine delegiert werden können, statt direkt in der Gateway-Bedingung codiert zu sein. Das ist der Unterschied zwischen „Das Gateway prüft einen Feldwert“ und „Das Gateway ruft einen Regelservice auf, der die Routing-Entscheidung zurückgibt“. Für manuelle Prozessfreigaben reicht die einfachere Bedingung im Diagramm aus. Bei komplexer Genehmigungslogik mit mehreren Variablen hält der externe Regelansatz das BPMN lesbar.

Wenn Sie dieses Muster in einem Low-Code-Tool wie Latenode implementieren, gilt dieselbe Logik: Die zwei Freigabeschritte werden zu zwei Nodes in Folge, die Routing-Logik liegt in einem JavaScript-Node, der die Gateway-Bedingung abbildet, und die ausgehenden Pfade entsprechen den Verzweigungen „genehmigt“ und „abgelehnt“. Die Preisgestaltung pro Ausführung bedeutet, dass der gesamte mehrstufige Freigabeablauf als eine einzelne Ausführung zählt – relevant, wenn Sie Kosten mit aufgabenbasierten Preismodellen vergleichen.

BPMN-Diagrammbeispiele für Service Desk und Einstellungsprozesse

Bei internen Serviceprozessen sorgen Pools und Lanes für besonders viel Klarheit. Ein Service-Desk-Prozess hat mindestens drei Beteiligte: den Anfragenden, den Support-Mitarbeiter und bei Eskalationen den IT-Spezialisten. Jeder erhält eine Lane innerhalb des Service-Desk-Pools. Die Empfangsaufgabe am Anfang – der Schritt „Ticket empfangen“ – ist der Punkt, an dem die externe Eingabe ankommt. Von dort leitet das Diagramm anhand der Klassifizierung weiter.

Das Service-Desk-Beispiel von HEFLO ist eine der klareren Darstellungen von BPMN-Aufgabentypen in einem realen Support-Kontext. Es zeigt das Klassifizierungs-Gateway, die Zuweisung an einen Mitarbeiter, die Rückmeldung der Lösung an den Anfragenden und den Eskalationspfad, falls die Lösung durch den First-Level-Support scheitert. Die Prozessbeteiligten sind sauber getrennt. Das Diagramm ist für Personen lesbar, die noch nie einen BPMN-Modellierer geöffnet haben, was in einem Stakeholder-Review wichtig ist.

Das Beispiel für einen Einstellungsprozess folgt einer ähnlichen Struktur, erstreckt sich aber über mehr Pools: den Kandidaten-Pool, den HR-Pool und den Pool des einstellenden Managers. Nachrichtenflüsse verlaufen zwischen Kandidat und Unternehmen. Beispiele für eingegangene, geprüfte, interviewte und entschiedene Bewerbungen erzeugen jeweils eine eigene Prozessinstanz. Nützlich an der HEFLO-Vorlage für Einstellungen ist die explizite Modellierung der kandidatenorientierten Schritte als separater Pool. Dadurch zeigt das Diagramm, was extern sichtbar ist und was zum internen Prozess gehört. Viele BPMN-Beispiele für Einstellungen fassen alles in einem Pool zusammen und verlieren diese Unterscheidung.

Muster für Eskalation, Neuzuweisung und ereignisbasierte Gateways

Dieses BPMN-Muster bringt Praktiker mit mittlerem Erfahrungsniveau zuverlässiger aus dem Konzept als fast jedes andere. Nicht, weil es konzeptionell schwierig wäre, sondern weil sich die Notation für zeitgesteuerte Eskalationen leicht falsch zeichnen lässt und es niemand bemerkt, bis die Prozess-Engine einen Fehler meldet.

Ein ereignisbasiertes Gateway leitet den Prozess danach weiter, welches Ereignis als Nächstes eintritt – eine Nachricht, ein Timer oder ein Signal. Anders als ein exklusives Gateway, das Datenbedingungen prüft, wartet das ereignisbasierte Gateway tatsächlich und bewegt sich dann in die Richtung des Ereignisses, das zuerst ausgelöst wird. Damit ist es das richtige Werkzeug für Eskalationslogik: „Wenn wir innerhalb von 48 Stunden eine Antwort erhalten, gehe zu Pfad A; wenn das angehängte Timer-Ereignis zuerst ausgelöst wird, gehe zum Eskalationspfad.“

Das Beispiel „Two Step Escalation“ von Camunda zeigt dies klar. Auf eine Benutzeraufgabe folgt ein nicht unterbrechendes Boundary-Timer-Ereignis, das nach einem definierten Zeitraum ausgelöst wird. Der Unterschied zwischen unterbrechend und nicht unterbrechend ist hier wichtig: Ein unterbrechendes Ereignis bricht die aktuelle Aufgabe ab, wenn es ausgelöst wird; ein nicht unterbrechendes Ereignis startet einen parallelen Pfad, während die ursprüngliche Aufgabe weiterläuft. Eine Eskalationsbenachrichtigung ist typischerweise nicht unterbrechend – Sie möchten jemanden informieren, ohne die laufende Arbeit abzubrechen. Eine Neuzuweisung einer Aufgabe ist unterbrechend: Sie beenden die aktuelle Zuweisung und erstellen eine neue.

Das Konzept des fangenden Ereignisses ermöglicht beide Muster. Ein fangendes Zwischenereignis liegt auf dem Sequenzfluss und wartet. Wenn der Auslöser eintrifft, bewegt sich das Token weiter. Die Variante mit angehängtem Timer-Ereignis wird direkt an einer Aufgabengrenze befestigt, statt inline im Fluss zu liegen. Das ist die Variante, die in der Praxis bei den meisten Eskalations- und SLA-Durchsetzungsmustern verwendet wird. Wenn Sie ein SLA für Support-Tickets in BPMN modellieren, benötigen Sie die Variante mit angehängtem Timer, nicht das inline platzierte Zwischenereignis. Das Verhalten sieht im Diagramm ähnlich aus. Der Unterschied bei der Ausführung ist real.

BPMN-Modellierungs-Best-Practices, die Sie in jedem schlechten Beispiel verletzt sehen

Ich habe genug öffentlich geteilte BPMN-Diagramme geprüft, um eine Liste von Dingen zu haben, die in einem Screenshot harmlos aussehen und Probleme verursachen, sobald jemand versucht, ihnen zu folgen. Es geht nicht um Reinheit der Notation. Es geht um den Unterschied zwischen einem Prozessmodell, das die Ausführung leitet, und einem, das im Moment einer Übergabe Verwirrung erzeugt.

Das häufigste Muster: Sequenzflüsse, die sich kreuzen. Wenn sich Flüsse innerhalb eines Pools kreuzen, sieht das Diagramm wie eine Straßenkreuzung ohne Verkehrsregeln aus. Die Modellierungsempfehlungen von Camunda sind hier eindeutig: Flüsse sollten so geführt werden, dass Kreuzungen vermieden werden. Normalerweise bedeutet das, das Layout neu zu organisieren, statt nur die Pfeile zu verbiegen. Ein Diagramm, in dem Sie einem Pfad nicht folgen können, ohne ihn an einem Kreuzungspunkt zu verlieren, wird falsch gelesen werden.

Zweitens: inkonsistente Benennung von Aufgaben. BPMN-Aufgaben sollten einem Verb-Objekt-Muster folgen – „Rechnung prüfen“, „Ticket zuweisen“, „Anfrage genehmigen“. Wenn Aufgaben mit Substantiven benannt werden („Rechnungsprüfung“, „Ticketzuweisung“) oder als vollständige Sätze („Das System sendet dem Benutzer eine Bestätigungs-E-Mail“), wird das Diagramm schwerer zu überblicken und die Übergabe an Entwickler mehrdeutig. Konsistente Benennung ermöglicht es zudem, eine Prozesslandschaft im großen Maßstab zu modellieren und zu dokumentieren. Wenn Ihre Namenskonventionen zwischen Diagrammen variieren, wird das Portfolio unlesbar.

Drittens: asymmetrisches Layout. Gleich große Aufgaben und ausgerichtete Sequenzflüsse sind keine ästhetischen Vorlieben. Sie sind Werkzeuge für bessere Lesbarkeit. Ein Diagramm mit unterschiedlich großen Aufgaben, asymmetrischer Positionierung oder Flüssen, die ohne Grund die Richtung wechseln, erzeugt visuelles Rauschen, bevor es Prozesslogik vermittelt. Die Perspektive der BOC Group zur Prozessoptimierung macht denselben Punkt aus Sicht der Enterprise-Governance: Einer Prozessbeschreibung, die schwer zu lesen ist, wird nicht gefolgt, und ein Prozess, dem nicht gefolgt wird, liefert nicht die Optimierung, für die er entwickelt wurde.

Viertens: unbeschriftete Gateway-Verzweigungen. Ein exklusives Gateway mit zwei ausgehenden Flüssen, von denen keiner beschriftet ist, ist keine Modellierungsabkürzung. Es ist dokumentierte Mehrdeutigkeit. Jede Person, die das Diagramm liest – einschließlich einer Prozess-Engine –, muss raten, welche Bedingung zu welchem Pfad führt. Beschriften Sie jeden ausgehenden Sequenzfluss eines Gateways, auch den Standardfluss.

📊 In der Praxis:
Die Verletzung durch kreuzende Sequenzflüsse ist am leichtesten zu erkennen und für Autoren am schwersten in ihren eigenen Diagrammen zu sehen. Bevor Sie ein BPMN-Modell teilen, zoomen Sie heraus, bis das Diagramm auf einen Bildschirm passt, und verfolgen Sie jeden Fluss mit dem Finger. Wenn Ihr Finger einen anderen Fluss kreuzt, verlegen Sie ihn neu. Nie sollte der Fluss die Kreuzung sein – es ist immer das Layout, das angepasst werden muss.

Namenskonventionen und symmetrische Modellierung in BPMN

Die Regel für Namenskonventionen ist kurz: Aufgaben erhalten Verb-Objekt-Namen, Ereignisse erhalten Nominalphrasen. „Auftrag empfangen“ ist eine Aufgabe. „Auftrag eingegangen“ ist ein Ereignis. „Bestandsverfügbarkeit prüfen“ ist eine Aufgabe. „Bestand nicht verfügbar“ würde als Gateway-Beschriftung funktionieren, aber nicht als Aufgabenname. Das klingt wie eine Stilpräferenz, bis Sie versuchen, eine Prozesslandschaft aus dreißig Diagrammen zu modellieren, und feststellen, dass inkonsistente Benennung eine diagrammübergreifende Analyse bedeutungslos macht.

Symmetrisches Layout – gleich große Aufgaben, Sequenzflüsse mit einer Richtung von links nach rechts oder von oben nach unten, Gateways in konsistenten Abständen – dient demselben Ziel der Lesbarkeit. Wenn Sie einen Prozess modellieren, kommuniziert das Layout vor dem Inhalt. Ein Diagramm mit ungleichmäßigen Aufgabenboxen und Flüssen in vier Richtungen wirkt chaotisch, bevor der Leser auch nur eine Beschriftung verarbeitet hat. Das ist ein Problem, wenn das Modell eine Prüfung durch jemanden bestehen muss, der beim Erstellen nicht im Raum war.

Die Modellierungsempfehlungen von Camunda ergänzen noch einen Punkt: Halten Sie den Happy Path auf dem horizontalen Hauptfluss und führen Sie Ausnahmepfade nach unten oder oben davon weg. Das schafft für alle Leser, die mit dieser Konvention vertraut sind, eine konsistente Orientierung. Sie wissen, wo sie nach dem Standardverhalten und wo nach Sonderfällen suchen müssen, ohne jeden Pfad nachzuverfolgen. Wenn Sie einen Prozess in einer Teamumgebung modellieren, sind solche Konventionen entscheidend für die Übertragbarkeit des Diagramms.

Wo Sie bearbeitbare BPMN-2.0-Dateien und ausführbare Prozessmodelle finden

Hier ist die direkte Antwort auf die Frage, die die meisten BPMN-Übersichten nicht wirklich beantworten: Wo erhalten Sie eine Datei, die Sie in Ihrem eigenen Modellierer öffnen können, statt sie nur anzusehen?

ProcessMind bietet herunterladbare BPMN-Dateien im Standard-XML-Format. Das sind BPMN-Beispielmodelle, die Sie ohne Konvertierung im kostenlosen Online-Modellierer von Camunda, in BPMN.io – ebenfalls kostenlos und browserbasiert – oder in jedem anderen BPMN-2.0-konformen Modellierer öffnen können.

Die GitHub-Sammlung BPMN-for-Research ist der umfassendste offene Korpus: Hunderte Modelle in Standard-XML, von einfachen Freigabeabläufen bis zu komplexen Multi-Pool-Orchestrierungen. Sie wurde für akademische Zwecke zusammengestellt, funktioniert aber ebenso gut als Ausgangspunkt für Praktiker. Laden Sie das XML herunter, öffnen Sie es in Ihrem Modellierer und passen Sie es an.

Der Online-Modellierer von Camunda ist kostenlos und erfordert keine Installation. Sie können jede BPMN-2.0-XML-Datei direkt im Browser öffnen, bearbeiten und wieder als XML exportieren. Wenn Sie neu in der BPMN-Modellierung sind und später mit einer Prozess-Engine starten möchten, ist dies der richtige Einstieg: Der Modellierer exportiert Dateien, die ohne Konvertierung ausführbar sind. Damit beträgt die Lücke zwischen Modellierungstool und Prozess-Engine null.

Der Unterschied zwischen einem Modellierer und einer Laufzeitumgebung für die Ausführung von Prozesssprachen sollte klar benannt werden. Ein Modellierer ist das Tool, in dem Sie Diagramme zeichnen und bearbeiten. Eine Prozess-Engine oder BPMN-Laufzeitumgebung ist das System, das das Modell als laufenden Prozess ausführt, Instanzen verfolgt, Gateways verarbeitet und Aufgaben abschließt. Modellierer und Engine behandeln getrennte Anliegen, und nicht jede BPMN-Datei, die in einem Modellierer korrekt aussieht, wird in einer Engine korrekt ausgeführt. Testen Sie mit Webservice-Integrationen oder einer lokalen Engine, bevor Sie ein Modell als produktionsreif erklären.

Welche BPMN-Beispielquelle zu der Situation Ihres Teams passt

BPMN ist ein Standard für die Modellierung von Geschäftsprozessen, kein Produkt. Die Business Process Modeling Notation (BPMN) wurde ursprünglich von der Business Process Management Initiative entwickelt und wird heute unter der Object Management Group als Version 2.0 gepflegt – dieselbe Version, auf die sich alle folgenden Quellen beziehen. Das zu wissen ist nützlich, weil es die Notation von jedem einzelnen Anbieter trennt.

Sie müssen aber trotzdem eine Quelle wählen. Hier ist daher der kurze Rahmen.

Wenn Ihr Team überprüfbare OMG-Ausrichtung benötigt – Sie arbeiten mit Standardisierungsgremien, Compliance-Teams oder organisationsübergreifender Modellierung –, beginnen Sie mit Trisotech. Der Standard für die Geschäftsprozessmodellierung ist dort die primäre Ausrichtung, nicht ein nachrangiges Thema.

Wenn Sie BPMN benötigen, das eng mit einer Prozess-Engine verbunden ist, ist Camunda die richtige Wahl. Die Notation ist korrekt, die Dateien sind ausführbar, und der kostenlose Modellierer beseitigt die Einstiegshürde. BPMN ist ein Standard, den Camunda ernsthaft implementiert. Das gibt Ihnen Portabilität, selbst wenn Sie später zu einer anderen Engine wechseln.

Wenn Ihr Team bearbeitbare Vorlagen ohne Installation benötigt – Business-Anwender, funktionsübergreifende Teams bei Prozess-Reviews oder Operations-Verantwortliche, die vor der Automatisierung dokumentieren müssen –, lösen HEFLO und Lucidchart dieses Problem. Berücksichtigen Sie den Kompromiss: Sie erhalten Zugänglichkeit, keine strikte Konformität.

Für Forschung und Lehre oder wenn Sie einen sauberen Korpus unterschiedlicher BPMN-Prozessmodelle benötigen, um Muster zu untersuchen, ist die GitHub-Sammlung die richtige Wahl. Sie erfordert keine Bindung an eine Plattform, und die Dateien sind tatsächlich portabel.

Ein Hinweis zu UML: Teams fragen manchmal, ob BPM oder BPMN UML ersetzt. Das tut es nicht. UML (Unified Modeling Language, für Softwaredesign mit anderer Semantik entwickelt) und BPMN behandeln unterschiedliche Anliegen. BPMN modelliert, wie Geschäftsprozesse ablaufen. UML-Aktivitätsdiagramme oder Sequenzdiagramme modellieren, wie sich Softwaresysteme verhalten. Wenn die Frage lautet „Wie funktioniert dieser Geschäftsprozess?“, ist BPMN die richtige Notation. Wenn die Frage lautet „Wie interagiert diese Softwarekomponente mit dieser API?“, übernimmt UML eine andere Aufgabe.

🤔 Warten Sie.
Die meisten Übersichten zu BPMN-Beispielen empfehlen toolspezifische Vorlagen, ohne zu erwähnen, dass für die Bearbeitung dieser Vorlagen häufig ein aktives Konto bei diesem Tool erforderlich ist. Eine in HEFLO bearbeitete HEFLO-Vorlage bleibt in HEFLO, bis Sie sie exportieren. Ein Lucidchart-Diagramm lässt sich nur in kostenpflichtigen Tarifen als BPMN-2.0-XML exportieren. Wenn Ihr Team das Modell später in einen anderen Modellierer oder eine Prozess-Engine überführen möchte, sind standardisierte BPMN-2.0-XML-Dateien die einzigen Formate, die sauber übertragbar sind – genau das bieten ProcessMind und der GitHub-Korpus, während die meisten Vorlagen visueller Tools dies bewusst nicht hervorheben.