Wie verwaltet man Lieferanten-Produktfeeds?

In einem Onlineshop 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 muss sich rechtfertigen, 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 wird nicht kontrolliert.

Die Frage ist also nicht nur, wie wir 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, API-Verbindung oder sogar ein regelmäßig per E-Mail eingehängter Anhang sein. Er kann Produktnamen, Artikelnummern, Preise, Bestände, Beschreibungen, Bilder, Kategorien und Versandinformationen enthalten. Das technische Format ist jedoch nur die Oberfläche.

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

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 Aktualisierungsfrequenzen. 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 die Admin-Oberfläche des Onlineshops hoch. Danach ändert jemand den ERP-Preis, oder vielleicht auch nicht.

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

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

Ohne Identifikator keine zuverlässige Verbindung

Ein häufig versteckter Fehler bei Produktfeeds ist die Identifikation. Die Lieferantenartikelnummer, die Herstellerartikelnummer, der EAN-Code, die interne Shop-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 Variantenbeziehung.

Ohne klare Zuordnungsregel kann das System den Preis oder Bestand 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 duplizierte Produktkarten, unterschiedliche Bestandswerte und unsichere Berichte.

Daher sollte für jede Quelle der primäre Identifikator sowie die ergänzenden Felder festgelegt werden, 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 Onlineshop durchzulassen. Lieferantendaten sind externe Daten. Sie sind nützlich, aber nicht automatisch zuverlässig und passen nicht unbedingt zur eigenen Geschäftslogik.

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

Die Regeln müssen nicht zu kompliziert sein, sollten aber dokumentiert und konsistent bleiben. Ein gut definierter Prozess kann z.B. 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.

Bestand und Preis sind keine gleichwertigen Daten

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

Das Gleiche 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 Onlineshop.

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. Sie fällt der Nullpreis, der zehnfache Bestand oder die fehlende Kategorie auf. Bei automatisierter Verarbeitung muss diese geschäftliche Kontrolle durch Regeln ersetzt werden.

Die Validierung kann z.B. prüfen, ob die Artikelnummer obligatorisch ist, ob ein gültiger Preis vorhanden ist, ob der Bestand 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 Veränderungen und prüfungsbedürftigen Ereignissen unterscheiden kann.

Ausnahmen sollten in einer Aufgabenliste angezeigt werden, aus der klar hervorgeht, was passiert ist, warum der betreffende Datensatz gestoppt wurde und wer darüber entscheiden muss. Wenn Fehlerbenachrichtigungen 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 gelangt sind und welche Abweichungen sich wiederholen. Diese Zahlen sind keine IT-Dekorationen. Für den Handels- und Betriebsleiter zeigen sie an, ob das Produktangebot, aus dem der Vertrieb arbeitet, zuverlässig ist.

Nicht als ein einziges großes Projekt behandeln

Wenn mehrere Lieferanten, Onlineshops, ERP- und Lagerprozesse miteinander verbunden sind, kann es verlockend sein, alles auf einmal neu zu planen. Dies birgt oft ein zu großes Risiko. Es ist sinnvoller, dort zu beginnen, wo die meisten manuellen Arbeiten, Bestellfehler oder geschäftlichen Unsicherheiten entstehen.

Vielleicht besteht die erste Verbesserung nur darin, die Artikelnummernzuordnungen zu vereinheitlichen und tägliche Berichte über fehlgeschlagene Importe zu erstellen. In anderen Fällen ist eine stabile Integration zwischen Lieferant, Produktdatenverwaltung und Onlineshop gerechtfertigt. Wenn die Produktdaten in mehrere Kanäle fließen, 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 welcher Regel sie geändert werden und wer für die Ausnahmen verantwortlich ist.

Ein gut verwalteter Lieferantenfeed ist letztlich nicht deshalb wertvoll, weil weniger Dateien geöffnet werden müssen. Sondern weil der Vertrieb, das Lager und der Kundenservice aus demselben zuverlässigeren Bild arbeiten können, während sich die Aufmerksamkeit der Menschen auf echte geschäftliche Entscheidungen statt auf das Kopieren konzentrieren kann.