Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen

Problem

Eine typische Landschaft hat einen Metadatenkatalog, ein paar veröffentlichte Policies und ein Glossar mit den wichtigen Fachbegriffen. Gleichzeitig sitzen vierzig INLINE-Tabellen in Qlik-Skripten, zwölf Excel-Dateien steuern Länder- und Produktmappings, und ein halbes Dutzend SQL-VALUES-Klauseln kodiert Statuscodes, über die Finance und Sales sich nicht mehr einig sind.

Der Katalog indexiert dann Tabellen, die die Join-Keys nicht besitzen. Zugriffsrichtlinien referenzieren Rollennamen, die weder in Section Access noch in Row-Level-Filtern vorkommen. Lineage-Graphen enden an der BI-App, weil die echte Abhängigkeit ein hardcodiertes Mapping ist, das niemand registriert hat.

Unsichtbare Abhängigkeiten sind die operative Signatur dieses Musters:

• ein Länder-Remap in einer Qlik-App ist nicht derselbe Remap wie im Warehouse-Load;
• ein Parameter, der eine Fiskalperiode schließt, existiert nur in einer Notebook-Zelle;
• eine Berechtigung-Liste wird in drei Tools kopiert und unabhängig bearbeitet;
• eine Exception-Liste für „Sonderkunden“ wird als CSV per E-Mail verschickt und wöchentlich überschrieben.

Danach folgen Reload-Brüche. Ein Entwickler benennt eine Spalte im Excel-Mapping um. Ein Steward löscht eine Zeile, die noch in einem INLINE-Load vorkommt. Ein dbt-Seed wird in Git aktualisiert, während ein operatives CSV die Datei bleibt, die der Job tatsächlich liest. Die Pipeline scheitert spät — oder schlimmer: sie läuft durch mit stillschweigend falschen Joins.

Als Nächstes entstehen Audit-Lücken. Wenn ein Auditor fragt, wer das Mapping freigegeben hat, das die Umsatzallokation im letzten Quartal verändert hat, lautet die Antwort ein Git-Blame auf einem Skript, ein Timestamp im Fileshare oder „die Person, die gegangen ist“. Es gibt keinen Steward of Record, keine Valid-from-Historie und keine Consumer-Liste.

Multi-Tool-Duplikation vervielfacht die Kosten. Qlik, Power BI, Excel, SQL und Notebooks halten jeweils eine lokale Kopie „derselben“ Control-Tabelle. Teams reconcilen endlos. Metric Governance und Katalogprogramme stocken, weil die gemeinsamen Keys, die sie brauchen, keine eigene Asset-Klasse sind.

Das ist nicht dasselbe Problem wie Kennzahlen-Drift in Formeln, behandelt in Excel-Schatten-BI und Kennzahlen-Drift. Schatten-BI versteckt wiederverwendbare Berechnungen. Steuerdaten-Chaos versteckt wiederverwendbare Lookups, Parameter und Zugriffslisten. Es ist auch keine Semantic-Layer-Lücke: Kennzahlen definieren Measures; Steuerdaten definieren die kodierte Wahrheit, an die diese Measures joinen.

Verwandter Architekturkontext steht in der Serie Building a Modern Data Warehouse, der Serie BI-Governance-Entscheidungen und dem Catalog Deep Dive.

Entscheidung

Behandeln Sie Steuerdaten als eigene Asset-Klasse.

Steuerdaten sind die kleinen, geteilten, fachlich gepflegten oder architekturseitig besessenen Tabellen, die Loads, Joins, Zugriff und Interpretation steuern. Sie sind keine transaktionalen Fakten. Sie sind kein Dashboard. Sie sind kein einmaliger persönlicher Lookup.

Nutzen Sie eine praktische Taxonomie:

Entscheidungsrechte unterscheiden sich nach Klasse, aber alle sechs teilen dieselben Betriebsanforderungen: stabile ID, Owner, Change-Prozess, Publication Contract und Auffindbarkeit im Katalog.

Vergraben Sie Steuerdaten nicht in BI-Skripten als Source of Truth. Lassen Sie sie nicht nur in E-Mail-Excel. Tun Sie nicht so, als ersetze ein Glossareintrag eine gepflegte Tabelle. Platzieren Sie Steuerdaten dort, wo Stewardship, Historie und Consumers zusammentreffen — Teil 5 dieser Serie behandelt die Platzierung. Zuerst machen Sie die Asset-Klasse sichtbar und besessen.

Unterscheiden Sie klar:

• Metrics / Kennzahlenmodell — Definitionen von Measures und Populationen (BI-Governance-Entscheidungen).
• Shadow BI — unkontrollierte Arbeitsmappe-Autorität für wiederkehrende Entscheidungen (Excel-Schatten-BI und Kennzahlen-Drift).
• Kontrollregel data — kodierte Tabellen und Parameter, die Integration, Zugriff und Interpretation steuern.

Dünne BI-Apps brauchen trotzdem Control-Tabellen. Die Regel aus Fachliche Logik außerhalb der BI-Apps halten gilt: gemeinsame Wahrheit außerhalb der App; toolspezifisches Verhalten darf innen bleiben. Steuerdaten sind gemeinsame Wahrheit.

Checkliste

Bauen Sie ein First-Pass-Inventar, ohne das Meer auszukochen:

• listen Sie INLINE- / VALUES- / Seed- / „Enter data“-Tabellen in BI- und Transform-Jobs;
• listen Sie Excel-/CSV-Dateien, die als führende Quellen für Mappings und Parameter dienen;
• taggen Sie jeden Eintrag mit der Taxonomieklasse oben;
• erfassen Sie Nutzer (Apps, Modelle, Jobs) und Reload-/Veröffentlichungspfade;
• benennen Sie einen vorläufigen Owner und Backup verantwortliche Person;
• markieren Sie Sensitivität (besonders Berechtigung und personenbezogene Daten-verknüpfte Mappings) — siehe Access & Security Governance;
• notieren Sie, ob ein Katalogeintrag oder eine Richtlinie diese Tabelle bereits voraussetzt;
• kennzeichnen Sie stille Duplikate über Tools hinweg;
• erfassen Sie den zuletzt bekannten Change-Kanal (Git, E-Mail, UI, unbekannt);
• bewerten Sie operatives Risiko: Reload-Bruch, falscher Join, Audit-Lücke, Access-Leak.

Stoppen Sie, wenn Sie antworten können: Welche Control-Tabellen würden Governance morgen lahmlegen, wenn sie verschwinden?

Artefakt

Erstellen Sie ein Control Data Risk Register mit einer Zeile pro Steuerdaten-Item oder -Familie.

Pflichtfelder:

• stabile Kontrollregel-Data-ID;
• Name und Taxonomieklasse (reference / mapping / parameter / entitlement / hierarchy / exception);
• aktueller Ort (Script Inline, Excel, CSV, DB-Tabelle, Seed, Notebook);
• Owner und Backup verantwortliche Person;
• Nutzer und abhängige Jobs;
• Sensitivität und Zugriffshinweise;
• Change-Kanal und Evidenz der letzten Änderung;
• Duplikatgruppe (gleiche logische Tabelle an mehreren Orten);
• Katalog-/Richtlinie-Abhängigkeit (ja/nein und Link);
• Risiko-Tags: reload-break, silent-wrong, audit-gap, access-leak, orphan;
• Disposition: inventory, classify, extract, govern-in-place, retire-duplicate;
• Ziel-Owner und nächstes Review-Datum.

Ergebnisse: die Karte unsichtbarer Abhängigkeiten, die Duplikat-Cluster, die Berechtigung-Hotlist und der Backlog für Teile 2–5 dieser Serie.

Tools

Nutzen Sie Report Inventory und Lineage-Exports, um Consumers zu finden. Nutzen Sie Skript- und Repo-Suche nach INLINE, VALUES, Seed-Ordnern und hardcodierten Mapping-Arrays. Nutzen Sie den Katalog, um vorläufige Assets zu markieren, noch bevor sie physisch umziehen. Nutzen Sie Access Reviews für Berechtigung-Zeilen. Halten Sie Scanregeln Least-Privilege, wenn Dateien sensible Keys enthalten können.

Ressourcen

Nützliche interne Quellen sind Qlik-Skriptbibliotheken, dbt-Seed-Verzeichnisse, Warehouse-Lookup-Schemas, Fileshare-Mapping-Ordner, Section-Access-/RLS-Konfiguration, Steward-Interviews und frühere Incident-Tickets zu „falsches Mapping“ oder „Reload nach Excel-Änderung fehlgeschlagen“.

Architektur-Nachbarn: Building a Modern Data Warehouse, BI-Governance-Entscheidungen, Catalog Deep Dive. Wenn dieselbe Bedeutung in vielen Tools neu implementiert wird — nicht nur als dateibasierte Steuertabellen — weiter mit dem Redundanz Deep Dive.