Das Variantenproblem kennt jeder - aber kaum einer hat es wirklich gelöst
Du öffnest die Exportdatei deines ERP-Systems und siehst: 847 Zeilen. Dein Sortiment umfasst eigentlich nur 40 Basisartikel, aber jede Größen-, Farb- und Materialvariante ist eine eigene Zeile. Und das ist noch der einfache Teil. Jetzt soll jede dieser Varianten auf dem eigenen Webshop, auf Amazon Business und im Händlerportal landen. Mit unterschiedlichen Texten, unterschiedlichen Pflichtfeldern, unterschiedlichen Bildformaten.
Was folgt, ist meistens eine Kombination aus mehreren Excel-Tabellen, ein paar Absprachen im Team und einem Produktmanager, der drei Nachmittage pro Woche mit Copy-Paste verbringt.
Das Variantenproblem ist in der B2B-Praxis so verbreitet wie schlecht dokumentiert. Die meisten mittelständischen Hersteller und Händler arbeiten seit Jahren mit demselben Workaround: ERP für die Stammdaten, Excel für den Rest. Solange das Sortiment überschaubar ist und nur ein Kanal bespielt wird, funktioniert das. Aber sobald Variantenvielfalt und Kanalanzahl wachsen, gerät das System ins Wanken.
Laut einer Branchenstudie zu B2B-Produktdatenmanagement verwalten 37% der Unternehmen ihre Produktdaten noch immer manuell. Die eigentliche Ursache liegt dabei selten in fehlendem Fleiß, sondern im falschen Werkzeug.
Was ERP und Excel wirklich können - und wo sie aufhören
Ein ERP-System ist nicht dafür gebaut, Produktdaten zu kommunizieren. Es ist dafür gebaut, Transaktionen zu verwalten. Das ist kein Fehler, das ist Design.
Das ERP kennt die SKU, die Stückliste, den Einkaufspreis, den Lagerbestand und die Lieferantenbeziehung. Aber wenn du anfängst, es als Produktdaten-Redaktionssystem zu verwenden, stößt du schnell an Grenzen.
Konkret bricht das System an diesen Punkten:
Kanalspezifische Produkttexte: Amazon Business braucht eine andere Beschreibung als der eigene B2B-Shop. Im ERP gibt es in der Regel ein Freitextfeld. Das reicht nicht.
Mehrsprachige Pflichtfelder: Wer in der DACH-Region plus Benelux verkauft, braucht pro Variante Texte auf Deutsch, Niederländisch, ggf. Französisch. Das ERP denkt in einer Sprache.
Medienverknüpfung pro Variante: Ein Freisteller-Bild für Variante "Schwarz", ein Lifestyle-Bild für Variante "Weiß". ERP-Systeme speichern meist einen Bildlink pro Artikelstammsatz, nicht pro Variante pro Kanal.
Händlerspezifische Daten: Händler A bekommt Nettopreise ohne Verpackungshinweise, Händler B braucht GTIN, Zertifizierungsnummern und eine spezifische Kategoriemapping-Struktur. Das ist im ERP nicht abbildbar, ohne die Basisdaten zu verschmutzen.
Excel springt dann in die Bresche. Und funktioniert zunächst. Bis die zweite Person anfängt, in derselben Datei zu arbeiten. Bis der dritte Kanal dazukommt. Bis jemand vergisst, die Gewichtsangabe in der Marktplatz-Spalte zu aktualisieren, nachdem das Produkt überarbeitet wurde.
Das ERP denkt in Transaktionen. Das PIM denkt in Kontexten: Wer sieht welche Daten, auf welchem Kanal, in welcher Sprache, mit welchen Pflichtfeldern?
Drei B2B-Branchen, drei Herausforderungen für Variantenmanagement
Maschinenbau: 288 SKUs und vier verschiedene Ausgabeformate
Ein Hersteller von Industriepumpen vertreibt ein Basismodell in 12 Baugrößen, 4 Materialausführungen (Edelstahl, Gusseisen, Kunststoff, Bronze) und 6 Druckstufen. Das ergibt 288 SKUs allein für dieses Modell.
Das ERP kennt alle 288 Varianten mit Artikelnummer, Stückliste und Lagerstatus. Aber das sind nicht die einzigen Daten, die bewegt werden müssen. Das Webportal für Direktkunden braucht gefilterte Produktseiten mit technischen Spezifikationen, Anwendungsbeispielen und Zubehörempfehlungen. Der Händlerkatalog (als PDF und als Digital-Download) braucht Maßzeichnungen, Einbauhinweise und Ersatzteilnummern. Amazon Business erwartet strukturierte Attribute wie item_length, material und color_name in spezifischen Formaten. Und der Außendienst braucht für Kundenbesuche ein konfigurierbares Angebots-PDF, das die technischen Details der gewählten Variante mit dem Kundenlogo kombiniert.
Vier Ausgabeformate, vier verschiedene Datensätze, 288 SKUs. Im ERP gibt es dafür keine strukturierte Lösung. Was bleibt, sind manuelle Exports, Nachbearbeitung in Excel und ein Produktmanager als Flaschenhals.
Telekommunikation: Wenn die Kombination den Preis bestimmt
Ein Telekommunikations-Distributor, der Händler mit Hardware-Bundles und Mobilfunktarifen beliefert, kennt ein noch komplexeres Szenario. Im Händler-Vertriebsmodell bestimmt nicht ein einzelnes Attribut den Preis, sondern die Kombination mehrerer voneinander abhängiger Faktoren.
Nehmen wir ein konkretes Beispiel: Router-Modell × Netzanbieter × Datentarif-Volumen × Vertragslaufzeit × Händlerklasse. Jede dieser Variablen hat mehrere Ausprägungen. Das Ergebnis sind keine 288, sondern potenziell mehrere Tausend gültige Kombinationen mit jeweils eigenen Preisen, Konditionen und Vertragsunterlagen.
Ein Hublify-Kunde aus dem Telekommunikationsbereich hat genau diese Kombinationsvielfalt jahrelang in Excel verwaltet — über zwei Millionen Kombinationen, gepflegt in Tabellenblättern, bevor Hublify PIM als zentrale Datenbasis eingeführt wurde.
Viele Distributoren und Telko-Reseller steuern diese Kombinationslogik heute noch über Excel-Tabellen. Das Ergebnis: Preisfehler, weil jemand eine Zeile überschrieben hat. Veraltete Konditionen im Händlerportal, weil die neue Preisstruktur erst in Woche drei eingepflegt wird. Und Vertriebsmitarbeiter, die vor einem Kundengespräch erstmal die "aktuelle" Excel-Version erfragen müssen.
Wer Vertriebsmitarbeitern, Zwischenhändlern oder Endkunden einen Produktkonfigurator zur Verfügung stellen will, um schnell zur am besten passenden Option zu kommen, braucht im Hintergrund eine saubere, strukturierte Datenbasis. Die muss wissen, welche Kombinationen gültig sind, welcher Preis gilt und welche Unterlagen dazu gehören. Excel kann das nicht zuverlässig liefern.
Mode & Textil (Wholesale): Wenn jeder Händler seine eigene Wahrheit braucht
Ein Modelieferant im Großhandel hat pro Saison 300 Styles. Jeder Style kommt in 3 Farben, 7 Größen und 2 Passformen — das sind 42 Varianten pro Style, 12.600 SKUs insgesamt. Soweit noch handhabbar.
Das Problem beginnt, wenn die Abnehmer ins Spiel kommen. Händler A bestellt über ein EDI-Portal und braucht GTIN, Staffelpreise nach Bestellmenge und Größentabellen im standardisierten Format. Händler B betreibt einen eigenen Onlineshop und möchte Freisteller auf weißem Hintergrund, Lifestyle-Bilder pro Farbvariante und ausformulierte Produkttexte mit Pflegehinweisen. Der eigene B2B-Webshop braucht zusätzlich filterbare Attribute: Materialzusammensetzung, Passform, Saison, Kollektion.
Und dann wechselt die Saison. Aus "Herbst/Winter 2024" wird "Frühjahr/Sommer 2025". 300 neue Styles, viele Attribute übernommen, manche angepasst, einige neu. Wer das in Excel pflegt, verbringt die ersten drei Wochen jeder Saison damit, Spalten zu kopieren und Tippfehler in Farbbezeichnungen zu korrigieren: "dunkelblau", "Dunkelblau", "Navy", "navy blue" im selben Katalog.
Ein PIM-System mit Property Sets für "Oberbekleidung" und "Accessoires", Attributvererbung auf Variantenebene und kanalspezifischen Exportprofilen pro Händler löst das ein für alle Mal. Jeder Händler bekommt seinen Datensatz — aus einer einzigen gepflegten Quelle.
Wenn Varianten sich dynamisch kombinieren: PIM als Datenbasis für Produktkonfiguratoren
Es gibt zwei grundlegend verschiedene Variantentypen — und beide stellen das gleiche Infrastrukturproblem.
Typ 1: Statische Varianten. Alle Kombinationen sind gültig. Ein T-Shirt in 5 Farben und 6 Größen ergibt 30 Varianten, die alle gleichwertig existieren. Das Datenmodell ist planbar, die Attributstruktur klar.
Typ 2: Regelbasierte Konfiguration. Nicht alle Kombinationen sind erlaubt. Der 5G-Tarif ist nur mit bestimmten Hardware-Modellen kombinierbar. Die 24-Monats-Laufzeit gibt es nur ab einem bestimmten Volumen. Die Händlerklasse "Premium" hat Zugang zu Tarifen, die "Standard"-Händler nicht buchen können. Hier greift Kombinationslogik, die ein einfaches Attributmodell überfordert.
In beiden Fällen gilt dieselbe Grundregel: Wer Vertriebsmitarbeitern, Zwischenhändlern oder Endkunden einen Produktkonfigurator zur Verfügung stellen will, um schnell zur am besten passenden Option zu kommen, braucht eine strukturierte, zuverlässige Datenbasis im Hintergrund. Der Konfigurator ist das Frontend. Das PIM ist das Backend.
Wenn dieses Backend eine Excel-Tabelle ist, entstehen vorhersehbare Probleme. Preise werden nicht synchron gehalten, weil zwei Personen gleichzeitig in derselben Datei arbeiten. Neue Kombinationsregeln werden vergessen, weil die Logik verteilt über mehrere Tabellenblätter liegt. Änderungen sind nicht nachvollziehbar, weil kein Audit Trail existiert. Und Vertriebsmitarbeiter vertrauen dem System irgendwann nicht mehr, weil sie zu oft falsche Preise genannt haben.
Ein API-first-PIM als Datenbasis löst das strukturell: Preise, Attribute und Kombinationsregeln liegen in einem System, versioniert, validiert und über eine API direkt abrufbar. Der Konfigurator zieht die Daten live — keine Synchronisierungsprobleme, kein manueller Export.
Wie ein flexibles Datenmodell das Variantenchaos löst
Der Kern des Problems liegt darin, die richtigen Property Sets aufzubauen: Welche Tabellenspalten — also welche Attribute — braucht es für welche Produkttypen? Eine Pumpe braucht andere Felder als ein Router, ein Textilprodukt andere als ein Lebensmittel. Wer das nicht strukturiert gelöst hat, kämpft dauerhaft mit inkonsistenten Daten, fehlenden Pflichtfeldern und manueller Nacharbeit.
Ein flexibles PIM-Datenmodell für Hersteller und Händler löst das mit drei Bausteinen:
Property Sets bündeln Attribute nach Produkttyp. Statt alle Attribute in eine flache Tabelle zu quetschen, definierst du Property Sets pro Kategorie: "Pumpen" enthält Baugröße, Material, Druckstufe, Nenndurchmesser. "Netzwerk-Hardware" enthält Frequenzband, PoE-Kapazität, Zertifizierungen, Kompatibilitätsliste. Jede Variante erbt das richtige Set automatisch..png)
Attributvererbung stellt sicher, dass Stammdaten nicht 288 Mal gepflegt werden müssen. Markenname, Produktfamilie, allgemeine Beschreibung, Zertifizierungshinweise: einmal am Basisartikel gepflegt, automatisch an alle Varianten vererbt. Variantenspezifische Daten wie Farbe, Größe, Gewicht werden nur dort gepflegt, wo sie sich unterscheiden.
Kanalspezifische Pflichtfelder stellen sicher, dass eine Variante erst dann als "bereit" markiert wird, wenn alle für diesen Kanal erforderlichen Felder befüllt sind. Amazon Business braucht item_length in cm. Otto braucht Abmessungen als zusammengesetztes Feld. Der eigene B2B-Shop braucht einen ausformulierten Langtext plus drei Bullet Points. Das PIM prüft pro Kanal, was fehlt, bevor die Ausspielung startet.
Das Ergebnis in der Praxis: Ein "Herren-Funktionsshirt Langarm Schwarz Gr. L" mit 12 Attributen wird aus einem zentralen Datensatz in vier Kanäle ausgeleitet. Jeder bekommt exakt die Felder, die er braucht, im richtigen Format, mit dem richtigen Pflichtfeld-Status.
Eine Quelle, viele Kanäle - Variantendaten in der Praxis ausspielen
Das flexibelste Datenmodell nützt nichts, wenn die Daten nicht zuverlässig ankommen, wo sie gebraucht werden. Der operative Vorteil eines PIM für den Mittelstand liegt in der kanalspezifischen Ausleitung aus einer einzigen Quelle.
Für den Shopware-Shop bedeutet das: Property Groups mit normierten Attributwerten für Filter und Facetten. Wenn du im Shop nach "Material: Edelstahl" filterst, müssen alle Varianten mit diesem Material denselben Attributwert haben. Nicht "Edelstahl", "edelstahl", "Stainless Steel" durcheinander. Das PIM normiert einmal, Shopware bekommt saubere Daten.
Für Amazon Business gelten andere Regeln. item_length, item_width, item_height werden in Zentimetern als separate Felder erwartet. material und color_name folgen Amazon-spezifischen Wertelisten. Ein Wert, der nicht auf der Werteliste steht, führt zu Ablehnungen. Das PIM mappt die internen Attributwerte automatisch auf die Amazon-Nomenklatur.
Für EDI (Elektronischer Datenaustausch)-Händlerportale, wie sie im Maschinenbau und in der Elektronik-Distribution üblich sind, braucht es strukturierte Datenformate: BMEcat, ETIM, eCl@ss. Das sind Branchen-Datenstandards, die exakt definieren, welche Felder in welchem Format übergeben werden. Ein API-first-PIM kann diese Formate direkt als Exportkanal bedienen.
Die Verbindung zum ERP läuft dabei sauber in beide Richtungen: Stammdaten, Lagerbestände und Preise kommen aus dem ERP ins PIM. Aufbereitete Produktdaten gehen vom PIM in die Kanäle. Kein System überschreibt das andere.
Wann lohnt sich ein PIM für Variantenmanagement - und wann nicht
Ab wann ein PIM grundsätzlich sinnvoll ist, haben wir im Artikel Wann lohnt sich PIM für Shopify-Händler? ausführlich beschrieben. Für das spezifische Thema Variantenmanagement im B2B gilt: Die Anzahl der SKUs ist nicht der entscheidende Faktor. Auch wer nur 20 Produkte verkauft, aber jedes in hunderten gültigen Kombinationen mit eigenen Preisen und Konditionen, hat ein Variantenproblem, das Excel und ERP nicht lösen können.
Der Kipppunkt lässt sich besser an der Komplexität ablesen als an der reinen Produktanzahl. Als Orientierung für B2B-Sortimente:
Varianten entstehen aus der Kombination mehrerer voneinander abhängiger Attribute (nicht nur Farbe und Größe)
Verschiedene Kanäle erfordern unterschiedliche Attribute, Texte oder Formate pro Variante
Produktdaten kommen von mehr als einem Lieferanten oder System
Mehr als zwei Vertriebskanäle werden gleichzeitig bespielt (Shop, Marktplatz, Händlerportal, EDI)
Produkttexte müssen in mehr als einer Sprache gepflegt werden
Neue Produkte brauchen regelmäßig länger als eine Woche bis zur Marktreife
Produktmanager verbringen mehr als 30% ihrer Zeit mit manueller Datenpflege
Wenn du bei vier oder mehr Punkten nickst, ist die Frage nicht ob, sondern wann.
Das PIM-System ist dazu da, alle produktrelevanten Informationen an einem Ort flexibel zu verwalten und zu strukturieren, damit sie mit möglichst wenig Aufwand an unterschiedlichen Touch Points ausgespielt werden können. Nicht durch mehr manuelle Arbeit, sondern durch weniger.
Wenn du wissen willst, wie das konkret für dein Sortiment aussieht: Lass dir Hublify zeigen. In 30 Minuten siehst du, wie Hublify deine Variantenstruktur abbildet — und wo du heute unnötig Zeit verlierst.
Häufige Fragen zum Variantenmanagement mit PIM
Was ist der Unterschied zwischen PIM und ERP bei der Produktdatenpflege?
Das ERP verwaltet Transaktionsdaten: SKU, Menge, Preis, Lagerbestand, Lieferant. Es ist optimiert für Buchungslogik und Bestandsführung. Das PIM verwaltet Kommunikationsdaten: Produkttexte, Attribute, Mediendateien, kanalspezifische Pflichtfelder, Übersetzungen. Beide Systeme sind notwendig, haben aber vollständig getrennte Aufgaben. Die Integration läuft über eine API: Stammdaten vom ERP ins PIM, aufbereitete Produktdaten vom PIM in die Kanäle.
Wie viele Varianten kann ein PIM verwalten?
Ein cloud-basiertes PIM wie Hublify setzt keine feste Obergrenze für Varianten. In der Praxis werden problemlos Sortimente mit 100.000 Produkten und Millionen von Varianten verwaltet. Entscheidend ist nicht die Anzahl der Varianten, sondern die Qualität des Datenmodells — also wie gut die Attributstruktur, Property Sets und Vererbungsregeln aufgesetzt sind.
Wie funktioniert ein Produktkonfigurator im B2B mit PIM?
Das PIM ist das Datenbankbackend des Konfigurators. Es liefert über eine API alle relevanten Daten: gültige Attribute und ihre Ausprägungen, Kombinationsregeln (welche Varianten miteinander kompatibel sind), kanalspezifische Preise und zugehörige Dokumente. Der Konfigurator als Frontend fragt diese Daten live ab. Das stellt sicher, dass Preise und Kombinationsregeln immer aktuell sind, ohne manuelle Synchronisierung.
Ab wann brauche ich ein PIM für Variantenmanagement?
Nicht die Anzahl der Produkte ist entscheidend, sondern die Komplexität der Varianten. Sobald Kombinationen aus mehreren Attributen entstehen, verschiedene Kanäle unterschiedliche Daten brauchen oder die manuelle Pflege mehr als 30% der Arbeitszeit eines Produktmanagers frisst, lohnt sich die Bestandsaufnahme. Eine Demo mit konkreten Sortimentsdaten zeigt in der Regel innerhalb einer Stunde, wo der größte Hebel liegt.
Kann ein PIM direkt mit meinem ERP kommunizieren?
Ja, über eine API. Hublify bietet direkte Konnektoren zu ERP-Systemen wie Xentral und kommuniziert über die REST-API mit anderen Systemen. Die Verbindung läuft in beide Richtungen: Produktstamm und Preise kommen vom ERP, aufbereitete Produktinformationen gehen vom PIM in Shops, Marktplätze und Händlerportale. Wer auf sein eigenes ERP nicht festgelegt ist, kann Hublify PIM auch zum ERP ausbauen und Module wie Warehouse, CDM oder Order Management hinzubuchen. Damit erhält man ein PIM, das direkt ins ERP integriert ist.
