La maggior parte delle tue funzionalità logistiche in tempo reale non sono in tempo reale

Ogni piattaforma logistica vende il tempo reale. Tracking in tempo reale. Visibilità in tempo reale. Alert in tempo reale. Nella demo, l'icona di un camion scivola fluidamente su una mappa e l'ingegnere in sala annuisce con approvazione.

In produzione, l'icona del camion si aggiorna ogni trenta secondi, e la posizione che mostra risale a quaranta secondi fa. Il percorso che disegna è interpolato. L'evento "consegnato" arriva, in una giornata normale, tra due e quindici minuti dopo la consegna effettiva. Nulla di tutto questo è sbagliato. Tutto questo è "tempo reale" nel senso in cui il settore usa la parola. Ma il cliente pensa che tempo reale significhi la stessa cosa di una videochiamata, e il divario tra queste due definizioni causa circa metà delle escalation dei clienti in questo settore.

Quanto costa il tempo reale

Il tempo reale, in senso stretto, costa denaro. Specificatamente, costa tre cose che si scalano tutte linearmente con quanto stretta si rende la definizione.

Larghezza di banda della telematica. Un camion che riporta la sua posizione GPS una volta al secondo usa circa sessanta volte più dati di uno che riporta ogni minuto. Moltiplicato per una flotta di diecimila veicoli, per i costi dei piani dati, per le zone morte cellulari dove i dati bufferizzati devono essere inviati in burst quando torna la copertura. Il conto della larghezza di banda è reale e il ROI di un intervallo di cinque secondi rispetto a uno di trenta secondi è, in quasi ogni caso di business, nullo.

Infrastruttura per gestire il diluvio. Una volta che le posizioni arrivano a risoluzione di un secondo, ogni sistema downstream deve gestire quella portata. Storage. Stream processor. Motori di geofencing. Notifiche push alle app degli autisti. Ognuno di questi ha il proprio profilo di scalabilità, e non si scalano tutti linearmente. Un intervallo di aggiornamento di un secondo può facilmente significare dieci volte il costo infrastrutturale di uno di trenta secondi — per quasi nessun miglioramento operativo.

Ore ingegneristiche per sempre. La rigidità diventa una proprietà dell'architettura, e l'architettura diventa una proprietà dell'azienda. Ogni nuova funzionalità deve rispettarla. Ogni nuova integrazione con fornitori deve rispettarla. Il costo totale non è la costruzione; è i prossimi cinque anni di ogni ingegnere che pensa alla latenza di cui il business non aveva mai davvero bisogno.

Cosa hanno davvero bisogno i clienti

La cosa interessante è che quasi nessun cliente logistico ha davvero bisogno di posizioni secondo per secondo. Quello di cui hanno bisogno è una di tre cose specifiche.

Un ETA accurato. "Quando arriverà il mio camion?" Rispondere bene a questo richiede distanza del percorso, traffico, il ritmo storico dell'autista e una posizione abbastanza recente da essere il punto di partenza. Una posizione di trenta secondi fa è più che sufficiente. Una posizione di un secondo fa non dà un ETA migliore.

Eventi di geofence. "Dimmi quando il mio camion entra nel deposito." Questo richiede una consegna degli eventi garantita (il problema più difficile), non un polling più veloce. Un evento corretto che arriva quaranta secondi dopo è più prezioso di uno stream che potrebbe o meno averlo catturato.

Alert di eccezione. "Dimmi quando qualcosa sta andando storto." Partenza in ritardo, deviazione fuori rotta, sosta inattesa. Queste sono rilevazioni di pattern su una finestra temporale. Non hanno bisogno del tempo reale; hanno bisogno della correttezza.

In tutti e tre i casi, l'architettura vincente è event-driven con polling relativamente grossolano alla base, non streaming ad alta frequenza. L'eccezione è la mappatura live genuina — un cliente che guarda letteralmente un camion muoversi su uno schermo, in tempo reale, per scopi di intrattenimento o supervisione. Questo caso d'uso esiste, ed è una o due schermate nel business, non l'intera piattaforma.

Cosa fare davvero

Il pattern che funziona, dalla nostra esperienza:

Definire un contratto di freschezza dei dati per ogni funzionalità. ETA: la posizione non deve essere più vecchia di novanta secondi. Eventi di geofence: devono essere consegnati con garanzia entro cinque minuti dall'occorrenza. Mappa live: best-effort trenta secondi, nessun SLA. Scriverli. Mostrarli ai clienti. I clienti li trovano rassicuranti, non deludenti — sono stati scottati da vaghe promesse di "tempo reale" e apprezzano l'onestà.

Costruire prima lo spine degli eventi, poi il polling. Geofence-entered, route-deviated, delivery-completed. Questi sono gli eventi su cui gira il business. Costruirli come eventi duraturi, ordinati, esattamente-una-volta. Poi aggiungere il polling delle posizioni sopra, alla frequenza richiesta dal contratto di freschezza.

Progettare per una rete pessima. Gli autisti passano per i tunnel. I magazzini sono dentro edifici d'acciaio. Il modem del camion si riavvia. Il telefono esaurisce la batteria. Un sistema logistico che finge che la connettività sia affidabile è un sistema che produce dati errati nella maggior parte dei giorni. Bufferizzare localmente, riconciliare alla riconnessione, progettare ogni evento in modo da poter essere riprodotto.

L'offerta onesta

Abbiamo costruito molto di questo. La versione che viene rilasciata e rimane rilasciata non è quasi mai quella con i numeri di tempo reale più aggressivi. È quella dove il contratto tra il sistema e il cliente è onesto su cosa significa "tempo reale," e l'architettura ottimizza per le cose di cui il business ha davvero bisogno — ETA accurati, eventi garantiti e resilienza a una rete che a volte prova a rovinarti la giornata.