Artikelstammdaten in ERP, PIM und Onlineshop: Wer hält was – und wo ist der Single Point of Truth?

E-Commerce
,
1

In fast jedem Projekt mit ERP + PIM + Onlineshop kommt früher oder später die gleiche Frage:
Welche Artikelinformationen werden wo gepflegt – und welches System ist für welches Attribut die „Single Source of Truth“?
Wenn das nicht sauber definiert ist, entstehen Dublettenpflege, widersprüchliche Daten (Preis, Beschreibung, Verfügbarkeit) und im schlimmsten Fall falsche Ausspielungen im Shop.

Dieser Thread sammelt ein praxiserprobtes Vorgehen, wie man die Verantwortlichkeiten und Datenflüsse beherrschbar aufsetzt.

1) Grundprinzip: „Single Source of Truth“ ist oft attributbasiert (nicht systembasiert)

In der Realität ist selten ein System „das führende System für alles“. Häufig ist die Lösung:
Pro Attributgruppe ein führendes System definieren (und die anderen Systeme sind Konsumenten).

Typische Aufteilung (als Orientierung):

  • ERP (z. B. Haufe X360): kaufmännische/logistische Stammdaten

  • PIM: Marketing-/Produktcontent, Variantenlogik, Medien, Katalogstruktur

  • Shop: kanal-/frontend-spezifische Anreicherungen (z. B. SEO/Sortierung), aber idealerweise wenig „Stammdatenführung“

2) Beispiel: Attributgruppen und sinnvolle Führungslogik

ERP als führend (häufig)

  • Artikelnummer/SKU, Einheit, Steuer-/Kontierungslogik

  • Disposition/Bestand, Lieferzeiten (falls aus ERP), Status „verkaufbar“ (wenn Prozesse dort liegen)

  • Einkaufskonditionen, Verkaufspreise (je nach Preislogik/Channel-Strategie)

  • Basis-Klassifikationen, die prozessrelevant sind

PIM als führend (häufig)

  • Produktbeschreibungen, Bullet Points, technische Datenblätter

  • Bilder/Medien, Kategorien/Taxonomien, Übersetzungen

  • Varianten-/Attributmodelle für die Ausspielung (Größe/Farbe etc.)

  • Katalog-/Sortimentslogik (was wird wo ausgespielt)

Shop als führend (sparsam einsetzen)

  • SEO-Elemente (Meta Title/Description), Landingpage-Logik

  • Merchandising (Sortierungen, Cross-/Upsell-Regeln)

  • Channel-spezifische Texte, wenn nicht im PIM abbildbar
    Ziel: Shop sollte möglichst wenig „Stammdaten-Hauptpflege“ sein, sonst wird er zur Schattenquelle.

3) Governance-Fragen, die in Projekten oft unterschätzt werden

  • Wer darf welche Attribute ändern? (Rollen: Einkauf, Produktmanagement, Marketing, eCommerce)

  • Wie werden Änderungen versioniert/freigegeben? (4-Augen, Staging, Veröffentlichungsworkflow)

  • Wie gehen wir mit Konflikten um? (z. B. PIM vs. ERP schreibt ein Feld)

  • Wie verhindern wir „Schattenpflege“ im Shop? (Locking, Read-only Felder, klare Prozesse)

4) Integrationslogik: „Write once, distribute“ statt „Edit everywhere“

Bewährt hat sich:

  • pro Attributgruppe ein Schreibsystem

  • die anderen Systeme bekommen die Daten automatisiert (Schnittstelle, Eventing, nächtliche Läufe – je nach Bedarf)

  • klare Regeln, wann publiziert wird (z. B. PIM-Release → Shop)

5) Typische Stolpersteine (aus der Praxis)

  • Preise in 2 Systemen gepflegt (ERP + Shop) → Abweichungen, Reklamationen

  • Produkttexte/Bilder im Shop „schnell angepasst“ → PIM wird umgangen, Inkonsistenzen wachsen

  • Variantenlogik nicht sauber modelliert (ERP anders als PIM) → fehlerhafte Zuordnungen im Shop

  • Keine eindeutigen Keys/IDs (SKU/EAN/VariantID) → Matching-Probleme in Schnittstellen

Fragen an die Community

  1. Habt ihr in ERP/PIM/Shop eine attributbasierte Führungslogik definiert – oder eher „System X ist führend“?

  2. Welche Attributgruppe verursacht bei euch am meisten Konflikte: Preis, Varianten, Texte/Medien, Verfügbarkeit?

  3. Wie stellt ihr sicher, dass der Shop nicht zur Schattenquelle wird?