Ihre Automatisierung prüft den Lagerbestand, nicht die Verfügbarkeit
Bestand größer null heißt nicht lieferbar. Wenn der Workflow die Reservierungen nicht mitliest und die geprüfte Menge nicht wegnimmt, bestätigt er Termine für Ware, die längst einem anderen Auftrag zugesagt ist.
Dieser Beitrag wurde mit KI erstellt. Kennzeichnung gemäß Art. 50 EU AI Act. Verantwortlich für die Veröffentlichung: Sophera Consulting.
340 Kartons im System, 40 im Regal
Ein Großhändler für Arbeitsschutz beliefert Logistikbetriebe und zwei Kliniken. Die Bestellungen kommen über ein Portal, ein Workflow legt sie im ERP an. Vorher prüft er den Lagerbestand: Ist die bestellte Menge kleiner als der Bestand, geht die Auftragsbestätigung samt Liefertermin automatisch raus. Zwei Werktage.
Im Juni bestellt ein Kunde 300 Kartons Nitrilhandschuhe. Das ERP meldet 340 Stück im Bestand. Bestätigung raus, Liefertermin Mittwoch.
Am Dienstagmorgen findet die Kommissionierung 40 Kartons. Die anderen 300 waren seit zwei Wochen für den Rahmenabruf einer Klinik disponiert, Auslieferung Donnerstag. Sie lagen physisch im Regal, deshalb standen sie im Bestand. Frei waren sie nicht.
Wir haben anschließend ein halbes Jahr Auftragsdaten durchgesehen. 22 Aufträge mit demselben Muster, davon 6 mit einem Liefertermin, der nicht zu halten war. Bei den übrigen 16 war zufällig genug nachgeliefert worden, bevor jemand es gemerkt hat.
Drei Zahlen, die alle Bestand heißen
Im Lager liegen Kartons. Im System stehen mindestens drei Zahlen dazu, und sie sind selten gleich.
Der Buchbestand ist das, was laut System im Lager liegt. Diese Zahl gibt fast jede Artikel-Schnittstelle als `quantity` oder `stock` zurück.
Der reservierte Bestand ist der Teil davon, der bereits fest zugeordnet ist: offene Aufträge, Rahmenabrufe, Umlagerungen an ein anderes Lager, Kommissionen, bei produzierenden Betrieben auch Fertigungsaufträge.
Der verfügbare Bestand ist die Differenz, erweitert um bestätigte Zugänge in einem Zeitfenster. Im ERP heißt er je nach Hersteller Available-to-Promise, freier Bestand oder disponibler Bestand.
Nur die dritte Zahl beantwortet die Frage, die der Workflow eigentlich stellt: Kann ich das zusagen?
Warum die Schnittstelle die falsche Zahl anbietet
Der Buchbestand ist ein Feld am Artikel. Er braucht keinen Kontext, deshalb kann ihn jeder Endpunkt liefern, der einen Artikel zurückgibt.
Verfügbarkeit ist keine Eigenschaft des Artikels, sondern das Ergebnis einer Rechnung mit Parametern: Welches Lager, welcher Termin, welche Charge, in manchen Häusern auch welcher Kunde, weil bestimmte Bestände für bestimmte Abnehmer gesperrt sind. Diese Rechnung steckt im ERP an einer anderen Stelle, meist im Auftragsmodul oder in einem eigenen Verfügbarkeitsdienst.
Wer den Artikel abfragt, bekommt eine Zahl. Sie stimmt, sie beantwortet nur eine andere Frage.
Ohne Datum ist verfügbar bedeutungslos
Selbst wenn der Workflow den freien Bestand liest, fehlt oft der zweite Teil der Frage.
Verfügbarkeit ist eine Aussage über einen Zeitpunkt. 300 Kartons sind heute frei und am Donnerstag nicht mehr, weil zwischendrin die Klinik abruft. Umgekehrt sind heute 0 Kartons frei und am Freitag 800, weil ein Wareneingang angekündigt ist.
Ein Workflow, der beim Bestelleingang prüft und daraus einen Liefertermin ableitet, vergleicht einen Wert von jetzt mit einem Versprechen für übermorgen. Das geht so lange gut, wie zwischen Prüfung und Kommissionierung nichts passiert.
Prüfen ist keine Zusage
Der zweite Fehler ist unabhängig vom ersten und tritt auch dann auf, wenn Sie sauber den freien Bestand lesen.
Zwei Bestellungen treffen im Abstand von vier Sekunden ein. Beide Workflows fragen den verfügbaren Bestand ab, beide bekommen 340, beide bestätigen 300. Keiner der beiden hat etwas weggenommen, denn eine Abfrage verändert nichts. Der Bestand fällt erst, wenn die Auftragsposition im ERP steht, und bis dahin vergehen in einem No-Code-Workflow schnell mehrere Sekunden: Adressabgleich, Preisfindung, Anlage des Auftragskopfs, Anlage der Positionen.
Bei zehn Bestellungen am Tag fällt das nie auf. Bei einer Portalanbindung mit Sammelbestellungen am Monatsanfang passiert es regelmäßig.
Die Korrektur landet nicht im System
Ein falscher Bestand im ERP ist ärgerlich, aber reparierbar. Eine falsche Zusage ist es nicht.
Beim Arbeitsschutz-Händler bedeutete jeder dieser Fälle: Kundenservice ruft an, erklärt, bietet Teillieferung oder neuen Termin an. Bei den beiden Kliniken war das teurer als bei den Logistikkunden, weil dort mit dem zugesagten Termin geplant wird. Eine Klinik hat nach dem zweiten Vorfall parallel bei einem anderen Lieferanten bestellt, um nicht wieder ohne dazustehen. Diese Doppelbestellung kam nie zurück.
Die Automatisierung hat den Prozess dabei nicht kaputt gemacht. Sie hat ihn schneller gemacht und dabei eine Kontrolle entfernt, die vorher nebenbei stattfand: Die Sachbearbeiterin, die den Auftrag manuell erfasst hat, hat in der Auftragsmaske gesehen, dass der freie Bestand rot war. Sie hätte das nie eine Verfügbarkeitsprüfung genannt. Sie hat die Farbe gesehen und angerufen.
Was wir stattdessen bauen
Der erste Schritt ist, Verfügbarkeit anzufragen statt Bestand zu lesen. Fast jedes ERP hat dafür einen eigenen Weg: einen Verfügbarkeitsendpunkt, eine Auftragssimulation oder einen Positionsvorschlag, der bereits terminiert zurückkommt. Wenn Sie nicht wissen, welcher es ist, fragen Sie den Betreuer Ihres ERP, bevor Sie die API-Dokumentation durchsuchen. Der Endpunkt steht dort meist unter Aufträgen und nicht unter Artikeln.
Der zweite Schritt ist wichtiger und wird häufiger übersehen: Prüfen und Reservieren gehören in denselben Aufruf. Wenn Ihr ERP Reservierungen über die Schnittstelle kennt, benutzen Sie sie. Wenn nicht, legen Sie den Auftrag zuerst an und prüfen danach, ob die Position gedeckt ist. Der Bestätigungsmail muss ein Datensatz vorausgehen, nicht eine Abfrage.
Reservierungen brauchen einen Ablauf, sonst haben Sie in vier Wochen das umgekehrte Problem. Bestellungen, die im Freigabeprozess hängen, blockieren Mengen, auf die niemand wartet. Für Portalbestellungen sind 48 Stunden ein brauchbarer Startwert.
Trennen Sie außerdem die Eingangsbestätigung von der Terminzusage. "Ihre Bestellung ist eingegangen" können Sie immer schicken. "Lieferung Mittwoch" nur, wenn die Menge reserviert ist. Diese Trennung kostet eine halbe Stunde im Workflow und nimmt den größten Teil des Schadens weg.
Bei Artikeln mit hoher Umschlagshäufigkeit sagen wir automatisch nur bis zu einem Anteil des freien Bestands zu, der Rest geht in die manuelle Prüfung. Das ist unelegant und funktioniert.
Und messen Sie die Abweichung. Ein wöchentlicher Abgleich von zugesagtem und tatsächlichem Lieferdatum zeigt das Problem, bevor der Kunde es zeigt. Beim Arbeitsschutz-Händler läuft das inzwischen als Auswertung, die freitags in einen Kanal schreibt.
Wenn das ERP keine Reservierung über die Schnittstelle kennt
Das kommt häufiger vor als erwartet, besonders bei älteren Systemen und bei Anbindungen über Zwischenschichten.
Zwei Wege haben bei uns funktioniert. Der erste ist eine eigene Reservierungstabelle in einer kleinen Datenbank neben dem Workflow. Sie hält fest, welche Menge wann von welchem Auftrag zugesagt wurde, und der Verfügbarkeitscheck rechnet diese offenen Zusagen vom ERP-Bestand ab. Das ist eine zusätzliche Komponente, die gepflegt werden will, aber sie bleibt überschaubar.
Der zweite Weg: automatische Termine nur oberhalb eines Sicherheitsbestands. Bei einem Kunden liegt die Grenze bei 30 Prozent des durchschnittlichen Wochenabgangs. Alles darunter bekommt eine Eingangsbestätigung ohne Datum und einen Eintrag in einer Liste, die zweimal täglich jemand durchgeht. Es ist die schlechtere Lösung, sie war in zwei Tagen fertig.
Woran Sie es in Ihrem Setup erkennen
Öffnen Sie den Schritt in Ihrem Workflow, der den Bestand prüft.
Welches Feld wird gelesen? Heißt es `quantity`, `stock`, `bestand` oder `menge`, ist es mit hoher Wahrscheinlichkeit der Buchbestand.
Steht ein Datum in der Abfrage? Wenn nicht, prüfen Sie gegen heute und sagen für übermorgen zu.
Wie viele Schritte liegen zwischen Prüfung und Auftragsanlage? Jeder davon ist ein Zeitfenster, in dem eine zweite Bestellung dieselbe Menge zugesagt bekommt.
Bei den meisten Anbindungen, die wir uns ansehen, liegt der Fehler in genau einem Schritt. Das ist die gute Nachricht an der Sache: Sie müssen den Workflow nicht neu bauen, Sie müssen ihn eine andere Zahl fragen.