Was ist BPMN? Notation, Zweck und was BPMN ausdrücklich nicht ist

BPMN steht für Business Process Model and Notation. Es ist eine Notation, kein Werkzeug und kein Produkt: ein festgelegter Satz von Symbolen, mit dem ein Geschäftsprozess so aufgezeichnet wird, dass Fachbereich und IT dasselbe Bild lesen. Standardisiert wird sie von der Object Management Group, und die aktuelle formale Version ist 2.0.2 aus dem Januar 2014.

Der Punkt, an dem BPMN sich von jedem anderen Flussdiagramm unterscheidet, steht in der Zusammenfassung der Spezifikation selbst: Es soll direkt von den Menschen benutzt werden können, die Prozesse entwerfen und verantworten, und trotzdem präzise genug sein, damit eine Maschine es ausführen kann. Beides gleichzeitig. Daran hängt alles Weitere.

Wer standardisiert BPMN, und welche Version gilt?

Die Object Management Group, ein Standardisierungskonsortium, das auch UML verantwortet. Die formale Versionsgeschichte steht auf der Spezifikationsseite (omg.org/spec/BPMN/2.0.2).

Seit Januar 2014 keine neue formale Version: Das klingt nach einem toten Standard und ist das Gegenteil: BPMN 2.0 ist der seltene Fall einer Spezifikation, die sich nicht mehr bewegen muss, weil die Werkzeuge sie eingeholt haben. Für Sie heißt das, dass ein Modell von 2015 heute noch geöffnet und ausgeführt werden kann.

Was BPMN ist: ein Bild und eine Datei, zur gleichen Zeit

Die Object Management Group formuliert den Anspruch so: „Business Process Model and Notation has become the de-facto standard for business processes diagrams. It is intended to be used directly by the stakeholders who design, manage and realize business processes, but at the same time be precise enough to allow BPMN diagrams to be translated into software process components. BPMN has an easy-to-use flowchart-like notation that is independent of any particular implementation environment.“

In diesem Absatz stecken drei Zusagen, und sie sind der ganze Grund, warum BPMN in Unternehmen benutzt wird.

• Es ist für den Fachbereich lesbar. Wer den Prozess verantwortet, soll das Diagramm ohne Übersetzer verstehen. Ein Kästchen ist eine Aufgabe, ein Pfeil ist der nächste Schritt.
• Es ist präzise genug für Software. Jedes Symbol hat eine definierte Bedeutung, deshalb kann ein Programm daraus ableiten, was als Nächstes passiert.
• Es ist herstellerunabhängig. Die Notation hängt an keiner bestimmten Implementierungsumgebung. Die Spezifikation liefert dazu ein XML-Schema, BPMN20.xsd, als Austauschformat.

Die dritte Zusage ist die, an der sich in Migrationsprojekten entscheidet, wie teuer ein Wechsel wird. Und sie gilt in der Praxis nur für die Teile des Modells, die tatsächlich aus dem Standard stammen. Dazu gleich mehr.

Was BPMN ausdrücklich nicht ist

Diese Liste erspart mehr Missverständnisse als jede Symbolübersicht.

• Kein Datenmodell. BPMN zeigt, dass Daten fließen, nicht wie sie strukturiert sind. Wer sein Datenmodell in BPMN aufzeichnet, malt ein zweites, unvollständiges Schema.
• Kein Organigramm. Bahnen und Rollen zeigen Zuständigkeit im Prozess, nicht die Hierarchie des Unternehmens.
• Kein Projektplan. Es gibt keine Termine, keine Dauer und keine Ressourcenplanung im Modell.
• Keine Regelsprache. Für Entscheidungslogik gibt es einen eigenen Standard derselben Organisation, DMN. Entscheidungstabellen gehören dorthin, nicht in eine Kette von Gateways.
• Kein ausführbares Programm. Ein gültiges BPMN-Diagramm läuft nicht, nur weil es gültig ist. Es fehlen genau die Angaben, die niemand sehen will: welcher Dienst hinter einer Aufgabe steht, was bei einem Fehler passiert, wie lange gewartet wird.

Der Unterschied zwischen einem Diagramm, das dokumentiert, und einem, das läuft

Ein Diagramm, das dokumentiert, darf ungenau sein. Ein Diagramm, das läuft, darf es nicht, und die Stellen, an denen das auffällt, sind immer dieselben: Was passiert, wenn der aufgerufene Dienst nicht antwortet? Was passiert, wenn zwei Pfade gleichzeitig zurückkommen? Wie lange wartet der Prozess auf eine Unterschrift, und was tut er danach?

Diese Angaben stehen nicht in der Notation, sondern in herstellerspezifischen Erweiterungen des BPMN-XML. Bei Camunda 7 ist das der Namensraum camunda:. Er ist der Grund, warum ein Modell „reines BPMN“ sein kann und trotzdem nicht ohne Weiteres in einem anderen Produkt läuft, und er ist einer der Posten, die eine Migration teuer machen. Camunda 7 setzt den BPMN-2.0-Elementumfang breit um, von Service-, Send-, User- und Business-Rule-Tasks bis zu den Gateway-Typen (docs.camunda.org, Implemented Standards).

Wenn Sie an dieser Stelle wissen wollen, welche Engine hinter Ihrem Modell steht und was das für Sie bedeutet: Was ist Camunda? beantwortet das in fünf Minuten.

Die drei Symbole, über die in der Praxis tatsächlich gestritten wird

Nicht die exotischen. Die Gateways, also die Rauten, an denen sich der Weg teilt. Sie sehen sich ähnlich und bedeuten Verschiedenes, und die Verwechslung ist der häufigste Grund, warum ein Prozess in Produktion anders läuft als im Workshop besprochen.

Als Faustregel für ein Modell, das laufen soll: Jede Teilung mit demselben Typ wieder zusammenführen, und an jedem exklusiven und jedem inklusiven Gateway einen Standardpfad setzen. Das sind zwei Regeln, und sie verhindern die Mehrheit der Fälle, in denen eine Instanz hängen bleibt oder mit einer Ausnahme abbricht.

Wenn Ihr Bestand bereits auf Camunda 7 läuft, ist die dringlichere Frage die nach den Wartungsterminen. Die vollständige Matrix je Version steht in Camunda 7: Wartungsende je Version.