Einen digitalen Katalog veröffentlichen
Für viele Unternehmen ist der Katalog das Startprojekt, weil die Produktdaten zusammengeführt und strukturiert sein müssen, bevor irgendetwas anderes möglich wird. Es ist zugleich der Einstieg mit dem geringsten Risiko: Gegen einen Katalog kann niemand eine falsche Bestellung aufgeben, und jedes spätere Projekt (Shop, Portal, Ersatzteile, Punchout) wird kürzer, weil dieses hier abgeschlossen ist. Wer es überspringt, macht dieselbe Arbeit später, unter Zeitdruck, mit einem Starttermin im Nacken.
Warum das schwerer ist, als es klingt
Der schwere Teil ist nicht der Import. Importe sind ein Nachmittag. Der schwere Teil ist, dass die Daten heute nicht in der Form existieren, die Sie brauchen, und der Weg dorthin Entscheidungen verlangt, die sich schlecht rückgängig machen lassen.
Diese Schwierigkeit ist konkret. Sobald Produkte Bestellhistorie tragen, ist eine Modelländerung eine Migration und keine Bearbeitung mehr. Einen Artikel in eine Familie mit Varianten aufzuteilen oder ein Freitextfeld in ein typisiertes Attribut zu verwandeln, heißt, Belege abzugleichen, die noch auf die alte Struktur verweisen. Die Entscheidungen der ersten zwei Wochen sind die, mit denen Sie leben. Deshalb kommt Modellieren vor Laden, und deshalb ist „das räumen wir später auf" der teuerste Satz in diesem Projekt.
Das zweite Hindernis: „Vollständig" bedeutet nichts, solange kein Kanal genannt ist. Dasselbe Produkt kann für Ihren Webshop fertig und im Beschaffungssystem eines Kunden unbrauchbar sein, weil dieser Kanal einen Mengeneinheiten-Code und eine Klassifikation verlangt, die die Webseite nie gebraucht hat. Vollständigkeit ist eine Rechnung pro Kanal. Wer sie einmal global definiert, streitet das folgende Jahr darüber, ob der Katalog fertig ist.
Drittens gehört ein großer Teil Ihrer Daten jemand anderem. Lieferantendateien kommen in der Struktur, die jeder Lieferant bevorzugt, ändern sich ohne Ankündigung, und die Attribute, die Sie brauchen, stecken in Spalten, die nach seiner internen Logik benannt sind. Lieferantenstrukturen auf Ihr Modell abzubilden ist wiederkehrende Arbeit. Bauen Sie sie als wiederholbaren Weg, statt sie jedes Mal heldenhaft zu erledigen.
Und dann der Verfall. Ein Katalog ist kein Projekt mit Ende. Ohne benannten Verantwortlichen pro Attributgruppe und ohne wöchentliche Routine ist er ein Jahr nach dem Start messbar schlechter als am Starttag, und niemand merkt es, weil sich die Verschlechterung über tausende Produkte verteilt.
Die Hebel
Das Modell entscheiden, bevor Sie irgendetwas laden
So sieht es gut aus: Sie können auf einer Seite sagen, was ein Attribut ist und was eine Variantenachse, welche Familien es gibt, welche Werte typisiert sind und welche Freitext, und wie sich Ihre Kategorien von den Warengruppen des ERP unterscheiden. Jemand außerhalb des Projekts kann das lesen und ein neues Produkt richtig einordnen.
Wovon es abhängt: Sie wissen, wonach Einkäufer filtern. Fragen Sie den Vertrieb, wonach Kunden fragen, sehen Sie in Ihre Suchprotokolle, falls Sie welche haben, und bauen Sie das Modell um diese Antworten statt um die Feldliste des ERP.
- Wie Produktinformationsmanagement funktioniert
- Das Katalog-Datenmodell
- Datenmodell planen
- Attribute und Attributgruppen
- Familien und Varianten und Familienvarianten
- Kategorien
- Maße und Einheiten · Referenzentitäten
Die Daten hineinbringen
So sieht es gut aus: Zuerst ein Produkt von Hand angelegt, um zu prüfen, ob das Modell trägt; dann das Sortiment in Masse aus einer vorbereiteten Datei geladen; dann Medien an die Produkte gehängt, statt als 4711_neu_final_2.jpg auf dem Netzlaufwerk zu liegen.
Wovon es abhängt: Die Zuordnung zwischen den Spalten jeder Quelle und Ihrem Modell. Diese Zuordnung ist das Ergebnis. Der Importlauf ist der triviale Teil, und eine Zuordnung, die Sie erneut ausführen können, macht aus jedem Lieferanten-Update eine Aufgabe statt eines Projekts.
- Ein Produkt anlegen
- Importdatei vorbereiten
- Produkte in Masse importieren
- Viele Produkte auf einmal bearbeiten
- Assets und Asset-Familien
Festlegen, was „vollständig" heißt, pro Kanal
So sieht es gut aus: Jeder Kanal hat eine schriftliche Anforderung. Das Web braucht Bilder und eine Beschreibung; ein Beschaffungskanal braucht Einheiten, Klassifikation und Längenbegrenzungen; ein Druckblatt braucht wieder etwas anderes. Die Plattform berechnet die Vollständigkeit dagegen, und „fertig" ist eine Zahl.
Wovon es abhängt: Sie kennen Ihre Kanäle im Voraus, auch die, die Sie noch nicht gebaut haben. Die Regeln eines Kanals an ein bestehendes Modell anzuhängen ist viel billiger, als Daten für einen Kanal nachzurüsten, an den niemand gedacht hat.
- Kanäle, Sprachen und Vollständigkeit
- Vollständigkeit und Bereitschaft
- Datenqualität in der Praxis
- Warum ein Produkt nicht erscheint
Veröffentlichen und am Leben halten
So sieht es gut aus: Der Katalog ist dort sichtbar, wo er sein muss, und es gibt eine wöchentliche Routine mit dem Namen einer Person daran: neue Produkte geprüft, unvollständige Produkte nachgefasst, Lieferanten-Updates ausgeführt, Suchen ohne Treffer durchgesehen.
Wovon es abhängt: Verantwortung. Weisen Sie Attributgruppen den Abteilungen zu, die die Antworten kennen: technische Attribute dem Produktmanagement, Logistikdaten der Logistik, kaufmännische Texte dem Marketing.
- Wie Storefronts funktionieren
- Storefront anlegen
- Suche und Auffindbarkeit
- Seiten und Blöcke bearbeiten
- Sprachen und Märkte
- Benachrichtigungen
Eine sinnvolle Reihenfolge
Phase 1: Modell, dann eine Familie, vollständig. Modell entwerfen, dann eine einzige Produktfamilie von Hand laden und sie für einen definierten Kanal ganz bis zur Vollständigkeit bringen. Das ist klein genug, um es noch einmal zu machen, wenn es sich als falsch herausstellt, was beim ersten Mal passieren wird. Der Wert liegt darin, dass aus einer Modelldiskussion ein konkretes Objekt wird, das man ansehen und über das man produktiv streiten kann.
Phase 2: das Sortiment in Masse laden, nach Umsatz sortiert. Arbeiten Sie sich von den Familien mit dem meisten Umsatz nach unten. Veröffentlichen Sie den Katalog, sobald die erste Gruppe vollständig ist, statt auf alles zu warten. Ein teilweise veröffentlichter Katalog, der stimmt, ist weit nützlicher als ein vollständiger, der noch intern ist. Phase 2 setzt voraus, dass das Modell aus Phase 1 hält, und genau dafür war Phase 1 da.
Phase 3: der zweite Kanal und die Pflegeschleife. Fügen Sie hinzu, was als Nächstes kommt (einen Beschaffungskanal für Punchout, eine zweite Sprache, eine Druck- oder Datenblattausgabe), und richten Sie die wöchentliche Routine mit benannten Verantwortlichen ein. Phase 3 verhindert, dass der Katalog am Starttag so gut ist wie nie wieder.
Typische Fehler
- Den ERP-Export als Modell übernehmen. Die Struktur des ERP wurde für die Fakturierung entworfen. Sie liefert Ihnen eine 40-Zeichen-Beschreibung und keine filterbaren Attribute.
- Die Attributliste ungesteuert wachsen lassen. Jedes Feld braucht Zweck und Verantwortlichen, bevor es existiert.
- Vollständigkeit global definieren. Ohne Kanal ist „vollständig" ein Gefühl.
- Medien auf dem Netzlaufwerk lassen. Bilder und Datenblätter, die nicht am Produkt hängen, gehören nicht zum Katalog, wie der Ordner auch heißt.
- Alle Lieferanten gleichzeitig anbinden. Einen richtig machen, die wiederverwendbare Zuordnung bauen, dann nutzen.
- Auf Perfektion warten, bevor Sie veröffentlichen. Veröffentlichen Sie den vollständigen Teil. Der Rest ist ein sichtbarer, priorisierter Rückstand.
- Keine Pflegeroutine. Ein Katalog ohne Routine ist am Starttag am besten und wird von da an schlechter.
Woran Sie erkennen, dass es funktioniert
- Produkte mit 100 % Vollständigkeit für Ihren Hauptkanal, als Zahl und als Anteil. Das ist die Kopfzahl, und sie bedeutet erst etwas, wenn Vollständigkeit pro Kanal definiert ist.
- Filterbare Attribute für Einkäufer, gezählt pro Kategorie. Zwei Filter in einer Kategorie mit 4.000 Artikeln sind kein auffindbarer Katalog.
- Anteil des Sortiments mit mindestens einem Bild und einem Datenblatt. Der billigste Qualitätsindikator, den es gibt, und am Anfang meist die peinlichste Zahl.
- Suchen ohne Treffer, nach Häufigkeit sortiert. Jeder Eintrag ist entweder ein Produkt, das Sie nicht führen, oder eine Modelllücke, und beides lohnt sich zu wissen.
- Attribute mit benanntem Verantwortlichen. Alles ohne einen ist innerhalb eines Jahres veraltet.
- Dauer, bis die Daten eines neuen Lieferanten angebunden sind. Dauert der zweite Lieferant so lange wie der erste, ist der Zuordnungsweg noch nicht wiederverwendbar.
- Produkte, deren Daten sich seit einem Jahr nicht geändert haben, als Anteil. In einem lebenden Katalog bleibt diese Zahl niedrig; steigt sie, hat die Pflege aufgehört.
Verwandte Ziele
- Einen B2B-Shop starten, das Projekt, für das dieses hier das Fundament ist.
- Mehr Kunden erreichen, denn ein veröffentlichter Katalog ist die erste Quelle neuer Nachfrage.
- Systeme konsolidieren, wo der Katalog meist die erste Domäne ist, die zusammengeführt wird.
Was Sie bauen
Einen Produktkatalog im PIM der Plattform, der jeden verkaufbaren Artikel mit typisierten Attributen, Familien, Varianten, Kategorien und Medien hält, gespeist aus Ihrem ERP und Ihren Lieferanten über wiederholbare Importe, mit Vollständigkeit pro Kanal gemessen. Eine öffentliche Storefront zeigt den vollständigen Teil. Noch keine Preise, noch kein Checkout. Alles Spätere liest aus diesem einen Katalog.
flowchart LR
ERP["Ihr ERP: Artikelstamm"]
SUP["Lieferantendateien: BMEcat, CSV"]
DAM["Bilder, Datenblätter"]
subgraph IS["Integration Studio"]
IMP["Importprofile"]
WF["Workflows"]
end
subgraph CS["Commerce Studio"]
DM["Datenmodell: Familien, Attribute"]
P["Produkte"]
CAT["Kategorien"]
AS["Assets"]
CH["Kanäle"]
end
subgraph XS["Experience Studio"]
SF["Storefront: Katalogseiten"]
end
ERP --> IMP
SUP --> IMP
IMP -- "zugeordnete Spalten" --> P
DAM --> AS
AS --> P
DM --> P
P --> CAT
CH -- "Vollständigkeit pro Kanal" --> P
P -- "nur vollständige Produkte" --> SF
WF -- "geplante Lieferanten-Updates" --> IMP
SRCH["Such-App (geplant)"]:::planned
P -.-> SRCH
SRCH -.-> SF
classDef planned stroke-dasharray: 5 5
Was Sie brauchen
- Ein einseitiges Datenmodell: Attribute gegen Variantenachsen, Familien, typisierte gegen Freitextwerte, Kategorien — Datenmodell planen
- Eine Liste, wonach Einkäufer filtern, aus dem Vertrieb und aus Suchprotokollen — Wie PIM funktioniert
- Eine schriftliche Vollständigkeitsanforderung für Ihren ersten Kanal — Kanäle, Sprachen und Vollständigkeit
- Der ERP-Artikelexport und die erste Lieferantendatei, mit einer Spaltenzuordnung, die Sie erneut ausführen können — Importdatei vorbereiten
- Bilder und Datenblätter gesammelt und nach Artikelnummer benannt — Assets und Asset-Familien
- Ein benannter Verantwortlicher pro Attributgruppe — Datenqualität in der Praxis
- Eine Storefront zum Veröffentlichen, auch eine schlichte — Storefront anlegen
So bauen Sie es
- Modell auf einer Seite aufschreiben und vom Produktmanagement abnehmen lassen — Datenmodell planen
- Attributgruppen und Attribute mit Einheiten im Cockpit anlegen — Attribute
- Familien anlegen und, wo die Kombinationen endlich sind, Familienvarianten — Familien
- Kategoriebaum in der Logik des Einkäufers aufbauen — Kategorien
- Ersten Kanal und seine Vollständigkeitsanforderung anlegen — Kanäle
- Ein Produkt der ersten Familie von Hand anlegen und auf 100 % bringen — Ein Produkt anlegen
- ERP-Export dem Modell zuordnen und die umsatzstärksten Familien importieren — Produkte in Masse importieren
- Medien über Asset-Familien anhängen — Assets
- Unvollständige Produkte in Masse nachpflegen, Familie für Familie — Viele Produkte auf einmal bearbeiten
- Vollständige Familien in der Storefront veröffentlichen — Storefront anlegen
- Erste Lieferantendatei zuordnen und das Update terminieren — Import/Export
- Wöchentliche Routine mit Namen in den Kalender setzen — Datenqualität in der Praxis
- Vollständigkeitsregeln des zweiten Kanals ergänzen, sobald er entschieden ist — Vollständigkeit und Bereitschaft
Entscheidungen, die Sie treffen müssen
| Entscheidung | Die Abwägung | Wohin die meisten Kunden gehen |
|---|---|---|
| Ist die ERP-Warengruppe Ihr Kategoriebaum? Übernehmen, oder einen Baum in der Logik des Einkäufers bauen und die ERP-Warengruppe als Attribut mitführen. | Übernehmen ist in einer Stunde erledigt und gibt Einkäufern einen Baum, der für die Fakturierung gebaut wurde. Ein eigener Baum ist Modellarbeit und muss gepflegt werden, wenn Produkte hinzukommen. | Ein eigener Baum, mit der ERP-Warengruppe als Attribut fürs Reporting. Wer einmal einem Einkäufer beim Navigieren eines ERP-Baums zugesehen hat, entscheidet nicht anders. |
| Varianten oder Einzelprodukte? Ein Produkt pro Artikelnummer, oder eine Familie mit Variantenachsen. | Einzelprodukte sind das, was der ERP-Export liefert, und erzeugen 252 fast identische Seiten. Varianten brauchen vorab entschiedene Achsen, und Einzelprodukte später zu Varianten zusammenzuführen heißt, Bestellhistorie anzufassen. | Varianten für alles mit zwei oder mehr Achsen; entschieden in Phase 1, weil das die Änderung ist, die sich später nicht billig machen lässt. |
| Wie viele Attribute? Alles, was irgendeine Abteilung verlangt, oder nur, was einen Filter, eine Kanalregel oder einen gesetzlichen Grund hat. | Ein großes Modell erfasst alles, und niemand pflegt es. Ein kleines Modell lässt Lücken, die als „dafür brauchen wir ein Feld" auftauchen. | Klein, mit einer Regel: Zweck plus Verantwortlicher, sonst wird es nicht angelegt. Ein Attribut später hinzuzufügen ist billig; 400 stillzulegen, die niemand gefüllt hat, nicht. |
| Teilweise veröffentlichen oder warten? Die vollständigen Familien jetzt zeigen, oder starten, wenn alles fertig ist. | Teilweise Veröffentlichung heißt, Einkäufer sehen einen Katalog mit Lücken. Warten heißt, ein Jahr lang sieht niemand etwas, und „fertig" verschiebt sich ständig. | Teilweise, nach Umsatz, wobei unvollständige Produkte durch die Vollständigkeitsregel ausgeblendet werden statt halbfertig zu erscheinen. |
| Wo leben Lieferantendaten und Bilder? In die Plattform importieren, oder in einem getrennten PIM oder DAM lassen und synchronisieren. | Ein System heißt ein Ort zum Pflegen und ein Importweg. Ein getrenntes System ist nur dann richtig, wenn es bereits Eigentümer von etwas ist, das Sie nicht verschieben können. | In der Plattform, außer ein funktionierendes PIM oder DAM ist bereits Eigentümer der Daten; dann bleibt dieses System Eigentümer und die Plattform liest daraus. |
Verwandte Produktbereiche
- Commerce Studio — Produkte · Produktimport · Massenaktionen · Familien · Familienvarianten · Attribute · Attributgruppen · Maße · Kategorien · Referenzen · Assets · Vollständigkeit · Kanäle
- Experience Studio — Sites · Seiten · Sprachen und Märkte
- Integration Studio — Import/Export · SFTP-Server · Zeitpläne · Läufe