Was ist Prozessmodellierung?

Viele operative Probleme sind in Wahrheit Prozessprobleme:

• Arbeit bleibt bei Übergaben hängen
• Freigaben laufen über Nebenkanäle
• “Ausnahmen” werden zur Norm
• niemand kann den End-to-End Flow erklären

Prozessmodellierung schafft gemeinsames Verständnis, damit Teams Workflows verbessern und steuern können. Das Modell wird Referenzpunkt für Onboarding, Compliance und kontinuierliche Verbesserung.

Die Begriffe werden oft synonym genutzt:

• Prozess-Mapping ist meist leichteres Dokumentieren (“wie es fließt”).
• Prozessmodellierung ist formaler und kann Ausführungssemantik enthalten (besonders mit BPMN).

In der Praxis: mit Mapping schnell starten – und Detail ergänzen, wenn Governance oder Automatisierung nötig wird.

Eine schnelle Faustregel:

• Flowcharts für Brainstorming und einfache Erklärungen
• BPMN für operative Workflows mit Rollen, Ausnahmen und dem Weg zur Automatisierung

BPMN liefert einen Standard (Events, Aktivitäten, Gateways, Swimlanes), damit Modelle mit Komplexität skalieren.

BPMN-Basics lesen →

Ein pragmatischer Ablauf:

1. Einen Prozess mit klarem Outcome wählen
2. Die Leute interviewen, die die Arbeit machen
3. Happy Path zuerst modellieren
4. Entscheidungen, Freigaben und Top-Ausnahmen ergänzen
5. Rollen über Swimlanes zuweisen
6. Review und Sign-off
7. Modell in eine SOP übersetzen

Schritt-für-Schritt BPMN Guide →

Diese Gewohnheiten halten Modelle nutzbar:

• Verb-Objekt Benennung: “Rechnung freigeben”, nicht “Rechnungsfreigabe”
• Ein Zweck pro Diagramm: bei größerem Scope splitten
• Ausnahmen bewusst modellieren: erst Top 2–3
• Subprozesse statt riesiger Canvas
• Ownership und Review-Rhythmus definieren

Klarheit schlägt Vollständigkeit.

Der schnellste Weg, Prozessmodellierung unangenehm zu machen, ist: das ganze Unternehmen in ein Diagramm zu packen.

Bleiben Sie auf der richtigen Ebene:

• L0 (Value Chain / Value Stream): große Übersicht; meist eine Seite
• L1 (End-to-End Prozess): ein messbares Outcome (z. B. “Rechnung freigeben”)
• L2 (Subprozess): zusammenhängender Teil (z. B. “Rechnungsdaten validieren”)
• L3 (Procedure/SOP): Schritt-für-Schritt Ausführung (wer macht was, in welchem Tool)
• L4 (Work Instruction): Mikro-Schritte (meist toolspezifisch)

Was gehört wohin

• L1/L2 zeigen Übergaben, Freigaben und Entscheidungslogik.
• L3 erklärt Ausführung und Tool-Schritte.
• L4 gehört nicht in BPMN-Diagramme, sondern in Training/Arbeitsanweisungen.

Faustregel: Wenn man das Diagramm nicht in ~2 Minuten erklären kann, sind Sie vermutlich auf der falschen Ebene. In Subprozesse splitten und verlinken.

Gute Modelle starten mit Grenzen.

Bevor Sie zeichnen, festhalten:

• Trigger: was startet den Prozess (Event/Request)
• Outcome: was bedeutet “fertig” (Endzustand)
• In scope: was Sie modellieren und verbessern
• Out of scope: was Sie (vorerst) nicht abdecken

Warum Grenzen zählen

Ohne Grenzen diskutieren Teams endlos, weil sie unterschiedliche Dinge modellieren.

Quick Test

Wenn ein Prozess mehrere Outcomes hat (genehmigt/abgelehnt/eskaliert/abgebrochen), ist das ok — aber jedes Outcome braucht eine klare Endbedingung.

Grenzen sind auch die Brücke zur Messung: ohne Outcome keine KPI.

Die meisten operativen Verzögerungen passieren an Übergaben.

Darum sind Rollen im Modell wichtig:

• Wer besitzt die Arbeit gerade?
• Welche Information muss mitwandern?
• Welche Freigaben sind nötig?

Swimlanes als Klarheits-Tool

Lanes machen Responsibility sichtbar:

• Sales
• Operations
• Finance
• IT

Wenn Ownership sichtbar ist, können Sie bessere Fragen stellen:

• Wo wartet Arbeit?
• Welche Entscheidungen erzeugen Rework?
• Welche Freigaben sind High-Frictions und Low-Value?

Wenn Sie ein Modell wollen, das über den Workshop hinaus nützlich ist, sind Lanes nicht optional.

Lesbarkeit ist vor allem Konvention.

Naming (Quick Wins)

• Verb + Objekt: “Rechnung freigeben”, “Daten validieren”, “Antragsteller informieren”
• Nomen-only Labels vermeiden: “Freigabe”, “Validierung”
• Tasks kurz und eindeutig halten

Gateway-Regeln

• jeden ausgehenden Pfad mit einer Bedingung labeln
• “Ja/Nein” nur, wenn die Entscheidungsfrage klar am Gateway steht

Komplexität kontrollieren

• Subprozesse statt riesiger Canvas
• erst Top-Ausnahmen modellieren (die Risiko oder Delay treiben)

Wenn zwei Leute das Diagramm lesen und sich nicht einig sind, was als Nächstes passiert, ist das Modell noch nicht fertig.

Validierung ist der Moment, in dem Modelle Vertrauen gewinnen.

Einfacher Validierungsablauf

1. Happy Path mit Operatoren durchgehen
2. Top 2–3 Ausnahmen durchgehen
3. Ownership und Freigaben bestätigen
4. Missing Inputs identifizieren (welche Daten fehlen wo)
5. SOP und Review-Rhythmus vereinbaren

Szenario-Tests (high leverage)

Nehmen Sie 3–5 echte Fälle aus den letzten Wochen und “spielen” Sie sie durchs Diagramm. Sie finden schnell:

• fehlende Schritte
• Ausnahmen, die eigentlich häufig sind
• Freigaben, die off-diagram passieren

So vermeiden Sie den Idealprozess. Realität gewinnt immer — also modellieren Sie Realität.

Ein Modell ist nicht das End-Deliverable. Es ist das Rückgrat.

SOP aus dem Modell ableiten

Eine SOP beantwortet praktische Fragen, die das Diagramm nicht beantwortet:

• welches Tool pro Schritt
• welche Inputs erforderlich sind
• wie “done” aussieht
• was bei Fehlern zu tun ist

Automatisierungs-Readiness Checkliste

• sind Decision Rules explizit?
• sind Pflichtinputs definiert?
• sind Ausnahmepfade modelliert?
• ist Ownership klar?
• gibt es Baseline-Metriken?

Wenn Sie das nicht beantworten können, wird Automatisierung fragil.

Prozessdokumentation Best Practices →

Workflow-Automatisierung Best Practices →

Ein solides erstes Onboarding-Modell enthält typischerweise:

• Trigger: “Contract signed” oder “Invoice paid”
• Datenvalidierung: Company Details, Billing, Contacts
• Freigaben: Pricing-Ausnahmen, Security Reviews (falls nötig)
• Übergaben: Sales → Ops → Support
• Ausnahmen: fehlende Informationen, verzögerte Kundenreaktion
• Outcome: “Customer activated” (und was das konkret bedeutet)

Was Sie am Anfang rauslassen

• Mikro-Schritte einzelner Teams
• detaillierte Tool-Anweisungen

Starten Sie End-to-End und splitten Sie später in Subprozesse, wenn ein Teilbereich Ownership und Messung verdient.

Mit diesen Templates wird Ihre nächste Modeling-Session schneller.

Interviewfragen (copy/paste)

• Was triggert den Prozess?
• Was bedeutet “done”?
• Was sind die Top-Ausnahmen?
• Wo wartet Arbeit?
• Welche Freigaben passieren und warum?
• Welche Inputs fehlen am häufigsten?

Modeling-Checkliste

• Trigger und Endbedingung definiert
• Rollen/Lanes zugewiesen
• Entscheidungen haben explizite Bedingungen
• Top-Ausnahmen modelliert
• Ownership + Review-Rhythmus definiert
• SOP-Entwurf verlinkt

Wenn Sie diese Checkliste auf jedes Modell anwenden, bleibt Ihre Prozessbibliothek nutzbar.

“Welche Notation sollen wir nutzen?” sind eigentlich drei Fragen:

1. Wer ist die Zielgruppe?
2. Welche Entscheidungen müssen eindeutig sein?
3. Wollen wir einen Weg zur Ausführung?

Praktischer Vergleich

Die Kombi, die skaliert

• BPMN für Flow und Ownership.
• DMN (oder Decision Tables) für komplexe Gateway-Bedingungen.
• SOPs für Tool-Schritte und Ausführung.

So bleiben Diagramme lesbar und eindeutig.

BPMN vs Flowchart (Deep Dive) →

Jeder Prozess hat Ausnahmen. Die Frage ist: welche gehören ins Modell.

Einfache Auswahlregel

Modellieren Sie Ausnahmen, die:

• häufig sind (wöchentlich)
• high-risk sind (Compliance, Geld, Zugriff)
• high-delay sind (lange Warteschleifen/Loops)

Seltene Edge Cases können in SOPs oder Eskalationsregeln.

Drei Exception-Patterns, die lesbar bleiben

1. Repair Loop: Missing Data → Info anfordern → re-validieren
2. Eskalation: keine Antwort → Reminder → eskalieren → rerouten
3. Alternatives Outcome: Ablehnung/Abbruch ist ein echtes Outcome, kein “Ende im Nichts”

Warum das zählt

Wenn Ausnahmen nicht modelliert sind, werden sie in Nebenkanälen gelöst — und das Diagramm wird zur Fiktion.

Tipp: eine kurze “Exception Catalog” am Modell verlinken und wiederkehrende Ausnahmen in Verbesserungen übersetzen.

Viele Modelle scheitern an Gateways, weil die Entscheidungsregel unklar ist.

Ein Gateway ist eine Frage

Formulieren Sie die Entscheidung als Frage:

• “Ist der Betrag über der Schwelle?”
• “Ist der Kunde Enterprise?”

Dann die ausgehenden Pfade mit Bedingungen labeln.

Wann Decision Tables (DMN-Style) sinnvoll sind

Decision Tables helfen, wenn:

• mehrere Kriterien zählen
• Schwellen sich ändern
• Policy-Logik auditierbar sein muss

Beispiel:

Tabelle als Source of Truth behalten und vom Diagramm verlinken.

So vermeiden Sie “Tribal-Knowledge Gateways”.

Das Schwierigste an Prozessmodellierung ist nicht zeichnen, sondern aktuell bleiben.

Minimum Governance, die funktioniert

• Owner zuweisen
• Review-Rhythmus festhalten (quartalsweise ist guter Default)
• jede Änderung versionieren (mit Grund)
• definieren, wer Changes an Controls/Freigaben freigibt

Einfacher Change-Workflow

1. Change Request (was/warum)
2. Modell aktualisieren
3. Stakeholder-Review
4. SOP aktualisieren
5. publish + messen

Wenn Sie das konsequent tun, wird Drift beherrschbar.

Ohne Governance wird Ihre “Prozessbibliothek” zum Museum.

Wenn Sie für echte Operations modellieren, zählen Kollaborations-Features.

Achten Sie auf:

• Kommentare und Review-Workflows
• Role-based Access (wer darf editieren vs nur sehen)
• Versionierung und Change History
• wiederverwendbare Templates (Lanes, Freigabe-Patterns)
• Export/Sharing, damit Modelle auffindbar bleiben

Praktischer Rat

• Modelle dort ablegen, wo Operatoren sie finden.
• SOPs und “how to run it” direkt am Diagramm verlinken.
• eine Source of Truth, nicht fünf Kopien.

Das beste Modell ist das, das Teams pflegen können.

Wenn Automatisierung später möglich ist, sammeln Sie früh ausführungsnahe Details.

Metadaten pro Schritt

• Owner/Rolle
• Pflichtinputs
• System/Tool
• erwartete Zeit/SLA
• Evidenz-Anforderungen
• Exception Handling

Warum das hilft

Aus “Kommunikation” wird “Design”. Beim Implementieren im WMS haben Sie bereits:

• explizite Regeln
• explizite Ownership
• explizite Ausnahmepfade

Das macht Automatisierung zuverlässig.

Workflow-Management-System Guide →

Ein Prozessmodell entsteht meist im Workshop.

Wenn der Workshop unstrukturiert ist, bekommen Sie:

• ein “Ideal”-Diagramm
• fehlende Ausnahmen
• unklare Ownership

Agenda, die funktioniert (60–90 Minuten)

1. Grenzen definieren (10 Min)
   • Trigger
   • Outcome
   • in/out of scope
2. Happy Path erfassen (20 Min)
   • Schritte, Rollen, Übergaben
3. Entscheidungen und Freigaben identifizieren (10 Min)
   • welche Entscheidungen, warum, wer genehmigt
4. Top-Ausnahmen ergänzen (15 Min)
   • 2–3 Ausnahmen, die Delay/Risiko treiben
5. Ownership + Next Steps (10 Min)
   • Owner
   • Review-Rhythmus
   • SOP Plan

Moderations-Tipps (praxisnah)

• “Was passiert, wenn…?” Fragen konsequent stellen.
• Bei Dissens: beide Pfade notieren und mit echten Fällen testen.
• Scope eng halten: Unklares markieren und weiter.

Ein guter Workshop liefert ein Modell, das validiert werden kann — nicht Perfektion.

Die meisten operativen Prozesse nutzen dieselben Patterns.

Pattern: Freigabe

• expliziter Freigabe-Task
• Gateway mit genehmigt/abgelehnt
• Reason Code bei Ablehnung

Pattern: Eskalation

• Timer
• Reminder
• Eskalation an Manager
• Reroute an Backup Approver

Pattern: Repair Loop

• Inputs validieren
• wenn Missing: Info anfordern
• re-validieren und weiter

Pattern: parallele Arbeit

• in parallele Tasks splitten
• joinen mit “alle müssen” vs “einer reicht”

Pattern: Exception Queue

• ambivalente Fälle in Queue
• Operator fixen und re-run

Wenn Modelle diese Patterns konsistent nutzen, werden sie:

• leichter lesbar
• leichter governable
• später einfacher zu automatisieren

Workflow Design Patterns →

Nutzen Sie diese Rubrik für Reviews.

Klarheit

• Kann eine neue Person den Happy Path nach 5 Minuten erklären?
• Sind Rollen und Übergaben offensichtlich?

Eindeutigkeit

• Sind Gateway-Bedingungen explizit?
• Sind Outcomes explizit?

Vollständigkeit (pragmatisch)

• sind Top 2–3 Ausnahmen drin?
• sind Freigaben als Steps modelliert?

Wartbarkeit

• gibt es einen Owner?
• gibt es Versionierung?
• gibt es einen Review-Rhythmus?

Operative Nutzbarkeit

• ist eine SOP am Modell verlinkt?
• sind Pflichtinputs und “done”-Kriterien klar?

Wenn Klarheit oder Eindeutigkeit fehlen, wird das Modell nicht genutzt — und alles andere ist egal.

Ein Modell wird operational, wenn es als Paket veröffentlicht wird.

Was zusammen veröffentlicht werden sollte

• Prozessmodell (BPMN/Flowchart)
• SOP mit Tool-Schritten und Exceptions
• Decision Rules (Schwellen, Policy-Logik) als Tabelle
• Ownership + Review-Rhythmus

Wo publishen

Dort, wo Operatoren arbeiten — nicht dort, wo Doku stirbt:

• Link im WMS/Workflow Tool
• Link im Team Wiki
• Teil des Onboardings

Warum das funktioniert

Es verhindert den Klassiker:

• Diagramm in Tool A
• SOP in Doc B
• Regeln in Spreadsheet C
• Freigaben in E-Mail

Wenn alles verbunden ist, wird Change beherrschbar und Automatisierung realistisch.

Es gibt zwei sinnvolle Modelltypen:

• As-is: was heute wirklich passiert
• To-be: wie es nach Verbesserungen laufen soll

Warum Sie beides brauchen

• As-is schafft Vertrauen (Operatoren erkennen Realität).
• To-be schafft Alignment (Stakeholder einigen sich auf Zielbild).

Pragmatischer Ablauf

1. As-is Happy Path + Top-Ausnahmen modellieren
2. mit echten Fällen validieren
3. Improvement Opportunities identifizieren (Warten, Rework, unklare Regeln)
4. To-be Changes explizit modellieren
5. Delta dokumentieren (was/warum)
6. SOPs und Governance updaten

Die Trust-Falle

Starten Sie direkt mit To-be, wirkt es schnell wie “Fantasie”.

Bleiben Sie nur bei As-is, passiert keine Verbesserung.

Gewinnendes Pattern: as-is zuerst, dann bewusstes to-be — und beide Versionen mit Change Log verlinken.

Große Prozesse sind normal. Riesige Diagramme sind optional.

Wann splitten

• Happy Path > ~12–15 Hauptaktivitäten
• mehrere Zielgruppen (Exec Overview vs Operator Detail)
• Subprozess hat anderen Owner oder KPI

Sauber splitten

• L1 Modell als Map behalten
• L2 Subprozesse für komplexe Teile
• Subprozesse aus Parent Model verlinken
• Naming konsistent halten

Praktisches Decomposition Pattern

• L1: “Customer Onboarding” End-to-End
• L2: “Data Validation”
• L2: “Security Review”
• L2: “Activation”

So bleiben Modelle lesbar und Ownership wird realistisch.

Tipp: Decomposition hält Modelle automation-ready: stabile Subprozesse zuerst automatisieren, messy Teile behalten Human Checkpoints.

Wenn Sie schneller besser modellieren wollen: Patterns studieren.

Beispiel 1: Rechnungsfreigabe

Rein:

• Schwellen und Routing
• Ablehnungsgründe
• Missing Data Repair Loop
• Eskalations-Timer

Beispiel 2: Access Request

Rein:

• SoD Control (Antragsteller ≠ Approver)
• Dual Approvals für sensitive Access
• Evidence Capture
• audit-freundliche Outcomes

Beispiel 3: Customer Onboarding

Rein:

• Übergaben über Rollen
• “waiting for customer” State
• Top-Ausnahmen (fehlende Infos)
• klares Activation Outcome

Überall gilt: das Modell ist wertvoll, wenn es beantwortet:

• was passiert als nächstes
• wer besitzt es
• was passiert, wenn es schiefgeht

Das ist der Unterschied zwischen Zeichnung und operationalem Modell.

Mit dieser Checkliste werden Reviews schneller und weniger subjektiv.

Scope und Grenzen

• Trigger ist explizit
• End-Outcomes sind explizit
• In/out of scope ist agreed

Rollen und Ownership

• Lanes entsprechen realen Rollen
• Übergaben sind explizit
• jeder Step hat klaren Owner

Entscheidungen und Freigaben

• Freigaben sind als Tasks modelliert
• Gateway-Bedingungen sind explizit
• Ablehnung hat Outcome + Reason Capture

Ausnahmen

• Top 2–3 Ausnahmen modelliert
• Repair Loops für Missing/Invalid Inputs
• Eskalation bei Timeouts

Lesbarkeit

• Happy Path < ~15 Hauptaktivitäten
• Subprozesse genutzt, wo sinnvoll
• Naming ist Verb–Objekt

Governance

• Owner + Review-Rhythmus definiert
• Versionierung vorhanden
• Change Approvals definiert

Operatives Paket

• SOP verlinkt
• Decision Table/Rules verlinkt (falls komplex)
• KPIs gelistet

Wenn Sie diese Checkliste nutzen, shippen Sie Modelle, die Teams wirklich nutzen — und pflegen können.

• Prozess: End-to-End Flow mit messbarem Outcome.
• Subprozess: zusammenhängender Teil eines Prozesses.
• Task: eine Arbeitseinheit.
• Trigger: was den Prozess startet.
• Outcome: was “done” bedeutet.
• Übergabe: Wechsel der Ownership zwischen Rollen.
• Ausnahme: nicht-happy path, der gehandhabt werden muss.
• Repair Loop: strukturierter Pfad für Rework.
• Gateway: Entscheidungspunkt.
• Swimlane: wer die Arbeit macht.

Gemeinsame Begriffe machen Modeling schneller und reduzieren Fehlinterpretation.

Process Mining und Prozessmodellierung lösen unterschiedliche Probleme.

Process Mining (data-first)

• rekonstruiert Flows aus Event Logs
• zeigt, wo Zeit verbraucht wird (Warten vs Arbeiten)
• macht Loops und Variationen sichtbar

Prozessmodellierung (Menschen + Intention)

• erfasst Rollen, Ownership, Freigaben
• macht Entscheidungslogik explizit
• definiert, wie Arbeit laufen soll

Die beste Kombi

1. Mining nutzt Hypothesen (“Freigaben treiben 60% der Durchlaufzeit”).
2. Workshops erklären das “warum” und erfassen Ausnahmen außerhalb von Systemen.
3. Modell und SOP updaten.
4. erneut messen.

Mining ohne Modellierung optimiert Rauschen.

Modellierung ohne Daten endet oft in Endlos-Diskussionen.

Zusammen bekommen Sie Realität + Intention — und das braucht nachhaltige Verbesserung.

“Wie detailliert sollte mein Modell sein?”

Detailliert genug, um Unklarheit zu entfernen — aber nicht so detailliert, dass es unlesbar wird. Wenn der Happy Path länger als ~12–15 Aktivitäten ist, in Subprozesse splitten.

“Soll ich jede Ausnahme modellieren?”

Nein. Top 2–3 Ausnahmen modellieren, die Delay oder Risiko treiben. Den Rest als verlinkten Exception Catalog.

“Was, wenn Stakeholder sich nicht einig sind?”

Dissens ist Daten. Beide Pfade erfassen und mit echten Fällen testen. Oft unterscheidet sich der “reale Prozess” je Team — das heißt: Ownership/Regeln sind nicht klar.

“As-is oder To-be zuerst?”

As-is zuerst, um Vertrauen zu schaffen. Dann ein To-be Modell für die Verbesserung, die Sie wirklich shippen.

“Wie halte ich Modelle aktuell?”

Owner zuweisen, Changes versionieren, quartalsweise oder bei großen Policy/System-Änderungen reviewen. SOPs mit dem Modell koppeln.

Wenn Sie diese Fragen konsistent beantworten können, skaliert Ihre Modeling-Praxis.

Ein detailliertes Beispiel zeigt, wie “gut” in der Praxis aussieht.

1) Grenzen definieren

• Trigger: Rechnung eingegangen
• Outcome: bezahlt oder abgelehnt (mit Grund)
• In scope: Validierung, Freigaben, Ausnahmebehandlung
• Out of scope (v1): Spezialfälle der Buchhaltungsabstimmung

2) Rollen (Lanes) definieren

• Accounts Payable (AP)
• Antragsteller
• Manager
• Finance

3) Happy Path (high-level)

1. Rechnung empfangen
2. Pflichtfelder validieren
3. Vendor + PO matchen
4. Freigabe routen
5. Entscheidung + Evidenz speichern
6. Zahlung ausführen

4) Decision Rules (Routing explizit machen)

Decision Table für das Freigabe-Gateway:

Diese Tabelle vom Modell verlinken, damit “warum geroutet” auditierbar ist.

5) Top-Ausnahmen (die relevanten modellieren)

• PO fehlt → Repair Loop zurück an Antragsteller
• Vendor Mismatch → AP Exception Queue
• Approver Timeout → Eskalation an Backup Approver
• Ablehnung → Reason Code erfassen und schließen

6) Operatives Paket

• SOP am Diagramm verlinkt
• Owner + Review-Rhythmus
• KPIs: Durchlaufzeit, Approval Latency, Exception Rate

Wenn Sie so modellieren, zeichnen Sie nicht — Sie designen Ausführung.

Business Process Management Guide →

Einzelne Modelle helfen. Eine Modeling-Praxis skaliert.

Leichter Standard (was rein gehört)

• Naming Konventionen (Verb–Objekt)
• Lane Konventionen (reale Rollen)
• Gateway Konventionen (explizit, testbar)
• Regeln für Subprozess-Decomposition

Templates, die Sie standardisieren sollten

• Process Charter
• SOP Struktur
• Decision Table Format
• Review Checkliste

Governance gegen Drift

• Owner pro Prozess
• Versionierung
• Review-Rhythmus
• Change Approval für Controls/Freigaben

Training und Adoption

• Operatoren lernen, das Modell zu “lesen”
• Owner lernen, es zu pflegen
• quartalsweise Review Sessions

Konsistenz macht aus Prozessmodellierung ein echtes System of Work — und ein Fundament für spätere Automatisierung.

Diesen Spickzettel nutzen, wenn Sie unter Zeitdruck modellieren.

6 Fragen, die jedes Modell beantworten muss

1. Was triggert den Prozess?
2. Was bedeutet “done”?
3. Wer besitzt jeden Step?
4. Welche Entscheidungen gibt es — und welche Bedingungen gelten?
5. Was sind Top-Ausnahmen und Repair Loops?
6. Wie bleibt es aktuell (Owner + Cadence + Versionierung)?

5 Regeln für Lesbarkeit

• Happy Path unter ~12–15 Aktivitäten
• Verb–Objekt Naming
• explizite Gateway-Bedingungen
• Lanes entsprechen realen Rollen
• Subprozesse für Komplexität

4 Reliability-Patterns früh einbauen

• explizite Freigaben (inkl. Ablehnungspfade)
• Repair Loops für Missing/Invalid Data
• Eskalations-Timer
• Exception Queues

3 schnellste Validierungs-Moves

• 3–5 echte Fälle durchs Diagramm spielen
• Operatoren “was passiert wenn…?” fragen
• Ownership und Evidence Requirements bestätigen

Einfachster “Quality Test”

Wenn zwei Personen das Modell lesen und sich nicht einig sind, was als Nächstes passiert, ist es nicht fertig.

Diese Prinzipien halten Modelle operational nutzbar und machen spätere Automatisierung deutlich leichter.