Die Transporter-App: Offline-First-Abläufe für den Transport

Als TST Terschelling uns annahm, ihren papierbasierten Treiber-Workflow zu ersetzen, war der Brief einfach: es schneller zu machen, digital zu machen, zuverlässig zu machen. Was folgte, war eines der technisch anspruchsvollsten Projekte, die wir ausgeliefert haben.

Die Beschränkung, die alles geformt hat

Die Wadden-Inseln haben eine häufige mobile Abdeckung. Die Fähren überqueren zweimal täglich. Ein Fahrer, der um 6 Uhr morgens Güter am Hafen lädt, hat nicht den Luxus, jedes Mal, wenn er einen Barcode scannt, auf einen Server hin und her zu warten. Die App musste vollständig offline funktionieren nicht als Rückfall, sondern als primärer Betriebsmodus.

Diese einzige Einschränkung veränderte jede Architekturentscheidung, die wir getroffen haben.

Was Transporter tut

Transporter ist die operative Wirbelsäule eines Fahrers.

• Anmeldung des Fahrers und Zuteilung der Route
• Lastwagenladen mit Barcode-Scanning und Mengenvalidierung
• Arbeitsflow für die Lieferung von Stopp-für-Stopp mit Ausnahme-Handhabung
• Digitale Liefernachweise einschließlich Signaturerfassung
• End-of-day-Route-Schließung und Synchronisierung zurück zum Backend

Jede Aktion ist vor Ort. Das Gerät speichert den Zustand, stellt Ereignisse in Schlange und synchronisiert opportunistisch, wenn eine Verbindung verfügbar ist. Nichts blockiert einen Netzwerkanruf im kritischen Pfad.

Der technische Stapel

Wir bauten Transporter als native C# Anwendung auf Zebra Android Geräte. Zebra Handhelds sind der Branchenstandard für Lager- und Logistik-Scanning.

Das Backend ist ein PHP REST API, das von MySQL unterstützt wird. Die Zustandsvermittlung erfolgt über ein ereignisbezogenes Synchronisationsmodell: Das Gerät sammelt ein Protokoll der Operationen, der Server wendet sie in Reihenfolge an und Konflikte werden deterministisch gelöst. Der Fahrer sieht im kritischen Moment nie einen Lade-Spinner.

Was wir gelernt haben

Offline-first klingt einfach, bis man es ordnungsgemäß handhaben muss. Jeder Randfall, der in einer immer verbundenen App trivial ist, wird zu einem Designproblem: Was passiert, wenn ein Treiber das gleiche Element zweimal auf verschiedenen Geräten scannt? Was passiert, wenn sich die Routendaten auf dem Server geändert haben, seit die App zuletzt synchronisiert wurde? Was passiert, wenn die Gerätuhr falsch ist?

Wir haben viel Zeit für das Synchronisierungsprotokoll und das UI-Feedback-Modell verbracht, um sicherzustellen, dass der Fahrer immer den Autoritätstatus seiner Route kennt, auch wenn dieser Status vor drei Stunden bei einer Fährüberfahrt zuletzt aktualisiert wurde.

Das Ergebnis ist eine App, die seit dem Start täglich ohne ein einziges Problem der Datenintegrität läuft.

Das Ergebnis

TST Terschelling ersetzte den seit Jahren bestehenden Clipboard-und-Papier-Prozess. Die Ladezeit pro Lkw ist deutlich gesunken. Die Streitigkeiten über Liefernachweise verschwanden, da jede Lieferung nun eine zeitstempelte, signierte digitale Aufzeichnung hat. Und das Operationsteam kann die Weiterentwicklung der Strecke vom Büro sehen, anstatt auf die Anrufe der Fahrer zu warten.

Es ist die Art von Projekt, das uns daran erinnert, warum Software existiert: um Reibungen aus der Arbeit zu entfernen, die wirklich wichtig sind.