Datenprodukte finden: was im Warehouse liegt und niemand nutzt

Es zeigt, was geladen ist und nirgends ankommt. Bis dahin hat ein Data & AI Berater das Warehouse ausgemappt und gemessen, wie in Datenqualität messen beschrieben. Der Score steht bei 81 von 100 Punkten, ein Beispielwert. Die 19 Punkte bis zum Ziel sind auf Themen verteilt, jedes hat einen Zuständigen. Dann stellt der Fachbereich die nächste Frage: was sich mit diesen Daten jetzt Neues machen lässt.

Die übliche Antwort ist ein Workshop mit Ideen an der Wand. Der Berater antwortet aus dem Graphen, den er für die Messung gebaut hat. Der Grund: Eine Idee trägt nur, wenn die Daten dafür vorliegen. Was vorliegt, steht im Graphen.

Dort fallen drei Dinge auf, die im Bericht niemand sieht. Erstens Objekte der obersten Schicht, aus denen nichts liest. Zweitens Spalten, die geladen werden und nie in der Zugriffsschicht ankommen. Drittens Rechenwege und Listen, die Anwender neben dem Warehouse führen. Solange das niemand zusammen sieht, kann auch niemand sagen, was sich als Nächstes bauen ließe.

Die Frage kommt zur richtigen Zeit. Für die Arbeit am Warehouse gilt eine Reihenfolge: erst verlässlich, dann richtig, dann nützlich. Neue Berichte auf verspäteten oder doppelt gerechneten Daten verteilen falsche Zahlen nur schneller. Deshalb steht die Suche nach Datenprodukten am Ende des Guides und nicht am Anfang.

Aus der Suche entstehen zwei Arbeitsmittel: eine Potenzialkarte und ein Katalog möglicher Berichte. Beide enthalten Vorschläge. Was gebaut wird, entscheidet der Fachbereich.

Ein Data Mart ist ein Ausschnitt des Warehouse, ein Datenprodukt ist eine Zusage, und Data Mesh ist eine Organisationsform. Die drei Begriffe werden oft vermischt, weil sie dieselben Tabellen meinen können. Sie beantworten aber verschiedene Fragen. Die Tabelle unter der Kurzantwort stellt sie nebeneinander.

Ein Data Mart beantwortet, wo die Daten zu einem Thema liegen. Er ist der Teil des Warehouse für ein Fachgebiet oder eine Abteilung, zum Beispiel für den Vertrieb. Wer ihn pflegt und was er zusagt, steckt nicht im Begriff.

Ein Datenprodukt beantwortet, worauf sich Nutzer verlassen können. Dazu gehören fünf Dinge: ein Verantwortlicher, eine Beschreibung, eine feste Schnittstelle, eine zugesagte Qualität und bekannte Nutzer. Ein Data Mart kann die Grundlage sein. Zum Datenprodukt wird er erst mit diesen fünf Dingen.

Data Mesh beantwortet, wer verantwortlich ist. Zhamak Dehghani hat das Konzept 2019 vorgestellt und 2020 in vier Prinzipien gefasst: Verantwortung in den Fachbereichen, Daten als Produkt, eine Plattform zur Selbstbedienung und gemeinsame Regeln für alle. Von dort stammt der Gedanke, Daten wie ein Produkt zu führen.

Ein Datenprodukt braucht kein Data Mesh. Auch ein zentrales Datenteam kann einen Bestand wie ein Produkt führen. In diesem Kapitel ist ein Datenprodukt deshalb etwas Handfestes: eine beschriebene, berechtigte Sicht in der Zugriffsschicht, aus der Berichte lesen.

Mit einer Potenzialkarte: fünf Ringe um die oberste Schicht, und nach außen wird der Beleg schwächer. Der Berater beginnt in der Mitte, bei dem, was gebaut ist. Dort laufen in jeder Messung zwei Hinweisregeln mit, ohne Gewicht im Score. Die erste: Jedes Objekt der obersten Schicht hat einen Verbraucher. Die zweite: Jede fachliche Spalte der obersten Schicht erreicht die Zugriffsschicht.

Ein Verbraucher ist alles, was aus einem Objekt liest: eine Sicht, ein Modell oder ein Bericht. Wo eine der beiden Regeln nicht erfüllt ist, liegt etwas bereit. In ABIS zeigt die Topologie des Graphen diese Stellen: Objekte ohne Verbraucher und Spalten, deren Weg vor der Zugriffsschicht endet. Der Graph entsteht aus Definitionen und Code, nicht aus Datensätzen. Er zeigt deshalb, wer laut Code liest. Wer von Hand abfragt, sieht er nicht.

Von der Mitte geht der Berater nach außen. Ring A sind Felder, die in der Quelle gepflegt sind und vor der obersten Schicht verloren gehen. Ihr Füllgrad lässt sich zählen, deshalb ist der Beleg hier am stärksten. Weiter außen wird er schwächer: Was in Ring C liegt, sieht die Leserolle gar nicht, und Ring E ist nur beschrieben.

Jeder Eintrag der Karte trägt deshalb zwei Angaben: woher er stammt und wie sicher er ist. Dazu kommt die Zoomstufe: Wertkette, Prozess, Ablauf oder Objekt und Spalte. So sieht der Fachbereich, welchen Schritt in seinem Prozess ein Eintrag betrifft. Ein Eintrag ohne Quelle kommt nicht auf die Karte.

Wenn zwei Bedingungen erfüllt sind: Der Schlüssel zum Kernobjekt ist gepflegt, und der Fachbereich stellt die Frage dazu. Das Kernobjekt ist das, worum sich die Auswertung dreht: der Auftrag, der Kunde, die Lieferung. Ein Feld nützt nur, wenn es sich daran hängen lässt. Das prüft eine Zählung: bei welchem Anteil der Sätze der Schlüssel gefüllt ist und ob er eindeutig trifft.

Die zweite Bedingung kann kein Graph prüfen. Ob eine Auswertung jemandem hilft, weiß nur der Fachbereich. Der Berater legt die Karte deshalb vor. Erst wenn der Fachbereich zu einem Eintrag die Frage stellt, wird daraus ein Vorschlag im Katalog. Auch hier gilt: Der Agent misst, der Mensch entscheidet. Ein Vorschlag bleibt ein Vorschlag, bis der Fachbereich ihn bestätigt.

Was an einer der Bedingungen scheitert, verschwindet nicht. Es bleibt auf der Karte, mit dem Vermerk „geprüft, nicht tragfähig“ und dem Grund. So prüft niemand dieselbe Idee ein Jahr später noch einmal.

Jeder Vorschlag bekommt eine Bauklasse. Sie sagt, was vor dem Bau geschehen muss. Eine Schätzung des Aufwands ist sie nicht. Die Beispiele der Tabelle sind erfunden.

In drei Stufen, und jede Stufe wartet auf eine Voraussetzung. Die erste Stufe braucht nur einen verlässlichen Ladelauf. Die zweite wartet auf die Korrekturen am Code und auf gelieferte Schlüssel. Die dritte wartet auf zusätzliche Felder aus der Quelle. Das ist dieselbe Reihenfolge wie bei den Maßnahmen nach der Messung: erst verlässlich, dann richtig, dann nützlich.

Der Katalog möglicher Berichte ordnet jeden Vorschlag einer Stufe zu. So sieht der Fachbereich, was sofort geht und worauf ein Wunsch wartet. Ein Bericht der dritten Stufe ist nicht schlechter als einer der ersten. Er hat nur mehr Vorarbeit, und die Vorarbeit hat einen Zuständigen.

Die Auswahl trifft der Fachbereich zusammen mit dem Datenteam. Der Berater liefert Stufe, Bauklasse und Beleg. Muss für einen Vorschlag eine bestehende Sicht geändert werden, zeigt die Wirkungsanalyse in ABIS vorher, welche Objekte davon abhängen. Sie rechnet auf dem Graphen und ändert nichts am Warehouse.

Ein guter Anfang ist klein: ein Datenprodukt mit zwei bis vier Berichten. Bei welchen Fragen sich der Anfang im Controlling lohnt, zeigt das Kapitel KI im Controlling an zwölf Fällen.

Vier Dinge: eine Sicht als Schnittstelle, eine Beschreibung, eine Berechtigung und ein Stichtag. Der Regelkatalog des Beraters fasst das in drei Sätze. Jedes Datenprodukt gibt es als historische und als aktuelle Sicht, der Stichtag steht in der ersten Spalte. Die aktuelle Sicht sagt, wie es heute steht, die historische, wie es an einem Stichtag stand. Jede Sicht der Zugriffsschicht prüft die Berechtigung. Jede Sicht ist beschrieben. Wie eine solche Sicht aussieht, zeigt das Beispiel unter der Tabelle.

Snowflake liefert dafür die Bausteine, Stand November 2026. Eine Sicht gibt einen Teil der Daten frei, ohne Rechte auf die Tabellen darunter. Kommentare beschreiben Sicht und Spalten. Eine Row Access Policy legt fest, wer welche Zeilen sieht, ab der Enterprise Edition. Den Begriff selbst nutzt Snowflake beim Teilen von Daten: Dort ist ein Datenprodukt der Share oder die App an einem Listing.

Ein Datenprodukt trägt eine Qualitätszusage, und die wird überwacht. Die Regeln dafür laufen bei jedem Ladelauf mit. Wie aus den Ergebnissen ein Verlauf wird, steht in Datenqualität überwachen.

Innerhalb des Datenprodukts gilt eine Definition je Kennzahl. Deshalb gehört zu jedem Datenprodukt genau ein Semantikmodell. Zwei Modelle auf demselben Bestand rechnen früher oder später verschieden. Woran man das erkennt, zeigt Single Source of Truth. ABIS liest das Semantikmodell aus Power BI und den SQL-Code in einen Graphen. Welches Modell zu welchem Datenprodukt gehört, ordnet der Berater zu.

Die Karte zeigt, was möglich ist. Ob es sich lohnt, zeigt sie nicht. Das entscheidet der Fachbereich an der Frage, die er beantwortet haben will. Snowflake ist dabei nur das Beispiel. Das Verfahren gilt für jedes Warehouse, das SQL spricht. Fünf Grenzen gehören dazu:

• Der Graph sieht den Code, nicht die Nutzung. Ein Objekt ohne Verbraucher im Graphen kann trotzdem von Hand abgefragt werden. Wer tatsächlich liest, zeigt in Snowflake die Sicht ACCESS_HISTORY, ab der Enterprise Edition und für die letzten 365 Tage, Stand November 2026.
• Was die Leserolle nicht sieht, fehlt. Ring C bleibt deshalb eine Vermutung, bis der Zugriff geklärt ist.
• ABIS kennt kein Objekt für Datenprodukt, Verantwortlichen oder Vertrag. Potenzialkarte und Berichtskatalog sind Beratungsarbeit auf dem Graphen und liegen als Tabelle vor.
• Einen Verantwortlichen kann niemand auslesen. Wer ein Datenprodukt führt, legt die Organisation fest. Ohne ihn bleibt es eine Sicht mit Kommentar.
• Die Bauklasse ist keine Schätzung des Aufwands. Sie sagt, was vorher geschehen muss. Wie lange das dauert, klärt das Datenteam.