Definition
Ein Datenqualitäts-Framework für Prozessdokumentation definiert messbare Regeln für Modell- und Metadaten-Health (Vollständigkeit, Aktualität, Eindeutigkeit, Konsistenz) und übersetzt sie in Scorecards mit Ownership und Remediation – damit das Repository langfristig vertrauenswürdig bleibt.
- Nicht über Policy-Dokumente steuern – sondern über **Scorecards**.
- Jede rote Metrik braucht Owner, SLA und Eskalationspfad.
- Mit 4 Dimensionen starten: Vollständigkeit, Aktualität, Eindeutigkeit, Konsistenz.
- Drift-Erkennung ergänzen: Abweichungen zwischen Modell und Ausführung sind Risiko, nicht nur Doku-Schuld.
Das versteckte Risiko: Prozess-Repositories verfallen still
Prozess-Repositories scheitern selten laut – sie scheitern leise:
- Modelle sind „fast richtig“, aber nicht audit-tauglich
- Duplikate und Varianten wachsen
- Metadaten sind leer oder inkonsistent
- Owner wechseln, Accountability verschwindet
Das Ergebnis ist vorhersehbar: Stakeholder verlieren Vertrauen und Prozessarbeit wird wieder zur einmaligen Workshop-Übung.
Ein Datenqualitäts-Framework macht Health messbar und handhabbar.
Die 4 Kerndimensionen (und was sie für Prozesse bedeuten)
1) Vollständigkeit
Sind Pflichtfelder vorhanden?
- Owner + Reviewer
- Scope (Produkte, Regionen, Systeme)
- Last Reviewed Date
- Controls-Coverage (wo relevant)
2) Aktualität
Ist das Modell innerhalb der Policy geprüft?
- z. B. High-Risk Journeys: alle 90 Tage
- niedrigere Risiken: 180–365 Tage
3) Eindeutigkeit
Gibt es Duplikate oder überlappende Varianten?
- gleicher Name, anderer Inhalt
- gleicher Inhalt, andere Objekte
4) Konsistenz
Folgen Modelle Konventionen, damit Teams sie verstehen?
- Naming-Standards
- Lane-Strategie
- Gateway-Nutzung und Exception-Patterns
Anti-Pattern: messen ohne Remediation
Scorecards ohne Owner werden zum Theater. Das Framework funktioniert nur, wenn jede rote Metrik einen Remediation-Workflow auslöst und eine accountable Person hat.
Scorecards: RAG-Schwellenwerte und „Definition of Done“ für Prozessmodelle
Erstellen Sie Scorecards pro Modell und für die Landschaft insgesamt.
Pragmatischer Start:
- Grün: Pflichtmetadaten vollständig; rechtzeitig geprüft; keine Duplikate; Konventionen erfüllt
- Gelb: kleine Lücken; innerhalb SLA beheben
- Rot: fehlende Ownership, veraltete Reviews oder controls-relevante Lücken; eskalieren
Definieren Sie dann eine Definition of Done für Publikation:
- Minimum-Metadaten gefüllt
- Owner zugewiesen
- Review + Freigabe protokolliert
- Ausnahmen nach Standardpattern modelliert
Score sichtbar machen – dort, wo Arbeit passiert
Wenn Teams extra ein Dashboard öffnen müssen, tun sie es nicht. Health im Repository UI und in Publish-Workflows sichtbar machen.
Ownership: Model Owner, Control Owner, Data Owner
Die meisten Quality-Programme scheitern an vager Ownership.
Definieren Sie drei Rollen:
- Model Owner: accountable für BPMN-Lifecycle und Semantik
- Control Owner (in regulierten Ops oft kritisch): accountable für Control-Design + Evidence Points
- Data Owner: accountable für Evidence-Quellen (Logs, Dashboards, Integrationen)
Dann SLAs anbinden:
- veralteter Review: Benachrichtigung, dann Eskalation
- fehlende Metadaten: Publikation blockieren
- Duplikate: Remediation-Ticket zuweisen
Drift-Erkennung: „Model Health“ mit „Reality Health“ verbinden
Vollständigkeit und Aktualität reichen nicht.
Wenn das Modell vollständig, aber falsch ist, ist es trotzdem Risiko.
Drift-Signale ergänzen:
- Conformance Checking (Soll vs Ist), wo Logs existieren
- Spot Checks via Walkthrough-Recordings
- Exception-Volumen (zu viele Ausnahmen → Main Path falsch)
Weiterführend:
Rollout-Strategie: klein starten, mit Templates skalieren
Realistischer Rollout:
- 20–30 High-Value Modelle auswählen (Risiko + Volumen).
- Vier Dimensionen + RAG-Schwellenwerte implementieren.
- Remediation-Workflow automatisieren (Tasks automatisch erzeugen).
- Wöchentliches Scorecard-Update publizieren (ohne Meetings).
- Über Templates skalieren: Metadaten-Schemata, Naming-Konventionen, Exception-Patterns.
Häufige Fehler, die Sie vermeiden sollten
Lernen Sie von anderen, um dieselben Fallstricke zu vermeiden.
Nur jährliche Reviews
Repositories driften monatlich, nicht jährlich.
Aktualitäts-Scorecards mit Eskalationen und leichter Cadence nutzen.
Felder optional machen
Optional wird zu fehlend.
Pflichtfelder definieren und Publikation blockieren, wenn sie fehlen.
Duplikate als harmlos behandeln
Duplikate zerstören Vertrauen und Controls-Coverage.
Duplikate erkennen und Remediation-Tickets mit Ownern zuweisen.
Experten-Insights
Was die Experten sagen
"Ein Repository ist entweder ein lebendes System mit Scorecards und Ownership – oder ein Museum veralteter Diagramme."
Process-Governance-Architekt:in
Handeln Sie
Ihre Aktions-Checkliste
Wenden Sie das Gelernte mit dieser praktischen Checkliste an.
Pflichtmetadaten definieren (CDEs)
RAG-Schwellenwerte für Vollständigkeit/Aktualität/Eindeutigkeit/Konsistenz setzen
Owner und SLAs pro Regel festlegen
Publikation blockieren, wenn Pflichtfelder fehlen
Wöchentliche Scorecards publizieren und Remediation-Tasks automatisch erzeugen
Drift-Erkennung für High-Risk Journeys ergänzen