Definition
BPMN-Governance in ARIS ist das Operating Model, das Prozessmodelle konsistent, aktuell und vertrauenswürdig hält: Standards + Ownership + Publish-Workflow + Qualitätsscorecards + Remediation – damit das Repository trotz ständigem Change nutzbar bleibt.
- Governance ist ein Workflow, kein PDF: Draft → Review → Freigabe → Publikation.
- 3-Zonen-Repository: Working, Library, Approved.
- Modellqualität kontinuierlich scoren: Vollständigkeit, Aktualität, Eindeutigkeit, Konsistenz.
- Exception Handling in BPMN standardisieren, damit Varianten nicht explodieren.
- Adoption braucht Speed: Standards müssen in 20 Minuten lehrbar sein.
Was BPMN-Governance leisten muss (Outcomes statt Bürokratie)
In regulierten Operations muss BPMN-Governance Outcomes liefern:
- Trust: Stakeholder glauben dem Modell
- Traceability: Kontrollen/Evidence Points sind mit Entscheidungen verbunden
- Konsistenz: globale Teams modellieren lesbar für andere
- Speed: Verbesserungen ohne Governance-Lähmung
Ein Governance-Programm, das nur mehr Regeln erzeugt, scheitert. Ein Programm, das messbare Qualität + einen wiederholbaren Publish-Pfad liefert, skaliert.
Standards, die skalieren: das minimale BPMN-Konventions-Set
Starten Sie mit einem kleinen Standard-Set für 80% der Fälle:
Naming
- Verb + Objekt (z. B. „Antrag validieren“, „Auszahlung freigeben“)
- keine Synonyme für denselben Schritt über Modelle hinweg (Library-Objekte nutzen)
Lanes
- Lanes repräsentieren Accountability (Teams/Rollen), nicht Systeme
- Systeme ggf. als Annotationen ergänzen
Gateways
- jedes Gateway hat explizite Bedingungen
- Exception Paths werden modelliert (nicht implizit)
Events und Ausnahmen
- Standardpattern für Timeouts, Eskalationen, Abbrüche
- Ausnahmen nicht in Freitext-Notizen verstecken
Exception Patterns zuerst standardisieren
Varianten explodieren, wenn Ausnahmen inkonsistent sind. Ein gemeinsames Exception Pattern reduziert Sprawl schneller als jede Naming-Guideline.
Repository-Struktur: Working → Library → Approved
Die effektivste Governance-Maßnahme ist die 3-Zonen-Struktur:
- Working: schnelle Drafts und Iteration
- Library: kuratierte Objekte (Rollen, Systeme, Kontrollen, Funktionen) + Canonical Naming
- Approved: freigegebene Wahrheit, meist read-only
Das reduziert unbeabsichtigten Drift und macht Konsolidierung planbar statt krisengetrieben.
Weiterführend:
Publish-Workflow: Draft → Review → Freigabe → Publikation
Ein Publish-Workflow muss schneller sein als ihn zu umgehen.
Review als Checklist:
- Pflichtmetadaten vorhanden
- Qualitätsscore über Schwelle
- Owner + Reviewer Sign-off
- Control-Impact-Check (wo relevant)
Dann publizieren mit Versionslog:
- was hat sich geändert
- warum hat es sich geändert
- wer hat freigegeben
Wenn Change Logs explizit sind, werden Audits und Transformationen planbar.
Lange Review-Queues vermeiden
Dauert Publikation Wochen, forken Teams Modelle oder bleiben ewig in Drafts. Reviews time-boxen und Rigor dort erhöhen, wo Risiko am höchsten ist.
Qualitätsscorecards: Modelle nach Go-Live gesund halten
Governance scheitert nach Go-Live ohne messbare Qualität.
Scorecards für:
- Vollständigkeit: Pflichtmetadaten vorhanden
- Aktualität: Reviews innerhalb Policy
- Eindeutigkeit: Duplikate/Overlaps erkannt
- Konsistenz: Konventionen erfüllt
Dann Scorecards mit Remediation verbinden:
- Remediation-Tasks automatisch
- Publikation blockieren bei kritischen Lücken
- rote Items eskalieren
Weiterführend:
Über ARIS hinaus: Operating Layer für Evidence und Ausführung
ARIS Governance beantwortet: Wie speichern und steuern wir Modelle?
Die nächste Frage ist: Wie verändern Modelle Verhalten?
Process Designer ergänzt als Operating Layer:
- Operational Knowledge: Prozesse mit Kontrollen, Systemen und Evidence verknüpfen
- Guided Execution (HEIDI) für Adoption
- Automatisierung mit Freigaben für stabile Schritte
- Conformance Loops gegen Drift
Weiterführend:
Häufige Fehler, die Sie vermeiden sollten
Lernen Sie von anderen, um dieselben Fallstricke zu vermeiden.
Standards schreiben, die niemand liest
Teams modellieren nach Gewohnheit, nicht nach Policy.
Minimal-Set teachen und über Scorecards erzwingen.
Ausnahmen implizit lassen
Implizite Ausnahmen werden unkontrollierte Varianten.
Exception Patterns explizit modellieren und wiederverwenden.
Freigaben ohne Versionslog
Audits können nicht nachvollziehen, warum sich etwas änderte.
Bei jeder Publikation ein strukturiertes Change Log.
Handeln Sie
Ihre Aktions-Checkliste
Wenden Sie das Gelernte mit dieser praktischen Checkliste an.
Minimales BPMN-Konventions-Set definieren und in 20 Minuten trainieren
Working/Library/Approved Zonen mit Berechtigungen umsetzen
Publish-Workflow mit Checklist + Versionslogs etablieren
Modell-Qualitätsscorecards wöchentlich publizieren
Exception Patterns standardisieren und wiederverwenden