Mobile Lager- und Versand-App

Ausgangslage

Lagerarbeit lebt vom Tempo: Wareneingang, Umlagerung, Kommissionierung, Versand — jede Buchung, die am PC statt am Gerät passiert, kostet Wege und produziert Übertragungsfehler.

Standard-Lagersoftware passte nicht zu den eigenen Abläufen, und jede Anpassung beim Hersteller kostete Zeit und Lizenzgebühren.

Das Schwierige daran

Ein Handscanner ist kein kleines Smartphone. Der Bildschirm ist klein, bedient wird mit Handschuhen, im Kühlbereich beschlägt die Scheibe, und das WLAN hat im Regalgang Löcher. Eine Oberfläche, die am Schreibtisch überzeugt, ist im Lager oft unbrauchbar — die Prüfung findet nicht im Büro statt, sondern zwischen den Regalen.

Der wichtigste Unterschied zu einer gewöhnlichen App aber ist die Folge eines Fehlers. Jede Buchung ist eine Lagerbewegung. Was hier falsch läuft, ist kein Anzeigefehler, sondern eine Inventurdifferenz — und die fällt Wochen später auf, wenn niemand mehr weiß, woher sie kommt.

Dazu die unangenehmste Fehlerart überhaupt: die stille. Eine Liste, die zu lang ist und deshalb abgeschnitten wird, sieht auf einem kleinen Bildschirm genauso aus wie eine vollständige. Man sieht ohnehin nur ein paar Zeilen.

Lösung

Gebaut wurde eine mobile Lager-App für Handscanner: sieben Workflows — Wareneingang, Umlagerung, Inventur, Kommissionierung, Versand, Verladekontrolle und Journal — direkt am Gerät, mit Barcode-Scan im Sekundentakt.

Etiketten kommen ohne Umweg aus dem Prozess: Carrier-Labels für vier Paket- und Speditionsdienstleister gehen direkt per ZPL auf Zebra-Drucker. Ohne Etikett kein Abschluss — das erzwingt saubere Prozesse.

Dahinter arbeitet ein schlankes Rust-Backend mit über 300 API-Endpunkten direkt gegen ERP und Lagerdatenbank; eine native Android-Version läuft bereits in der Erprobung, parallel zur produktiven Web-App.

Wie es gebaut ist

Hinter der App arbeitet ein schlankes, in Rust geschriebenes Backend mit über 300 Endpunkten direkt gegen ERP und Lagerdatenbank. Die Wahl ist bewusst getroffen. Ein Handscanner-Ablauf lebt von kurzen Antwortzeiten, und zwischen Scan und Bestätigung darf keine Denkpause liegen, sonst scannt der Mitarbeiter längst weiter, bevor überhaupt gebucht ist.

Sieben Abläufe sind produktiv: Wareneingang, Umlagerung, Inventur, Kommissionierung, Versand, Verladekontrolle und Journal. Jeder ist eigenständig bedienbar. Niemand muss durch ein Hauptmenü navigieren, um eine Palette umzulagern.

Etiketten entstehen im Ablauf statt daneben, und Carrier-Labels für vier Dienstleister gehen direkt in der Druckersprache an die Etikettendrucker, ohne dass jemand zwischendurch an einen Rechner zurückläuft. Ohne gedrucktes Etikett kein Abschluss. Der Zwang ist Absicht.

Das Journal protokolliert jede Bewegung mit Zeitpunkt, Gerät und Person — es ist damit zugleich Fehlersuche und Nachweis, und über 1,2 Millionen Bewegungen sind seit dem Start aufgezeichnet.

Im Betrieb

Die Web-App läuft produktiv, eine native Android-Fassung parallel in Erprobung. Beide sprechen dasselbe Backend, und weil das so ist, passieren Umstellungen geräteweise statt als Stichtag für ein ganzes Lager, das an diesem Tag ohnehin ausliefern muss.

Neue Fassungen werden signiert ausgeliefert und zunächst auf einem einzigen Gerät im Echtbetrieb geprüft, bevor sie auf alle anderen gehen, denn ein Lager lässt sich nicht für eine halbe Stunde anhalten, nur um eine App zurückzurollen.

Im Alltag ist das Journal das wichtigste Werkzeug. Kommt eine Rückfrage aus der Buchhaltung, ist in Sekunden sichtbar, wer wann was gebucht hat, statt dass jemand den Vorgang aus Erinnerungen rekonstruieren muss.

Ergebnis

Über 1,2 Millionen Lagerbewegungen sind seit dem Start vor gut einem halben Jahr protokolliert — jede davon am Gerät gebucht statt am Schreibtisch.

Erfassungsfehler fallen dort auf, wo sie entstehen, und der Etiketten-Zwang macht unvollständige Vorgänge unmöglich.

Was wir daraus gelernt haben

Eine Oberfläche, die Daten weglässt, muss das sagen. Sonst sagt sie: Es gibt nicht mehr. Die Frage an jede Liste lautet, woran der Nutzer erkennt, dass dies nicht der vollständige Bestand ist. Kann er es nicht, steht ein Ergebnis auf dem Gerät, das keines ist.

Ein WLAN mit Löchern ist Teil des Entwurfs und kein Störeignis. Der Augenblick ohne Verbindung entscheidet, ob eine App im Lager benutzt wird: was ein Vorgang ohne Netz tut, muss am Gerät sichtbar sein. Sonst wird der Scan noch einmal gemacht, und zweimal gebucht ist eine Differenz.

Auch die Auslieferung hat ihre eigene Falle. Wird eine neue Programmfassung über den bestehenden Pfad verschoben statt hineinkopiert, tauscht sie die Datei aus, ohne dass der ausliefernde Dienst es bemerkt: Er hält die alte weiter offen und verteilt sie weiter. Man sucht den Fehler dann in einer Version, die auf den Geräten nie angekommen ist. Ein halber Tag, den man genau einmal verliert.