Im Lager ist das Schlimmste nicht der Mangel an Waren, sondern falsches Kommissionieren, Übersehen beim Kommissionieren und falsche Verpackung in die falschen Kartons. Sobald das Auftragsvolumen steigt, können Papier‑Kommissionierlisten und WeChat‑Screenshots nicht mehr mithalten: Mehrere Mitarbeiter greifen gleichzeitig auf denselben Lagerplatz zu, dieselbe SKU wird in mehreren Chargen durcheinander gelagert, und die Kontrolle beruht lediglich auf einem kurzen Blick. Nach Fehllieferungen folgen Kundenbeschwerden, Rücksendungen und Nachlieferungen – die Kosten sind oft höher, als wenn man einfach eine weitere Person einstellen würde.
Die Probleme lassen sich wie folgt aufschlüsseln: Kommissionieren ist keineswegs so einfach wie „Waren nach Auftrag suchen“
In der Praxis gibt es mindestens vier Phasen: Erstellung von Wellen/Aufträgen, Lagerplatznavigation und Kommissionierung, Kontrolle und Verpackung sowie Übergabe beim Ausgang. Tabellen können zwar festhalten, „was kommissioniert wurde“, aber nicht, „wann kommissioniert werden sollte, wer kommissioniert und ob das Kommissionierte anschließend durch eine Kontrolle gesperrt wurde“. Was den Arbeitsablauf vor Ort wirklich lahmlegt, sind Parallelitätskonflikte und der Umstand, dass der Status nicht rückverfolgbar ist.
- Wellen: Aufgaben werden nach Route, Spediteur und Stichtag zugeschnitten, um unnötige Wege zu vermeiden
- Kommissionierung: Aufträge werden in der Reihenfolge der Lagerplätze verteilt; neben dem Kommissionieren kann auch sofort gescannt werden, und Mengenabweichungen werden sofort erkannt und abgefangen
- Kontrolle: Durch zweifache Überprüfung mittels Karton‑ oder Produktcode werden Fehllieferungen bereits vor dem Ausgang des Lagers erkannt
- Übergabe: Verbunden mit der Kurier‑Sendungsnummer und der Ladecharge, was die spätere Haftung erleichtert
Wie gestaltet man das System? Rollen, Prozesse und Datenbegrenzungen
Empfohlen wird, die Rollen aufzuteilen in Disponent, Kommissionierer, Kontrolleur und Lagerverwalter. Der Disponent sieht nur Stichtag und Wellen; der Kommissionierer nur seine eigene Auftragsliste; der Kontrolleur ist für den jeweiligen Karton verantwortlich; der Lagerverwalter kümmert sich um fehlende Waren und Umlagerungen. Die Berechtigungen werden über einen Zustandsautomaten gesteuert – kein „Superknopf“, der beliebig den Lagerbestand ändern kann.
Kern‑Datenobjekte:
- Kommissionierauftrag: Sammlung von Auftragspositionen, Lagerplatz‑Route, Verantwortlicher, Status (zu kommissionieren / im Kommissionieren / zur Kontrolle / fertig / abnormal)
- Kommissionierdetails: SKU, Charge/Haltbarkeit, geplante Menge, tatsächlich kommissionierte Menge, Scan‑Verlauf
- Kontrollprotokolle: Kartoncode, Scan‑Reihenfolge, Grund der Abweichung, Ergebnis der Freigabe/Blockierung
- Lagerbestands‑Belegung: Bei Auftragsbildung wird reserviert, nach Abschluss wird abgebucht, bei Stornierung wird freigegeben
Die Schnittstellen müssen klar definiert sein: Am Kommissionierterminal werden nur Aufträge und Scans angezeigt; Bestandsanpassungen erfolgen über den Lagerverwalter; bei Kundenservice werden Fehllieferungen über das Kontrollprotokoll erfasst, statt mündlich beim Lagerverwalter nachgefragt.
Wie entwickelt man das System? Datenerfassung, Schnittstellen und Abnahme
Die Datenerfassung basiert hauptsächlich auf Barcodescanning, wobei manuelle Eingaben als Backup dienen und zur Auditerstellung genutzt werden. Nur wenn alle drei Codes – Lagerplatz, Produkt und Karton – gescannt wurden, darf der Auftrag geschlossen werden. Bei fehlenden Waren wird der Auftrag ausgesetzt und die versprochene Lieferfrist im Auftrag aktualisiert, statt stillschweigend weniger zu liefern.
Häufige Schnittstellen: ERP‑Ausgangsrechnungen, WMS‑Bestände, TMS‑Kurier‑Sendungsnummern. Bei der Abnahme sollten nicht nur „Funktionspunkte“ gezählt werden, sondern auch Belastungstests durchgeführt werden:
- Wenn zwei Aufträge für denselben Lagerplatz gleichzeitig eingehen, wie ordnet das System sie in der Warteschlange oder teilt sie auf?
- Kann ein falsch gescanntes SKU sofort blockiert und protokolliert werden?
- Stimmt der Lagerbestand nach der Freigabe durch die Kontrolle mit der Sendungsnummer überein?
- Kann die Rückverfolgung einer Fehllieferung innerhalb von 3 Minuten auf Person, Karton und Zeitpunkt eingegrenzt werden?
Wenn die Kontrolle ausschließlich visuell erfolgt, verliert das System in der Hochsaison schnell seinen Wert. Das Prinzip „Erst gescannt, dann kommissioniert“ sollte in die Abnahmekriterien aufgenommen werden.
Risiken, die bei der Implementierung besonders beachtet werden sollten
In der ersten Woche treten häufig Probleme auf wegen der Barcode‑Qualität und der Lagerplatz‑Stammdaten: Ein Gegenstand hat mehrere Codes, Lagerplätze sind falsch gekennzeichnet, Chargen sind noch nicht aktiviert. Zuerst sollten die Stammdaten bereinigt werden, dann erst die Wellen implementiert werden; die Wellenstrategie sollte zunächst einfach nach Stichtag unterteilt werden, später jedoch weiter optimiert werden, etwa nach Gängen. Fehllieferungsrate, durchschnittliche Anzahl der kommissionierten Positionen pro Mitarbeiter und die Rate der abgefangenen Fehler sollten innerhalb von drei Wochen besonders beobachtet werden.
Drei häufige Fehlermuster vor Ort
Das erste ist das zu feine Aufteilung der Aufträge: Jeder Auftrag bekommt eine eigene Welle, der Kommissionierer läuft durch das ganze Lager, was zu enormem Wegverlust führt. Wellen sollten nach Gängen oder Spediteuren gebündelt werden, doch zu große Bündelungen bergen das Risiko eines Stichtags‑Überschreitens. Das System muss in der Lage sein, nach dem Stichtag rückwärts zu sortieren, und überfällige Aufträge automatisch in einen Eilverzug zu überführen.
Das zweite Problem ist die Nicht‑Synchronisation zwischen Lagerbestand und physischer Realität: Das ERP meldet bereits ausgehende Ware, während das Regal noch gefüllt ist; oder das Regal ist leer, doch das System zeigt weiterhin verkaufsfähige Artikel an. Reservierungen müssen bereits bei der Auftragsvergabe erfolgen, stornierte Aufträge müssen unbedingt freigegeben werden, Inventur‑Abweichungen werden separat dokumentiert, und direkte Buchungsänderungen am Kommissionierterminal sind strengstens untersagt.
Das dritte Problem ist die scheinbare Sinnlosigkeit der Kontrolle: In der Hochsaison wird aus Gründen der Geschwindigkeit auf die zweite Scan‑Runde verzichtet. Die Kosten für Fehllieferungen entladen sich dann in der Rücksende‑Saison. Man könnte die Kontrolle als Stichprobe plus hochwertige Vollkontrolle gestalten: Beträge oder leicht verwechselbare SKUs werden zwingend vollständig kontrolliert, der Rest wird stichprobenweise geprüft; bei fehlgeschlagenen Stichproben wird die gesamte Welle zurückgestellt.
Wie stimmt man sich mit Vor‑ und Nachgelagerten ab
Das vorgelagerte Bestellsystem liefert die versprochene Lieferfrist und die Präferenz für Verpackungsmaterial; das nachgelagerte Kurier‑Sendungsblatt schreibt die Sendungsnummer und das Gewicht zurück. Das Lager ist nur für die „ausführbare Ausgangsware“ verantwortlich. Bei Schnittstellenfehlern muss eine Wiederholung möglich sein und idempotent funktionieren: Eine wiederholte Übermittlung derselben Ausgangsrechnung darf nicht zu zwei unterschiedlichen Kommissionieraufträgen führen. Die Protokolle müssen den Scan‑Verlauf mindestens 90 Tage lang aufbewahren, um Kundenbeschwerden nachvollziehen zu können.
Personaltraining ist wichtiger als die Inbetriebnahme: Neue Mitarbeiter sollen in den ersten drei Tagen nur feste Gangaufträge bearbeiten, erst danach dürfen sie in gemischte Wellen eintreten. Auf der Systemseite hilft ein „Neuling‑Auftragspool“, die Komplexität zu begrenzen – effektiver als bloß zusätzliche Berechtigungen.
Checkliste für die Implementierung
Vor der Inbetriebnahme prüfen: Vollständigkeit der Lagerplatz‑Stammdaten, Lesbarkeit der Barcodes, Feldzuordnung der ERP‑Ausgangsrechnung, ob die Kontrollgeräte die Spitzenlast abdecken. Während der Testphase werden täglich Ranglisten der Fehllieferungen und Blockierungen veröffentlicht; bei der Frühbesprechung werden nur die Gründe der Top‑3 analysiert, und innerhalb von zwei Wochen lassen sich meist offensichtliche Probleme beseitigen.
Bei Drittanbieter‑Lagern oder kooperierenden Mehrfachlagern müssen Aufträge mit Lagerkennzeichnungen versehen sein, und die Lagerbestands‑Belegung darf nicht über verschiedene Lager hinweg erfolgen. Berichte werden nach Lager getrennt, sonst erhält das Management den Eindruck, „der Gesamtbestand reicht, doch einzelne Lager sind knapp“.
Sicherheitsmäßig sind Handgeräte mit Benutzerkonten verbunden und werden bei Kündigung sofort deaktiviert; die Scan‑Schnittstelle wird mit Rate‑Begrenzung gegen Missbrauch geschützt. Wesentliche Konfigurationsänderungen werden von zwei Personen gemeinsam geprüft, um zu vermeiden, dass eine falsche Änderung der Lagerplatz‑Strategie die Effizienz des gesamten Lagers abrupt einbrechen lässt.
Wenn ein Unternehmen sowohl Produktionsergebnisse ins Lager als auch Verkäufe aus dem Lager hat, sollte das Kommissioniersystem keine Produktionsmeldungen übernehmen; die Grenzen sind klar zu ziehen, und die Schnittstelle nimmt nur „verkaufsfähige Bestände“ entgegen. So sind die Verantwortlichkeiten klar und Probleme lassen sich besser lokalisieren.
Solche Lager‑Betriebssysteme gehören zu den häufigsten Elementen bei der kundenspezifischen Softwareentwicklung auf Unternehmensebene: Sie müssen sowohl den örtlichen Abläufen entsprechen als auch mit den Bestands‑, Verkaufs‑ und Bestellsystemen abgestimmt sein. Shandong XYN Information Technology Co., Ltd. (XYN Tech) entwickelt seit Langem maßgeschneiderte Software für verschiedene Branchen; ihre Website lautet https://www.xynkeji.com; falls zusätzlich Produktions‑ oder Bestandskoordination benötigt wird, kann auch https://www.xynadmin.com herangezogen werden.