Wenn die Verbindung abbricht: Was Ihr Betrieb dann tut

Ein Fahrer fährt in einen Straßentunnel, auf ein unterirdisches Ladedeck, auf das Autodeck einer Fähre – oder einfach in ein Tal, in dem ein einziger schwacher Mast drei Dörfer versorgt –, und für fünf Minuten oder vierzig hat das Telefon kein Netz. Das ist kein Systemausfall und kein seltener Sonderfall, sondern ein normaler Teil des Fahrbetriebs in echter Geografie, und jeder Betrieb mit mehr als einer Handvoll Routen erlebt das routinemäßig. Die interessante Frage ist nicht, ob das passiert. Sie lautet, was die App auf der Halterung am Armaturenbrett und der Dispositionsbildschirm im Büro dann tun – und ob jemand weiter unten in der Kette den Unterschied erkennen kann zwischen „hier ist nichts passiert“ und „hier ist etwas passiert, wir wissen nur noch nichts davon“.

Drei verschiedene Probleme unter einem Namen

„Offline“ wird oft so verwendet, als wäre es ein einziger Zustand. Tatsächlich verliert eine Fahrer-App drei voneinander trennbare Dinge, wenn das Signal ausfällt, und die drei verhalten sich beim Wiederkehren des Netzes nicht gleich.

Das Erste ist Zustand, der bereits lokal vorlag – die heutige Stoppliste, die Route, das Frachtmanifest für die aktuell geladene Sendung. Nichts davon braucht eine aktive Verbindung, um nützlich zu sein; es muss nur vor der Einfahrt in das Funkloch geladen worden sein, was eine Frage der letzten Synchronisation ist, nicht des Verhaltens im Offline-Zustand. Ein Fahrer, der im Tunnel seinen nächsten Stopp prüft, liest Daten, die vor einer Stunde eingetroffen sind, und braucht dafür überhaupt kein Netz mehr.

Das Zweite ist eine Handlung, die genau in dem Moment erfasst werden muss, in dem sie geschieht, ob das Netz in diesem Augenblick mitspielt oder nicht. Eine Lieferung wird an der Tür verweigert. Eine Palette kommt beschädigt an. Ein Stopp wird abgeschlossen, weil der Empfänger unterschrieben hat. Das sind Tatsachen mit einem Zeitstempel, und der Zeitstempel ist jetzt, im Funkloch – nicht irgendwann, wenn die Balken wiederkommen. Eine App, die eine Tatsache erst dann festhalten kann, wenn sie sie auch gleich melden kann, zwingt den Fahrer entweder zum Warten am Straßenrand oder dazu, sich auf sein Gedächtnis für die spätere Eingabe zu verlassen – und „ich mach’s, sobald ich Netz habe“ ist genau der Mechanismus, durch den aus einem Betriebsprotokoll eine nachträgliche Rekonstruktion wird.

Das Dritte ist ein Live-Feed, der keine nachträgliche Antwort kennt – vor allem die Frage, wo sich das Fahrzeug gerade befindet. Position ist, ehrlich betrachtet, keine Tatsache, die man später nachliefern kann: Verbringt ein Lkw achtzehn Minuten in einem Tunnel, gibt es auf die Frage „wo war er in Minute neun“ keine wahre Antwort außer „irgendwo im Tunnel, zwischen den beiden Punkten davor und danach“. Das richtige Verhalten besteht nicht darin, Kontinuität vorzutäuschen. Es besteht darin, die zuletzt bekannte Position mit ihrem Zeitstempel anzuzeigen und der Person, die zuschaut, die naheliegende Schlussfolgerung selbst zu überlassen – statt stillschweigend eine gerade Linie durch massives Gestein zu interpolieren und sie als Daten auszugeben.

Der Datensatz und sein Beleg sind sich selten einig, wer zuerst kommt

Die meisten betrieblichen Ereignisse sind kein einzelner Schreibvorgang, sondern ein Datensatz plus etwas, das ihn belegt: eine Lieferung plus eine Unterschrift, eine Verweigerung plus ein Foto, eine Inspektion plus die Bilder des Schadens. Im Funkloch lässt sich in der Regel genau eines der beiden lokal und günstig schreiben – der Datensatz selbst, der klein ist –, während das andere, insbesondere ein Foto, groß genug ist, dass „einfach den Upload wiederholen“ eine echte Wartezeit bedeutet, keine sofortige.

Die beiden Ereignisse wollen nicht dieselbe Reihenfolge. Ein Lieferdatensatz, der ohne dazugehöriges Foto existiert, ist ein kleines Risiko, das sich im Zweifelsfall noch klären lässt. Ein Fahrer, der an der Tür festhängt, weil die App einen Stopp erst dann als abgeschlossen markiert, wenn ein Bild über ein einziges Balken Signal fertig hochgeladen ist, ist ein größeres und dringenderes Problem – der Stopp steckt jetzt fest, der Fahrer wartet oder umgeht die App, und genau so wächst neben einem digitalen Prozess still wieder ein Papierprozess heran. Der Datensatz sollte also nicht darauf warten, dass sein Beleg unterwegs ist; der Beleg sollte umgekehrt aber auch nicht als verzichtbare Fracht behandelt werden, deren Verlust in Ordnung ist. Er muss im Hintergrund eigenständig weiter versuchen, bis er ankommt oder tatsächlich verloren ist – und wenn er verloren ist, muss das für jemanden sichtbar werden, statt einfach zu verschwinden.

Diese Reihenfolge gilt allerdings nicht universell, und das ist der bemerkenswerte Teil: Bei manchen Ereignissen kehrt sich die Priorität um. Die Meldung einer fehlgeschlagenen Zustellung ist dem Büro vermutlich auch ganz ohne Foto nützlicher, als gar nicht in dem Moment gemeldet zu werden, in dem sie passiert – denn ein gescheiterter Stopp verändert, wie der Rest des Tages aussieht: ein zweiter Zustellversuch, ein Anruf beim Kunden, eine Umplanung der Tour. Das muss die Disposition erreichen, bevor die Fotos es tun, wenn eine Wahl getroffen werden muss. Was zuerst kommt, sollte keine technische Voreinstellung sein, die jemand aus Versehen danach festlegt, welcher Aufruf im Code am leichtesten zuerst abzusetzen ist. Es ist eine bewusste Entscheidung darüber, welches Fehlen mehr schaden würde – einmal getroffen, pro Art von Datensatz.

Ein erneuter Versuch ist kein zweites Ereignis

Der unangenehme Fall ist der, bei dem tatsächlich niemand weiß, was passiert ist: Die App hat die Anfrage abgeschickt, die Verbindung brach mittendrin ab, und allein vom Gerät aus lässt sich nicht unterscheiden, ob der Server die Anfrage empfangen und nicht geantwortet hat, oder ob er sie nie gesehen hat. Blind erneut zu senden ist unproblematisch bei etwas Idempotentem. Es ist nicht unproblematisch bei einer Handlung, die bei jedem Aufruf einen neuen Datensatz erzeugt – ein zweiter „zugestellt“-Eintrag nach einem unklaren Timeout kann für alles, was nachgelagert darauf aufbaut, wie ein zweiter Zustellversuch aussehen statt wie die Bestätigung des ersten. Ein ehrliches System muss diesen Unterschied abbilden: „definitiv fehlgeschlagen, sicher erneut sendbar“ ist ein anderer Zustand als „wir wissen es nicht“, und Letzterer verdient mehr Vorsicht – eine Bestätigung durch einen Menschen, bevor es erneut abgeschickt wird, statt eines stillen Wiederholungsversuchs, der ein reales Ereignis auf dem Papier verdoppeln könnte.

Bekannte Funklöcher als bekannt behandeln, nicht als Vorfall

Das meiste davon lässt sich mit Vorausschau bewältigen, nicht mit Cleverness. Führt eine Route jede Woche durch denselben Tunnel oder dasselbe Funkloch zwischen drei Dörfern, ist das keine Neuigkeit, sondern ein bekanntes Merkmal der Strecke – und zehn Minuten Funkstille auf diesem Abschnitt als Alarm statt als Erwartung zu behandeln, gewöhnt die Disposition daran, Fahrer wegen etwas zu jagen, das gar nicht falsch läuft. Die Gewohnheit, die sich lohnt aufzubauen, ist, die eigenen Funklöcher gut genug zu kennen, um „still, weil Tunnel“ von „still, weil tatsächlich etwas nicht stimmt“ zu unterscheiden. Das bleibt eine Einschätzung, die ein Mensch treffen muss – aber nur dann gut treffen kann, wenn das System davor ehrlich sagt, was es gerade weiß und was nicht.

Wo navichain steht

Die Fahrer-App erfasst Status, Unterschrift, Fotos und den Grund einer fehlgeschlagenen Zustellung direkt vor Ort, und die heutigen Stopps, die Navigation und das Frachtmanifest je Stopp liegen bereits vor Tagesbeginn auf dem Telefon – ein Fahrer, der den nächsten Drop abarbeitet, liest einen Plan, der schon da war, nicht einen, der erst live nachgeladen werden muss. Die Plattformseite zeigt den Rest dessen, was daneben läuft: tägliche Rundgangskontrollen, die im Moment eines Fehlers sofort einen Mangel eröffnen, und Gefahrgutangaben, die genau auf den Stopp zugeschnitten sind, an dem ein Fahrer gerade steht – damit die Information, die an der Tür zählt, nicht davon abhängt, was das Signal gerade tut, wenn die Tür aufgeht.