Tool-lokale Modelle und Kennzahlen-Drift

Mehrere Tool-Semantikmodelle für dieselbe fachliche Frage erzeugen Reconciliation-Schmerz und Executive-Misstrauen. Drift ist selten Absicht — sie entsteht, wenn Builder Power im Tool mit Autorität über Wahrheit verwechseln.

Power BI, Tableau und Qlik zeigen denselben Monatsnamen und drei Revenues. Ein Catalog-Badge ändert daran nichts. Dieser Teil macht Inventory, eine autoritative Schicht und Dual-Run zum Betriebsvertrag — auf den Capability-Stufen aus Teil 2.

Vorher: Capability-Stufen: was Sie ändern dürfen. Weiter: Wann Shadow-BI erlaubt ist.

z in Power BI. Team B in Tableau. Team C in Qlik. Filter, Wechselkurse und Ausschlüsse weichen still ab. Jeder Report ist lokal erklärbar; der Vergleich ist nicht. Meetings enden in Zahlenkämpfen statt Entscheidungen.

Lösung: Tool-lokale Modelle werden inventarisiert, an eine autoritative Schicht gebunden, im Dual-Run mit Toleranz und Enddatum verglichen und dann gebunden, migriert oder retired. Der Data Owner schließt Population und Grain; der Steward triagiert Drift; der Custodian setzt die Upstream-Bindung durch.

In einem Satz: Eine autoritative Schicht für Population und Grain; Tool-UX darf abweichen, die Fachdefinition nicht.

Entscheidung

Behandeln Sie Tool-lokale Modelle als Verdachtsfälle für Drift, nicht als Standardarchitektur.

1. Inventarisieren — Modelle, Measures, Consumer, Kritikalität (Report Inventory).
2. Eine autoritative Schicht wählen — Mart + Semantic Layer / zertifizierte Data Source als Upstream-Bindung.
3. Dual-Run — Referenz vs. Tool-Ausgabe mit Toleranz und Enddatum.
4. Sunset — konkurrierende Logik upstream migrieren oder Tool-Modell an die autoritative Schicht binden; Duplikate retire-n.
5. Bridge nutzen — Report/BI-Builder × Modell: Builder gestalten mit, entscheiden Grain nicht allein.

Darstellung und Layout bleiben tool-spezifisch. Population, Grain und Base Measures nicht.

Drift-Workflow

1. Modelle inventarisieren

Der Steward führt ein Tool-Local Model Drift Register: Modell-ID, Tool, Owner, Kennzahlen, Consumer, Kritikalität. Report Inventory liefert Fund und Abhängigkeiten. Ohne Register bleibt jede Abweichung ein Meeting-Streit statt ein Ticket.

2. Autoritative Schicht wählen

Der Data Owner benennt Mart plus Semantic Layer oder zertifizierte Data Source als Upstream. KPI Definition hält den Vertrag für Population und Grain. Ein Catalog-Eintrag „Revenue“ allein beweist keine vergleichbaren Zahlen.

3. Dual-Run fahren

Custodian vergleicht Referenz gegen Tool-Ausgabe mit Toleranz und Enddatum. Der Steward triagiert operative Breaches; der Data Owner entscheidet bei Definitionsverdacht. Dual-Run ohne Enddatum wird Dauer-Reconciliation.

4. Binden, migrieren oder retire-n

Konkurrierende Logik wandert upstream oder das Tool-Modell bindet sich an die autoritative Schicht. Duplikate bekommen Disposition und Review-Datum. „Beide behalten, bis es passt“ ist Sunset-Verweigerung.

5. Builder-Brücke nutzen

Builder gestalten Layout und erlaubte Measures mit; Grain schließen sie nicht allein. Formelgeneratoren laufen nur auf freigegebenen Mustern. Wird die Brücke übersprungen, entsteht das nächste Parallelmodell unter demselben Namen.

Handoffs

Anti-Patterns

• Tool-lokale Models als Standardarchitektur behandeln
• Catalog-Badge „Revenue“ als Drift-Fix akzeptieren
• Dual-Run ohne Toleranz und ohne Enddatum
• Builder fachliche Ebene und Grundgesamtheit allein schließen lassen
• Konkurrierende Definitionen behalten, weil „jedes Tool anders ist“

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. Drei Tool-Modelle inventarisieren, die dieselbe Kennzahl beanspruchen.
2. Eine autoritative Schicht mit dem Data Owner benennen.
3. Einen Dual-Run mit Toleranz und Enddatum auf einer kritischen Kennzahl starten.
4. Eine Disposition (bind / migrate / retire) für das kritischste Duplikat festhalten.