Einen Onlineshop hat man schnell aufgesetzt. Einen Shop, der weiß, was tatsächlich noch im Regal liegt, ist eine ganz andere Aufgabe. Wenn E-Commerce-Projekte kippen, dann fast nie am Design und fast immer an der Verbindung zwischen Shop und Warenwirtschaft.
Das Muster wiederholt sich mit ermüdender Regelmäßigkeit. Der Shop geht live, die ersten Wochen laufen gut, dann häufen sich die Vorgänge, die niemand eingeplant hat. Eine Bestellung auf einen Artikel, der seit Tagen weg ist. Ein Kunde, der im Warenkorb einen anderen Preis gesehen hat als auf der Rechnung. Ein Paket, das die Logistik nicht packen kann, weil eine Angabe fehlt. Jeder Einzelfall ist klein. In Summe kosten sie mehr als der Shop selbst.
Der Bestand bricht zuerst
Überverkäufe entstehen nicht aus Nachlässigkeit, sondern weil zwischen Verkauf und Bestandsbuchung Zeit vergeht. Wird der Bestand einmal nachts abgeglichen, verkauft Ihr Shop den ganzen Tag gegen den Stand von gestern Abend. Bei fünf Bestellungen am Tag merkt das niemand. Am ersten Tag mit echter Nachfrage merkt es jeder, und zwar genau bei den Artikeln, die gerade gut laufen.
Dazu kommt: Ihre Ware liegt selten nur an einer Stelle. Filiale, Lager, reservierte Kommissionen, Retouren in der Prüfung. Die Warenwirtschaft kennt diese Unterschiede. Der Shop bekommt in vielen Projekten nur eine einzige Zahl, und niemand hat je entschieden, welche das eigentlich sein soll.
Zwei Systeme, zwei Wahrheiten über denselben Artikel
Im ERP heißt der Artikel "Schraube M6x40 verz. VE100". Im Shop heißt er "Sechskantschraube M6, 40 mm, verzinkt, 100 Stück". Beides ist richtig. Nur verbindet die beiden Datensätze nichts außer der Artikelnummer, und die hat vor einem halben Jahr jemand im Shop von Hand korrigiert.
Am härtesten trifft es die Varianten. Der Shop braucht Größe und Farbe als auswählbare Achsen. Viele Warenwirtschaften führen stattdessen einzelne Artikelnummern ohne jede Beziehung untereinander. Wer diese Beziehung nicht sauber abbildet, baut sie im Shop nach und pflegt sie ab dann doppelt. Beim nächsten Sortimentswechsel läuft die eine Seite der anderen davon.
Preise und Rabatte gehören an eine Stelle
Ein Preis sieht aus wie ein einfaches Feld. Er ist es nie. Staffelpreise, Kundengruppen, Aktionszeiträume, Mindestmengen, Mengenrabatte. Wenn diese Logik im ERP existiert und im Shop noch einmal nachgebaut wird, betreiben Sie zwei Rechenwerke, die dasselbe Ergebnis liefern sollen. Sie werden auseinanderlaufen. Nicht irgendwann, sondern beim ersten Sonderfall.
Die belastbare Variante ist die unbequemere: Der Shop rechnet nicht selbst, er fragt. Das kostet Entwicklungszeit und verlangt eine Schnittstelle, die antwortet, während der Kunde wartet. Dafür stimmt der Warenkorb mit der Rechnung überein, und daran hängt Vertrauen.
Eine führende Quelle je Datenart
Die wichtigste Entscheidung im Projekt kostet keinen Cent Entwicklung. Legen Sie fest, welches System für welche Datenart die Wahrheit sagt. Artikelstamm und Bestand aus der Warenwirtschaft. Beschreibungen, Bilder und SEO-Daten aus dem Shop. Bestellungen entstehen im Shop und wandern in einer Richtung ins ERP. Kundendaten: entscheiden Sie sich, aber entscheiden Sie sich einmal.
Was nie funktioniert, ist "beide pflegen alles". Der Satz fällt in Workshops gern, weil er nach Flexibilität klingt. Er bedeutet, dass es keine Wahrheit gibt und jeder Konflikt später von Hand geklärt wird.
An derselben Entscheidung hängt, ob die Bestellung vollständig ankommt. Die Logistik braucht Felder, die den Shop nicht interessieren: Lieferbedingung, Packstückvorgaben, Kostenstelle, abweichende Lieferanschrift mit Zustellhinweis. Wenn diese Felder im Checkout nie erhoben wurden, kann keine Schnittstelle sie erfinden.
Nächtlicher Import gegen ereignisgetriebene Synchronisation
Der CSV-Import um drei Uhr nachts ist billig, schnell gebaut und in der Abnahme unauffällig. Er verschiebt die Kosten nur nach hinten. Ein Batch-Lauf kennt keine Reihenfolge, nur einen Endzustand. Fällt er aus, merkt es niemand bis zum Morgen. Und er skaliert schlecht, weil er alles anfasst, auch wenn sich drei Artikel geändert haben.
Ereignisgetriebene Synchronisation dreht das um. Ändert sich ein Bestand, meldet das System die Änderung, und der Shop übernimmt sie in Sekunden. Der Weg ist aufwendiger. Er ist auch der einzige, der beim ersten Ausverkauf hält. Am besten fahren Sie mit beidem: Ereignisse für Bestände und Preise, ein nächtlicher Vollabgleich als Sicherheitsnetz für verlorene Meldungen. In unseren Shopprojekten planen wir die Schnittstelle, bevor jemand das erste Template anfasst.
Häufige Fragen
Reicht die Standardschnittstelle unseres Shopsystems?
Bei einem einfachen Katalog mit wenigen Artikeln oft ja. Sobald Varianten, Kundengruppenpreise oder mehrere Lager im Spiel sind, stößt sie an ihre Grenzen. Prüfen Sie vor dem Kauf, ob das Modul Ihre Preislogik wirklich abbildet und nicht nur den Grundpreis.
Wie oft muss der Bestand abgeglichen werden?
Das hängt an Ihrer Umschlagsgeschwindigkeit. Bei schnell drehenden Artikeln mit dünnem Bestand zählen Minuten. Bei Lagerware, die Sie in Hunderten Stück führen, reichen ein paar Stunden.
Was tun wir mit einem Shop, der schon läuft?
Nicht abreißen. Zuerst die führende Quelle je Datenart festlegen, dann die Bestände auf Ereignisse umstellen, weil dort der Schaden entsteht. Der Rest kann folgen.
Wenn Ihr Shop und Ihre Warenwirtschaft sich gerade streiten, sehen wir uns das gerne mit Ihnen an und sagen Ihnen offen, was wir zuerst reparieren würden, unverbindlich und ohne Verkaufsdruck.
Dieser Beitrag gehört zu unserem Wissens-Hub Webentwicklung und E-Commerce.