„Schön“ klingt nach Geschmack, und über Geschmack lässt sich bekanntlich streiten. Bei Prozessmodellen ist das ein Missverständnis. Die Frage ist nie, ob ein BPMN-Diagramm hübsch aussieht, sondern ob es das tut, wofür es gemacht ist: einen Prozess so darzustellen, dass eine Fachexpertin und ein Entwickler ihn gleichermassen verstehen — und zwar identisch. Ein Diagramm, das diese Verständigung nicht leistet, ist nicht „unschön“. Es ist wirkungslos.
Der wichtigste Beitrag zur Frage, wie man das erreicht, trägt einen Namen: Method & Style. Und das Bemerkenswerte ist: Wo Bruce Silver diese Konventionen aus jahrelanger Modellierungs- und Schulungspraxis destilliert hat, ist die akademische Prozessforschung wenige Jahre später unabhängig zu fast denselben Schlüssen gekommen. Wenn Handwerk und Empirie sich treffen, lohnt es sich hinzuschauen.
BPMN kann fast alles — und genau das ist das Problem
BPMN 2.0 ist seit 2011 ein Standard der Object Management Group und seit 2013 zusätzlich als ISO/IEC 19510 normiert. Die Spezifikation umfasst mehrere hundert Seiten und definiert ein grosses Vokabular: verschiedene Aufgabentypen, über ein Dutzend Ereignistypen, mehrere Gateway-Arten, Pools, Lanes, Nachrichtenflüsse, Datenobjekte und vieles mehr.
Diese Ausdrucksstärke ist Segen und Fluch zugleich. Man kann fast jeden Sachverhalt modellieren — und man kann denselben Sachverhalt auf viele Arten modellieren, von denen die meisten schwer zu lesen sind. Der Standard definiert Syntax, nicht Stil: Er sagt, was erlaubt ist, nicht, was verständlich ist. Ein Modell kann vollkommen normkonform und trotzdem für jeden Menschen ausser seinem Autor unlesbar sein.
Genau diese Lücke — zwischen „formal gültig“ und „für Menschen verständlich“ — füllt Method & Style.
Method & Style: eine Methode und ein Stil
Der Name ist Programm und besteht bewusst aus zwei Teilen.
Der Stil ist ein Satz von Konventionen, die ein Diagramm selbsterklärend machen. Silvers Leitprinzip lautet, dass die Prozesslogik allein aus dem ausgedruckten Diagramm verständlich sein soll — ohne begleitendes Dokument, ohne mündliche Erklärung des Modellierers. Denn der eigentliche Wert von BPMN liegt darin, eine gemeinsame Sprache zwischen Fachbereich und IT zu sein; diesen Wert realisiert nur ein Diagramm, das der Fachbereich tatsächlich lesen kann. Zu den zentralen Stilregeln gehören:
- Aktivitäten im Verb-Objekt-Stil: „Antrag prüfen“, nicht „Prüfung“. Ein Verb-Objekt-Label sagt, wer was tut; eine Nominalisierung verschleiert es.
- Gateways als Fragen, Ausgänge als Antworten: ein datenbasiertes exklusives Gateway wird mit einer Frage beschriftet („Antrag vollständig?“), seine Ausgänge mit den möglichen Antworten.
- Endereignisse als benannte Endzustände: Jeder distinkte Ausgang eines Prozesses bekommt ein eigenes, beschriftetes Endereignis, damit alle möglichen Ergebnisse auf einen Blick sichtbar sind.
- Ein Detaillierungsgrad pro Ebene: Haupt- und Detailfluss werden nicht im selben Diagramm vermischt; Komplexität wandert in Teilprozesse, die man aufklappt.
- Hierarchische Vollständigkeit: Ein Teilprozess muss sich zu einem in sich gültigen Kindprozess ausklappen lassen — die Ebenen bleiben konsistent.
Der Methoden-Teil ergänzt den Stil um ein Vorgehen: top-down und ergebnisorientiert. Man modelliert zuerst den „Happy Path“ — den störungsfreien Normalverlauf vom Auslöser zum gewünschten Ergebnis — und fügt erst danach die Ausnahmen und Sonderpfade hinzu. So entsteht ein Gerüst, an dem die Vollständigkeit überprüfbar wird: Für jeden Endzustand lässt sich fragen, ob es einen Weg dorthin gibt, und für jeden Pfad, wo er endet.
Silver ordnet das Ganze in Detaillierungs-Ebenen ein — von einer deskriptiven Ebene für die fachliche Verständigung bis zu einer ausführungsnahen Ebene, die genug Präzision für die Automatisierung enthält. Method & Style ist damit kein Selbstzweck, sondern der rote Faden vom lesbaren Fachmodell zum umsetzbaren Prozess.
Zwei Wege, ein Ziel: als Praxis und Forschung sich trafen
Das Überzeugende an diesen Konventionen ist, dass sie nicht die private Vorliebe eines Autors sind. Um 2009 bis 2011 entstanden zwei unabhängige Stränge, die zu erstaunlich ähnlichen Empfehlungen kamen.
Der eine ist Silvers BPMN Method and Style, aus der Modellierungs- und Schulungspraxis heraus formuliert und mittlerweile auch in einer deutschsprachigen Ausgabe verfügbar, die die Konventionen im DACH-Raum zugänglich gemacht hat.
Der andere ist die empirische Prozessmodell-Forschung, prominent zusammengefasst in den Seven Process Modeling Guidelines (7PMG) von Jan Mendling, Hajo Reijers und Wil van der Aalst (Information and Software Technology, 2010). Ihre Besonderheit: Sie sind aus der Analyse grosser Modellsammlungen abgeleitet, in denen sich Strukturmerkmale mit gemessenen Fehlerwahrscheinlichkeiten verknüpfen liessen. Die sieben Leitlinien, verkürzt:
1. G1 — so wenige Elemente wie möglich (Modellgrösse ist der stärkste Einzeltreiber für Fehler). 2. G2 — Routing-Pfade pro Element minimieren. 3. G3 — so wenige Start- und Endereignisse wie möglich. 4. G4 — so strukturiert wie möglich modellieren (jeder Split hat einen passenden Join). 5. G5 — OR-Gateways vermeiden. 6. G6 — Aktivitäten im Verb-Objekt-Stil beschriften. 7. G7 — Modelle mit mehr als ca. 30–50 Elementen zerlegen.
Man halte das neben die Stilregeln oben: Verb-Objekt-Beschriftung (G6) deckt sich exakt; „ein Detaillierungsgrad pro Ebene“ und Dekomposition entsprechen G1 und G7; strukturiertes Modellieren ist G4. Eine gesonderte Studie derselben Forschungsrichtung — Mendling, Reijers und Recker, Activity labeling in process modeling (Information Systems, 2010) — hat den Beschriftungsstil sogar isoliert untersucht und den Verb-Objekt-Stil als signifikant verständlicher und eindeutiger belegt. Dass eine Praktiker-Kodifizierung und eine empirische Fehleranalyse unabhängig voneinander zu denselben Regeln finden, ist in diesem Feld etwa so nah an einem Beweis, wie man kommt.
Ehrlicherweise gibt es einen dokumentierten Unterschied: 7PMG rät (G3), Endereignisse zu minimieren, während Method & Style jeden distinkten Endzustand explizit darstellt. Das ist kein Widerspruch aus Nachlässigkeit, sondern ein bewusster Zielkonflikt — Reduktion der Komplexität gegen Explizitheit der Ergebnisse. Method & Style gewichtet hier die Kommunikation: Ein Prozess, dessen mögliche Ausgänge man nicht auf einen Blick sieht, ist fachlich schwerer zu validieren. Beide Seiten sind sich einig, dass ein Endereignis etwas bedeuten muss und nicht dekorativ sein darf. Wer den Konflikt kennt, entscheidet bewusst — und das ist der Kern guter Modellierung.
Ein Beispiel — zwei Modelle
Theorie wird an einem Beispiel greifbar. Nehmen wir einen Genehmigungsprozess, der etwas realistischer ist als ein Lehrbuchpfeil: Ein Antrag geht ein, wird auf Vollständigkeit geprüft, bei Bedarf werden Unterlagen nachgefordert, danach wird fachlich entschieden — mit mehr als nur „ja/nein“ als Ergebnis.
Modell A — so, wie es unter Zeitdruck oft entsteht:
Formal ist daran nichts „falsch“ — und doch trägt es fast jede vermeidbare Sünde: ein unbenannter Auslöser; nominalisierte Label („Antragsbearbeitung“, „Prüfung“), die offenlassen, wer was tut; ein Gateway ohne Frage und mit unbeschrifteten Ausgängen, sodass die Verzweigungslogik unsichtbar bleibt; eine Rückwärtskante ohne erkennbare Bedingung; und ein einziges, generisches „Ende“, das verbirgt, ob der Antrag genehmigt oder abgelehnt wurde. Wer dieses Diagramm einem Fachbereich vorlegt, bekommt keine Validierung, sondern Rückfragen.
Modell B — dasselbe fachliche Anliegen, nach Method & Style:
Der Auslöser ist benannt, die Aktivitäten sind Verb-Objekt, beide Verzweigungen sind Fragen mit beschrifteten Antworten, die Vollständigkeitsschleife ist als solche erkennbar — und vor allem sind alle drei möglichen Ergebnisse als eigene Endzustände sichtbar. Ebenso wichtig ist, was nicht im Diagramm steht: „Antrag fachlich prüfen“ ist als Teilprozess dargestellt, nicht in seine Einzelschritte aufgelöst. Das Hauptdiagramm bleibt auf einer Ebene und damit lesbar; die Detailtiefe wandert eine Ebene tiefer. Genau das meint Silver mit „ein Detaillierungsgrad pro Ebene“ — und es ist der Grund, warum ein gut geschnittenes Top-Level-Diagramm mit einer Handvoll Hauptaktivitäten auskommt statt mit fünfzig Kästchen. Jede einzelne Änderung von Modell A zu Modell B ist eine der genannten Stilregeln in Aktion, und jede hat in den 7PMG ihr empirisches Echo.
Vom lesbaren Modell zum Rest des Lebenszyklus
Der Nutzen endet nicht beim Verständnis. Ein Method-&-Style-konformes Modell ist nicht nur heute lesbar, sondern auch in einem Jahr, wenn jemand anders es ändern muss. Seine Explizitheit — benannte Endzustände, strukturierter Fluss, saubere Dekomposition — ist zugleich die Voraussetzung dafür, es zuverlässig in ausführbaren Code zu übersetzen, gegen Szenarien zu testen und später zu optimieren. Mehrdeutigkeit, die man im Diagramm nicht sieht, taucht spätestens in der Umsetzung wieder auf — teurer. Die „halbe Miete“ für den gesamten Lebenszyklus wird in der Modellierung bezahlt.
Der Engpass sitzt früher, als man denkt
Wenn all das so gut belegt ist: Warum sind unlesbare Modelle trotzdem verbreitet? Es gibt zwei Gründe, und der zweite ist der unterschätzte.
Der erste ist Disziplin unter Zeitdruck. Das unbenannte Gateway, der implizite Endzustand, die Aktivität, die eigentlich zwei sind — jede Einzelsünde ist harmlos, in Summe entsteht Modell A.
Der zweite, tieferliegende Grund wird gelegt, bevor das erste Kästchen gezeichnet ist: Zuschnitt und Granularität. Wer zu modellieren beginnt, ohne zu wissen, wo der Prozess anfängt und aufhört und auf welcher Ebene er beschrieben wird, produziert Wildwuchs — ein Diagramm, das mehrere Detailebenen vermischt und ins Uferlose wächst. Dagegen hilft kein noch so sauberer Stil im Nachhinein; es verletzt die 7PMG-Leitlinien G1 und G7 (wenige Elemente, dekomponieren) und Silvers „ein Detaillierungsgrad pro Ebene“ schon im Ansatz. Method & Style setzt die richtige Granularität voraus — es stellt sie nicht selbst her.
Genau hier setzt MESTRO an, und zwar an beiden Enden.
Die Voraussetzung: der Überbau aus der Analyse-Phase. Bevor überhaupt ein Diagramm entsteht, zerlegt MESTRO in der Analyse-Phase die Prozesslandschaft in klar abgegrenzte End-to-End-Prozesse und strukturiert jeden davon in typischerweise fünf bis zehn Hauptaktivitäten. Das ist keine Kosmetik, sondern exakt der Zuschnitt, den Method & Style voraussetzt: ein Top-Level-Prozess, der auf eine Ebene und auf eine Seite passt, mit einer überschaubaren Zahl von Hauptaktivitäten, die jede für sich Kandidatin für eine eigene Detailebene ist — so wie „Antrag fachlich prüfen“ im Beispiel oben. Die Leitlinien „wenige Elemente“, „ein Detaillierungsgrad pro Ebene“ und „dekomponieren“ sind damit durch Konstruktion erfüllt, nicht durch Willenskraft am Ende eines langen Tages. Der Überbau liefert die tragfähige Struktur, bevor der Stil sie lesbar macht.
Die Umsetzung: konformer Output als Voreinstellung. Auf dieser Grundlage erzeugt MESTROs KI-gestützte Modellierung die Diagramme selbst nach Method & Style — Gateways als Fragen, Verb-Objekt-Aktivitäten, benannte Endzustände — und weist auf Stilverstösse hin, statt sie stillschweigend durchzuwinken. Was beim Menschen bleibt, ist die fachliche Entscheidung; was die Maschine übernimmt, ist die stumpfe Disziplin.
So werden die beiden schwierigsten Teile von Method & Style zugleich adressiert: die vorgelagerte strukturelle Urteilskraft — richtiger Zuschnitt, richtige Granularität — und die laufende Konsequenz, jede Konvention bei jedem Modell einzuhalten. Das ist der Grund, warum ein durchgängiges Werkzeug hier mehr beiträgt als ein reines Zeichenprogramm: Es macht aus einer gut belegten Best Practice eine, die auch unter realen Bedingungen eingehalten wird.
Fazit
Lesbarkeit in BPMN ist keine Geschmacksfrage. Method & Style hat die Konventionen benannt, die aus einem mächtigen, aber stilneutralen Standard ein echtes Verständigungsmittel machen — und die empirische Forschung hat unabhängig bestätigt, dass genau diese Konventionen mit weniger Fehlern und besserem Verständnis einhergehen. Wer in sie investiert, spart nicht am falschen Ende, sondern legt das Fundament für alles, was danach kommt: Validierung, Umsetzung, Test, Optimierung. Ein Diagramm, das Menschen verstehen, ist nicht der schöne Schein eines Prozesses. Es ist der Beweis, dass er verstanden wurde.
Autoren-Hinweis: Die deutschsprachige Ausgabe von BPMN Method and Style wurde von Stephan Fischli mitgestaltet und übersetzt — Method & Style ist damit auch im deutschen Sprachraum verankert.
Quellen & Weiterlesen
- B. Silver: BPMN Method and Style, 2. Auflage, Cody-Cassidy Press, 2011. https://methodandstyle.com/
- B. Silver / S. Fischli: BPMN Methode & Stil, Zweite Auflage — deutschsprachige Ausgabe mit Handbuch zur Prozessautomatisierung, Cody-Cassidy Press. Zur deutschen Ausgabe
- J. Mendling, H. A. Reijers, W. M. P. van der Aalst: Seven process modeling guidelines (7PMG). Information and Software Technology 52(2), 2010, S. 127–136.
- J. Mendling, H. A. Reijers, J. Recker: Activity labeling in process modeling: Empirical insights and recommendations. Information Systems 35(4), 2010, S. 467–482.
- Object Management Group: Business Process Model and Notation (BPMN) Version 2.0.2, 2013. https://www.omg.org/spec/BPMN/2.0.2/
- ISO/IEC 19510:2013. https://www.iso.org/standard/62652.html
