Die meisten eurer Echtzeit-Logistik-Features sind nicht Echtzeit

Jede Logistikplattform verkauft Echtzeit. Echtzeit-Tracking. Echtzeit-Transparenz. Echtzeit-Alerts. In der Demo gleitet ein LKW-Symbol sanft über eine Karte, und der Ingenieur im Raum nickt anerkennend.

In der Produktion aktualisiert sich das LKW-Symbol alle dreißig Sekunden — und die Position, die es zeigt, stammt von vor vierzig Sekunden. Die Route, die es zeichnet, ist interpoliert. Das "Zugestellt"-Ereignis trifft, an einem normalen Tag, zwischen zwei und fünfzehn Minuten nach der tatsächlichen Zustellung ein. Nichts davon ist falsch. Alles davon ist "Echtzeit" im Sinne, den die Branche verwendet. Aber der Kunde denkt, Echtzeit bedeute dasselbe wie in einem Videoanruf — und die Lücke zwischen diesen beiden Definitionen verursacht etwa die Hälfte der Kunden-Eskalationen in diesem Bereich.

Was Echtzeit kostet

Echtzeit im strengen Sinne kostet Geld. Konkret kostet es drei Dinge, die alle linear skalieren, je strenger ihr die Definition macht.

Telematik-Bandbreite. Ein LKW, der seine GPS-Position einmal pro Sekunde meldet, verbraucht etwa sechzigmal mehr Daten als einer, der es jede Minute tut. Multipliziert mit einer Flotte von zehntausend Fahrzeugen, mit Datentarifkosten, mit den Funklöchern, in denen die gepufferten Daten schließlich in Schüben gesendet werden müssen, wenn die Abdeckung zurückkehrt. Die Bandbreiten-Rechnung ist real — und der ROI eines Fünf-Sekunden-Intervalls gegenüber einem Dreißig-Sekunden-Intervall ist in fast jedem Business Case gleich null.

Infrastruktur, um den Datenstrom zu bewältigen. Sobald Positionen in Einer-Sekunden-Auflösung ankommen, muss jedes nachgelagerte System diesen Durchsatz verarbeiten. Speicher. Stream-Prozessoren. Geofencing-Engines. Push-Benachrichtigungen an Fahrer-Apps. Jedes davon hat sein eigenes Skalierungsprofil, und sie skalieren nicht alle linear. Ein Einsekundenintervall kann leicht das Zehnfache der Infrastrukturkosten eines Dreißigsekundenintervalls bedeuten — bei kaum einer operativen Verbesserung.

Engineering-Stunden für immer. Die Strenge wird zu einer Eigenschaft der Architektur, und die Architektur wird zu einer Eigenschaft des Unternehmens. Jedes neue Feature muss sie einhalten. Jede neue Anbieterintegration muss sie einhalten. Die Gesamtkosten sind nicht der Build; es sind die nächsten fünf Jahre, in denen jeder Ingenieur über Latenz nachdenkt, die das Unternehmen nie wirklich brauchte.

Was Kunden tatsächlich brauchen

Das Interessante ist, dass fast kein Logistik-Kunde wirklich Positionen von Sekunde zu Sekunde braucht. Was sie brauchen, ist eines von drei spezifischen Dingen.

Eine genaue ETA. "Wann kommt mein LKW an?" Diese Frage gut zu beantworten braucht Routenentfernung, Verkehr, das historische Tempo des Fahrers und eine Position, die frisch genug ist, um der Ausgangspunkt zu sein. Eine dreißig Sekunden alte Position reicht dafür völlig aus. Eine einsekundenalte Position gibt euch keine bessere ETA.

Geofence-Ereignisse. "Sag mir, wenn mein LKW das Depot betritt." Das braucht eine garantierte Ereignislieferung (das schwierigere Problem), kein schnelleres Polling. Ein korrektes Ereignis, das vierzig Sekunden zu spät ankommt, ist wertvoller als ein Stream, der es vielleicht erfasst hat oder vielleicht nicht.

Ausnahme-Alerts. "Sag mir, wenn etwas schiefläuft." Verspäteter Abgang, Routenabweichung, unerwarteter Stopp. Das sind Mustererkennung über ein Fenster. Sie brauchen keine Echtzeit — sie brauchen Korrektheit.

In allen drei Fällen ist die gewinnende Architektur ereignisgesteuert mit relativ grobem Polling darunter, nicht hochfrequentes Streaming. Die Ausnahme ist echtes Live-Mapping — ein Kunde, der buchstäblich einen LKW auf einem Bildschirm in Echtzeit zuschaut, zu Unterhaltungs- oder Aufsichtszwecken. Dieser Anwendungsfall existiert — und ist einer oder zwei Bildschirme im Unternehmen, nicht die gesamte Plattform.

Was man tatsächlich tun sollte

Das Muster, das funktioniert, aus unserer Erfahrung:

Pro Feature einen Datenfrische-Vertrag definieren. ETA: Position darf nicht älter als neunzig Sekunden sein. Geofence-Ereignisse: müssen innerhalb von fünf Minuten nach dem Auftreten garantiert geliefert werden. Live-Karte: Best-effort dreißig Sekunden, kein SLA. Das aufschreiben. Den Kunden zeigen. Kunden finden das beruhigend, nicht enttäuschend — sie wurden von vagen "Echtzeit"-Versprechen enttäuscht und schätzen Ehrlichkeit.

Zuerst die Ereignis-Wirbelsäule bauen, dann das Polling. Geofence-betreten, Route-abgewichen, Zustellung-abgeschlossen. Das sind die Ereignisse, auf denen das Unternehmen läuft. Sie als dauerhafte, geordnete, exactly-once-Ereignisse bauen. Dann Position-Polling darüberlegen, mit welcher Frequenz auch immer der Frische-Vertrag es erfordert.

Für ein schlechtes Netzwerk entwerfen. Fahrer fahren durch Tunnel. Lager liegen in Stahlgebäuden. Das Modem des LKWs startet neu. Das Telefon geht aus. Ein Logistiksystem, das Konnektivität als zuverlässig voraussetzt, ist ein System, das an den meisten Tagen falsche Daten produziert. Lokal puffern, bei Wiederverbindung abgleichen, jedes Ereignis so entwerfen, dass es wiederholbar ist.

Die ehrliche Botschaft

Wir haben viel davon gebaut. Die Version, die ausgeliefert wird und ausgeliefert bleibt, ist fast nie die mit den aggressivsten Echtzeit-Zahlen. Es ist die, bei der der Vertrag zwischen System und Kunde ehrlich darüber ist, was "Echtzeit" bedeutet — und die Architektur das optimiert, was das Unternehmen tatsächlich braucht: genaue ETAs, garantierte Ereignisse und Resilienz gegen ein Netzwerk, das gelegentlich versucht, euren Tag zu ruinieren.