Geschäftsprozesse mit BPMN modellieren
https://bildung.social/@oerinformatik/113306383647472168
https://oer-informatik.de/bpmn
Geschäftsprozessmodellierung, BPMN, Business Process Model and Notation, Gateway, Pool, Swimlane, Nachrichtenfluss, Datenobjekt, Kollaborationsdiagramm, Ablauforganisation, Prozessanalyse
tl/dr; (ca. 22 min Lesezeit): Bevor Geschäftsprozesse optimiert und digitalisiert werden, müssen die bestehenden Geschäftsprozesse verstanden und modelliert werden. Eine verbreitete Modellierungssprache dafür ist Business Process Model and Notation (BPMN). Der Artikel zeigt, warum sich Prozesse grafisch besser darstellen lassen als im Fließtext, erklärt Ereignisse, Aktivitäten, Gateways, Pools, Lanes und Datenobjekte der BPMN, vergleicht BPMN mit der Ereignisgesteuerten Prozesskette (EPK) und zeigt, wie Du aus einem Modell Häufigkeiten und Zeitaufwand ermittelst [AI-Assisted]. (Zuletzt geändert am 28.10.2026)
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Als Grundlagen der Prozessmodellierung kann ich nach Durchlesen des Artikels…
… Vorteile einer grafischen, normierten Prozessdarstellung gegenüber einer Textbeschreibung erläutern und für eine Fragestellung eine passende Darstellung der Ablauf- oder der Aufbauorganisation auswählen,
… Einsatzzweck und Vorteile von BPMN benennen,
… die Grundstruktur eines BPMN aus Ereignissen, Aktivitäten und Gateways erklären,
… alternative, parallele und Ereignis-basierte Verzweigungen modellieren,
… zwischen Sequenzfluss und Nachrichtenfluss unterscheiden,
… Geschäftsprozesse auf Lanes aufteilen und mit anderen Pools kommunizieren lassen,
… Unterschiede zwischen EPK und BPMN beschreiben.
Darüber hinaus kann ich als Expertenwissen…
… bekannte Geschäftsprozesse als BPMN-Kollaborationsdiagramm mit Datenobjekten, Zeit- und Nachrichtenereignissen modellieren,
… Syntaxregeln für BPMN-Kollaborationsdiagramme aufführen und Modelle damit prüfen,
… BPMN-modellierte Geschäftsprozesse lesen, erklären, mit Häufigkeiten und Zeiten auswerten und darauf basierend optimieren.
Prozessmodelle als Sprache der Problemdomäne
Flussdiagramme werden verwendet, um feste, immer gleiche Abläufe zu dokumentieren, sie so reproduzierbar zu machen und darüber Qualität zu sichern. Sie bestehen allgemein aus Knoten (Aktivitäten, Verzweigungen) und Kanten (Pfeilen). Wir kennen Flussdiagramme in der IT beispielsweise in Form von Programmablaufplänen, mit denen wir einfache Algorithmen beschreiben können. Komplexere Abläufe in der IT beschreiben wir beispielsweise mit dem UML-Aktivitätsdiagramm.
Programmablaufplan und Aktivitätsdiagramm sind geläufige Diagramme für Informatiker*innen, sie beschreiben Daten- und Kontrollflussabläufe und dienen uns zur Beschreibung der Lösung eines bestimmten Problems. Sie gehören also der Lösungsdomäne an.
Neue IT-Projekte basieren häufig auf der Optimierung bestehender Geschäftsprozesse. Deren Verständnis ist in den auftraggebenden Unternehmen ein betriebswirtschaftliches: sie werden nicht als Daten- und Kontrollflussabläufe verstanden, sondern als Abfolge betriebswirtschaftlicher Aktivitäten, die Arbeitspakete repräsentieren. Die Geschäftsprozesse werden in Unternehmen in der Regel nicht von Informatiker*innen dokumentiert und beschrieben, sondern von der jeweiligen Fachabteilung. Entsprechend erfolgt die Dokumentation mithilfe von betriebswirtschaftlichen Auszeichnungen - in der Sprache der Problemdomäne.
Neben der Ereignisgesteuerten Prozesskette (EPK / eEPK) dient Business Process Model and Notation (BPMN) häufig als Flussdiagramm zur Modellierung und Dokumentierung von Geschäftsprozessen.
Wer sich direkt in der Primärquelle - der Spezifikation - informieren will, wird zunächst einen Schrecken bekommen: sie umfasst derzeit 532 Seiten. Die meisten Fragen klärt aber ein Blick in Kapitel 7.3.1 Basic BPMN Modeling Elements - hier werden auf 13 Seiten die Notationselemente und deren Besonderheiten kurz vorgestellt. BPMN 2.0 ist außerdem als internationale Norm ISO/IEC 19510 veröffentlicht.
Warum Geschäftsprozesse grafisch und normiert darstellen?
Viele Prozessbeschreibungen beginnen als Fließtext oder Stichpunktliste. Das reicht für einfache Abläufe, wird aber schnell unübersichtlich, sobald es Verzweigungen, parallele Tätigkeiten, mehrere Beteiligte oder Ausnahmen gibt. Eine Visualisierung hat mehrere Vorteile:
Überblick: Der gesamte Ablauf ist auf einen Blick erfassbar, auch für Personen, die den Prozess nicht kennen (Einarbeitung neuer Beschäftigter, Vertretung).
Schnittstellen und Verantwortlichkeiten werden sichtbar: Wer übergibt wann was an wen?
Schwachstellen erkennen und optimieren: Medienbrüche, doppelte Datenerfassung, Wartezeiten oder fehlende Fälle fallen in einem Modell eher auf als im Text.
Gemeinsame Sprache zwischen Fachabteilung und IT: Das Modell dient als Grundlage für Anforderungen und Software.
Wichtig ist, dass dabei eine normierte Notation verwendet wird. Zeichnet jede Person mit eigenen Symbolen, bleibt unklar, was ein Kasten oder Pfeil bedeutet: Symbole werden unterschiedlich interpretiert, Verantwortlichkeiten bleiben offen, und Werkzeuge können das Modell nicht weiterverarbeiten. Normierte Notationen legen Symbole und Regeln fest, sodass ein Modell eindeutig gelesen werden kann.
Prozessmodelle beschreiben die Ablauforganisation (wer macht wann was in welcher Reihenfolge?). Davon zu unterscheiden sind Darstellungen der Aufbauorganisation (welche Stellen und Abteilungen gibt es, wer ist wem unterstellt?). Welche Darstellung passt, hängt von der Frage ab, die Du beantworten willst:
| Typische Frage | passende Darstellung | Sicht |
|---|---|---|
| Welche Abteilungen gibt es, und wer berichtet an wen? | Organigramm | Aufbau |
| Was darf und muss eine bestimmte Stelle entscheiden? | Stellenbeschreibung, Stellenplan | Aufbau |
| Welche Geräte hängen in welchem Netzsegment, wo verlaufen die Verbindungen? | Netzwerkplan (Rechnernetz) | Aufbau der IT-Infrastruktur |
| Welches Ereignis löst welche Tätigkeit aus, und welcher Zustand ist danach erreicht? | EPK | Ablauf |
| Welche Beteiligten arbeiten an einem Ablauf mit, und was schicken sie einander zu? | BPMN-Kollaborationsdiagramm | Ablauf |
| Wie setzt eine Software den Ablauf um, und welche Objekte entstehen dabei? | UML-Aktivitätsdiagramm | Ablauf (Softwaresicht) |
| Wie arbeitet ein einzelner Algorithmus Schritt für Schritt? | Programmablaufplan, Struktogramm | Ablauf (Algorithmus) |
| Wann ist welches Arbeitspaket eines Projekts dran, und welche Vorgänge bestimmen den Endtermin? | Gantt-Diagramm, Netzplan | Ablauf (Projektplanung) |
Die folgenden Abschnitte stellen die Notationselemente der BPMN vor. Die Ereignisgesteuerte Prozesskette als zweite verbreitete Notation ist im Artikel Geschäftsprozesse mit der Ereignisgesteuerten Prozesskette (EPK) modellieren beschrieben.
Ereignisse (Events) als Token-Quelle und Token-Senke
In einem Flussdiagramm wird beginnend von einem Startpunkt eine Abfolge durchlaufen. An welcher Stelle der Abfolge man sich gerade befindet, kann man sich mit einer Art imaginärer Markierung vorstellen - man nennt diese Token.
Den Startpunkt eines solchen Diagramms kann man als Tokenquelle verstehen - der Token fließt in Richtung der Pfeile durch das Diagramm. Der Token kann in Zwischenereignissen pausieren und wird am Ende im Endereignis konsumiert.
Alle Ereignisse werden als Kreise dargestellt (Start: einfach, Zwischenereignis: doppelt, Ende: dick). Ereignisse finden zwischen den eigentlichen Arbeitsschritten (den Aktivitäten) statt.
Zur näheren Beschreibung können nach BPMN Annotationen verwendet werden (siehe oben die Beschriftungen).
Ereignisse haben häufig einen Auslöser (trigger) und ein Ergebnis (result).
Alle Geschäftsprozesse beginnen und enden mit einem Ereignis, jedoch können Start- und Endereignis auch implizit aus dem Diagramm hervorgehen: Laut Standard (BPMN 2.0.2) sind sie optional, solange ein Prozess gar keine Start- und Endereignisse enthält. Für Kollaborationsdiagramme in Ausbildung und Prüfung zeichnest Du sie aber immer ein (siehe Syntaxregeln für BPMN-Kollaborationsdiagramme).
Aktivitäten
Aktivitäten repräsentieren Arbeit, die während eines Geschäftsprozesses erledigt wird. Wenn eine Aktivität aus einer einzelnen, nicht weiter teilbaren Aufgabe besteht (atomic activity), spricht man von Tasks. Wenn Aktivitäten aus zusammengesetzten Aufgaben (compound activity) bestehen, spricht man von Subprozessen (Sub-Process).
Subprozesse können in kompakter Form dargestellt werden (collapsed sub-process), dann wird mit einem Pluszeichen angedeutet, dass die einzelnen Aktivitäten, aus denen sich ein Subprozess zusammensetzt, in einem weiteren Diagramm im Detail dargestellt werden.
Die Unteraktivitäten können aber auch direkt im selben Diagramm innerhalb des Subprozesses dargestellt werden (expanded sub-process):
Gateways
Die Abfolge von Aktivitäten muss nicht immer sequenziell sein, sondern kann verzweigt, zusammenführend oder parallel erfolgen. Das wird im BPMN mit Gateways in Rauten notiert.
Einfache Verzweigung (exklusives Oder)
Eine einfache Verzweigung ist ein exklusives Oder: nur eine der ausgehenden Kanten wird genommen. Die Bedingungen werden an den Kanten notiert, die Raute selbst darf leer sein - oder (besser, weil eindeutiger:) ist mit einem “X” gefüllt.
Sobald einer der an den Kanten genannten Bedingungsausdrücke zutrifft, wird der Pfad dieser Kante genommen und die weiteren Bedingungen nicht mehr geprüft. Häufig werden bei Verzweigungen default-Pfade angegeben: diese Pfade nimmt der Token, sofern keine der Bedingungen als zutreffend ausgewertet wurde. Gekennzeichnet wird der default-Zweig mit einem schrägen Strich auf dem Pfeil (und häufig dem Text “default” statt einer Bedingung) - in obigem Diagramm ist dies an dem rot markierten Pfad zu erkennen. Durch default-Zweige kann verhindert werden, dass bei einfachen Verzweigungen kein Pfad genommen werden kann - und somit der modellierte Ablauf eine Ausnahme (Exception) werfen muss (also so nicht navigierbar ist).
Die alternativen Sequenzflüsse können mit einem weiteren Gateway wieder vereinigt werden (merge, unten grün eingezeichnet) oder direkt mit mehreren eingehenden Kanten in eine Aktivität münden (unten blau eingezeichnet). Es reicht also, wenn an einer eingehenden Kante ein Token anliegt (anders beim UML-Aktivitätsdiagramm: hier müssen an allen eingehenden Kanten Token anliegen, damit die Aktivität gestartet wird).
Parallele Abläufe
Sofern mehrere Aktivitäten parallel ausgeführt werden müssen, wird dies mit dem parallel gateway notiert (eine Raute mit “+”). Die Pfade werden also alle durchlaufen (“Und”-Logik), nicht alternativ. Sobald an allen eingehenden Kanten ein Token anliegt, wird an allen ausgehenden Kanten ein Token erzeugt. Daher kann dieses Gateway sowohl zur Parallelisierung (im Beispiel grün) als auch zur Synchronisierung (im Beispiel blau) verwendet werden:
Inklusive Abläufe
Sofern mehrere parallele Aktivitäten möglich, aber nicht zwingend erforderlich sind, kommt ein inklusives Gateway ins Spiel: bei dieser Art Verzweigung werden die Bedingungen an allen ausgehenden Kanten geprüft und überall, wo sie zutreffen, wird ein Token gefeuert. Das Gateway wird als Raute mit einem Kreis dargestellt (im folgenden Diagramm gelb hervorgehoben):
Da es in diesem Fall wieder dazu kommen kann, dass die Bedingung an keiner ausgehenden Kante zutrifft (womit das BPMN dort nicht navigierbar wäre), ist zu empfehlen, wieder einen default-Pfad zu kennzeichnen (Strich durch den Pfeil, hier rot hervorgehoben). Dieser Pfad wird gewählt, sofern von keinem anderen Pfad die Bedingung zutrifft.
Ereignis-basierte Verzweigungen
Bisher haben wir anhand von Bedingungen entschieden, welcher Pfad genommen wird (exklusive und inklusive Verzweigungen). Darüber hinaus besteht die Möglichkeit, diese Entscheidung durch Eintreten unterschiedlicher Events zu treffen. Die Bedingungen sind häufig an interne Prozessdaten geknüpft, wohingegen Ereignisse häufig von außen auf einen Geschäftsprozess treffen.
Im untenstehenden Beispiel wird die Bearbeitung des Angebots abhängig davon weitergeführt, ob ein Auftrag eingeht (message intermediate event, grün gekennzeichnet) oder das Angebot abgelaufen ist (timer intermediate event, hier blau gekennzeichnet). Das Gateway selbst wird durch ein in einen Doppelkreis eingefasstes Fünfeck in der Gateway-Raute notiert (hier lila gekennzeichnet). Alle folgenden Events müssen als Zwischenereignisse (intermediate events) ebenso in einen Doppelkreis eingefasst sein.
Sequenz- und Nachrichtenfluss
In der Informatik unterscheiden wir häufig Kontrollfluss und Datenfluss (beispielsweise im UML-Aktivitätsdiagramm). Im BPMN wird die Reihenfolge von Aktivitäten mit dem Sequenzfluss (sequence flow) abgebildet: die Token, die kennzeichnen, welche Aktivität gerade ausgeführt wird, bewegen sich in der Richtung der Sequenzflusspfeile (durchgezogene Linien, gefüllte Pfeilspitze). Die Entsprechung im Programmablaufplan und UML-Aktivitätsdiagramm wäre der Kontrollfluss.
Innerhalb eines Geschäftsprozesses kommt es auch zu Nachrichtenflüssen (message flow) zwischen den Teilnehmern. Der Nachrichtenfluss wird mit gestrichelten Linien, einem kleinen Kreis am Anfang und nicht ausgefüllter Pfeilspitze dargestellt.
Einige Beispiele für Nachrichtenflüsse sind im Diagramm des folgenden Abschnitts farblich hervorgehoben.
Nachrichten können mit einem Message Start Event (unten gelb hervorgehoben) empfangen werden, das markiert den Beginn eines Prozesses. Innerhalb eines Prozesses können sie mit einem Catch-Message-Intermediate-Event (unten grün hervorgehoben) empfangen werden - der Prozess pausiert dann, bis die Nachricht eintrifft. Das gleiche Verhalten kann mit einem Receive Task (Aktivität mit nicht ausgefülltem Briefumschlag, unten blau markiert) erzielt werden.
Nachrichten senden kann man unter anderem mit einem Send Task (Aktivität mit ausgefülltem Briefumschlag, unten lila hervorgehoben), einem Throw-Message-Intermediate-Event (im Kreis, lila) oder einem Throw-Message-End-Event (im Kreis, rot).
Verantwortlichkeiten mit Swimlanes und Pools
Wenn an einem Geschäftsprozess mehrere Teilnehmer zusammenarbeiten, können diese Rollen, Teilnehmer oder Verantwortlichkeiten grafisch mit Pools oder Lanes abgebildet werden.
Ein Pool stellt hierbei einen Bereich dar, innerhalb dessen ein Geschäftsprozess abläuft. Es gibt keinen Sequenzfluss über die Poolgrenzen hinaus. Die gesamte Verantwortlichkeit eines Prozesses liegt innerhalb des Pools. Sollte Interaktion mit anderen Rollen/Verantwortlichkeiten außerhalb des Pools nötig sein, so wird dies über Nachrichtenflüsse dargestellt. Ein Geschäftsprozess kann sich auf mehrere Lanes (hier: Fachabteilung, Buchhaltung) aufteilen, findet aber immer innerhalb eines Pools (hier: Dienstleister) statt.
Die Interaktion zwischen Pools kann als Blackbox dargestellt werden, ohne dass der gegenüberliegende Geschäftsprozess bekannt ist (siehe oben: Customer-Relationship-Datenbank) oder kann unmittelbar an Aktivitäten des Geschäftsprozesses eines anderen Pools andocken (siehe Kunde).
Datenobjekte, Zeitereignisse und das Zusammenspiel mehrerer Pools
Im folgenden Beispiel kommen weitere häufig genutzte Elemente zusammen:
Datenobjekt (Blatt mit Eselsohr): Information, die eine Aktivität liest oder erzeugt, z. B. die Bestellung. Datenobjekte sind über gepunktete Linien (Datenassoziation) mit Aktivitäten verbunden.
Datenspeicher (Zylinder): dauerhaft gespeicherte Daten, die den Prozess überdauern, z. B. die Warenwirtschaft oder eine Datenbank.
Zeitereignis (Uhr im Kreis): als Startereignis („jeden Sonntag 1:00 Uhr“) oder als Zwischenereignis („3 Tage warten“, „Frist abgelaufen“).
Nachrichtenereignis (Briefumschlag): Ein leerer Umschlag empfängt (catch), ein ausgefüllter sendet (throw). Sende- und Empfangsaufgaben tragen das Umschlagsymbol in der Aktivität.
Zugeklappter Pool (Blackbox): Die Kundin oder der Kunde ist beteiligt, ihr interner Ablauf interessiert aber nicht. Nachrichtenflüsse enden dann am Rand des Pools.
Teilprozess (Aktivität mit „+“): fasst einen ausführlich an anderer Stelle modellierten Ablauf zusammen.
Syntaxregeln für BPMN-Kollaborationsdiagramme
Damit ein BPMN-Modell eindeutig lesbar ist, gelten unter anderem diese Regeln:
Jeder Prozess beginnt mit mindestens einem Startereignis und endet mit mindestens einem Endereignis.
Jeder beteiligte Teilnehmer (Organisation, Rolle, System) bekommt einen beschrifteten Pool; Verantwortlichkeiten innerhalb eines Pools werden auf beschriftete Lanes verteilt.
Sequenzflüsse verbinden nur Elemente innerhalb desselben Pools; über Poolgrenzen hinweg gibt es ausschließlich Nachrichtenflüsse.
Nachrichtenflüsse verbinden nie zwei Elemente desselben Pools.
Aktivitäten werden mit Substantiv + Verb benannt („Bestellung prüfen“), Ereignisse beschreiben einen Zustand („Bestellung eingegangen“).
An verzweigenden Gateways stehen eindeutige Bedingungen an den ausgehenden Flüssen; parallele Zweige werden mit einem parallelen Gateway wieder zusammengeführt.
Nach einem ereignisbasierten Gateway folgen nur Zwischenereignisse (bzw. Empfangsaufgaben); der Pfad des zuerst eintretenden Ereignisses wird genommen.
Der Fluss verläuft einheitlich von links nach rechts.
Prozessmodelle auswerten: Häufigkeiten und Zeitbedarf
Ist im Modell angegeben, wie häufig ein Pfad genommen wird und wie lange eine Aktivität dauert, kannst Du den Aufwand eines Prozesses abschätzen. Die Häufigkeit eines Pfades ist das Produkt aus der Anzahl der Prozessdurchläufe und den Anteilen aller Gateways auf dem Weg dorthin.
Beispiel: Eine Fahrradwerkstatt erhält 1.200 Reparaturaufträge im Monat. Bei 30 % davon werden Ersatzteile gebraucht, und 20 % dieser Teile sind nicht am Lager und müssen bestellt werden (8 Minuten je Bestellung).
1200 \cdot 0{,}30 \cdot 0{,}20 = 72 \text{ Bestellungen pro Monat} \quad \Rightarrow \quad 72 \cdot 8\ \mathrm{min} = 576\ \mathrm{min} = 9\ \mathrm{h}\ 36\ \mathrm{min}
Vergleichst Du ein Ist- mit einem Soll-Modell, multiplizierst Du die Häufigkeit mit den Zeiten der Aktivitäten, die wegfallen oder sich ändern. Typische Ansatzpunkte für einen besseren Soll-Prozess sind:
Medienbrüche vermeiden (Daten werden ausgedruckt und wieder abgetippt),
doppelte Datenhaltung und Mehrfacherfassung abschaffen (eine zentrale Datenbank),
Tätigkeiten parallelisieren statt nacheinander auszuführen,
Wartezeiten und Rückfragen durch vollständige Formulare und automatische Prüfungen verringern,
Ausnahmefälle zwar berücksichtigen, aber nicht so ausführlich modellieren, dass der Normalfall untergeht.
EPK und BPMN im Vergleich
Wer beide Notationen kennt, kann je nach Zweck die passende wählen. Die Elemente und Regeln der EPK sind im Artikel Geschäftsprozesse mit der Ereignisgesteuerten Prozesskette (EPK) modellieren erklärt.
| Merkmal | EPK | BPMN |
|---|---|---|
| Leserichtung | von oben nach unten | meist von links nach rechts |
| Ereignisse | zwingend, wechseln sich mit Funktionen ab | Start- und Endereignisse, Zwischenereignisse nur bei Bedarf |
| Verzweigungen | Konnektoren (Kreise) ∧, ∨, XOR | Gateways (Rauten) mit +, O, X und ereignisbasiert |
| Beteiligte | Organisationseinheiten an den Funktionen | Pools und Lanes |
| Zusammenarbeit mehrerer Organisationen | nur über Prozesswegweiser | Nachrichtenflüsse zwischen Pools |
| Daten | Informationsobjekte (eEPK) | Datenobjekte und Datenspeicher |
| Standardisierung | etablierte Konvention (ARIS), keine internationale Norm | OMG-Standard BPMN 2.0.2, ISO/IEC 19510 |
| Detailtiefe | eher fachliche Übersicht; wird bei vielen Ereignissen schnell lang | sehr fein bis zur Ausführung in Workflow-Engines |
Neben EPK und BPMN gibt es weitere Darstellungen von Abläufen:
UML-Aktivitätsdiagramm: Aktionen mit Kontroll- und Objektfluss, auch mit Swimlanes; stammt aus der Softwareentwicklung und stellt Objektknoten ausdrücklich dar.
Programmablaufplan (PAP) und Struktogramm: beschreiben Algorithmen, keine Zuständigkeiten oder Nachrichten zwischen Beteiligten.
Wertschöpfungskettendiagramm (WKD): grobe Übersicht der Hauptprozesse als Pfeilsymbole, ohne Verzweigungen und Ereignisse.
Swimlane- oder Blockdiagramm: Tätigkeiten in Spalten je Beteiligten, meist ohne genormte Ereignisse.
Weitere Notationen
Der BPMN-Standard umfasst über 500 Seiten - entsprechend viele weitere Notationsmittel gibt es. Darüber hinaus kann BPMN noch erweitert werden und so an die Bedürfnisse der Institutionen angepasst werden. Die hier genannten Notationsmittel stellen also nur einen ersten Einblick in die Fülle dar, wie Prozesse mit BPMN modelliert und dokumentiert werden können.
Da die Symbolik weitgehend selbsterklärend ist, sollte dieser Einblick trotzdem reichen, um bestehende BPMN richtig zu interpretieren, anhand des Standards weitere Notationsmittel verstehen oder einfache BPMN selbst erstellen zu können.
Tools zur Erstellung von BPMN
Zur Erstellung eigener BPMN eignen sich u. a. die Online-Tools:
Auch draw.io / diagrams.net bietet die Möglichkeit, die BPMN-Notationselemente zu zeichnen; dort gibt es auch eine Symbolbibliothek für EPK.
Professionelle Tools zur Erstellung von BPMN sind beispielsweise:
Leitfragen
- Warum werden Geschäftsprozesse grafisch und mit einer normierten Notation dargestellt?
Ein Modell zeigt den Ablauf, Schnittstellen und Verantwortlichkeiten auf einen Blick, erleichtert Einarbeitung und Optimierung und ist eine gemeinsame Sprache von Fachabteilung und IT. Eine Norm legt die Bedeutung der Symbole fest, sodass das Modell nicht unterschiedlich interpretiert wird. siehe Abschnitt „Warum Geschäftsprozesse grafisch und normiert darstellen?“
- Wie unterscheiden sich Sequenzfluss und Nachrichtenfluss in BPMN?
Der Sequenzfluss (durchgezogener Pfeil) legt die Reihenfolge innerhalb eines Pools fest; der Nachrichtenfluss (gestrichelt, mit Kreis und offener Spitze) verbindet ausschließlich verschiedene Pools. siehe Abschnitt „Sequenz- und Nachrichtenfluss“
- Welche Syntaxregeln gelten für BPMN-Kollaborationsdiagramme?
Unter anderem: Start- und Endereignis je Prozess, beschriftete Pools und Lanes, Sequenzflüsse nur innerhalb eines Pools, zwischen Pools nur Nachrichtenflüsse, eindeutige Bedingungen an Gateways, Aktivitäten als Substantiv + Verb. siehe Abschnitt „Syntaxregeln für BPMN-Kollaborationsdiagramme“
- Wie ermittelst Du aus einem BPMN-Modell, wie oft ein Pfad durchlaufen wird?
Du multiplizierst die Anzahl der Prozessdurchläufe mit den Anteilen aller Gateways auf dem Weg zu diesem Pfad; mit der Dauer der Aktivitäten ergibt sich der Zeitbedarf. siehe Abschnitt „Prozessmodelle auswerten: Häufigkeiten und Zeitbedarf“
- Nenne zwei Unterschiede zwischen EPK und BPMN.
Zum Beispiel: Die EPK verlangt nach jeder Funktion ein Ereignis, BPMN nur Start- und Endereignisse; die EPK ordnet Organisationseinheiten den Funktionen zu, BPMN nutzt Pools und Lanes; EPK wird von oben nach unten, BPMN meist von links nach rechts modelliert. siehe Abschnitt „EPK und BPMN im Vergleich“
Links und weitere Informationen
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Geschäftsprozesse mit BPMN modellieren” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/bpmn veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/betriebswirtschaft/geschaeftsprozesse. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
