Die meisten ERP-Evaluationen starten mit denselben Kriterien: Lagerverwaltung, Auftragsabwicklung, Buchhaltung, Schnittstellen zu Marktplätzen. Produktdaten werden dabei meist nur aus interner Sicht betrachtet. Was es braucht, damit ein Produkt konsistent über mehrere Kanäle, Länder und Zielgruppen verkauft wird, kanalspezifische Attribute, Übersetzungen, Bildformate, Qualitätschecks, bleibt außen vor. Verantwortlich gemacht wird dafür häufig das fehlende PIM-System. Dabei liegt die eigentliche Ursache tiefer: Die meisten ERPs sind für diesen vertrieblichen Blick auf Produktdaten schlicht nicht gebaut.
In diesem Beitrag geht es um eine Frage, die ERP-Suche und PIM-Suche gleichzeitig betrifft: Müssen PIM und ERP wirklich zwei Systeme sein? Wir schauen uns an, wo ERPs bei Produktdaten strukturell an ihre Grenzen stoßen, was eine Schnittstellenlösung wirklich bedeutet – und welche Alternative es gibt.
Produktdaten im ERP: die unbequeme Wahrheit
Ein ERP kennt deine Produkte. Aber es kennt sie als Stammdaten – Artikelnummer, Einkaufspreis, Lagerort, Steuerklasse, Lieferant. Das reicht für Beschaffung, Lagerverwaltung und Buchhaltung, und genau dafür ist ein ERP gebaut.
Was das ERP dabei nicht abbildet, ist Produktdatenmanagement im eigentlichen Sinne. Der Unterschied ist nicht trivial:
- Stammdaten beschreiben ein Produkt aus Prozess-Sicht: Was kostet es, wo liegt es, wer liefert es?
- Produktdaten beschreiben es aus Kommunikations-Sicht: Wie heißt es auf Englisch, welche Attribute gehören zu welchem Kanal, welche Bilder in welcher Auflösung?
Das meiste, was im ERP unter "Artikelstamm" läuft, deckt die erste Kategorie ab. Varianten mit eigener Attributstruktur, kanalspezifische Pflichtfelder, Qualitätschecks für Vollständigkeit, vererbte Attribute von Produktgruppen auf Varianten – das sind Anforderungen, für die ERP-Systeme nicht konzipiert wurden.
Für kleine Sortimente mit wenig Kanalvielfalt fällt das kaum auf. Mit wachsendem Sortiment, mehr Marktplätzen und internationalem Vertrieb wird es zur Stellschraube, die alles andere ausbremst.
Warum die meisten Unternehmen dann eine Schnittstelle bauen – und was das wirklich kostet
Die klassische Antwort auf dieses Problem: ein PIM-System daneben stellen und via API verbinden. Auf dem Papier klingt das sauber. In der Praxis sieht es anders aus.
Jede Schnittstelle zwischen zwei Systemen bedeutet: Ein Team muss definieren, welche Felder wohin fließen. Jemand muss das Mapping pflegen, wenn ein System eine Feldstruktur ändert. Jemand muss entscheiden, welches System bei Konflikten recht hat – und wie Konflikte überhaupt erkannt werden.
Typische Probleme in der Realität:
- Datenfelder, die im ERP existieren, haben im PIM keine exakte Entsprechung und umgekehrt.
- Synchronisierungen laufen zeitverzögert. Lagerbestand und Produktstatus im Shop passen gelegentlich nicht zusammen.
- Wenn das ERP eine Artikelnummer ändert oder das PIM einen Feldnamen umbenennt, muss jemand die Schnittstelle anpassen.
- Fehler im Datenfluss sind schwer zu debuggen, weil kein System weiß, was das andere gerade macht.
Das sind keine Ausnahmefälle. Das ist der Alltag der meisten Unternehmen, die PIM und ERP separat betreiben. Der eigentliche Kostenpunkt ist dabei selten die Lizenz, sondern die Entwicklerstunden, die kontinuierlich in Schnittstellenpflege fließen, statt in Produktweiterentwicklung.
Was ein "echtes" PIM im Unterschied zum ERP-Stammdatenmodul kann
Bevor wir zur Frage kommen, ob PIM und ERP ein System sein müssen – ein kurzer Blick darauf, was ein vollständiges Product Information Management (PIM) abdeckt, das über einen Artikelstamm hinausgeht:
- Variantenmanagement: Strukturierte Verwaltung von Farben, Größen, Materialien als echte Varianten, nicht nur als separate SKUs ohne Verbindung.
- Attributvererbung: Produktgruppen definieren gemeinsame Attribute, Varianten erben und überschreiben sie gezielt.
- Kanalspezifische Pflichtfelder: Was auf Amazon Pflicht ist, unterscheidet sich von dem, was für Google Shopping oder den eigenen Shop benötigt wird. Ein PIM kann das pro Kanal erzwingen und prüfen.
- Qualitätschecks: Vollständigkeitsanzeigen pro Produkt und Kanal - du siehst, welche Produkte noch nicht bereit für die Veröffentlichung sind.
- Media Asset Management (MAM): Bilder, Videos und Dokumente strukturiert verknüpft - mit Formatvarianten pro Kanal.
- Mehrsprachigkeit: Texte und Attribute in mehreren Sprachen, sauber getrennt und gezielt ausspielbar.
- KI-Anreicherung: Automatische Generierung oder Vervollständigung von Produktbeschreibungen auf Basis vorhandener Attribute.
- Workflows: Freigabeprozesse, Aufgaben, Rollenvergabe - damit klar ist, wer was wann prüft, bevor Daten live gehen.
Diese Features sind in keinem ERP-Artikelstamm nativ vorhanden. Das ist der strukturelle Unterschied zwischen Stammdatenpflege und Produktinformationsmanagement. Mehr dazu in unserem Blogartikel: Die wichtigsten Features von PIM im E-Commerce.
Der dritte Weg: ERP, das ein ausgereiftes PIM nativ enthält
Hier lohnt es sich, die Prämisse zu hinterfragen: Warum sind PIM und ERP überhaupt zwei Systeme?
Historisch hat das mit dem Aufkommen des E-Commerce zu tun. ERPs waren für interne Prozesse gebaut. Als Online-Vertrieb, Marktplätze und internationale Shops dazukamen, war der Artikelstamm schnell überfordert. PIM-Systeme entstanden als Antwort auf diesen Bedarf, als Ergänzung, nicht als Ablösung.
Das Ergebnis: Viele Unternehmen haben heute zwei Systeme, die eigentlich dasselbe Produkt beschreiben aus unterschiedlichen Blickwinkeln, mit unterschiedlichen Feldern, synchronisiert über eine Schnittstelle, die jemand pflegen muss.
Die Frage ist, ob das sein muss.
Wenn Produktdaten, Bestandsdaten, Auftragsdaten und Kundendaten auf derselben Datenbasis liegen, entfällt das Mapping. Ein Artikel ist ein Artikel, mit all seinen Attributen, Bildern, Kanalkonfigurationen und gleichzeitig seinem Lagerort, Einkaufspreis und Lieferstatus. Keine Synchronisierung, kein Konfliktfall, kein Debug-Aufwand.
Hier kommt Hublify ins Spiel: eine modulare Commerce-Plattform, bei der PIM und ERP auf derselben Daten- und Softwarearchitektur aufbauen. Das PIM ist ein eigenständig nutzbares Modul und eben kein Fremdsystem, das angebunden werden muss. Die Schnittstelle mit allem, was sie an Aufwand, Pflege, Fehlerquellen und Abhängigkeiten mitbringen würde, entfällt vollständig.
Was das konkret bedeutet, zeigt sich am besten an einer Frage, die in getrennten Systemen aufwendig zu beantworten ist: Welche Produktvarianten werden auf welchen Kanälen besonders häufig retourniert – und warum? In Hublify liegen Retourendaten und Produktattribute im selben Datenraum. Analytics kann direkt auswerten, ob es die Größe ist, die Farbe oder eine bestimmte Materialkombination, die eine hohe Retourenquote treibt. In einem ERP mit angebundenem PIM wäre dafür erst ein manueller Datenabgleich aus zwei Systemen nötig oder ein BI-Tool, das beide Quellen separat anzapft.
Das bedeutet nicht, dass du gleich alle Systeme ersetzen musst. Du startest mit dem PIM. Und wenn du bereit bist, schaltest du weitere Module dazu: Order Management, Warehouse, CDM, Billing. Die Datenbasis bleibt dieselbe und du erhältst einen immer größeren Überblick über alle deine Daten.
Wann die Schnittstellen-Lösung trotzdem die richtige Wahl ist
Nicht jede Architektur ist für jeden Kontext die beste. Es gibt Situationen, in denen ein eigenständiges PIM neben einem bestehenden ERP die sinnvollere Wahl ist.
Ein bestehendes ERP, das nicht ersetzt werden kann oder soll: Wer tief in SAP oder einem anderen Großsystem verankert ist, wird das nicht kurzfristig abwickeln. Hier ist ein PIM als Standalone-Lösung, die sauber per API angebunden wird, ein pragmatischer Weg.
Regulatorische oder branchenspezifische ERP-Anforderungen: Manche Branchen setzen auf zertifizierte ERP-Lösungen mit spezifischen Compliance-Anforderungen. In diesen Fällen ist ein Systemwechsel keine realistische Option.
Klare, stabile Schnittstelle auf beiden Seiten: Wenn beide Systeme über dokumentierte, stabile APIs verfügen und das Mapping einmalig sauber definiert werden kann, hält sich der laufende Aufwand in Grenzen.
Auch in diesen Szenarien ist Hublify eine Option, als eigenständiges PIM, das neben einem bestehenden ERP läuft. Der Unterschied: Du weißt, dass du die Plattform später erweitern kannst, wenn die Rahmenbedingungen sich ändern.
Worauf du bei der Entscheidung achten solltest
Ob du ein ERP mit nativem PIM suchst oder ein PIM, das später zum vollständigen ERP wachsen kann – ein paar Leitfragen helfen bei der Einordnung:
Wie komplex sind deine Produktdaten?
Wenige Hundert Artikel mit einfacher Attributstruktur und einem Kanal lassen sich auch mit einem Artikelstamm managen. Ab mehreren Tausend Artikeln, mehreren Sprachen oder Marktplätzen mit eigenen Anforderungen brauchst du ein vollständiges PIM.
Wie viele Kanäle belieferst du – und wie unterschiedlich sind deren Anforderungen?
Onlineshop, Amazon, Otto, B2B-Portal, eigener Außendienst – je mehr Kanäle mit eigenen Datenformaten, desto teurer wird ein ERP ohne PIM im Betrieb.
Greenfield oder bestehendes ERP?
Wer von null startet oder ein veraltetes ERP ersetzt, hat die Chance, PIM und ERP von Anfang an als Einheit zu denken. Wer ein laufendes ERP ergänzen will, braucht eine Lösung, die sich sauber daneben stellen lässt.
Wie hoch sind deine Wachstumsambitionen?
Systeme, die heute ausreichen, können morgen zur Bremse werden. Eine modulare Plattform, die mit dir wächst, reduziert das Risiko, in zwei Jahren wieder vor einer Systemauswahl zu stehen.
Der Schlüssel liegt darin, nicht mit dem Endzustand zu starten – sondern mit dem System, das den heutigen Schmerz löst und morgen weitergebaut werden kann.
Wenn dich das interessiert: Lass dir Hublify zeigen – in 30 Minuten siehst du, wie PIM und ERP auf einer Plattform zusammenspielen.
