Wie verwalten wir Lieferanten-Produktfeeds?

In einem Webshop ist ein Produkt morgens noch verfügbar, mittags wird es vom Lieferanten aus dem Sortiment genommen, und nachmittags geht eine Bestellung dafür ein. Der Kundenservice erklärt sich, der Einkauf sucht nach Alternativen, die Buchhaltung storniert, und das Lager versucht, eine Artikelnummer zu identifizieren, die in mehreren Systemen unterschiedliche Status hat. In solchen Fällen handelt es sich nicht einfach um ein Produktdatenproblem. Der Informationsfluss ist nicht unter Kontrolle.

Die Frage ist also nicht nur, wie wir die Lieferanten-Produktfeeds technisch handhaben. Zuerst muss geklärt werden, welche geschäftlichen Entscheidungen auf diesen Daten basieren, wer dafür verantwortlich ist und was passiert, wenn die Datenquelle des Lieferanten unvollständig, verspätet oder fehlerhaft ist.

Ein Produktfeed ist nicht nur eine Importdatei

Ein Lieferantenfeed kann eine CSV-, XML-, Excel-Datei, eine API-Verbindung oder sogar ein regelmäßig eingehender E-Mail-Anhang sein. Er kann Produktnamen, Artikelnummern, Preise, Lagerbestände, Beschreibungen, Bilder, Kategorien und Versandinformationen enthalten. Das technische Format ist jedoch nur die Oberfläche.

Die eigentliche Frage ist, was sich im Unternehmensbetrieb ändert, nachdem die Daten eingegangen sind. Wird der Preis im Webshop automatisch aktualisiert? Kann das neue Produkt sofort angezeigt werden? Verschwindet das Angebot bei einem auf null gesetzten Lagerbestand? Kann die Lieferantenartikelnummer sicher mit dem im eigenen ERP, Lagersystem oder Rechnungswesen verwendeten Produkt verknüpft werden?

Bei vielen wachsenden Händlern wird die Handhabung von Feeds schwierig, weil ursprünglich eine funktionierende Routine für einen einzigen Lieferanten und einige hundert Produkte entwickelt wurde. Später kommen Daten aus fünf, zehn oder zwanzig Quellen mit unterschiedlichen Strukturen und Aktualisierungshäufigkeiten. Die alte Routine erfordert dann oft immer mehr manuelle Überprüfungen, Tabellen und Ausnahmebehandlungen.

Zuerst muss der Datenfluss kartiert werden

Bevor neue Integrationen, PIM-Systeme oder Automatisierungen in Betracht gezogen werden, sollte der Weg eines konkreten Produktdatensatzes verfolgt werden. Zum Beispiel: Der Lieferant ändert den Einkaufspreis, die Daten gelangen in eine Datei, jemand lädt sie herunter, kopiert sie in eine Tabelle, überprüft die prozentuale Abweichung und lädt sie dann in das Webshop-Admin-Panel hoch. Danach ändert jemand den ERP-Preis oder vielleicht auch nicht.

In diesem Prozess wird in der Regel schnell sichtbar, wo Risiken entstehen. Leben die Daten an mehreren Orten? Hat ein Mitarbeiter im Kopf die Regel, welche Marge bei bestimmten Marken verwendet werden soll? Gibt es einen Lieferanten, dessen Lagerdaten als unzuverlässig angesehen werden, aber trotzdem automatisch veröffentlicht werden? Wer bemerkt, wenn ein Feed an einem Tag nicht eintrifft?

Nicht jeder manuelle Schritt ist schlecht. Die Genehmigung eines neuen, strategisch wichtigen Produkts kann eine bewusste Handelsentscheidung sein. Auch die Untersuchung einer ungewöhnlich großen Preisbewegung kann gerechtfertigt sein. Das Problem beginnt, wenn die menschliche Aufmerksamkeit für sich wiederholende Aufgaben wie das Vergleichen von Spalten, das Umbenennen von Dateien oder das Suchen nach Fehlern aufgebraucht wird, während kaum Zeit für Ausnahmen und Entscheidungen bleibt.

Ohne Identifikation gibt es keine zuverlässige Verbindung

Ein häufiger versteckter Fehler bei Produktfeeds ist die Identifikation. Die Lieferantenartikelnummer, die Herstellernummer, der EAN-Code, die interne Webshop-ID und der ERP-Produktcode stimmen nicht immer überein. Ein Produkt kann mehrere Varianten, Verpackungen oder Farben haben, die in einem Feed als separate Zeilen erscheinen, in einem anderen System jedoch als Hauptprodukt und Variante dargestellt werden.

Ohne klare Zuordnungsregeln kann das System den Preis oder den Lagerbestand für das falsche Produkt aktualisieren. Noch schlimmer ist es, wenn es stillschweigend ein neues Produkt erstellt, weil es das vorhandene nicht findet. Innerhalb weniger Wochen entstehen doppelte Produktkarten, unterschiedliche Lagerwerte und unsichere Berichte.

Daher ist es ratsam, für jede Quelle den primären Identifikator sowie die ergänzenden Felder festzulegen, mit denen die Übereinstimmung überprüft werden kann. Der EAN ist oft ein guter Ausgangspunkt, aber keine universelle Lösung: Er kann fehlen, fehlerhaft sein oder die Varianten nicht ausreichend unterscheiden.

Wie handhaben wir Lieferanten-Produktfeeds mit Regeln?

Gute Feed-Verwaltung beginnt nicht damit, alles sofort vom Lieferanten zum Webshop durchzulassen. Lieferantendaten sind externe Daten. Nützlich, aber nicht automatisch zuverlässig und nicht unbedingt mit der eigenen Geschäftslogik kompatibel.

Das Unternehmen benötigt daher klare Regeln. Welche Felder können direkt vom Lieferanten kommen? Welche Daten werden vom eigenen Team verwaltet, wie z.B. Produktbeschreibungen, Kategorien oder Marketingnamen? Welche Preisänderungen können automatisch veröffentlicht werden und welche Abweichungen erfordern eine Genehmigung? Was soll passieren, wenn der Lagerbestand unbekannt ist und nicht null?

Die Regeln müssen nicht zu kompliziert sein, aber sie müssen dokumentiert und konsistent bleiben. Ein gut definierter Prozess kann beispielsweise die Erstellung neuer Produkte, die Aktualisierung bestehender Produkte und die Behandlung fehlerhafter Datensätze trennen. So stoppt ein fehlender Preis oder ein Bild nicht die gesamte Verarbeitung, wird aber auch nicht unbemerkt den Kunden präsentiert.

Lagerbestand und Preis sind keine gleichwertigen Daten

Lagerbestandsdaten haben oft einen anderen Rhythmus und eine andere geschäftliche Bedeutung als Produktbeschreibungen. Eine wöchentliche Aktualisierung einer Beschreibung verursacht normalerweise keine Probleme. Eine Verzögerung des Lagerbestands eines schnell verkauften Produkts um einen Tag oder eine Stunde kann jedoch die Auftragsabwicklung direkt beeinflussen.

Dasselbe gilt für Preise. Ein Lieferant kann den Einkaufspreis ändern, aber für den eigenen Verkaufspreis müssen die Marge, Aktionen, Versandkosten, Vertragsbedingungen und gegebenenfalls die Marktposition berücksichtigt werden. Eine Aktualisierung des Lieferantenpreises bedeutet also nicht zwangsläufig eine sofortige Preisänderung im Webshop.

Es ist auch ratsam, die Verfügbarkeit separat zu behandeln. „Auf Lager“ kann bedeuten, dass das Produkt tatsächlich sofort lieferbar ist, aber auch, dass es theoretisch im externen Lager des Lieferanten verfügbar ist. Wenn diese Zustände auf ein einziges Ja-Nein-Feld vereinfacht werden, kann die dem Kunden zugesagte Lieferzeit leicht ungenau werden.

Ohne Validierung und Ausnahmebehandlung skaliert der Fehler

Wenn eine Person die Produkte hochlädt, bemerkt sie viele Fehler instinktiv. Ein Preis von null Euro, ein zehnfacher Lagerbestand oder eine fehlende Kategorie fallen auf. Bei automatisierter Verarbeitung muss diese geschäftliche Kontrolle durch Regeln ersetzt werden.

Die Validierung kann beispielsweise prüfen, ob die Artikelnummer erforderlich ist, ob ein gültiger Preis vorhanden ist, ob der Lagerbestand unrealistisch stark verändert wurde oder ob das neue Produkt den Veröffentlichungsbedingungen entspricht. Ziel ist es nicht, jede Abweichung zu verhindern. Ziel ist es, dass das System zwischen normalen Änderungen und prüfungsbedürftigen Ereignissen unterscheiden kann.

Ausnahmen sollten in einer Aufgabenliste angezeigt werden, aus der klar hervorgeht, was passiert ist, warum der Datensatz gestoppt wurde und wer darüber entscheiden muss. Wenn Fehlermeldungen nur an eine allgemeine technische E-Mail-Adresse gesendet werden oder im Posteingang eines einzigen Kollegen verbleiben, bleibt der Prozess weiterhin personenabhängig.

Für den Betrieb ist auch Beobachtbarkeit erforderlich. Es sollte sichtbar sein, wann der Feed zuletzt eingetroffen ist, wie viele Datensätze verarbeitet wurden, wie viele Produkte aktualisiert wurden, wie viele in die Ausnahmebehandlung fielen und welche Abweichungen sich wiederholen. Diese Zahlen sind keine IT-Dekorationen. Für den Handels- und Betriebsleiter zeigen sie an, ob das Produktangebot, mit dem der Vertrieb arbeitet, zuverlässig ist.

Nicht als ein einziges großes Projekt behandeln

Wenn mehrere Lieferanten, Webshops, ERP- und Lagerprozesse miteinander verbunden sind, kann es verlockend sein, alles auf einmal neu zu gestalten. Dies birgt oft ein zu großes Risiko. Es ist ratsamer, dort zu beginnen, wo die meiste manuelle Arbeit, Bestellfehler oder geschäftliche Unsicherheit entstehen.

Vielleicht besteht die erste Verbesserung nur darin, die Artikelnummern-Zuordnungen zu vereinheitlichen und tägliche Berichte über fehlgeschlagene Importe zu erstellen. In anderen Fällen ist eine stabile Integration zwischen Lieferant, Produktdatenverwaltung und Webshop gerechtfertigt. Wenn die Produktdaten in mehrere Kanäle gehen, mit vielen Ausnahmen und reichhaltigem Inhalt, kann eine separate zentrale Produktdatenverwaltungsschicht ebenfalls gerechtfertigt sein.

Die richtige Lösung hängt davon ab, wie viele Datenquellen es gibt, wie schnell sich die Daten ändern, wie groß das Produktsortiment ist und welchen geschäftlichen Schaden ein Fehler verursacht. Nicht jedes Unternehmen benötigt dasselbe System. Aber jedes Unternehmen muss wissen, woher die Daten kommen, nach welchen Regeln sie geändert werden und wer für die Ausnahmen verantwortlich ist.

Ein gut verwalteter Lieferantenfeed ist schließlich nicht deshalb wertvoll, weil weniger Dateien geöffnet werden müssen. Sondern weil Vertrieb, Lager und Kundenservice aus demselben zuverlässigeren Bild arbeiten können, während sich die Aufmerksamkeit der Menschen von der Kopie auf die tatsächlichen Geschäftsentscheidungen verlagern kann.