Von SAP in den Shop: Produktdaten zwischen ERP und PIM automatisieren

Der Engpass, den niemand fotografiert

Ich sage es direkt: Der langsamste Teil der meisten Produktlaunches ist nicht die Fertigung und nicht das Marketing. Es ist ein Mensch, der Daten aus einem ERP kopiert, Materialnummern und technische Codes in etwas umschreibt, das ein Kunde lesen kann, das Ganze in fünf Sprachen übersetzt und in einen Shop oder ein PIM einfügt. Jedes neue Produkt wartet in dieser Warteschlange.

Das ist kein Chatbot-Problem. Es ist ein Pipeline-Problem, und es ist eines der lohnendsten Automatisierungsziele in jedem Unternehmen, das physische Produkte verkauft. Das ERP hält bereits die Wahrheit. Der Shop braucht eine Übersetzung dieser Wahrheit. KI übernimmt die Übersetzung, ein PIM setzt die Regeln durch, und ein Mensch prüft die Ausnahmen.

Dein ERP ist die Source of Truth für SKU, Preis und Bestand. Es ist nicht die Source of Truth für eine gute Produktbeschreibung. Hör auf, Menschen diese Lücke von Hand überbrücken zu lassen.

Wir bauen diese Pipelines als Teil unserer Data-Engineering-Practice, und wir betreiben selbst eine in unserer Exfinity-Plattform, um Lieferantenkataloge in großem Maßstab zu normalisieren. Dieser Guide ist die Architektur. Den Business Case hinter der Automatisierung solcher Backoffice-Arbeit findest du in Echte KI ist kein Chatbot.

Wen interessiert was

Die Arbeitsteilung: ERP versus PIM

Das Erste, was stimmen muss, ist konzeptionell, nicht technisch. SAP oder jedes andere ERP verwaltet transaktionale Daten: Materialstammsätze, Preise, Bestände, Beschaffung. Ein PIM verwaltet Kanal-Content: Beschreibungen, technische Spezifikationen, digitale Assets, Kategorisierung. Wenn du beide integrierst, bleibt das ERP autoritativ für SKUs, Preise und Bestände, und das PIM übernimmt die Anreicherung für den Shop, Marktplätze und andere Kanäle.

Verwisch diese Linie und du bekommst das klassische Chaos: Preise, die im PIM editiert werden und vom ERP wegdriften, oder Beschreibungen, die in SAP gepflegt werden und die kein Marketer anfassen kann. Halte sie sauber und jedes System macht das, was es gut kann. Unser PIM-Implementierungs-Guide behandelt das Governance-Modell im Detail.

Die Pipeline, Ende zu Ende

So sieht der automatisierte Flow aus.

SAP / ERP
   │  (material master, feeds, exports)
   ▼
Extract ──▶ Map ──▶ Enrich ──▶ Translate ──▶ Review ──▶ Publish
             │        │           │            │           │
       ERP language  fill        multi-      human on    PIM / shop
       to shop       missing     language    exceptions   (governed)
       attributes    fields

Drei Stellen, an denen du KI einsetzen kannst, und zu wissen, welche du nutzt, ist der Unterschied zwischen einer sauberen Pipeline und einem teuren Chaos.

Pre-Processing, vor dem PIM-Import: rohe ERP-Felder normalisieren und ins PIM-Schema mappen.

In-PIM-Anreicherung, als Workflow-Schritt: Beschreibungen und Attribute im PIM generieren, dort, wo die Qualitätsregeln leben.

Post-Processing, pro Kanal: den angereicherten Content für einen bestimmten Marktplatz oder eine bestimmte Storefront zuschneiden.

Für die meisten B2B-Kataloge liegt der wertvollste Einsatzpunkt in der Transformation zwischen ERP-Sprache, also Materialnummern und technischen Codes, und Shop-Sprache, also kundenfreundlichen Beschreibungen und Filterattributen. Genau dort verdient ein Modell seine Kosten.

Extraktion und Mapping: erst Regeln, dann Modell

Der teure Fehler ist, ein Modell jedes Feld jedes Produkts lesen zu lassen. Das ist langsam, teuer und schwer zu auditieren. Das Produktionsmuster ist hybrid: Deterministische Regeln und Feld-Mappings erledigen die strukturierte Arbeit, und ein Modell füllt nur die Lücken.

In unserer eigenen Ingestion-Pipeline für Exfinity kommen Lieferantendaten über Konnektoren, Feeds und einen Crawler an, und ein hybrider Extraktor wendet zuerst feste Selektoren und Mapping-Regeln an und ruft ein Modell nur für Felder auf, die die Regeln nicht auflösen konnten. Er trackt Token-Verbrauch und geschätzte Kosten pro Job, damit die Modellausgaben sichtbar und steuerbar sind statt ein mysteriöser Kostenposten. Derselbe Ansatz funktioniert für ERP-Exporte.

// Hybride Extraktion: Regeln lösen, was sie können, das Modell füllt den Rest
function extractProduct(raw, mapping) {
  const fields = {};
  for (const rule of mapping.fields) {
    const value = applyRule(raw, rule);      // Selektor / Regex / direktes Mapping
    if (value != null) fields[rule.target] = value;
  }
  const missing = mapping.fields.filter((r) => fields[r.target] == null);
  if (missing.length) {
    Object.assign(fields, callModelForGaps(raw, missing)); // Modell nur für Lücken
  }
  return normalize(fields);                    // ein Schema, validiert
}

Alles konvergiert zu einem normalisierten Schema, validiert gegen das, was das Zielsystem akzeptiert. Unser Guide zu Produktdaten-Systemen geht tiefer auf sauberes Modellieren ein, und das allgemeine Prinzip steht in unserem Guide zu API-Design für langlebige Systeme.

Anreicherung und Übersetzung: der Teil, den KI gut kann

Sobald die Daten gemappt sind, ist die Anreicherung der Ort, an dem KI glänzt und an dem ein PIM sie ehrlich hält. Ein Modell kann einen knappen Materialsatz in eine lesbare Beschreibung verwandeln, fehlende Attribute vorschlagen und in jede Sprache übersetzen, in der du verkaufst. Das PIM setzt dann die Regeln durch: keine verbotenen Claims, Pflichtattribute vorhanden, konsistente Formatierung.

Die Disziplin, die Produktion von einer Demo trennt:

1. Vollständigkeit scoren. Liegt ein generierter Datensatz unter einer Vollständigkeits-Schwelle, wird er nicht automatisch publiziert. Er geht in den Review.
2. Anreicherung reviewbar halten. Ein falsches Attribut im Katalogmaßstab ist ein Rückruf oder eine Retourenwelle. Generierter Content ist ein Entwurf, bis ein Mensch oder eine Regel ihn freigibt.
3. Strukturell übersetzen, nicht blind. Einheiten, Teilenummern und strukturierte Attribute erhalten. Die Prosa übersetzen, nicht die SKU.

Das ist das Human-in-the-Loop-Muster auf Katalogdaten angewandt, und im großen Maßstab ist es nicht verhandelbar. Ein Modell, das ungeprüfte Produkt-Claims publiziert, ist eine Haftung, kein Feature.

Mehrsprachig aus einer Quelle

Übersetzung ist der Punkt, an dem der manuelle Prozess am meisten wehtut, weil sie jedes Produkt mit der Anzahl deiner Märkte multipliziert. Ein Mensch, der fünf Sprachen von Hand pflegt, macht dieselbe Anreicherung fünfmal, und die Übersetzungen driften auseinander, sobald sich die Quelle ändert.

Die Pipeline löst das, indem sie Sprache als Output-Dimension eines einzigen Quelldatensatzes behandelt, nicht als fünf separate Datensätze, die gepflegt werden müssen. Das angereicherte Produkt wird einmal generiert, in jede Locale übersetzt und pro Sprache publiziert, sodass eine Änderung an der Quelle in jeden Markt fließt, statt neu eingetippt zu werden. In unserer eigenen Exfinity-Ingestion wird jedes Produkt einmal pro konfigurierter Locale indexiert, und ein neuer Markt macht bestehende Produkte dort verfügbar, ohne dass irgendetwas neu erfasst wird. Dieselbe Form funktioniert zwischen einem ERP und einem Multi-Markt-Shop: eine Quelle unter Governance, viele publizierte Sprachen, keine manuelle Duplizierung. Strukturierte Attribute wie Einheiten und Teilenummern laufen unangetastet durch, und nur die Prosa wird übersetzt, damit eine SKU nie in etwas "lokalisiert" wird, das ein Lager nicht mehr zuordnen kann.

Der harte Teil: Concurrency

Hier ist der Fehlermodus, der naive Pipelines versenkt. Ein Batch-Anreicherungsjob und ein menschlicher Editor fassen dasselbe Produkt zur gleichen Zeit an. Ohne Transaktionsdisziplin überschreibt einer den anderen stillschweigend, und dein Katalog hat eine Änderung verloren, die niemand bemerkt, bis sich ein Kunde beschwert.

Deshalb haben wir PimTx gebaut, eine Transaktions- und Concurrency-Schicht für Enterprise-PIM-Arbeit. Sie weigert sich, stillschweigend zu überschreiben: Konkurrierende Writes werden erkannt und durch eine explizite Strategie aufgelöst statt Last-Write-Wins, sodass ein Hintergrundjob und eine menschliche Änderung sich nicht leise gegenseitig plattmachen können. Wenn du Writes in ein System automatisierst, das auch Menschen editieren, ist das nicht optional.

Die zugrunde liegenden Prinzipien behandeln wir in unserem Guide zu Concurrency und Datenintegrität. Wenn deine Automatisierung in ein Live-System schreibt, lies das, bevor du shipst.

Frisch halten: Sync statt One-Shot

Ein Produktkatalog wird nicht einmal geladen und fertig. Preise ändern sich im ERP, neue Produkte erscheinen, alte werden ausgemustert. Die Pipeline muss nach Zeitplan laufen und mit Änderungen umgehen, ohne alles neu zu verarbeiten.

Drei Eigenschaften machen Sync zuverlässig.

Exfinity aktualisiert seinen Katalog nach Zeitplan pro Quelle, schiebt Datensätze, die es nicht verarbeiten kann, in eine Dead-Letter-Queue, damit nichts stillschweigend verloren geht, und re-indexiert pro Sprache ohne Redeploy. Das allgemeine Muster steht in unserem Guide zu Event-getriebener Architektur. Das ist Standard-Disziplin im Data Engineering, und sie zu überspringen ist der Weg, auf dem Kataloge verrotten.

Was es kostet und wann es sich rechnet

Der Return skaliert mit der Katalog-Geschwindigkeit. Wenn du eine Handvoll Produkte pro Jahr launchst, automatisiere etwas anderes. Wenn du Hunderte oder Tausende launchst und jedes davon aktuell in einer manuellen Daten-Warteschlange wartet, kommt der Payback schnell, weil du einen Engpass entfernst, der Umsatz blockiert, nicht nur Kosten.

Die ehrliche Größenordnung: Eine gut geschnittene ERP-zu-PIM-Pipeline erreicht Produktion in Wochen, und die Modellkosten sind steuerbar, weil Regeln den Großteil der Arbeit machen. Skizziere eine grobe Spanne mit unserem Kalkulator, und hol dir dann eine echte Zahl für deinen Katalog über unseren Angebots-Flow. Unser Consulting-Team scopet Phase eins mit dir.

Wie das typischerweise schiefgeht

1. KI jedes Feld lesen lassen. Langsam, teuer, nicht auditierbar. Erst Regeln, Modell nur für Lücken.
2. ERP- und PIM-Ownership verwischen. Preise, die zwischen Systemen driften, sind ein Datenintegritäts-Albtraum. Halte die Linie sauber.
3. Generierten Content automatisch publizieren. Ungeprüfte Produkt-Claims im großen Maßstab sind ein Rechts- und Retourenrisiko. Reviewe die Ausnahmen.
4. Keine Transaktionsschicht. Batch-Jobs und menschliche Änderungen werden kollidieren. Erkenne Konflikte, überschreibe nicht stillschweigend.
5. One-Shot-Importe. Kataloge ändern sich täglich. Baue inkrementellen, idempotenten, beobachtbaren Sync.

Wer das baut

Oronts ist ein gründergeführtes Softwareunternehmen in München. Refaat Al Ktifan, unser Gründer und Solution Architect, führt ein Senior-Team über Backend, Data und Commerce. Wir haben Produktdaten-Pipelines für Enterprise-Kataloge gebaut, und wir betreiben eine in Exfinity. PimTx ist unsere eigene Antwort auf das Concurrency-Problem, das diese Pipelines erzeugen. Wir designen den Flow, bauen Extraktion, Anreicherung und Sync und übergeben dir ein System, das dir gehört und das du selbst betreiben kannst. Sieh dir unsere Seiten Services und Solutions an.

Takeaways

• Produktdaten-Automatisierung ist eine Pipeline, kein Chatbot, und eines der lohnendsten Ziele im Commerce.
• Halte das ERP autoritativ für SKU, Preis und Bestand, und lass das PIM die Anreicherung besitzen.
• Extrahiere zuerst mit Regeln und nutze ein Modell nur für die Lücken, um Kosten und Audit im Griff zu behalten.
• Reviewe generierten Content und übersetze strukturell, publiziere Claims nie automatisch im großen Maßstab.
• Nutze eine Transaktionsschicht, damit automatisierte Writes und menschliche Änderungen sich nicht stillschweigend gegenseitig überschreiben.

Das Ziel ist nicht, Menschen aus den Produktdaten zu entfernen. Es ist, das Copy-Paste zu entfernen, damit deine Leute ihre Zeit mit den Ausnahmen und der Qualität verbringen, nicht mit der Tastatur.

Wenn Produktlaunches an der Dateneingabe hängen, erzähl uns von deinem ERP und PIM. Starte bei Kontakt oder hol dir ein sauber gescoptes Angebot.