Data-Contract
Definition
Ein Data Contract ist eine verbindliche Vereinbarung zwischen Dateneigentümern (z. B. Produktion, Logistik, Vertrieb) und Datenkonsumenten (z. B. Finance, Controlling, Agentic‑AI‑Agenten). Er legt technisch und inhaltlich fest, welche Daten in welcher Qualität, Struktur und Frequenz zu liefern sind – inklusive Fehler‑/Ausweichlogik und Verantwortlichkeiten. Anders als reine API‑Beschreibungen definiert ein Data Contract die „Service Level für Wahrheit“: Nur Daten, die den Contract erfüllen, gelten als steuerungsfähig. Data Contracts sind das fundamentale Werkzeug, um im Rahmen einer Finance Data Mesh Architektur die Qualität zwischen Datenerzeugern und -konsumenten sicherzustellen.
Kurz zusammengefasst:
Qualitätsgarantie: Standards für Vollständigkeit, Korrektheit, Pünktlichkeit.
Governance‑Tool: Eigentümerschaft, Pflichten, Eskalationswege.
Agentic‑ready: Verhindert Fehlentscheidungen durch mangelhafte Daten.
Kurze Beschreibung
Data Contracts schließen die berüchtigte „Garbage‑in, Garbage‑out“‑Falle. Wenn ein ERP‑Update Felder ändert, Formate kippen oder Pflichtwerte leer laufen, bricht ohne Contract die nachgelagerte Analyse (z. B. EBITDA‑Brücke) leise zusammen. Mit Data Contracts agieren Systeme wie digitale Türsteher: Sie lassen nur Daten durch, die den vereinbarten Standard erfüllen – Abweichungen werden sofort gemeldet (Observability), nicht erst beim Monatsabschluss.
Ausführliche Beschreibung: Der „Lieferschein“ der Finance‑Architektur
In einer Organisation mit hoher Connectivity muss Finance blind vertrauen können, dass Daten aus Vorsystemen semantisch korrekt und qualitativ belastbar sind. Data Contracts machen aus „nebenbei anfallenden IT‑Daten“ bewusste Steuerungsprodukte – sie sind damit Grundlage für prüfungsfähige KPI‑Logik (IFRS‑18‑kompatible MPM‑Überleitungen), Agentic‑AI‑Entscheidungen und IKS‑Kontrollen.
Die 4 Säulen eines Data Contracts:
Schema & Struktur Welche Felder werden geliefert und in welchem Typ?z. B.: invoice_amount (Decimal, 2 Nachkommastellen), currency_code (ISO‑4217), posting_date (ISO‑8601), ds_o_category (Enum).
Semantik Was bedeutet der Wert, in welcher Logik wurde er erzeugt?z. B.: „Bruttobetrag inkl. MwSt in lokaler Währung, konvertiert erst im Finance‑Layer; Rabatt bereits abgezogen, Skonto noch nicht.“
Qualitäts‑Metriken (SLOs) Frische, Vollständigkeit, Korrektheit und Pünktlichkeit – messbar.z. B.: „Latenz < 5 Min ab Ereignis“, „Null‑Rate < 0,5 % für Pflichtfelder“, „Validierungsfehler < 0,1 % pro Tag“.
Change Management Verpflichtung des Dateneigentümers: Änderungen (ERP‑Upgrade, Feldumbenennung, neue Enum‑Werte) nur nach abgestimmter Freigabe mit Finance/IKS; Versionierung und rollbarer Deploy‑Plan (Blue/Green, Canary).
Kurz zusammengefasst:
Was? Felder & Typen
Wie? Bedeutung & Erzeugungslogik
Wieviel / Wie schnell? SLOs
Was bei Änderung? Prozess & Freigaben
Warum Finance Data Contracts braucht
Ohne Data Contracts verbrennt Finance Zeit mit Datenputzen; mit ihnen wird die Versorgung prüfbar und audit‑ready. Auditoren sehen, welche Kennzahl (z. B. EBITDA) auf Datenquellen mit erfüllten Contracts basiert. IKS erhält einen messbaren Kontrollpfad (Journal, Freigaben, Rollen), Agenten eine verlässliche Einsatzgrundlage – und Covenants bleiben stabil, weil Definitionen & Qualitäten konsistent sind.
Kurz zusammengefasst:
Sicherheit: Schutz vor Silent Failures.
Effizienz: Automatisierte Validierung statt Excel‑Kontrolle.
Haftung: Klare Ownership für Datenquellen.
NextLevel‑Spezial: Data Contracts & Agentic AI
Für Agentic AI sind Data Contracts die Einsatzinstruktion. Bevor ein Agent handelt (z. B. Mahnstopp bei Disput), prüft er automatisch, ob alle beteiligten Contracts (CRM, Logistik, ERP) grün sind. Unsichere Datenlage? → Der Agent verweigert autonome Aktion, fordert Human‑in‑the‑Loop an und loggt die Policy‑Begründung. So werden Fehler nicht skaliert, sondern kontrolliert.
DACH‑Navigator: Governance, Datenschutz & Aufbewahrung
Im DACH‑Umfeld sind Data Contracts Teil des IKS und müssen Compliance abbilden: Datenschutz (DSG/nDSG, DSGVO), Aufbewahrung (GoBD/GeBüV), Mitbestimmung (Betriebsvereinbarungen), Bank‑/Energie‑Schnittstellen (API‑Stabilität, Nachweisführung). Jeder Contract enthält Rollen, Freigaben, Versionierung und Audit‑Trail – jede Abweichung ist zeitgestempelt, signiert und nachvollziehbar.
NextLevel‑Praxisbeispiel
Ein Industrieunternehmen definiert für den Datenstrom „Sales Logs → Finance KPIs“ einen Data Contract:
Schema/Semantik: net_revenue_local (Decimal), gross_margin_pct (Calculated), customer_id (CRM‑GUID ↔ ERP‑DebitorID), country_code (ISO‑3166), dispute_flag (Boolean).
SLOs: Latenz < 5 Min, Pflichtfelder 100 % gefüllt, Null‑Rate < 0,5 %, Validierungsfehler < 0,1 % pro Tag.
Change: Neue Rabattlogik → Change‑Review, Sandbox‑Test, stufenweises Roll‑out, Rollback dokumentiert.
Event: Nach einem CRM‑Update kippt country_code in Freitext („D/AT/CH“).Wirkung: Contract schlägt Alarm (Null‑/Enum‑Verstoß), Agent stoppt KPI‑Write‑Back, öffnet Ticket an CRM‑Owner, Finance bekommt Warnung: „EBITDA‑Vergleich gefährdet (Zeitreihen‑Bruch).“Ergebnis (48 h): Feld wird korrigiert, Daten werden re‑validiert, KPI‑Pfad stabil – keine Fehlsteuerung, keine Covenant‑Irritation, prüfungsfähiger Audit‑Trail.
Mini‑Template (Beispiel)
Ein Data Contract gibt die verbindliche Grundstruktur vor, inklusive Pflichtfeldern, Bedeutungen, Qualitätsregeln und Spielregeln für Änderungen. Er ist die verfassungsähnliche Basis, an die sich alle beteiligten Systeme und Teams halten müssen. Hier ein Beispiel:
Plain Text
Data Contract – Kurzformat (NextLevel)
Name: Sales-to-Finance KPI Contract v1.3
Owner (Source): Vertrieb (CRM), Logistik (QMS), Finance (ERP)
Consumers: Controlling BI, Agentic AI (WCM/DSO Agent)
Schema:
- customer_id (string, GUID) | must_map_to ERP.debitor_id
- invoice_amount (decimal(18,2)) | local currency, VAT_included=false
- currency_code (enum, ISO-4217) | allowed=[CHF,EUR,USD]
- posting_date (date, ISO-8601) | tz=Europe/Zurich
- dispute_flag (boolean) | true if any open QMS ticket
Semantik:
- invoice_amount = net (after discounts, before VAT)
- gross_margin_pct = (net_revenue - COGS) / net_revenue
SLOs:
- Freshness: <5 min
- Completeness: required fields 100%
- Validity: enum violations <0.1%/day
- Null-rate: <0.5%
Change Management:
- Any enum/list change requires Finance approval (IKS ticket #)
- Versioned rollout (canary 10%), auto-rollback on SLO breach
Observability:
- Metric IDs, alerts to #finance-data-quality, audit log retained 12 months
Typische Fehler & Missverständnisse
„API‑Doku reicht“: Nein. Ohne Semantik, SLO und Change‑Pfad bleibt Datenqualität zufällig.
„Einmal definieren, dann läuft’s“: Data Contracts sind lebendig – Releases, neue Produkte, Länder, Steuern ändern die Datenlogik.
„Validierung in BI genügt“: Späte Checks sind teuer. Contracts müssen am Eingang prüfen (Near‑Source‑Validation) – mit Write‑Back‑Stop.
Kurz zusammengefasst:
Früh prüfen > spät reparieren.
Semantik > Syntax.
Versionieren > „still“ ändern.
NextLevel‑Praxischeck
Haben wir für unsere Top‑10 Steuerungs‑Datenströme (z. B. Sales‑Logs → EBITDA/WCM) schriftliche oder technische Contracts mit Ownern und SLOs?
Gibt es automatische Alarme bei Contract‑Verstößen (Enum/Null, Frische, Vollständigkeit)?
Werden ERP/CRM‑Updates systematisch gegen betroffene Contracts geprüft (Impact‑Matrix, Rollback‑Plan)?
Ist der Agenten‑Einsatz an „Contract‑grün“ gebunden (Policy, Kill‑Switch, Human‑in‑the‑Loop)?
NextLevel‑Statement
„Data Contracts sind die Spielregeln der Wahrheit. Erst wenn Daten ihr Contract‑Examen bestehen – semantisch korrekt, frisch, vollständig – werden Kennzahlen prüfbar, Agenten verlässlich und Finance zur Steuerungsfunktion statt zur Datenputzkolonne.