„Simone, ich verstehe das nicht." Karin klang ratlos am Telefon. „Der Software-Hersteller hat mir nach der BPMN-Schulung eine 12-seitige Modellierungsrichtlinie mitgegeben. Damit sollen wir jetzt arbeiten. Aber ... wozu?"
Ich musste schmunzeln. Karin und ich arbeiten seit Monaten nach dem Giersberg®-Prozessmodell. Ihr kleines Team von drei Prozessverantwortlichen modelliert ihre Geschäftsprozesse – strukturiert, klar und ohne großes Regelwerk.
„Karin," sagte ich, „stell Dir vor, Du schreibst mit drei Freundinnen ein Kochbuch. Ihr kennt Euch gut, sprecht täglich miteinander und habt Euch auf eine klare Struktur geeinigt: Zutaten, Zubereitung, Tipp. Brauchst Du dann ein 50-seitiges Stilhandbuch?"
Pause. Dann: „Aha."
Diese Situation erlebe ich immer wieder: Unternehmen investieren in BPMN-Schulungen und bekommen umfangreiche Modellierungsrichtlinien an die Hand – oft ohne zu verstehen, **wann** sie diese wirklich brauchen. Als Prozessexpertin mit 30 Jahren Erfahrung und über 100 durchgeführten Prozessprojekten kann ich Dir sagen: Eine dicke Richtlinie ist meist ein Symptom, nicht die Lösung.
Der Kontext, um den es hier geht: Die Darstellung der Prozesse in BPMN – also das, was die Mitarbeitenden tun, um Prozessoptimierung voranzutreiben oder das notwendige Prozesswissen für die Einführung eines ERP-Systems wie SAP HANA zu dokumentieren. Ohne klare, einheitliche Prozessdarstellungen wird die erhoffte Transparenz nicht erreicht.
In diesem Artikel zeige ich Dir, wann Modellierungsrichtlinien sinnvoll sind, welche drei Faktoren wirklich über einheitliche Prozessdarstellungen entscheiden – und warum das Giersberg®-Prozessmodell mit einem kleinen, gut abgestimmten Team die elegantere Alternative ist.
TL;DR – AUF DEN PUNKT GEBRACHT
Problem: Unternehmen kämpfen mit unterschiedlichen Prozessdarstellungen, obwohl sie BPMN-Modellierungsrichtlinien nutzen – was Prozessoptimierung und ERP-Einführungen erschwert.
Lösung in 3 Schritten:
1. Klarer Zuschnitt: Schneide einen Geschäftsprozess auf eine Abteilung und ein Abteilungsergebnis zu
2. Definierter Detaillierungsgrad: Stelle einen Geschäftsprozess in BPMN in einem mittleren Detaillierungsgrad dar
3. Kleines, abgestimmtes Team: 3–5 Modellierer:innen, die regelmäßig gemeinsam die Modelle sichten
Erwartetes Ergebnis: Konsistente, verständliche Prozessmodelle ohne 12-seitige Regelwerke 
Lesezeit: 12 Minuten
Warum Modellierungsrichtlinien überhaupt existieren
Eine Modellierungsrichtlinie definiert Standards für die Darstellung von [Geschäftsprozessen](https://prozessoptimierung-sprung.de/was-sind-geschaeftsprozesse-wie-ist-die-definition-des-geschaeftsprozesses/) in BPMN (Business Process Model and Notation). Sie legt fest:
- Welche Symbole verwendet werden (Ereignisse, Aktivitäten, Gateways)
- Wie die Beschriftung der Kästchen erfolgt
- Welcher Detaillierungsgrad (Level of Detail) gewählt wird
- Wie Entscheidungen modelliert werden
Die Idee dahinter: Alle Beteiligten sollen Prozesse gleich verstehen und modellieren. Das klingt vernünftig – besonders wenn Prozessmodelle als Grundlage für Prozessoptimierung oder die Einführung eines ERP-Systems wie SAP HANA dienen [1].
Beispiel aus der Praxis: Das Bundesverwaltungsamt (BVA) stellt „Best Practices der BPMN-Modellierung" bereit, um Informationsaustausch und Verantwortlichkeiten klar zu regeln [2].
Soweit die Theorie.
In der Praxis erlebe ich etwas anderes: Unternehmen haben eine Richtlinie – und trotzdem entstehen völlig unterschiedliche Prozessmodelle. Warum?
AUF DEN PUNKT GEBRACHT
Eine Modellierungsrichtlinie definiert, wie Du modellierst (Symbole, Notation, Beschriftung). Sie löst aber nicht das Problem, was Du modellierst (Prozesszuschnitt, Detaillierungstiefe). Das ist der entscheidende Unterschied.
Das eigentliche Problem: Unklarer Bearbeitungsrahmen
Stell Dir vor, Du bittest fünf Menschen, einen „Apfelkuchen" zu backen. Jede:r nutzt dieselben Küchenutensilien (= BPMN-Symbole). Aber:
- Person A backt einen ganzen Kuchen mit Hefeteig
- Person B macht Apfeltaschen aus Blätterteig
- Person C bereitet nur den Teig vor, jemand anders soll backen
- Person D dokumentiert den gesamten Einkauf mit
Das Problem: Niemand hat gesagt, was genau ein „Apfelkuchen" ist. Wo fängt er an (mit dem Einkauf? Mit dem Teig?)? Wo hört er auf (nach dem Backen? Nach dem Servieren?)? Wie detailliert soll die Beschreibung sein?
Genau das passiert in Unternehmen, wenn der Bearbeitungsrahmen zu groß und unklar ist:
1. Der Zuschnitt eines Geschäftsprozesses bleibt vage
Was gehört zum Prozess „Auftragsabwicklung"? Beginnt er mit der Kundenanfrage oder erst mit der Bestellung? Endet er mit der Auslieferung oder erst mit der Rechnung? Welche Abteilung ist verantwortlich?
Ohne klare Definition, welche Abteilung den Prozess ausführt und welches Abteilungsergebnis entsteht, modelliert jede:r etwas anderes. Hier fehlt eine klare Prozessarchitektur, die den Rahmen vorgibt.
2. Die Detaillierungstiefe ist unkonkret
„Beschreibe die Aktivitäten" – was bedeutet das? Soll ich aufschreiben „Rechnung prüfen" oder „Rechnung in SAP öffnen, Bestellnummer abgleichen, Rechnungsbetrag mit Bestellung vergleichen, Freigabe erteilen"?
Wenn unklar ist, was ein Prozessschritt (ein Aktivitätenkästchen) überhaupt darstellen soll, entstehen Modelle mit völlig unterschiedlichem Zoom-Level.
3. Zu viele Modellierer:innen arbeiten ohne Abstimmung
15 Menschen an drei Standorten modellieren parallel – jede:r mit eigener Interpretation. Eine Richtlinie auf Papier hilft wenig, wenn niemand gemeinsam die Modelle sichtet.
AUF DEN PUNKT GEBRACHT
Die Richtlinie regelt die Oberfläche (Symbole, Farben, Linien).
Sie regelt nicht die Substanz (Was ist ein Prozess? Wie detailliert modellieren wir?).
Das ist wie eine Kleiderordnung ohne Anlass – Du weißt, welche Schuhe erlaubt sind, aber nicht, ob Du auf eine Hochzeit oder zum Sport gehst.
Die Lösung: 3 Tipps für einheitliche Prozessdarstellungen
Aus meiner 30-jährigen Erfahrung mit über 100 Prozessprojekten weiß ich: Einheitliche Prozessdarstellungen entstehen nicht durch dickere Richtlinien, sondern durch klarere Strukturen.
Hier sind die drei Faktoren, die wirklich den Unterschied machen:
Tipp 1: Schneide einen Geschäftsprozess auf eine Abteilung und ein Abteilungsergebnis zu
Jeder Geschäftsprozess braucht klare Grenzen. Das Giersberg®-Prozessmodell schneidet einen Geschäftsprozess auf eine Abteilung und ein Abteilungsergebnis zu.
Was bedeutet das konkret?
- Input: Das auslösende Element, das die Mitarbeitenden mit der Prozessausführung beginnen lässt
- Output: Das Abteilungsergebnis, das am Ende des Prozesses steht
Beispiel: Prozess „Material einkaufen" (Einkaufsabteilung)
- Input: „Bestellanforderung erhalten"
- Output: „Material eingekauft"
Mein Tipp
Name des Prozesses und Output können für die einfache Identifikation ähnlich formuliert werden („Material einkaufen" → „Material eingekauft").
Diese Leitplanken sorgen dafür, dass alle im Team sofort wissen: „Dieser Prozess gehört zur Einkaufsabteilung, beginnt mit einer Bestellanforderung und endet, wenn das Material eingekauft ist."
Warum das so wichtig ist:
Wenn Du für eine ERP-Einführung wie SAP HANA Prozesse dokumentierst, musst Du wissen:
Welche Abteilung nutzt welches SAP-Modul? Wo beginnt der Prozess im System, wo endet er?
Ohne klaren Zuschnitt auf eine Abteilung und ein Ergebnis wird die IT-Spezifikation zur Interpretationssache.
Mehr dazu, wie Du Prozesse richtig identifizierst und strukturierst, erfährst Du in meinem Artikel über Prozess Mapping.
Praxisbeispiel aus meiner Arbeit:
Ausgangslage: Unternehmensgruppe mit fünf Standorten, Lebensmittelproduktion, 300 Mitarbeitende
Problem: Jede Produktionsstätte modelliert den Prozess „Wareneingang" unterschiedlich – manche beginnen beim Lieferanten-Anruf, andere erst beim Entladen, manche enden bei der Einlagerung, andere bei der Buchung im ERP
Fehlentscheidung: Die Zentrale versucht, über eine 12-seitige Richtlinie „einheitliche Prozessgrenzen" vorzuschreiben – ohne zu definieren, welche Abteilung verantwortlich ist
Konsequenz: Die Standorte interpretieren die Richtlinie völlig unterschiedlich. Die Modelle bleiben inkompatibel
Lösung: Wir definieren gemeinsam:
- Prozess: „Wareneingang durchführen" (Logistikabteilung)
- Input: „Lieferung angekündigt"
- Output: „Wareneingang im ERP gebucht"
Ergebnis: Vergleichbare Modelle an allen Standorten, die sich standardisieren lassen – ohne neue Richtlinie.
AUF DEN PUNKT GEBRACHT
Ein Prozess = eine Abteilung = ein Ergebnis.
Diese Formel sorgt für klare Grenzen und verhindert, dass jede:r einen anderen Ausschnitt modelliert. Für Prozessoptimierung und ERP-Einführungen ist das die Basis.
Tipp 2: Stelle einen Geschäftsprozess in BPMN in einem mittleren Detaillierungsgrad dar
„Wie detailliert soll ich modellieren?" – diese Frage höre ich in jedem Projekt. Die übliche Antwort: „So detailliert wie nötig, so grob wie möglich." Das hilft niemandem.
Die Lösung: Behandele jeden Prozessschritt (ein Aktivitätenkästchen) als einen Handlungsstrang, der ein Zwischenergebnis erzeugt.
Beispiel: Prozess „Aufträge abschließen" (Vertriebsaußendienst)
Prozessschritte (Aktivitätenkästchen in BPMN):
- Beratungsgespräch durchführen → Zwischenergebnis: „Kundenbedarf ermittelt"
- Angebot erstellen → Zwischenergebnis: „Angebot liegt vor"
- Auftrag verhandeln → Zwischenergebnis: „Auftrag unterschrieben"
Jedes Kästchen beschreibt einen zusammenhängenden Handlungsstrang mit einem fachlichen Zwischenergebnis. Du modellierst nicht „Kunde anrufen", „Termin vereinbaren", „Präsentation vorbereiten" als einzelne Schritte – das wäre zu detailliert. Du modellierst auch nicht nur „Auftrag abschließen" – das wäre zu grob.
Warum dieser mittlere Detaillierungsgrad?
- Für Prozessoptimierung: Du erkennst, welche Handlungsstränge Probleme verursachen (z. B. „Angebot erstellen dauert zu lange")
- Für ERP-Einführungen: Du kannst jedem Handlungsstrang eine IT-Funktion zuordnen (z. B. „Angebot erstellen" → SAP-Modul SD)
- Für Mitarbeitende: Sie verstehen den Prozess, ohne in technischen Details zu ertrinken
In meinem Buch „Geschäftsprozesse erkennen, verstehen und optimieren" beschreibe ich ausführlich, wie Du den richtigen Detaillierungsgrad für verschiedene Prozessarten findest.
Praxisbeispiel aus meiner Arbeit:
Ausgangslage: Mittelständisches Maschinenbauunternehmen, 150 Mitarbeitende, SAP-HANA-Einführung geplant
Problem: Die Vertriebsabteilung modelliert den Prozess „Angebot erstellen" mit 40 Einzelschritten – von „E-Mail öffnen" bis „PDF speichern"
Fehlentscheidung: Die IT-Abteilung fordert noch mehr Details für die SAP-Spezifikation
Konsequenz: Das Prozessmodell wird unübersichtlich, niemand kann es mehr lesen, die SAP-Einführung verzögert sich
Lösung: Wir reduzieren auf mittleren Detaillierungsgrad mit Handlungssträngen:
- Kundenanfrage prüfen → „Anfrage qualifiziert"
- Technische Machbarkeit klären → „Machbarkeit bestätigt"
- Angebot kalkulieren → „Preis ermittelt"
- Angebot erstellen und versenden → „Angebot beim Kunden"
Ergebnis: Übersichtliches Modell, klare IT-Anforderungen, SAP-Einführung läuft planmäßig.
AUF DEN PUNKT GEBRACHT
Ein Aktivitätenkästchen = ein Handlungsstrang mit Zwischenergebnis.
Dieser mittlere Detaillierungsgrad ist ideal für Prozessoptimierung und IT-Einführungen. Nicht zu grob, nicht zu detailliert – genau richtig.
Tipp 3: Arbeite mit einem kleinen, abgestimmten Team
Hier die unbequeme Wahrheit: Eine Modellierungsrichtlinie ist oft ein Ersatz für fehlende Kommunikation.
Wenn 15 Modellierer:innen verteilt über Standorte und Abteilungen arbeiten – ohne regelmäßigen Austausch –, dann brauchst Du ein dickes Regelwerk. Aber selbst dann entstehen Lücken und Missverständnisse.
Die Alternative: Ein kleines Team von 3–5 Prozessverantwortlichen, die regelmäßig gemeinsam die Modelle sichten und:
- dieselbe Prozessarchitektur nutzen (z. B. Giersberg®-Prozessmodell)
- gemeinsam Entscheidungen treffen („Gehört das noch zu diesem Prozess?")
Warum das funktioniert:
Stell Dir vor, Du planst mit drei Kolleg:innen eine Veranstaltung. Ihr trefft Euch jede Woche, besprecht offene Fragen und stimmt Euch ab. Brauchst Du dann ein 50-seitiges Handbuch, wie Einladungen zu formulieren sind?
Nein. Weil ihr im Dialog seid.
Praxisbeispiel aus meiner Arbeit:
Ausgangslage: Familiengeführtes Maschinenbauunternehmen, 80 Mitarbeitende, stark gewachsen
Problem: Geschäftsführung will alle Prozesse dokumentieren, beauftragt 10 Mitarbeitende aus verschiedenen Abteilungen mit der Modellierung
Fehlentscheidung: Keine gemeinsame Abstimmung, nur eine 12-seitige Richtlinie als „Leitfaden"
Konsequenz: Nach vier Monaten liegen 30 Prozessmodelle vor – jedes in einem anderen Stil, mit unterschiedlicher Detailtiefe
Lösung: Wir reduzieren das Team auf vier Personen (Vertrieb, Produktion, Einkauf, Qualität). Vor der Aufnahme der Prozesse wurde die Prozesslandkarte erstellt und hierbei die Prozesse aus der Aufbauorganisation abgeleitet und in Prozessketten formuliert. Das Team sichtet regelmäßig gemeinsam die Modelle und modelliert nach dem Giersberg®-Prozessmodell.
Ergebnis: Vollständig dokumentierte Prozesse und konsistent dargestellte Prozesse – ohne Richtlinie.
AUF DEN PUNKT GEBRACHT
Dialog schlägt Dokumentation.
Ein kleines Team, das gemeinsam Modelle sichtet, erzeugt konsistentere Ergebnisse als 15 Menschen, die einer Richtlinie folgen – aber nie miteinander reden.
Zurück zu Karin. Nach unserem Gespräch hat sie die 12-seitige Modellierungsrichtlinie zur Seite gelegt. Stattdessen:
Zuschnitt geschärft: Sie hat mit ihrem Team jeden Prozess auf eine Abteilung und ein Abteilungsergebnis zugeschnitten. „Welche Abteilung führt den Prozess aus? Was ist das Ergebnis?"
Mittlerer Detaillierungsgrad festgelegt: Jedes Aktivitätenkästchen beschreibt einen Handlungsstrang mit Zwischenergebnis. Nicht zu grob, nicht zu detailliert.
Regelmäßige gemeinsame Sichtung: Das Team sichtet regelmäßig gemeinsam die Modelle und klärt offene Fragen.
Das Ergebnis?
Drei Monate später: Ihre Prozessmodelle sind einheitlich, verständlich und praxistauglich. Die Geschäftsführung ist begeistert. Und Karin schreibt mir: „Wir sind schneller als je zuvor – und alle verstehen unsere Prozesse. Die Richtlinie hätte uns nur aufgehalten."
FAZIT: Klarheit schlägt Regelwerke
Eine BPMN-Modellierungsrichtlinie ist nur dann notwendig, wenn:
- Dein Bearbeitungsrahmen zu groß und unklar ist
- viele Modellierer:innen ohne gemeinsame Basis und Dialog arbeiten
- es keine klare Prozessarchitektur gibt
Die bessere Lösung:
- Klarer Zuschnitt: Schneide einen Geschäftsprozess auf eine Abteilung und ein Abteilungsergebnis zu
- Definierter Detaillierungsgrad: Stelle einen Geschäftsprozess in BPMN in einem mittleren Detaillierungsgrad dar – jedes Aktivitätenkästchen als Handlungsstrang mit Zwischenergebnis
- Kleines, abgestimmtes Team: 3–5 Modellierer:innen, die regelmäßig gemeinsam die Modelle sichten
Investiere in Klarheit, Struktur und Kommunikation – nicht in dickere Dokumente.
Das ist prozessorientierte Organisation, wie ich sie verstehe: Klar. Pragmatisch. Menschenzentriert.
FAQ
Eine BPMN-Modellierungsrichtlinie ist ein Regelwerk, das festlegt, wie Geschäftsprozesse in der Business Process Model and Notation (BPMN) grafisch dargestellt werden. Sie definiert, welche Symbole für Aktivitäten, Ereignisse und Entscheidungen verwendet werden, wie die Beschriftung der Kästchen erfolgt und welcher Detaillierungsgrad gewählt wird. Das Ziel: Alle Beteiligten sollen Prozesse einheitlich verstehen und modellieren können. In der Praxis wird eine solche Richtlinie oft eingesetzt, wenn viele Modellierer:innen an verschiedenen Standorten arbeiten und keine gemeinsame Prozessarchitektur existiert [1].
Eine Modellierungsrichtlinie ist sinnvoll, wenn mindestens eine dieser Bedingungen zutrifft:
Du hast 10 oder mehr Modellierer:innen, die an verschiedenen Standorten ohne regelmäßigen Austausch arbeiten.
Es gibt keine klare Prozessarchitektur (z. B. kein definiertes Prozessmodell wie das Giersberg®-Prozessmodell).
Der Zuschnitt von Geschäftsprozessen ist unklar – niemand weiß genau, wo ein Prozess beginnt und endet.
In kleinen Teams (3–5 Personen) mit klarem Prozesszuschnitt (Input/Output), definiertem Detaillierungsgrad und regelmäßiger gemeinsamer Sichtung der Modelle ist eine umfangreiche Richtlinie meist überflüssig. Dialog schlägt dann Dokumentation.
Ein Geschäftsprozess sollte auf eine Abteilung und ein Abteilungsergebnis zugeschnitten werden.
Das Input-Element ist das auslösende Ereignis, das die Mitarbeitenden mit der Prozessausführung beginnen lässt (z. B. „Bestellanforderung erhalten").
Der Output ist das Abteilungsergebnis am Ende des Prozesses (z. B. „Material eingekauft"). Diese klaren Grenzen sorgen dafür, dass alle im Team wissen: Dieser Prozess gehört zu einer bestimmten Abteilung, beginnt an einem definierten Punkt und endet mit einem konkreten Ergebnis.
Für die einfache Identifikation können Name des Prozesses und Output ähnlich formuliert werden. Dieser Zuschnitt ist besonders wichtig für Prozessoptimierung und ERP-Einführungen wie SAP HANA. Mehr dazu erfährst Du in meinem Artikel über Prozess Mapping.
Der mittlere Detaillierungsgrad bedeutet: Jedes Aktivitätenkästchen in BPMN beschreibt einen Handlungsstrang, der ein fachliches Zwischenergebnis erzeugt.
Beispiel: Im Prozess „Aufträge abschließen" (Vertriebsaußendienst) sind die Prozessschritte „Beratungsgespräch durchführen" (→ „Kundenbedarf ermittelt"), „Angebot erstellen" (→ „Angebot liegt vor") und „Auftrag verhandeln" (→ „Auftrag unterschrieben"). Du modellierst also nicht zu grob („Auftrag abschließen" als ein Schritt) und nicht zu detailliert („Kunde anrufen", „Termin eintragen", „E-Mail schreiben" als einzelne Schritte).
Dieser mittlere Detaillierungsgrad ist ideal für Prozessoptimierung und IT-Einführungen, weil er übersichtlich bleibt und gleichzeitig Optimierungspotenziale sichtbar macht.
Ideal sind 3–5 Prozessverantwortliche, die als Kernteam zusammenarbeiten. Dieses kleine Team sollte regelmäßig gemeinsam die Modelle sichten, dieselbe Prozessarchitektur nutzen (z. B. das Giersberg®-Prozessmodell) und gemeinsam Entscheidungen treffen.
Warum? Weil ein kleines, gut abgestimmtes Team konsistentere Ergebnisse erzeugt als viele Modellierer:innen, die nur einer schriftlichen Richtlinie folgen. Ab 10 Personen wird es schwierig, ohne strukturierte Koordination und gemeinsame Sichtung einheitliche Modelle zu schaffen.
Vor der Modellierung sollte eine Prozesslandkarte erstellt werden, bei der die Prozesse aus der Aufbauorganisation abgeleitet und in Prozessketten formuliert werden.
BPMN (Business Process Model and Notation) ist eine grafische Notation – also die „Sprache", mit der Prozesse dargestellt werden (Symbole wie Aktivitäten, Ereignisse, Gateways, Verbindungen).
Das Giersberg®-Prozessmodell ist eine Prozessarchitektur – es definiert, wie Prozesse zugeschnitten werden (auf eine Abteilung und ein Abteilungsergebnis mit Input/Output), welcher Detaillierungsgrad verwendet wird (mittlerer Detaillierungsgrad mit Handlungssträngen und Zwischenergebnissen) und wie Prozesse strukturiert aufgebaut werden (aus der Aufbauorganisation abgeleitet, in Prozessketten formuliert).
Du kannst BPMN als grafische Notation nutzen, um nach dem Giersberg®-Prozessmodell zu modellieren. BPMN ist das „Wie" der Darstellung, das Giersberg®-Prozessmodell ist das „Was" und „Warum".
Mehr zur Unterscheidung findest Du in meinem Artikel über Prozessarchitektur.
Der häufigste Fehler: Unklarer Prozesszuschnitt.
Wenn nicht definiert ist, welche Abteilung den Prozess ausführt, wo er beginnt (Input) und endet (Output), modelliert jede Person einen anderen Ausschnitt. Das führt zu inkonsistenten Modellen – selbst wenn alle dieselbe Notation (BPMN) und Richtlinie nutzen.
Weitere typische Fehler: Zu viele Modellierer:innen arbeiten ohne regelmäßige gemeinsame Sichtung der Modelle.
Der Detaillierungsgrad schwankt zwischen „zu grob" und „zu detailliert", weil nicht klar ist, was ein Aktivitätenkästchen darstellen soll.
Es fehlt eine Prozesslandkarte als Grundlage – dadurch werden Prozesse isoliert modelliert, statt aus der Aufbauorganisation abgeleitet und in Prozessketten gedacht.
Investiere zuerst in klare Prozessgrenzen, mittleren Detaillierungsgrad und ein kleines Team – bevor Du Symbole und Benennungen regelst. In meinem Buch „Geschäftsprozesse erkennen, verstehen und optimieren" beschreibe ich die häufigsten Stolperfallen ausführlich.
Quellenverzeichnis
[1] Object Management Group (OMG): Business Process Model and Notation (BPMN) Version 2.0, 2011, https://www.omg.org/spec/BPMN/2.0/
[2] Bundesverwaltungsamt (BVA): Best Practices der BPMN-Modellierung
[3] Mendling, J., Reijers, H. A., & van der Aalst, W. M. (2010): Seven process modeling guidelines (7PMG). Information and Software Technology, 52(2), 127-136 https://www.vdaalst.com/publications/p574.pdf
