Ein Cut-off-Planungsboard, das zeigt, ob jeder Paketdienst rechtzeitig beladen wird

Das Lager versendet fast 3.000 Aufträge am Tag mit mehreren Paketdiensten, und jeder holt zu seiner eigenen Zeit ab. Das alte Board kannte nur eine Frist um 23:15 Uhr. An einem Abend zeigte es „im Plan“, obwohl Hunderte Aufträge die Abholung eines früheren Paketdienstes schon verpasst hatten.

Auch die offene Warteschlange stimmte nicht. Bereits versendete Aufträge und Aufträge mit Stornoanfrage zählten als kommissionierbar, sodass der Rückstand um rund 40 % zu hoch war. Schichtleiter planten Personal nach einer Zahl, der niemand traute.

Rund um das Board lief die tägliche Arbeit noch über Excel und Screenshots. Der Teamleiter baute den Tagesplan jeden Morgen von Hand neu, Dienstpläne kamen als Bilder aus einem Planungstool ohne Export, und SLA-Ergebnisse wurden erst im Nachhinein ermittelt.

Ich habe die Auftragszählung auf Basis der Fulfillment-Center-API von ChannelDock neu aufgebaut. Jeder nicht kommissionierbare Auftrag bekommt genau einen Ausschlussgrund (angehalten, ausstehend, Nachlieferung, Adressprüfung, zukünftiges Datum, blockiert, abgeschlossen oder storniert), sodass die Summen immer aufgehen. Ein Prüfskript testet die Einordnung gegen unabhängige Bedingungen. Paketdienste werden nach Versandart-ID gruppiert, nicht nach Namen, weil zwei „DHL“-Services mit unterschiedlichen Touren abfahren.

Die Prognose arbeitet in 15-Minuten-Blöcken. Basis sind die sechs letzten passenden Wochentage, gewichtet mit 30/25/18/12/8/7, mit Begrenzung von Ausreißern pro Block. Ein Live-Tagesfaktor passt sie an den heutigen Verlauf an und darf sich pro Viertelstunde höchstens um 0,10 ändern, damit jeder Bildschirm dieselbe stabile Zahl zeigt. Ein Fristenplaner spielt den Hallenbetrieb dann Viertelstunde für Viertelstunde durch, die früheste Cut-off-Zeit zuerst.

SLA-Mails laufen über einen Cron alle 5 Minuten, aber der Cron entscheidet nichts. Jeder Lauf fragt nach fälligen, noch nicht versendeten Mails und reserviert jede in einer Firestore-Transaktion vor dem Versand. Zwei Läufe können sie also nie beide verschicken. Ein Refresh-Job alle 5 Minuten erfasst über den Tag Auftragsblockaden, ein stündlicher Job speichert Snapshots, und ein nächtlicher Job ergänzt fehlende Historie innerhalb des API-Rate-Budgets.