Data Contracts: Klarheit für BI und KI

Dirk Müller
vor 19 Stunden
10 Min. Lesezeit

Ein Power-BI-Report ist selten der Ursprung des Problems. Er ist oft nur der Ort, an dem es sichtbar wird. Plötzlich stimmt eine Umsatzkennzahl nicht mehr, ein Filter liefert andere Ergebnisse, ein Feld ist leer oder ein Forecast wirkt unplausibel. Die Pipeline läuft trotzdem durch. Das Schema ist noch da. Die Spalten heißen wie gestern. Und genau deshalb wird es gefährlich.

Viele Datenprobleme sind keine technischen Ausfälle, sondern fachliche Brüche. Eine Definition ändert sich, ein Quellsystem liefert neue Statuswerte, ein Feld wird anders befüllt oder ein Fachbereich interpretiert eine Kennzahl anders als der andere. Solange diese Erwartungen nicht klar beschrieben sind, bleibt Datenqualität Glückssache.

Hier kommen Data Contracts ins Spiel. Sie beschreiben nicht nur, welche Felder ein Datensatz enthält. Sie klären, was diese Daten bedeuten, welche Qualität erwartet wird, wer verantwortlich ist, wie Änderungen angekündigt werden und wofür ein Datenprodukt verlässlich genutzt werden darf. Für Unternehmen, die Power BI oder KI-Anwendungen ernsthaft skalieren wollen, ist das ein wichtiger Schritt: weg von stillschweigenden Annahmen, hin zu belastbaren Vereinbarungen.

Data Contracts: Warum ein Schema nicht reicht

Was sind Data Contracts?

Ein Data Contract ist eine verbindliche Vereinbarung zwischen Datenproduzenten und Datenkonsumenten. Er legt fest, welche Daten bereitgestellt werden, in welcher Struktur, mit welcher fachlichen Bedeutung, mit welchen Qualitätsregeln und unter welchen Service-Erwartungen. Der Open Data Contract Standard beschreibt dafür unter anderem Bestandteile wie Schema, Datenqualität, Rollen, Supportkanäle, Team, Infrastruktur und Service Level Agreements.

Das klingt zunächst technisch, ist in der Praxis aber vor allem ein Governance-Thema. Ein Data Contract sollte nicht nur sagen: Es gibt eine Spalte customer_id vom Typ Integer. Er sollte klären, was genau mit Kunde gemeint ist. Debitor? Endkunde? Rechnungsempfänger? Konzernkunde? Aktiver Kunde? Genau an solchen Punkten entstehen später die Diskussionen, die in vielen Unternehmen fälschlicherweise als Reporting-Problem behandelt werden.

Der Vergleich mit API Contracts hilft, greift aber zu kurz. Auch bei APIs verlassen sich Konsumenten darauf, dass Schnittstellen stabil bleiben oder Änderungen sauber versioniert werden. Bei Daten kommt jedoch mehr hinzu: fachliche Semantik, Historie, Qualitätsdimensionen, Kennzahlenlogik und unterschiedliche Nutzungskontexte. Deshalb ist ein Data Contract mehr als ein technischer Schnittstellenvertrag.

Warum ein Schema allein nicht reicht

Ein Schema beschreibt Struktur. Es sagt, welche Tabellen, Spalten, Datentypen und Beziehungen existieren. Das ist wichtig, aber es beantwortet nicht die entscheidenden fachlichen Fragen.

Ein Beispiel: Eine Tabelle enthält das Feld revenue. Das Schema sagt vielleicht: Dezimalzahl, zwei Nachkommastellen, nicht leer. Für ein Reporting reicht das noch lange nicht. Ist Umsatz vor oder nach Rabatt gemeint? Brutto oder netto? Gebucht, fakturiert oder bezahlt? Mit oder ohne Storno? In welcher Währung? Auf welchem Datum basiert die Kennzahl?

Ein stabiles Schema kann fachlich falsche Daten trotzdem sauber durch eine Pipeline transportieren. Genau das ist das Risiko. Die Daten sehen technisch korrekt aus, können aber falsch interpretiert werden. Das fällt oft später auf als ein harter Ladefehler, weil nichts offensichtlich kaputt ist.

Data Contracts machen diese Erwartungen explizit. Sie verbinden technische Struktur mit fachlicher Bedeutung, Datenqualität, Ownership und Änderungslogik. Damit verschieben sie Qualitätssicherung nach vorne: nicht erst im kaputten Dashboard, sondern bereits bei der Bereitstellung eines Datenprodukts.

Was gehört in einen guten Data Contract?

Ein guter Data Contract muss nicht maximal umfangreich sein. Er muss die Punkte klären, die für verlässliche Nutzung wirklich relevant sind. Dazu gehören vor allem Zweck, Semantik, Qualitätsregeln, Ownership, Aktualität und Änderungsprozesse.

Der wichtigste Startpunkt ist der Zweck des Datenprodukts. Wofür ist der Datensatz gedacht? Für operatives Reporting, Monatsabschluss, Forecasting, Kundenanalyse, Produktionssteuerung oder KI-Anwendungen? Und genauso wichtig: Wofür ist er nicht gedacht? Viele Datenprobleme entstehen, weil Datenprodukte für Use Cases genutzt werden, für die sie nie gebaut wurden.

Danach braucht es fachliche Definitionen. Feldnamen allein helfen wenig. Kritische Attribute und Kennzahlen müssen so beschrieben werden, dass Fachbereich, BI-Team und Data Engineering dasselbe darunter verstehen. Das betrifft nicht nur Kennzahlen wie Umsatz, Marge oder Bestand, sondern auch scheinbar einfache Dimensionen wie Kunde, Produkt, Standort oder Auftrag.

Drittens gehören Qualitätsregeln dazu. Microsoft Purview beschreibt Data Quality Rules als Regeln, mit denen Organisationen Genauigkeit, Konsistenz und Vollständigkeit ihrer Daten prüfen und über Qualitätsscores bewerten können. Typische Regeln betreffen Pflichtfelder, Eindeutigkeit, zulässige Werte, Aktualität, Ausreißer, referenzielle Konsistenz und Plausibilitäten.

Viertens braucht es Ownership. Wer ist fachlich verantwortlich? Wer betreibt die technische Bereitstellung? Wer entscheidet über Änderungen? Ohne klare Rollen wird ein Data Contract schnell zur schönen Datei ohne Wirkung.

Fünftens muss der Änderungsprozess geregelt sein. Was gilt als Breaking Change? Wie früh werden Konsumenten informiert? Gibt es Versionierung? Wie lange laufen alte Strukturen parallel? Gerade hier entstehen in der Praxis viele Schäden, weil Quellsysteme geändert werden, während BI-Teams und Fachbereiche erst nach dem nächsten Refresh davon erfahren.

Data Contracts machen Data Governance konkret

Data Governance scheitert selten daran, dass Unternehmen keine Richtlinien formulieren können. Sie scheitert daran, dass Richtlinien nicht im Alltag ankommen. Es gibt Rollenmodelle, Gremien, Glossare und Prinzipien, aber im konkreten Datenprodukt bleibt trotzdem unklar, wer welche Qualität liefert und wer bei Problemen entscheidet.

Data Contracts übersetzen Governance in konkrete Erwartungen an ein konkretes Datenprodukt. Nicht abstrakt, sondern prüfbar: Diese Felder bedeuten genau das. Diese Qualitätsregeln gelten. Diese Person ist verantwortlich. Diese Änderung braucht Vorlauf. Diese Nutzergruppen dürfen sich auf diese Aktualität verlassen.

Das passt zur Entwicklung moderner Data-Governance-Werkzeuge. Microsoft Purview Unified Catalog beschreibt Data Products als Bündel von Datenassets mit Beschreibung und Use Case, die in Governance-Domänen verwaltet werden können. Für Unternehmen ist daran entscheidend: Daten werden nicht mehr nur als technische Tabellen verwaltet, sondern stärker in ihrem geschäftlichen Nutzungskontext.

Wer Data Contracts ernst nimmt, muss fachliche und technische Verantwortung zusammenbringen. Der Fachbereich definiert Bedeutung und Qualitätsbedarf. Data Engineering sorgt für stabile Bereitstellung, Tests und Monitoring. BI-Teams spiegeln zurück, wie Daten in Semantikmodellen, Kennzahlen und Reports genutzt werden. Governance sorgt dafür, dass daraus kein Wildwuchs entsteht.

Wenn genau diese Einordnung fehlt, ist eine pragmatische Standortbestimmung oft sinnvoller als der nächste Toolvergleich. Dann geht es nicht darum, noch ein weiteres Governance-Artefakt zu erzeugen, sondern die eigene Datenstrategie pragmatisch zu bewerten und die wichtigsten Datenprodukte, Verantwortlichkeiten und Qualitätsrisiken zu priorisieren.

Data Contracts in Microsoft Fabric und moderner Datenarchitektur

Moderne Datenarchitekturen sind verteilter als klassische BI-Landschaften. Daten landen nicht nur in einem Data Warehouse und werden von dort berichtet. Sie fließen durch Lakehouses, Warehouses, Pipelines, semantische Modelle, Self-Service-BI-Umgebungen, Planungsprozesse und KI-Anwendungen.

Microsoft Fabric bündelt dafür verschiedene analytische Workloads. OneLake ist dabei als zentraler, logischer Data Lake für Fabric-Tenants angelegt und soll Daten über Workloads hinweg nutzbar machen. Zusätzlich beschreibt Microsoft Purview Funktionen für Governance, Discovery, Lineage und Data Quality im Fabric-Umfeld.

Das ist fachlich relevant. Aber es löst nicht automatisch die eigentliche Frage: Was darf ein Datenprodukt fachlich versprechen? Eine moderne Plattform macht Daten leichter verfügbar. Sie entscheidet nicht automatisch, ob eine Umsatzdefinition konsistent ist, ob ein Kundendatensatz für Segmentierung geeignet ist oder ob eine Änderung im ERP Auswirkungen auf den Monatsabschluss hat.

Genau deshalb sind Data Contracts in Fabric-nahen Architekturen spannend. Sie können an mehreren Stellen wirken: bei der Datenaufnahme aus Quellsystemen, bei Tabellen im Lakehouse oder Warehouse, bei kuratierten Datenprodukten, bei semantischen Modellen und bei Power-BI-Berichten. Die Plattform liefert Bausteine. Der Contract beschreibt, was fachlich und organisatorisch gelten soll.

Für Unternehmen, die eine moderne Datenplattform mit Microsoft Fabric aufbauen, ist das ein wichtiger Punkt. Plattformarchitektur, Governance und Datenprodukte dürfen nicht nacheinander gedacht werden. Sie müssen zusammenpassen.

Der Power-BI-Bezug: Der Report ist oft nur der Tatort

Power BI zeigt viele Datenprobleme sichtbar an, verursacht sie aber nicht immer. Ein Bericht kann schlecht modelliert sein, eine DAX-Logik kann falsch aufgebaut sein, ein Semantikmodell kann unnötig komplex sein. Das gibt es alles. Aber häufig liegt die Ursache upstream: geänderte Quelllogik, fehlende Pflichtwerte, neue Statuscodes, andere Storno-Behandlung, verschobene Ladezeiten oder unklare Definitionen.

Der Report ist oft nur der Tatort. Die Ursache liegt früher in der Datenkette. Ein typisches Szenario: Das ERP-System führt einen neuen Auftragsstatus ein. Das Schema bleibt stabil. Die Pipeline läuft. Im Power-BI-Modell wird der neue Status aber nicht korrekt berücksichtigt. Der Umsatz sieht plötzlich niedriger aus, obwohl fachlich nur eine Prozessänderung stattgefunden hat. Ohne Contract beginnt die Fehlersuche im Bericht. Mit Contract wären zulässige Werte, Änderungsprozess, Owner und betroffene Konsumenten klarer.

Auch semantische Modelle profitieren davon. Sie sind der Ort, an dem Kennzahlenlogik, business-freundliche Begriffe und analytische Struktur zusammenkommen. Microsoft beschreibt semantische Modelle in Fabric als logische Beschreibung eines analytischen Bereichs, die Metriken und geschäftliche Begriffe für Analysen bereitstellt. Aber ein Semantikmodell kann nur so belastbar sein wie die Datenprodukte und Definitionen darunter.

Wenn Teams regelmäßig über Kennzahlenlogik, Datenqualität, Modellierung oder Governance im Power-BI-Alltag stolpern, reicht es selten, nur den nächsten Report zu optimieren. Häufig geht es darum, Power BI gezielt zu verbessern und gleichzeitig upstream mehr Verlässlichkeit in Datenprodukte, Definitionen und Änderungsprozesse zu bringen.

Data Contracts und Datenqualität

Datenqualität ist kein abstrakter Score für ein Dashboard. Datenqualität bedeutet: Daten sind für einen konkreten Zweck ausreichend korrekt, vollständig, aktuell, konsistent und verständlich. Das ist ein wichtiger Unterschied. Ein Datensatz kann für eine operative Tagesauswertung gut genug sein, aber für den Monatsabschluss ungeeignet. Oder er ist für eine Analyse nutzbar, aber nicht für automatisierte Entscheidungen.

Data Contracts machen Datenqualität verhandelbar, prüfbar und betreibbar. Verhandelbar, weil Fachbereich und Data-Team klären müssen, welche Qualität wirklich gebraucht wird. Prüfbar, weil Regeln definiert und technisch kontrolliert werden können. Betreibbar, weil bei Verstößen klar sein muss, wer reagiert.

Typische Qualitätsregeln sind zum Beispiel: keine negativen Umsätze, keine leeren Pflichtfelder, eindeutige Schlüssel, definierte Aktualität nach Ladefenster, gültige Statuswerte, plausible Datumslogik, referenzielle Konsistenz zwischen Auftrag und Kunde oder maximal erlaubte Abweichungen zu Vortagen.

Wichtig ist dabei die Priorisierung. Nicht jede Regel ist gleich kritisch. Ein fehlendes optionales Attribut ist etwas anderes als eine falsche Umsatzberechnung. Ein guter Data Contract unterscheidet zwischen Warnung, kritischem Fehler und Blocker. Sonst erzeugt Datenqualität nur Lärm.

Besonders relevant wird das in Bereichen, in denen viele Systeme und Prozesslogiken zusammenlaufen. In der Produktion können MES-, ERP- und Shopfloor-Daten fachlich nur dann sauber genutzt werden, wenn Kennzahlen, Zeitbezüge und Verantwortlichkeiten klar sind. Wer solche Szenarien vertiefen möchte, findet mit Power BI in der Produktion einen Praxisbezug.

Data Contracts und AI-Readiness

AI-Readiness beginnt nicht beim Copilot. Sie beginnt bei der Frage, ob Datenprodukte verständlich, zuverlässig und fachlich belastbar sind. KI-Anwendungen brauchen nicht nur Zugriff auf Daten. Sie brauchen Kontext. Was bedeutet eine Kennzahl? Welche Daten sind vertrauenswürdig? Welche Aktualität gilt? Welche Felder dürfen für welche Fragestellung genutzt werden? Welche Einschränkungen müssen bekannt sein? Welche Definition ist verbindlich, wenn mehrere Varianten im Unternehmen existieren?

Ohne klare Semantik und Datenqualität wird KI nicht automatisch intelligenter, sondern nur schneller überzeugend falsch. Microsoft Purview betont im Kontext von Data Quality, dass die Zuverlässigkeit von Daten direkten Einfluss auf die Genauigkeit KI-gestützter Erkenntnisse und Empfehlungen hat. Genau das ist der Punkt: KI-Systeme können nur dann belastbare Antworten liefern, wenn die zugrunde liegenden Datenprodukte belastbar beschrieben, geprüft und verantwortet sind.

Data Contracts lösen AI-Readiness nicht allein. Sie ersetzen keine Datenstrategie, keine saubere Modellierung, keine Berechtigungskonzepte und kein gutes Agenten-Design. Aber sie schaffen bessere Voraussetzungen. Sie machen sichtbar, welche Datenprodukte für analytische und KI-basierte Nutzung geeignet sind und welche nur technisch existieren.

Das ist für viele Unternehmen der eigentliche Reifegradunterschied: Viele haben Daten. Weniger haben verlässliche Datenprodukte. Noch weniger haben Datenprodukte mit klarer Semantik, Qualität, Ownership und Änderungslogik.

Wo Data Contracts in Planung und Forecasting wichtig werden

Planung ist ein gutes Beispiel, weil hier Ist-Daten, Planwerte, Forecasts, Verantwortlichkeiten und Annahmen zusammenlaufen. In vielen Unternehmen werden Ist-Daten aus ERP oder Data Warehouse mit Planwerten aus Excel, Planungstools oder Fachbereichsprozessen kombiniert. Technisch kann das funktionieren. Fachlich wird es schnell schwierig.

Planung scheitert selten nur an fehlenden Daten. Sie scheitert oft an unklaren Definitionen und Prozessgrenzen. Welche Version ist gültig? Welche Einheit plant auf welcher Ebene? Wann wird ein Forecast überschrieben? Welche Planwerte sind freigegeben? Welche Ist-Daten gelten als abgeschlossen? Welche Abweichung ist erklärbar, welche ist ein Datenproblem?

Data Contracts können hier helfen, Datenprodukte rund um Ist-Werte, Planwerte und Forecasts sauberer zu beschreiben. Sie klären nicht den gesamten Planungsprozess, aber sie schaffen belastbare Schnittstellen zwischen Datenbereitstellung, Fachbereich und Reporting.

Gerade wenn Planung näher an Reporting und Datenplattform rückt, wird diese Klarheit wichtig. Wer den Zusammenhang zwischen Reporting, Ist-Daten und Forecasts vertiefen möchte, findet mit Planung mit Microsoft Fabric einen passenden nächsten Anknüpfungspunkt.

Wie Unternehmen pragmatisch mit Data Contracts starten

Der größte Fehler bei Data Contracts ist, zu groß zu starten. Wer versucht, sofort jede Tabelle, jede Schnittstelle und jede Kennzahl vollständig zu vertraglichen, baut schnell ein Governance-Monster. Das wird gepflegt, bis der erste Projektstress kommt. Danach veraltet es.

Der bessere Startpunkt sind wenige kritische Datenprodukte. Gute Kandidaten sind Daten, die viele Konsumenten haben, regelmäßig für Management-Entscheidungen genutzt werden, in Planungs- oder Forecast-Prozesse einfließen, regulatorisch relevant sind oder künftig für KI-Anwendungen dienen sollen.

Ein pragmatischer Minimal-Contract kann mit acht Fragen starten:

Wofür wird dieses Datenprodukt genutzt?
Wer ist fachlicher Owner?
Wer ist technischer Owner?
Welche Felder oder Kennzahlen sind kritisch?
Welche Definitionen müssen eindeutig sein?
Welche Qualitätsregeln sind wirklich wichtig?
Welche Aktualität wird erwartet?
Wie werden Änderungen kommuniziert?

Erst danach geht es um Automatisierung, Repository-Strukturen, YAML, Tests, Deployment-Prozesse oder Catalog-Integration. Technische Umsetzung ist wichtig, aber sie sollte nicht die fachliche Klärung ersetzen. Sonst entsteht ein technischer Contract ohne organisatorische Wirkung.

In vielen Organisationen ist Data Contracting kein einmaliges Projekt, sondern ein laufender Reifeprozess. Datenprodukte ändern sich, Fachbereiche lernen dazu, Plattformen entwickeln sich weiter. Für Teams, die dafür regelmäßig Sparring brauchen, kann laufendes Data-&-Analytics-Sparring sinnvoller sein als ein großer Einmalaufschlag.

Grenzen und typische Fehler bei Data Contracts

Data Contracts sind kein Wundermittel. Sie machen aus schlechten Daten keine guten Daten. Sie verhindern nicht jede Änderung und ersetzen keine Zusammenarbeit. Ihr Nutzen entsteht erst, wenn sie im Betrieb ernst genommen werden.

Ein Data Contract ist nur so stark wie die Organisation, die ihn nutzt. Wenn Fachbereiche nicht eingebunden sind, bleibt er technisch. Wenn Ownership fehlt, bleibt er folgenlos. Wenn Qualitätsverletzungen niemanden interessieren, bleibt er Dekoration.

Ein häufiger Fehler ist der rein technische Blick. Dann schreiben Data Engineers eine Contract-Datei, aber Fachbereich und BI-Team erkennen sich darin nicht wieder. Das Ergebnis ist formal sauber, aber fachlich zu dünn.

Der zweite Fehler ist Überregulierung. Nicht jedes Excel-Reporting und nicht jede Hilfstabelle braucht einen vollständigen Data Contract. Priorität haben kritische Datenprodukte, wiederverwendete Datenassets und Schnittstellen mit echtem Ausfall- oder Fehlentscheidungsrisiko.

Der dritte Fehler ist fehlende Reaktion. Wenn Qualitätsregeln verletzt werden, aber niemand informiert wird oder niemand entscheidet, bleibt der Contract wirkungslos. Ein Contract braucht einen Betriebsprozess: Monitoring, Alerting, Eskalation und regelmäßige Pflege.

Der vierte Fehler ist falsche Sicherheit. Ein Data Contract beschreibt Erwartungen. Er garantiert nicht automatisch, dass jede fachliche Änderung erkannt wird. Gerade semantische Änderungen können schwierig sein: Eine Spalte bleibt gleich, aber die Geschäftslogik dahinter verändert sich. Deshalb braucht es neben technischen Checks auch fachliche Kommunikation.

Fazit: Data Contracts machen Erwartungen sichtbar

Data Contracts sind wichtig, weil sie unausgesprochene Erwartungen sichtbar machen. Genau daran scheitern viele Dateninitiativen: nicht an fehlenden Tools, sondern an unklarer Bedeutung, fehlender Ownership, schwacher Datenqualität und unkontrollierten Änderungen.

Ein Schema sagt, welche Struktur Daten haben. Ein Data Contract sagt, was ein Datenprodukt leisten soll. Das ist der entscheidende Unterschied. Für Power BI, Microsoft Fabric, Data Governance und AI-Readiness sind Data Contracts deshalb ein praktischer Baustein. Sie helfen, Datenprodukte verlässlicher zu machen, Governance näher an den Alltag zu bringen und Qualitätsprobleme früher zu erkennen. Aber sie funktionieren nur, wenn Fachbereich, Data Engineering, BI-Team und Governance gemeinsam Verantwortung übernehmen.

Der nächste sinnvolle Schritt

Wenn ihr klären wollt, welche Datenprodukte, Qualitätsregeln und Verantwortlichkeiten zuerst auf den Prüfstand gehören, lohnt sich eine pragmatische Standortbestimmung. Nicht als Großprogramm. Sondern als ehrlicher Blick darauf, wo eure Datenarchitektur heute stabil ist — und wo sie nur stabil aussieht.

Wenn du Power BI strukturiert aufsetzen oder bestehende Lösungen verbessern willst, unterstützen wir dich mit:

Data Strategy Check – um eure Analytics-Organisation ganzheitlich einzuordnen
Consulting Abo – für kontinuierliche Unterstützung bei Migration, Betrieb und Governance
Power BI Coaching – für konkrete Herausforderungen in Modellen, DAX oder Performance
Fabric Kick Start – für einen praxisnahen Einstieg in Architektur, Zielbild und erste Use Cases

So wird aus einem funktionierenden Bericht eine belastbare Analytics-Lösung.