Der Katalog ist nicht das Dashboard

Der Datenkatalog hilft, Datenobjekte, Kennzahlen und Kontext zu finden. Ein Dashboard beantwortet eine konkrete Frage mit Filtern, Zeitraum und Visualisierung. Katalog und Dashboard sind nicht dasselbe: Der Katalog genehmigt keine Zahl, und ein Dashboard dokumentiert nicht automatisch deren Herkunft.

Entscheidung

Jede wichtige Aussage in einem Dashboard erhält eine stabile Verbindung zu Kennzahl, Version, Datensatz, verantwortlicher Rolle und Gültigkeitsbereich im Katalog. Der Katalog verweist zurück auf die Berichte, die diese Kennzahl verwenden.

Ein Dashboard zeigt eine Zahl in einem bestimmten Zusammenhang, zum Beispiel mit Filtern, Zeitraum und Zielgruppe. Der Katalog hilft beim Finden und Verstehen. Wenn beide Aufgaben vermischt werden, sieht eine Zahl vertrauenswürdig aus, obwohl Definition, Filter oder Verantwortung fehlen.

Entscheidung: Jeder wichtige Dashboard-Aussage bekommt eine stabile Verbindung zur fachlichen Definition, zur Datenquelle, zum Owner und zur Version. Nutzer sehen im Dashboard genug Kontext für die Entscheidung und können bei Bedarf über den Katalog die Herkunft und Bedeutung prüfen.

Ein Aussage ist mehr als eine Kachel. Er ist eine überprüfbare Aussage wie: „Die monatliche Churn-Rate für zahlende Self-Service-Kunden liegt im Juli bei 3,2 Prozent.“ Damit andere die Aussage korrekt nutzen können, brauchen sie Kennzahlversion, Population, Zeitraum, Filter, Währung oder Einheit, Datenstand und Gültigkeitsgrenzen. Das Dashboard präsentiert diesen Kontext selektiv; der Katalog macht ihn auffindbar und verbindet ihn mit Definition, Datenprodukt und weiteren Consumern.

Unterschiedliche Nutzeraufgaben

Katalog-Nutzer fragen: Welche Daten oder Kennzahlen existieren? Wem gehören sie? Sind sie freigegeben? Woher stammen sie? Welche Produkte und Reports verwenden sie? Dashboard-Nutzer fragen: Was hat sich verändert? Ist ein Ziel gefährdet? Wo soll ich eingreifen? Das erste ist Discovery und Verständnis, das zweite eine analytische Entscheidungssituation.

Darum sollte eine Katalog-Seite nicht zu einem zweiten Dashboard werden. Kleine Profil- oder Qualitätsvisualisierungen können beim Verständnis helfen, ersetzen aber keinen kuratierten Entscheidungskontext. Ebenso sollte ein Dashboard nicht das gesamte Glossar nachbilden. Es zeigt die für die Entscheidung notwendigen Hinweise und bietet einen stabilen Direktlink für Details.

Praxisbeispiel: Churn im Executive Dashboard

Ein Executive Dashboard enthält „Monthly Logo Churn“. Die Kachel filtert Testkunden, interne Accounts und Kunden ohne volle Abrechnungsperiode aus. Im Katalog ist die Kennzahl-ID customer.logo_churn.monthly.v3 mit Definition, Owner, Semantic-Version, Datenprodukt, Lineage und aktiven Consumern verknüpft. Das Dashboard übergibt beim Direktlink seine Filterparameter, sodass ein Nutzer nicht auf einer allgemeinen Seite des Datenobjekts landet.

Das CRM-Team ändert den Statuscode für Kündigungen. Die Lineage-Analyse findet die betroffene Kennzahl und drei Dashboards. Der Katalog Steward erzeugt einen Hinweis auf Auswirkungen; Metric Owner und BI Owner prüfen, ob die Semantik oder nur das Mapping betroffen ist. Nach Tests wird die Änderung veröffentlicht. Ein Dashboard mit lokaler Altlogik fällt beim Abgleich auf und erhält ein Ablaufdatum.

Das Beispiel zeigt auch den Rückweg: Nutzungstelemetrie meldet, dass ein regionales Dashboard seit sechs Monaten nicht geöffnet wurde. Sein BI Owner bestätigt die Stilllegung. Der Katalog markiert es als retired, statt es weiter als aktiven Consumer und vertrauenswürdigen Einstiegspunkt anzuzeigen.

Vorgehen

1. Entscheidung und Zielgruppe erfassen. Dokumentiere nicht nur Dashboard-Name, sondern Handlung, Frequenz und Nutzergruppe.
2. Kritische Aussagen inventarisieren. Beginne mit fünf Kacheln, deren Fehlinterpretation materielle Folgen hätte.
3. Kontext explizieren. Halte Kennzahl-ID, Version, Population, Zeitraum, Filter, Einheit, Aktualität und Ausnahmen fest.
4. Beziehungen verlinken. Verbinde Aussage, Dashboard, Datenprodukt, Definition, Owner und Lineage mit stabilen IDs.
5. Freigabeprüfung anwenden. Prüfe vor Veröffentlichung Status, Kontext, Zugriffsrechte und Ergebnisabgleich.
6. Impact simulieren. Ändere Quelle, Filter oder Kennzahlversion und kontrolliere Benachrichtigung sowie Migration.
7. Lebenszyklus schließen. Speise Nutzung, Incidents und Stilllegung in den Katalog zurück.

Angemessener Umfang

SME/SMB: Nutze eine Dashboard-Produktseite mit Owner, Zweck, fünf Aussagen und Links. Eine einfache Liste stabiler Kennzahl-IDs genügt. Prüfe monatlich aktive Nutzung und veraltete Reports.

Mid-market: Fordere Katalog-Datenobjekt- und Kennzahl-IDs im BI-Publish-Prozess. Domänen betreiben Consumer-Register und Ablösung-Backlogs. Ein zentrales Team stellt Templates, API-Verlinkung und Nutzungsintegration bereit.

Enterprise: Trenne Consumer-Portal, Katalog-Suche und BI-Workspace bewusst. Automatisiere Cross-Tool-Lineage und Zugriffsprüfung, klassifiziere materielle Aussagen und führe gestufte Ablösung durch. Executive oder regulatorische Reports brauchen strengere Evidenz als explorative Team-Analysen.

Übergaben

Der BI Developer liefert nicht nur eine URL, sondern Aussage-Manifest, Filter und erwartete Ergebnisse. Der Metric Owner bestätigt fachliche Passung, nicht das visuelle Design. Der Katalog Steward stellt Auffindbarkeit und Beziehungen sicher. Der BI Owner verantwortet Zielgruppe, Veröffentlichung und Stilllegung. Consumer melden missverständliche Aussagen oder fehlende Kontexte zurück.

Definiere für materielle Änderungen eine Reaktionsfrist. Ein Hinweis auf Auswirkungen sollte betroffene Version, erwartete Auswirkung, Testfenster, Migrationsdatum und Rückfallplan enthalten. So wird aus passiver Lineage ein operativer Übergabe.

Anti-Patterns

Dashboard-Namen als fachliche Definition nutzen; jeden Chart als neue Metrik anlegen; tote Dashboards im Katalog als aktiv zeigen; Filterkontext verschweigen.

Screenshot-Katalog: Vorschaubilder dominieren, während Kennzahl-ID und Status fehlen. Linkfriedhof: URLs werden gesammelt, aber nicht auf Erreichbarkeit oder Nutzung geprüft. Unsichtbare Defaults: BI-Filter, Zeitzone oder Währung verändern die Aussage, ohne angezeigt zu werden. Zertifizierung ohne Scope: Ein ganzes Dashboard trägt ein Siegel, obwohl nur einige Kennzahlen kontrolliert sind. Viele Wahrheiten: Regional angepasste Aussagen verwenden denselben Namen ohne Variantenbeziehung.

Gegenmaßnahmen sind claim-basierte Verlinkung, maschinenlesbare Manifeste, sichtbare Defaults, Zertifizierung auf passender Granularität und versionierte Varianten. Nicht jede lokale Analyse muss registriert werden; produktive, geteilte oder entscheidungskritische Consumer schon.

Publish- und Betriebscheckliste

• Hat das Dashboard eine Zielgruppe, Entscheidung, Owner und Prüfdatum?
• Besitzt jede kritische Aussage eine stabile Kennzahl-ID und Version?
• Sind Grundgesamtheit, Filter, Zeitfenster, Zeitzone, Einheit und Aktualität sichtbar?
• Verlinkt der Katalog auf den konkreten Nutzer und dieser zurück auf die Aussage?
• Ist die Lineage bis zum verantworteten Datenprodukt testbar?
• Werden Zugriffsrechte beim Direktlink respektiert?
• Gibt es Auswirkungs-, Abgleich- und Rückfalltests?
• Fließen Nutzung, Incidents und Stilllegung-Status zurück?

Vom Beispiel zum verlässlichen Betrieb

Beginnt mit einem häufig verwendeten Dashboard und formuliert seine wichtigsten Aussagen als vollständige Sätze. Verknüpft jede kritische Aussage mit Kennzahl, Version, Datenprodukt, verantwortlicher Rolle und sichtbaren Filtern. Eine Person, die den Bericht nicht gebaut hat, sollte Bedeutung und Grenzen ohne mündliche Hilfe erklären können.

Prüft danach den Rückweg vom Katalog: Welche aktiven Dashboards verwenden dieselbe Kennzahl? Ein Abgleich mit tatsächlicher Nutzung zeigt tote Links, veraltete Berichte und nicht erfasste Verbraucher. Bei einer Änderung müssen betroffene Verantwortliche, Testfenster und Umstellung nachvollziehbar sein.

Für den Betrieb sind vollständige Aussagen, funktionierende Verknüpfungen, bestätigte Auswirkungsmeldungen und überfällige Stilllegungen wichtiger als Seitenaufrufe. Ist eine Kennzahl fragwürdig, muss der Bericht sie sichtbar kennzeichnen, auf den letzten bestätigten Stand wechseln oder kontrolliert ausblenden können.

Prüfung aus Sicht eines Consumers

Bitte für den monatliche Prüfung eine Person, die das Dashboard nutzt, aber nicht gebaut hat. Sie soll eine Aussage in einem vollständigen Satz erklären, Filter und Datenstand erkennen und über den Direktlink Definition, Owner und Datenprodukt finden. Anschließend soll sie feststellen, welche weiteren Consumer dieselbe Kennzahl verwenden. Jede notwendige mündliche Erklärung markiert fehlenden Kontext oder einen schwachen Übergabe.

Prüfe danach den umgekehrten Weg. Starte bei einer Kennzahl oder einem Datenprodukt im Katalog und ermittle alle aktiven Dashboards. Vergleiche diese Liste mit BI-Nutzung und Bestätigung durch den Owner. Abweichungen zeigen blinde Consumer, tote Links oder unvollständige Lineage. Für kritische Aussagen sollte das Team begründen können, warum ein Consumer aktiv, veraltet oder ausgenommen ist.

Ein wirkungsorientiertes Scoreboard verbindet Discovery und Betrieb: vollständige Aussage-Manifeste, erfolgreiche Direktlinks, bestätigte Hinweis auf Auswirkungene, Zeit bis zur Migration, überfällige Ablösungs und ungeklärte lokale Varianten. Ergänze qualitative Fehlinterpretationen aus Support oder Entscheidungsmeetings. Ein beliebtes Dashboard kann weiterhin semantisch riskant sein.

Lege für Ausfälle einen einfachen Rückfallweg fest. Ist eine Kennzahl oder Quelle fragwürdig, muss der BI Owner die Aussage sichtbar kennzeichnen, auf den letzten bestätigten Stand wechseln oder die Kachel kontrolliert ausblenden können. Ein still weiterlaufendes Dashboard vermittelt sonst Sicherheit, obwohl seine Bedeutungskette gebrochen ist.

Weiterführende Begriffe und Playbooks

Die Einordnung beginnt bei Die Vier-Schichten-Bedeutungslandkarte und Metadaten ist nicht der Katalog. Die ausführbare Wiederverwendung behandelt Semantic Layer statt dicker Consumer. Ergänzend helfen Glossar, Business Intelligence, Data Lineage, KPI und Data Product.