Bestellspitze zur Black Week: ERP-Schnittstelle vorbereiten

Die Nachfrage ist planbar hoch. In einer Umfrage des IFH Köln im Auftrag des HDE unter über 1.000 Online-Shoppern wollten im Oktober 2025 48 Prozent am Black Friday auf Schnäppchenjagd gehen und mehr als ein Drittel am Cyber Monday (HDE). Der Digitalverband Bitkom kam in einer repräsentativen Befragung von 1.120 Internetnutzerinnen und -nutzern ab 16 Jahren auf 52 Prozent, die die reduzierten Preise rund um Black Friday und Cyber Week nutzen wollten; 69 Prozent von ihnen wollten ausschließlich im Internet nach Angeboten suchen (Bitkom). Auch die amtliche Statistik zeigt den Monat: Nach vorläufigen, kalender- und saisonbereinigten Ergebnissen setzte der Internet- und Versandhandel im November 2025 real 5,9 Prozent mehr um als im November 2024 (Destatis).

Für die Technik heißt das: viele Bestellungen in wenigen Stunden, häufig gebündelt um den Start einer Aktion und die Abende. Die Storefront lässt sich darauf vorbereiten, mit Caches, zusätzlichen Servern und einem Lasttest. Das ERP dagegen ist auf den Tagesbetrieb ausgelegt. Es bucht Aufträge einzeln, prüft Kreditlimits, reserviert Bestand, vergibt Belegnummern und schreibt in dieselben Tabellen, mit denen Lager und Buchhaltung gerade arbeiten. Cloud-ERP-Systeme setzen zusätzlich feste Grenzen: Microsoft Dynamics 365 Business Central verarbeitet je Benutzer höchstens 5 OData-Anfragen gleichzeitig; weitere warten in einer Schlange und brechen nach 8 Minuten mit dem Statuscode 503 ab (Microsoft Learn).

Deshalb staut sich der Betrieb an drei Stellen, die im Alltag kaum jemand bemerkt:

Alle drei Flüsse laufen über dieselbe Schnittstelle, oft über dieselbe Middleware und denselben technischen Benutzer im ERP. Wer sie in der Aktionswoche getrennt beobachtet und getrennt priorisiert, hat einen großen Teil der Vorbereitung bereits erledigt.

Ein Shop, der jede Bestellung synchron ins ERP schreibt, wartet auf das langsamste Glied. Antwortet das ERP zäh, hängt der Bestellabschluss, im ungünstigen Fall bricht er ab. Robuster ist die Entkopplung: Der Shop legt die Bestellung in eine Warteschlange und bestätigt sie dem Kunden, ein Worker überträgt sie im eigenen Tempo an das ERP. Die Warteschlange nimmt die Spitze auf, das ERP arbeitet sie ab. Die Grundlagen beschreibt der Beitrag zu Event-Driven-Architektur und Message Queues.

In Shopware übernimmt diese Aufgabe die Message Queue. Für Produktivsysteme empfiehlt die Dokumentation, sie über Worker auf der Kommandozeile abzuarbeiten statt über den Admin-Worker im Browser (Shopware-Dokumentation). Für die Aktionswoche zählt außerdem die Reihenfolge: Bekommt ein Worker mehrere Transporte genannt, verarbeitet er sie in genau dieser Reihenfolge (Symfony-Dokumentation). Der Auftragsexport gehört damit in einen eigenen Transport, der vor allen anderen steht.

Zwei Eigenschaften muss der Auftragsexport mitbringen, bevor er in die Spitze geht. Erstens Idempotenz: Eine Nachricht kann im normalen Betrieb mehr als einmal zugestellt werden, etwa wenn ein Worker sie verarbeitet und vor der Bestätigung abstürzt (Symfony-Dokumentation). Das ERP muss einen Auftrag deshalb an der Bestellnummer des Shops wiedererkennen und darf ihn kein zweites Mal anlegen. Zweitens eine Fehlerablage: Nach drei vergeblichen Wiederholungen verwirft Symfony Messenger eine Nachricht standardmäßig oder legt sie in einem Fehlertransport ab, sofern einer eingerichtet ist (Symfony-Dokumentation). Ohne Fehlertransport verschwindet ein Auftrag also still, und auch der Fehlertransport braucht einen laufenden Worker (Shopware-Dokumentation). Wie Idempotenzschlüssel und Deduplizierung im Detail aussehen, steht im Beitrag zu Idempotenz und Retry-Strategien.

Eine Alarmregel, die bei jedem Übertragungsfehler anschlägt, ist in der Black Week nach einer Stunde stummgeschaltet. Aussagekräftiger ist der Wasserstand der Warteschlange, und zwar in drei Formen: das Alter des ältesten noch nicht quittierten Auftrags, ein Abfluss, der auf null fällt, während weiter Bestellungen eingehen, und ein Füllstand deutlich über dem erwarteten Pegel der jeweiligen Stunde. Das Alter ist der wichtigste Wert, weil es unabhängig von der Menge sagt, wie lange ein Kunde auf die Bearbeitung seines Auftrags wartet.

Diese Regeln ergänzen einen Alarm, der anschlägt, wenn gar keine Bestellungen mehr eingehen. Jener fängt einen defekten Checkout oder eine gestörte Zahlungsanbindung ab. Die Pegelregeln fangen den umgekehrten Fall ab: Bestellungen kommen an, aber sie kommen nicht im ERP an. Beide Alarme gehören in die Aktionswoche, keiner ersetzt den anderen.

Für die Höhe der Schwelle hilft ein Ziel, das sich in einem Satz formulieren lässt, zum Beispiel: 99 Prozent der Aufträge stehen innerhalb von 15 Minuten im ERP. Was darüber hinausgeht, verbraucht ein Fehlerbudget. Google empfiehlt als Startwerte, die Bereitschaft zu alarmieren, wenn 2 Prozent des Budgets in einer Stunde oder 5 Prozent in sechs Stunden verbraucht sind, und für 10 Prozent in drei Tagen ein Ticket anzulegen (Google SRE Workbook). Auf ein Monatsbudget bezogen heißt die erste Stufe: In diesem Tempo wäre das ganze Budget nach 50 Stunden aufgebraucht, also noch vor dem Ende der Aktionswoche.

Ebenso wichtig ist, wer den Alarm bekommt. Zwischen Donnerstag und Dienstag braucht es eine benannte Bereitschaft für die Schnittstelle, die Zugriff auf Warteschlange, Middleware und ERP-Protokolle hat und weiß, wen sie beim ERP-Betreiber erreicht. Welche Kennzahlen dafür in ein Dashboard gehören, beschreibt der Beitrag zu Observability für Schnittstellen.

Die Bestandsrückmeldung fällt in der Spitze am ehesten zurück, weil sie dem Auftrag folgt: Erst wenn das ERP den Auftrag gebucht hat, ist der Bestand reduziert und kann an den Shop zurückgemeldet werden. Steht der Auftragsexport im Stau, steht auch der Bestand im Shop zu hoch. Bei Aktionsartikeln mit kleiner Menge ist das der direkte Weg zum Überverkauf.

Wie Reservierungen, Sicherheitsbestände und Schwellenwerte bei mehreren Lagern zusammenspielen, beschreibt der Beitrag zur Bestandssynchronisation über mehrere Lager.

Unter Last zeigt sich jede Änderung, die nicht getestet wurde, zuerst. Deshalb gilt für den Auftragsfluss ein Änderungsstopp: Vom Montag vor der Aktionswoche, dem 23. November, bis zum Dienstag nach Cyber Monday, dem 1. Dezember, werden Middleware, Shop-Plugins der Schnittstelle, Mappings und Customizing im ERP nicht verändert. Das gilt auch für Updates, die ein Dienstleister einspielt. Klären Sie mit Ihrem ERP-Betreiber und Ihrem Hoster, ob in diesem Zeitraum Wartungsfenster oder Versionswechsel geplant sind, und lassen Sie sie verschieben.

Ausnahmen sind Sicherheitskorrekturen und Fehlerbehebungen am Auftragsfluss selbst, und zwar mit Test, Freigabe durch eine zweite Person und vorbereitetem Rückweg. Nach jedem Einspielen neuen Codes müssen die Worker neu starten, damit sie ihn überhaupt laden (Symfony-Dokumentation) – ein Schritt, der unter Zeitdruck leicht vergessen wird.

Der Lasttest in der vierten Woche kostet die meiste Vorbereitung und verrät am meisten. Er braucht kein großes Werkzeug, aber ein Testsystem des ERP mit realistischen Daten und ein Skript, das Bestellungen im Stundenprofil des Vorjahres einspielt. Ohne ihn bleibt jede Alarmschwelle eine Schätzung. Wir prüfen den Auftragsfluss Ihrer Warenwirtschaftsanbindung als Teil unserer Leistungen, bauen fehlende Bausteine wie Transporte, Idempotenz oder Alarmregeln nach und stimmen den Jobplan mit Ihrem ERP-Betreiber ab. Für eine erste Einschätzung genügt eine kurze Anfrage mit den Systemen, die Sie verbinden.