Ein Produkt, viele Lieferanten, viele Kanäle
Keine Tabellenkalkulation kam zu Schaden. Einige wurden in den Ruhestand geschickt.
Fast jedes E-Commerce-System geht davon aus, dass ein Produkt einen Preis hat. Die Annahme ist so vernünftig, dass man gar nicht merkt, sie getroffen zu haben, bis man auf ein Geschäft trifft, in dem sie nicht stimmt.
Die Distribution ist so ein Geschäft. Sie kaufen denselben Artikel bei mehreren Distributoren, jeder nennt einen anderen Einkaufspreis und hat einen anderen Lagerbestand. Sie verkaufen ihn über die Shops anderer Leute, jeder will einen anderen Preis und behält eine andere Provision ein. Das Produkt in der Mitte ist ein einziges Produkt. Fast nichts, was daran hängt, gibt es nur einmal.
Wir haben dieses Jahr damit verbracht, für Inovio doo ein System für genau diese Struktur zu bauen. Folgendes würden wir ins nächste Projekt mitnehmen.
Beide Richtungen sind Adapter
Der Import von einem Lieferanten und der Export in einen Kanal sehen nach unterschiedlichen Problemen aus. Eingehend ist es XML von einem Distributor, eine abgelegte CSV-Datei von einem zweiten, eine REST-API von einem dritten. Ausgehend sind es Marktplätze, von denen jeder sein eigenes Feed-Format will.
Strukturell sind sie identisch: etwas Externes, Veränderliches, das auf einer Seite einer Grenze sitzt, die Sie kontrollieren. Also ist jeder Lieferant ein Adapter, der Angebote in einer internen Form erzeugt, und jeder Kanal ein Adapter, der den Katalog in einer internen Form konsumiert. Was sich unterscheidet, gehört in den Adapter. Was zählt, gehört in die Mitte.
Das zahlt sich spätestens beim nächsten Lieferanten aus: Ihn hinzuzufügen heißt, einen Adapter zu schreiben. Preisberechnung, Lagerbestand und alle anderen Kanäle bleiben unberührt.
Eine Regel hat sich früh bewährt: An einer Grenze wird nichts stillschweigend verworfen. Eine Zeile, die wir nicht zuordnen können, verschwindet nicht in einer Logzeile. Wenn sie aktiv ist und einen Namen hat, wird daraus ein Produktentwurf, der auf einen Menschen wartet, markiert mit dem Grund, warum er nicht eingeordnet werden konnte, und bei jedem späteren Lauf über seinen Code wiedererkannt, statt erneut als Duplikat angelegt zu werden. Eingehende Feeds sitzen außerdem hinter einem Circuit Breaker: Ein Lieferant, der einen schlechten Morgen hat, wird ausgebremst und gemeldet, statt bis zum Umfallen erneut abgefragt zu werden.
Den Preis einmal berechnen
Die Regel, die wir am liebsten behalten würden: Nichts berechnet beim Export einen Preis neu.
Vorgefunden haben wir etwas anderes. Einige Kanäle wendeten auf dem Weg nach draußen ihre eigene Margenformel an, sodass der Preis im System und der Preis auf dem Marktplatz zwei verschiedene Zahlen waren. Die echte existierte nur in dem Code, der diesen einen Feed erzeugte. Fragen Sie, warum ein Artikel auf einem Marktplatz billiger ist, und niemand kann antworten, ohne zwei Feed-Generatoren zu lesen.
Heute ist die Preisberechnung eine einzige Engine, die die Konditionen je Kanal kennt und die Zahl erzeugt, die tatsächlich veröffentlicht wird. Der Export formatiert. Er rechnet nicht. Der Lagerbestand funktioniert genauso, abgeleitet in genau einer Funktion aus interner Verfügbarkeit und der des Lieferanten. Eine zweite Implementierung gilt als Bug, denn die zweite ist immer die, die auseinanderdriftet.
Ihre Kennungen gehören anderen Leuten
Das ist der Punkt, der am meisten Nachdenken gekostet hat, und der, auf den wir jeden hinweisen würden, der einen Katalog ablöst.
Bei einer Migration will man natürlich saubere neue interne Kennungen. Das Problem: Jeder Marktplatz, über den Sie verkaufen, kennt Ihre Produkte bereits unter der Kennung, die das alte System erzeugt hat. Dieser Code steht in deren Datenbank, verknüpft mit der Historie Ihres Angebots und seinem Ranking. Wenn Sie ihn ändern, ist das keine Migration mehr: Sie listen neu und werfen alles weg, was diese Angebote sich erarbeitet haben.
Ein migriertes Produkt hört also auf Kanälen, die es schon kannten, weiter auf seinen alten Code, während es für alles andere eine neue interne Kennung trägt. Unglamouröse Modellierung, aber genau sie unterscheidet eine Migration, die außerhalb des Unternehmens niemand bemerkt, von einer, die ein Quartal Marktplatz-Performance kostet.
Die allgemeine Fassung: Wenn Sie ein System ablösen, sind seine Kennungen womöglich der Teil, von dem andere abhängen. Und die haben Ihrer Migration nicht zugestimmt.
Das Backoffice ist keine Website
Ziemlich früh haben wir aufgehört, die Admin-Oberfläche wie eine Website zu behandeln.
Die Anwender machen hier den Großteil des Tages nur eines: lange Tabellen mit Produkten, Angeboten und Preisen durchgehen, auf der Jagd nach der Zeile, die falsch ist. Alles, was Sie beim Bau von Marketing-Websites verinnerlicht haben, arbeitet hier gegen Sie. Großzügiger Weißraum bedeutet weniger Zeilen auf dem Bildschirm. Ein bequemer 16px-Fließtext bedeutet weniger Zeilen auf dem Bildschirm. Jedes bisschen Luft, das Sie hinzufügen, kostet die Nutzer genau das, wofür sie gekommen sind.
Also ist der Fließtext 12px groß, die Abstände sind bewusst eng, und Zeilen pro Bildschirm ist die Zahl, die wir optimieren. Wir sind so weit gegangen, den alternativen Glyphensatz der Schrift für l, 1 und I einzuschalten, weil die drei in einer schmalen Spalte voller SKUs bei 12px wirklich schwer auseinanderzuhalten sind, und ein falsch gelesener Code kostet jemanden zehn Minuten und eine falsche Änderung.
In einem Design-Review wirkt das gedrängt, und wir haben dieses Gespräch mehr als einmal geführt, meist untereinander. Niemand, der den ganzen Tag damit arbeitet, hat uns gebeten, es aufzulockern.
KI schlägt vor, ein Mensch entscheidet
Ein Katalog, der aus vielen Distributoren zusammengesetzt ist, ist von Natur aus uneinheitlich. Ein Lieferant schickt eine vollständige Beschreibung und saubere Attribute. Der nächste schickt einen Namen, einen Preis und ein Foto. Beide müssen gut genug sein für einen Marktplatz, der ein Angebot wegen einer fehlenden Abmessung ablehnt.
Diese Lücke zu schließen war früher ein Personalproblem, was die Katalogqualität auf so viele Stunden deckelte, wie man dafür aufbringen konnte. Also behandeln wir KI als Anreicherungsdienst über dem Datenbestand, aus derselben Familie wie jeder andere Datenanbieter, den die Plattform aufruft: Sie nimmt das Produkt, das wir haben, füllt die Felder, die die Feeds nicht geliefert haben, und gibt sie zurück. Sie schlägt eine Kategorie mit Konfidenzwert vor, ergänzt fehlende Attribute, leitet die Logistikfelder ab und liest die Produktbilder, wenn der Text allein nicht reicht, um es zu erkennen.
Einen KI-Endpunkt aufrufen kann jeder. Spannend wird es bei der Frage, wo seine Ausgabe landen darf.
Nichts, was der Dienst zurückliefert, wird auf das Produkt geschrieben. Es wird daneben als offener Vorschlag gespeichert, und ein Anwender nimmt ihn im Vergleich zum aktuellen Wert an oder lehnt ihn ab. Die Annahme wird protokolliert, sodass Sie ein Jahr später noch sagen können, welche Felder ein Mensch eingegeben und welche ein Mensch freigegeben hat.
Diese Eigenschaft ist wichtiger, als sie klingt. Gefährlich ist weniger der offensichtliche Schnitzer, den jemand bemerkt, als der plausible, aber falsche Wert, der stillschweigend in einen Datensatz geschrieben wird, sich auf jeden Kanal ausbreitet und von Daten, die ein Mensch eingegeben hat, nicht zu unterscheiden ist. Sobald Sie nicht mehr sagen können, was was ist, können Sie es weder prüfen noch bereinigen, ohne alles noch einmal zu kontrollieren.
Eine Ausnahme haben wir zugelassen: Physische Abmessungen füllen leere Logistikfelder direkt, denn in der Breite eines Kartons steckt kein redaktionelles Urteil. Die Herkunft wird trotzdem protokolliert.
Der ehrliche Preis für all das ist eine Prüfwarteschlange. Jemand muss sich damit hinsetzen, und in einer schlechten Woche ist das ein ordentlicher Teil des Arbeitstags eines Anwenders. Man könnte einwenden, wir seien zu vorsichtig, und viele Teams würden die Werte einfach hineinschreiben und Beschwerden später beheben. Uns ist die Warteschlange lieber als ein Katalog, für den wir nicht geradestehen können. Es bleibt ein Tausch, und wir sind ihn bewusst eingegangen.
Was sich verallgemeinern lässt
Behandeln Sie jede externe Partei als Adapter, eingehend wie ausgehend. Leiten Sie jede bedeutsame Zahl an genau einer Stelle ab. Fragen Sie, bevor Sie irgendetwas migrieren, welche Ihrer Kennungen sich andere Leute bereits notiert haben.
Und wo KI Ihre Daten anreichert: Halten Sie, was der Dienst vorschlägt, getrennt von dem, was Ihr System für wahr hält, und protokollieren Sie den Übergang dazwischen. Sonst sitzen Sie am Ende auf einem Datenbestand, den Sie nie prüfen können.
Nichts davon ist raffiniert, aber es entscheidet darüber, ob der nächste Lieferant Sie einen Nachmittag oder ein Quartal kostet, und ob KI-Anreicherung Ihnen einen besseren Datenbestand hinterlässt oder einen Datenqualitätsvorfall in Zeitlupe.
Viele Kanäle. Eine Preis-Engine. Und ein Anreicherungsdienst, der nie das letzte Wort hat.
