Datenmodell Einkauf

Datenmodell Einkauf beschreibt formal die Entitäten (Lieferant, Material, Bestellung, Konditionssatz) und ihre Beziehungen — als gemeinsame Sprache zwischen Fachbereich, IT und Datenpflege. Ohne dokumentiertes Modell ist jeder System-Wechsel ein Blindflug, und jede neue Auswertung muss aufwendig rekonstruiert werden.

Detaillierte Erklärung

Datenmodelle existieren in drei Abstraktionsstufen. Das konzeptionelle Modell beschreibt die Geschäftsobjekte ohne technische Details — typisch in der Entity-Relationship-Notation nach Peter Chen (Originalpublikation 1976, "The Entity-Relationship Model — Toward a Unified View of Data" im ACM Transactions on Database Systems). Das logische Modell verfeinert die Entitäten zu Tabellen mit Attributen, Schlüsseln und Kardinalitäten — heute überwiegend in der Crow’s-Foot-Notation (Gordon Everest, 1976, später popularisiert durch James Martin) dargestellt, weil sie 1:1-, 1:n- und n:m-Beziehungen kompakt visualisiert. Das physische Modell ist die konkrete Implementierung in einer Datenbank — bei SAP MM beispielsweise die Tabellen LFA1 (Lieferant allgemein), LFB1 (Lieferant Buchungskreis), EINA (Einkaufsinfosatz, materialspezifisch) und EINE (Einkaufsinfosatz, einkaufsorganisationsspezifisch). Im Einkauf eines DACH-Mittelständlers umfasst das Standardmodell typischerweise zwölf Kernentitäten: Lieferant, Material, Materialgruppe, Werk, Einkaufsorganisation, Einkaufsinfosatz, Konditionssatz, Bestellung, Bestellposition, Wareneingang, Rechnung, Vertrag. In SAP S/4HANA wurde 2015 das Business-Partner-Konzept eingeführt, das Lieferant und Kunde unter einer einheitlichen Entität zusammenführt — ein Bruch im klassischen MM-Modell. Standards wie eCl@ss (Klassifikation, ZVEI/BME), GS1 (GLN, GTIN) und ISO 8000-110 (Datenaustauschformat) ergänzen das Modell um branchenübergreifende Elemente.

Praxisbeispiel (konkretes Einkaufsszenario)

Ein Hersteller von Sondermaschinen aus Niederbayern mit 980 Mitarbeitern plant 2025 die Migration von SAP ECC 6.0 auf S/4HANA. Vorab dokumentiert das Projektteam das bestehende Datenmodell des Einkaufs: 14 Kernentitäten, 240 Attribute, 38 Beziehungen, 4 Werks-spezifische Erweiterungen. Das Modell wird in Crow’s-Foot-Notation in Sparx Enterprise Architect gepflegt. Die Analyse zeigt drei kritische Befunde: Die Beziehung Lieferant—Material ist im Altsystem als 1:n implementiert (ein Material hat genau einen Stamm-Lieferanten), obwohl 870 Materialien tatsächlich Multi-Source-Strategien fahren. Zweitens existieren 28 Custom-Felder ohne Dokumentation. Drittens entsprechen Stammdatenattribute teilweise nicht ISO 8000-110 (Adressformat, Telefonnummern). Vor der Migration werden die 1:n-Beziehung zu n:m überarbeitet, Custom-Felder dokumentiert und 12 Felder DSGVO-konform stillgelegt. Die Migration läuft im November 2025 ohne Datenverluste, der Spend-Cube ist am Tag eins funktionsfähig — Kosten der vorgelagerten Modellierung 84.000 Euro, vermiedene Migrationsrisiken nach interner Schätzung über 600.000 Euro.

Typische Fehler & Verhandlungskontext

Der häufigste Fehler ist die Verwechslung von Datenmodell und Datenbankschema — viele Mittelständler haben das physische Schema (SAP-Tabellen) implementiert, ohne je ein logisches Modell zu dokumentieren; bei jeder Erweiterung beginnt die Architektur von vorn. Zweitens werden Custom-Felder ohne Modell-Update eingeführt und sind nach drei Jahren niemandem mehr erklärbar. Drittens fehlt die Synchronisation mit Nachbarmodellen — der Einkauf modelliert seinen Lieferanten anders als die Buchhaltung den Kreditor, mit dem Ergebnis, dass das Business-Partner-Konzept in S/4HANA nicht greift. Im Verhandlungskontext mit Software-Anbietern ist ein dokumentiertes Datenmodell entscheidend: Wer SAP MDG, Informatica oder ein neues ERP einführt, kann auf Basis eines vorhandenen Modells den Implementierungsaufwand realistisch schätzen — typischerweise sinkt das Projektbudget um 15 bis 25 %, weil weniger Reverse-Engineering nötig ist. Auch in Audits hat das Modell Bedeutung: ISO-9001-Auditoren prüfen 2026 zunehmend die Nachvollziehbarkeit von Datenflüssen, und ein dokumentiertes Modell ist der direkteste Nachweis. Anti-Pattern: "Wir machen das modellfrei agil" — funktioniert in Frontend-Apps, aber nicht im Einkaufsstamm, wo Datenkonsistenz über Jahrzehnte nachgewiesen werden muss.

Verwandte Begriffe

[[stammdatenmanagement-mdm]], [[datenqualitaet-einkauf]], [[data-governance-einkauf]], [[dublettenerkennung]], [[datenkatalog-einkauf]], [[etl-prozess-einkauf]], [[data-steward]], [[klassifizierungsquote]], [[golden-record]], [[match-merge-regeln]], [[datenbereinigung-einkauf]], [[master-data-governance]], [[datenowner]], [[datenqualitaetsbericht]]