Wann Shadow-BI erlaubt ist

Shadow-BI entsteht, wenn Teams Zahlen lokal bauen, weil der freigegebene Mart zu langsam oder zu eng ist. Unkontrolliert erzeugt das Drift und Audit-Lücken; mit Guardrails (Owner, Label, Ablauf) kann Local/Exploratory erlaubt bleiben — sonst verboten.

Dieser Teil trennt unkontrolliertes Shadow von kontrolliertem Local — auf den Stufen und der autoritativen Schicht aus Teil 2 und 3.

Vorher: Tool-lokale Modelle und Kennzahlen-Drift.

zerstört oft den Workflow und treibt Arbeit in noch undurchsichtigere Kopien. Uneingeschränkte Duldung macht jedes Workbook und jedes Tool-Modell zur konkurrierenden Wahrheit. Es fehlt die Trennung zwischen unkontrolliertem Shadow und kontrolliertem Local.

Lösung: Unkontrolliertes Shadow bleibt verboten. Kontrolliertes Local ist erlaubt mit Label, Owner, Ablauf und ohne Enterprise-Claim. Harte Stopps (kritische Entscheidung, mehrere Konsumenten, Finance/Regulatory, geschützte Namen) und ein Promotion-Pfad Local → Derived → Base trennen Exploration von Wahrheit.

In einem Satz: Local nur mit Owner, Label und Ablauf; Enterprise-Namen und kritische Entscheidungen brauchen governed Publish.

Entscheidung

Für jedes lokale Workbook, Tool-Modell oder Scratchpad:

1. Begriffe trennen — unkontrolliertes Shadow (versteckte Autorität, kein Owner/Test/Lineage) vs. kontrolliertes Local (Label, Owner, Ablauf, kein Zertifizierungs-Claim);
2. Guardrails — einmalige Hypothese, persönliches Scratchpad, gelabeltes Szenario auf Base, Analytics-Sandbox mit TTL oder Dual-Run mit Enddatum;
3. Harte Stopps — kritische Entscheidung, mehrere Konsumenten, wiederholte Verteilung, finanzielle oder regulatorische Wirkung, geschützter Name, fehlender Owner oder Ablauf;
4. Data Owner schließt Enterprise-Claim und Stopps; Steward führt Decision Card und Promotion; Custodian setzt Labels und Inventory-Flags durch;
5. Promotion-Pfad Local → Derived → Governed Base mit Inventory- und Owner-Review — siehe Capability-Stufen.

Kein Enterprise- oder Bonus-Claim auf einer Zahl ohne governed Publish.

Local-vs-Shadow-Workflow

1. Shadow von Local unterscheiden

Der Steward füllt eine Shadow vs Local Decision Card: Kritikalität, Scope, Owner, Ablauf, Upstream-Bindung. Versteckte Autorität ohne Test und Lineage ist Shadow — auch wenn das Dashboard offiziell aussieht. Wer nur das Dateiformat prüft, lässt Excel und Tableau dieselbe Lücke.

2. Guardrails setzen oder verbieten

Erlaubt bleibt zeitlich begrenzte Hypothese, persönliches Scratchpad ohne Weitergabe als Wahrheit, Domänen-Szenario auf Base, Analytics-Sandbox mit Contract-Extrakt und TTL, Dual-Run mit Enddatum. Der Data Owner genehmigt die Card. Ohne Guardrails ist „Exploration“ nur ein freundlicher Name für Shadow.

3. Harte Stopps durchsetzen

Kritische Entscheidungen, mehrere Konsumenten, Finance- oder Regulatory-Wirkung und geschützte Namen stoppen Local. Custodian flaggt Funde im Report Inventory. Eine Controlled-Local-Metrik, die Boni steuert, muss promotet oder der Anspruch gestoppt werden.

4. Promoten oder retire-n

Local → Derived → Base über Steward- und Owner-Review. Disposition auf der Card: retain local / promote / retire plus Review-Trigger. Dauerhafte Finance-Close-Logik nur in einem persönlichen Workbook ist Retirement-Verweigerung.

5. Zweck und PII halten

Auch Local bleibt zweckgebunden. PII- und Access-Grenzen gelten; Single-Person-Risiko braucht Backup. Wer Local vor dem Catalog versteckt, erzeugt die nächste Audit-Lücke — siehe Excel-Schatten-BI.

Handoffs

Anti-Patterns

• Pauschales Shadow-Verbot, das Arbeit in noch dunklere Kopien treibt
• Jedes Arbeitsmappe als Wahrheit dulden, weil „Self-Service“
• Controlled Local nennen und trotzdem Boni oder Board-Zahlen steuern
• verantwortliche Person oder Ablauf weglassen und es Exploration nennen
• Permanente Close-Logik nur in einem persönlichen Arbeitsmappe halten

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Metrics Foundations
• Lernpfad — Metrics Foundations

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Fünf lokale Workbooks oder Tool-Modelle als Shadow vs Local klassifizieren.
2. Eine Decision Card mit Owner, Label und Ablauf für ein erlaubtes Local führen.
3. Einen harten Stopp (geschützter Name oder Finance-Nutzung) mit dem Data Owner testen.
4. Ein bereits verteiltes Local promoten oder mit Notice retire-n.