PIM, ERP oder Frontend: Wo Kanal-Exporte wirklich zusammenlaufen sollten

Wenn ein Kanal-Export scheitert, zeigt sich meistens erst danach, dass niemand vorher entschieden hat, wem die betroffene Information gehört. Ein Preis, der auf drei Marktplätzen unterschiedlich ankommt. Eine Produktbeschreibung, die im Feed-Tool anders klingt als auf der Storefront. Eine Locale-Regel, die in drei Systemen leicht unterschiedlich implementiert ist und beim vierten Kanal bricht. In fast jedem dieser Fälle war die technische Ausleitung nicht das Problem. Das Problem war eine fehlende Landkarte: welche Schicht besitzt welche Wahrheit, und wo darf eine Information verwendet, aber nicht neu definiert werden. Dieser Post zieht diese Grenze bewusst, bevor sie im Sales-Call zur Rückfrage wird, und er zieht sie ohne Weichzeichner: Laioutr ist kein PIM und kein System of Record für Produktdaten. Wir orchestrieren, wir besitzen nicht.

Die Kernfrage, die jeder Sales-Call irgendwann stellt

Wer ein Frontend-Projekt aufsetzt, stößt früher oder später auf die Frage: "Kann das Frontend auch unsere Produktdaten pflegen?" Die ehrliche Antwort ist nein, und sie sollte nein bleiben, unabhängig davon, wie unbequem sie im ersten Moment klingt. Ein Frontend-Layer, der anfängt, Produktattribute zu pflegen, Klassifikationen zu verwalten oder Medien-Zuordnungen zu entscheiden, übernimmt eine Verantwortung, für die er nicht gebaut ist. Er hat keine Governance-Workflows für Datenqualität, keine Versionierung von Attributsets, keine Freigabeprozesse für neue Kategorien. Das sind PIM-Aufgaben, und sie bleiben es auch dann, wenn ein Frontend technisch in der Lage wäre, ein Feld zu schreiben.

Die eigentliche Frage lautet also nicht "kann das Frontend das", sondern "soll eine Schicht das tun, nur weil sie es kann". Genau hier entstehen die meisten Architekturfehler, die später als Datenqualitätsprobleme auftauchen. Ein Team, das kein PIM hat, empfindet den Frontend-Layer als naheliegenden Ausweg, weil er sichtbar ist und schnell reagiert. Aber ein fehlendes PIM ist ein fehlendes PIM. Es wird nicht durch ein leistungsfähiges Frontend ersetzt, es wird durch die Einführung eines PIM gelöst. Alles andere verschiebt das Problem nur in eine Schicht, die dafür nicht ausgelegt ist, und produziert langfristig genau die Inkonsistenzen, die man eigentlich vermeiden wollte.

ERP: Die kaufmännische Wahrheit

Das ERP ist und bleibt die Quelle für alles, was mit Geld, Recht und Logistik zu tun hat. Preise, Steuerlogik, Bestandsmengen, Auftragsstatus, Zahlungsbedingungen, Lieferzeiten: das sind kaufmännische Fakten, die aus einem System kommen müssen, das transaktionale Konsistenz garantiert. Wenn zwei Systeme parallel behaupten, einen aktuellen Bestand zu kennen, ist mindestens eines davon falsch, und in der Praxis stellt sich meistens heraus, dass beide falsch sind, weil sie zu unterschiedlichen Zeitpunkten synchronisiert wurden.

Diese Eindeutigkeit ist kein Nachteil des ERP, sie ist sein Zweck. Ein ERP ist bewusst restriktiv gebaut, weil kaufmännische Daten Audit-Trails, Buchungslogik und rechtliche Nachvollziehbarkeit brauchen. Genau deshalb ist es der falsche Ort für Produktbeschreibungen, Marketing-Content oder Bildmaterial. Ein ERP, das versucht, auch Content zu verwalten, wird entweder zu einem schlechten CMS, oder das Content-Feld bleibt leer, weil niemand im ERP-Team dafür verantwortlich ist. Beides ist schlecht, und beides sehen wir regelmäßig in Systemen, die historisch gewachsen sind, ohne dass jemand die Zuständigkeit klar gezogen hat.

Für eine Frontend Management Platform (FMP) wie Laioutr bedeutet das: kaufmännische Felder werden aus dem ERP oder aus einem vorgelagerten Commerce-System gelesen, nicht neu erfunden. Wenn ein Preis im Frontend anders aussieht als im ERP, ist das ein Bug in der Anbindung, kein Feature. Diese Klarheit muss von Anfang an im Datenmodell verankert sein, sonst entstehen genau die Sync-Konflikte, die sich später nur noch mit manuellem Abgleich reparieren lassen.

PIM: Die Produktdaten-Wahrheit

Das PIM ist das System of Record für alles, was ein Produkt inhaltlich ausmacht: Attribute, Klassifikation, Varianten-Struktur, Medien-Zuordnung und die Workflows, die sicherstellen, dass ein neues Produkt vollständig und konsistent angelegt ist, bevor es live geht. Diese Datenqualitäts-Workflows sind der eigentliche Wert eines PIM. Sie sind der Grund, warum ein Redakteur nicht versehentlich ein Pflichtfeld leer lässt, warum ein Attribut nur einmal zentral definiert wird und nicht in fünf Systemen leicht unterschiedlich, und warum eine Kategorie-Umstrukturierung an einer Stelle passiert statt an zehn.

Ein gut geführtes PIM ist kanalunabhängig aufgebaut. Das ist der Punkt, an dem viele Implementierungen scheitern: sobald kanalabhängige Transformationslogik ins PIM wandert, bläht sich das Datenmodell auf. Ein Attribut für "Titel, wie er auf Marktplatz A erscheinen soll" und ein zweites für "Titel, wie er auf Marktplatz B erscheinen soll" sind keine Produktdaten mehr, sie sind Kanal-Konfiguration, die im PIM nichts zu suchen hat. Jedes Mal, wenn ein neuer Kanal dazukommt, müsste das PIM-Schema erweitert werden, und genau das macht PIM-Projekte teuer und langsam in der Wartung.

Die saubere Trennung sieht anders aus: das PIM liefert die neutrale, kanalunabhängige Wahrheit über ein Produkt. Titel, Beschreibung, Attribute, Bilder in ihrer Ursprungsform, Klassifikation nach einem einheitlichen Schema. Was daraus für einen bestimmten Kanal wird, ist eine Transformationsfrage, keine Datenfrage. Diese Unterscheidung ist der wichtigste Hebel, um ein PIM langfristig wartbar zu halten, und sie ist gleichzeitig die Grundlage dafür, dass ein Frontend-Layer wie Laioutr überhaupt sinnvoll andocken kann, weil er auf ein stabiles, nicht kanalverschmutztes Datenmodell trifft.

Frontend und Orchestrierung: Zusammenführung, nicht Besitz

Der Frontend- beziehungsweise Orchestrierungs-Layer hat eine andere Aufgabe als ERP und PIM: er führt zusammen, was aus verschiedenen Quellen kommt, löst Locale-Kontexte auf, wendet kanalabhängige Transformation an und entscheidet, wie eine Information im jeweiligen Rendering-Kontext dargestellt wird. Das ist Orchestrierung, nicht Datenhaltung. Eine Frontend Management Platform (FMP) liest Preis und Bestand aus dem ERP, Attribute und Medien aus dem PIM, und fügt beides mit Content-Modulen, Personalisierungslogik und Markenregeln zu einer konkreten Ausgabe zusammen, die für den jeweiligen Kanal passt.

Genau hier gehört die kanalabhängige Transformation hin, die im vorherigen Abschnitt bewusst aus dem PIM herausgehalten wurde. Wenn ein Marktplatz eine gekürzte Titelvariante braucht, ein anderer Kanal ein anderes Bildformat erwartet, und die eigene Storefront eine dritte Darstellung nutzt, ist das eine Frage der Ausleitung, nicht der Quelle. Der Orchestrierungs-Layer kennt die Regeln pro Kanal und wendet sie auf die neutrale PIM-Wahrheit an, ohne diese Wahrheit zu verändern. Das PIM bleibt sauber, der Kanal bekommt trotzdem, was er braucht.

Auch Locale-Auflösung gehört hierher, und zwar an genau einer Stelle, nicht dreifach gepflegt in ERP, PIM und Feed-Tool gleichzeitig. Wenn ein Team feststellt, dass die gleiche Sprachregel in drei Systemen separat konfiguriert ist, ist das ein verlässliches Zeichen dafür, dass die Zuständigkeit nicht geklärt wurde. Ein composable Frontend-Layer wie Laioutr übernimmt diese Auflösung zentral: eine Regel, ein Ort, konsistente Ausleitung in alle angeschlossenen Kanäle. Das reduziert nicht nur Wartungsaufwand, es verhindert auch, dass sich Regeln im Lauf der Zeit unbemerkt auseinanderentwickeln.

Die typischen Fehlzuordnungen im Überblick

In der Praxis wiederholen sich vier Muster, und alle vier haben die gleiche Ursache: eine Schicht übernimmt eine Aufgabe, weil sie technisch dazu in der Lage ist, nicht weil sie dafür der richtige Ort ist. Das erste Muster ist kanalabhängige Transformationslogik im PIM, die das Datenmodell mit jeder neuen Kanal-Anforderung weiter aufbläht, bis das Schema unübersichtlich und teuer in der Pflege wird.

Das zweite Muster ist Marketing-Content im ERP, meist entstanden, weil ein Team kein PIM hatte und das ERP als einzig verfügbaren Ort für "irgendwo muss der Text ja hin" genutzt hat. Das funktioniert kurzfristig, produziert aber langfristig ein System, das weder gute Buchhaltung noch gutes Content-Management leistet.

Das dritte Muster ist Produktdaten-Wahrheit im Feed-Tool: ein Marktplatz-Konnektor oder Kanal-Adapter, der anfängt, eigene Attribut-Überschreibungen zu speichern, weil das PIM sie nicht liefert. Damit entsteht eine zweite, inoffizielle Produktwahrheit, die niemand systematisch zurückspielt, und die bei der nächsten PIM-Migration verloren geht.

Das vierte Muster ist dreifach gepflegte Locale-Logik, wie im vorherigen Abschnitt beschrieben. Alle vier Muster lassen sich vermeiden, wenn eine Organisation vor der technischen Umsetzung die Zuständigkeitsfrage explizit beantwortet, statt sie implizit durch die nächstliegende technische Möglichkeit zu klären.

Was Laioutr nicht ist

An dieser Stelle lohnt sich Klarheit statt Diplomatie: Laioutr ist kein PIM und kein System of Record für Produktdaten. Wir speichern keine Attribute dauerhaft als Quelle der Wahrheit, wir verwalten keine Klassifikationsbäume, und wir ersetzen keine Datenqualitäts-Workflows, die ein PIM bietet. Unsere Aufgabe ist die Orchestrierung: Daten aus ERP, PIM und weiteren Quellen zusammenführen, Content-Layer und Personalisierung ergänzen, und das Ergebnis kanalgerecht ausleiten, egal ob Storefront, Marktplatz oder ein weiterer Vertriebskanal.

Wer aktuell ohne PIM arbeitet und hofft, dieses Fehlen durch ein leistungsfähiges Frontend zu kompensieren, wird das Problem nicht lösen, sondern verschieben. Ein Frontend kann keine Datenqualität erzeugen, die an der Quelle nicht existiert. Es kann bestehende, saubere Daten hervorragend orchestrieren, aber es kann kein fehlendes System of Record ersetzen. Das ist keine Einschränkung, die wir bedauern, es ist eine bewusste Architekturentscheidung: eine Frontend Management Platform (FMP), die versucht, gleichzeitig PIM zu sein, verliert die Fähigkeit, in beiden Rollen gut zu sein.

Das bedeutet konkret: bevor ein Projekt mit Laioutr startet, ist es sinnvoll zu klären, ob ein PIM bereits vorhanden oder in Planung ist. Wenn nicht, ist der nächste Schritt nicht die Frontend-Auswahl, sondern die PIM-Einführung, zum Beispiel mit Pimcore als Produktdaten-Layer, an den Laioutr sich anschliesst. Diese Reihenfolge spart später Monate an Nacharbeit.

Die Entscheidungs-Heuristik für jede neue Logik

Wenn eine neue Anforderung auftaucht, hilft eine einfache Frage, um die richtige Schicht zu bestimmen: "Ist das eine Frage von Wahrheit, oder eine Frage von Darstellung?" Wenn es um kaufmännische Wahrheit geht, gehört die Logik ins ERP. Wenn es um die inhaltliche Wahrheit eines Produkts geht, gehört sie ins PIM. Wenn es um die Frage geht, wie diese Wahrheit für einen bestimmten Kanal, eine bestimmte Sprache oder einen bestimmten Nutzungskontext dargestellt wird, gehört sie in den Orchestrierungs-Layer.

Eine zweite, ergänzende Frage lautet: "Muss diese Regel für alle Kanäle gleichzeitig gelten, oder unterscheidet sie sich je Kanal?" Regeln, die für alle Kanäle identisch gelten sollen, wie eine Attributdefinition oder eine Steuerlogik, gehören dorthin, wo die Wahrheit liegt. Regeln, die sich je Kanal unterscheiden, wie Formatierung, Kürzung oder Locale-spezifische Darstellung, gehören in die Orchestrierung.

Diese beiden Fragen reichen in der Praxis fast immer aus, um eine neue Anforderung korrekt zuzuordnen, bevor sie zu technischer Schuld wird. Wer sie konsequent vor jeder Implementierungsentscheidung stellt, vermeidet die vier Fehlzuordnungen aus diesem Post, unabhängig davon, welches PIM, welches ERP und welche Frontend-Lösung im Einsatz sind.

Fazit: Klare Grenzen sind kein Nachteil

Eine saubere Zuständigkeits-Landkarte ist kein bürokratisches Extra, sie ist die Voraussetzung dafür, dass Kanal-Exporte langfristig stabil bleiben. ERP besitzt die kaufmännische Wahrheit, PIM besitzt die Produktdaten-Wahrheit, und der Frontend- beziehungsweise Orchestrierungs-Layer führt beides zusammen, ohne eine der beiden Wahrheiten zu verdoppeln oder zu verwässern. Laioutr positioniert sich bewusst in der dritten Rolle und nicht in den ersten beiden. Mehr zu unserem composable Frontend-Ansatz findest du unter Composable Headless Frontend, zu unserem Content-Management-Modell unter Content Management, zur Pimcore-Anbindung unter Pimcore-Anbindung, und zur Frage, wie mehrere Marken und Märkte auf einer gemeinsamen Datenbasis arbeiten, unter Multi-Brand und Multi-Market.

Wie Kanal-Exporte konkret aus dem Frontend-Layer heraus organisiert werden, beschreiben wir vertiefend unter product data channel distribution frontend layer, und die neun häufigsten Fehler bei Produktdaten-Exporten haben wir separat gesammelt unter nine product data export errors frontend. Wer diese Grenzen früh zieht, spart sich später den Sales-Call, in dem die Frage ungeplant auftaucht.