L’equivoco diffuso è chiamare ottimizzato qualsiasi viaggio uscito da un calcolatore di percorsi. La schermata mostra una sequenza ordinata, il mezzo risulta assegnato e il costo previsto rientra nei parametri. Eppure la consegna non può essere eseguita. Non per un incidente o per un errore dell’autista: il piano era già irrealizzabile quando è stato confermato.
Immaginiamo una spedizione affidata a un mezzo indicato come disponibile. All’arrivo della giornata operativa emerge che l’autista associato non è impiegabile in quella fascia e che la finestra comunicata dal destinatario è stata modificata. Il percorso calcolato è corretto. È l’insieme di informazioni sul quale è stato calcolato a essere sbagliato.
La consegna impossibile e gli indizi lasciati nella schermata
La ricostruzione parte dalla fine. Il destinatario non accetta la merce nell’orario previsto, l’ufficio traffico cerca un’alternativa e il viaggio deve essere riassegnato. Nella schermata, però, non compare alcuna anomalia. L’ordine è verde, il mezzo è compatibile e la sequenza delle tappe rispetta il piano.
Il primo indizio è proprio quell’assenza di allarmi. Una finestra di consegna mancante può essere interpretata come disponibilità completa. Un calendario autista non aggiornato può far risultare libera una risorsa che libera non è. Una capacità del mezzo registrata in modo generico può far passare un carico che, nella configurazione operativa prevista, non trova posto.
L’algoritmo non ha ignorato un vincolo: quel vincolo non gli è mai arrivato. La distinzione conta, perché cercare il difetto nel motore di calcolo porta a modificare parametri che non hanno causato il problema. Si cambiano pesi, priorità e criteri di ordinamento mentre la fonte dell’errore rimane nel dato iniziale.
Per separare il gestionale operativo dal solo calcolatore di rotta, si può consultare gestionaletrasportatori.it; il passaggio successivo consiste nel verificare quali informazioni arrivano davvero alla pianificazione. Un software può governare il viaggio soltanto entro i confini dei dati che riceve, con la loro precisione e con i loro ritardi.
Lasciare facoltativo il campo della finestra di consegna è una scelta progettuale sbagliata. Se l’informazione manca, il sistema deve segnalarne l’assenza, non convertirla tacitamente in disponibilità totale. Altrimenti un dato sconosciuto viene promosso a dato favorevole, e il piano nasce già falsato.
Il percorso corretto costruito sul problema sbagliato
Risaliamo ancora. L’ordine è stato assegnato perché il modello ha confrontato le opzioni disponibili e ne ha scelta una. IBM, nella propria spiegazione della modellazione di ottimizzazione, definisce il processo come la ricerca della soluzione migliore all’interno di un insieme di scelte possibili. La parola decisiva è migliore: migliore rispetto a quali obiettivi e sotto quali vincoli?
Se l’obiettivo dichiarato è ridurre percorrenza e costo, il sistema tenderà verso quella soluzione. Se la disponibilità dell’autista è registrata male, la finestra del destinatario è vecchia o una restrizione del mezzo non è codificata, quelle condizioni restano fuori dall’insieme valutato. Il risultato può essere matematicamente coerente e operativamente inutilizzabile.
È un limite normale della modellazione, non una stranezza del settore. Un ottimizzatore non ricostruisce automaticamente ciò che l’azienda non ha espresso. Deve sapere quali condizioni sono inderogabili e quali rappresentano preferenze. Una finestra tassativa non può avere lo stesso peso di una fascia gradita. La capacità fisica non può essere trattata come un costo da accettare in cambio di un percorso più corto.
Anche la voce costo richiede cautela. Se il modello considera soltanto la distanza, può preferire un viaggio che comporta un mezzo più oneroso, un’attesa prevedibile o una riassegnazione difficile. Il costo operativo deve essere composto da elementi coerenti con il lavoro reale, non ridotto alla linea più breve sulla mappa.
Per questo la schermata con il percorso colorato dice meno di quanto sembri. Certifica che il sistema ha concluso il calcolo sui dati disponibili. Non certifica che quei dati rappresentino la situazione corrente. Confondere le due cose sposta la fiducia dal processo di validazione all’aspetto ordinato del risultato.
Dietro il vincolo mancante c’è quasi sempre un passaggio fra sistemi
Scendendo ancora nella ricostruzione si arriva alle fonti. Le informazioni necessarie possono essere distribuite fra TMS, ERP, WMS, anagrafiche separate, calendari e comunicazioni ricevute dal cliente. La distinzione tecnica fra questi sistemi non è nominale: ciascuno presidia una parte diversa del flusso e aggiorna dati con tempi propri.
Il TMS lavora sulla pianificazione e sulla gestione del trasporto. L’ERP può conservare condizioni economiche e anagrafiche, mentre il WMS governa disponibilità e movimentazione di magazzino. Se una variazione resta confinata in uno di questi ambienti, il piano può usare una versione precedente dell’ordine. La sincronizzazione completata senza errori tecnici non basta: bisogna controllare quali campi sono passati e con quale data di validità.
Una tesi del Politecnico di Torino dedicata a una metodologia iterativa colloca prima dell’algoritmo due passaggi preparatori: la creazione del database e l’addestramento. È un richiamo concreto. Prima di chiedere al sistema di trovare una soluzione occorre costruire la base informativa e preparare il metodo a interpretarla.
Immaginiamo che l’anagrafica del mezzo riporti una capacità standard, mentre l’allestimento effettivamente disponibile la riduce. Il valore non è falso in assoluto, ma è falso per quel viaggio. Lo stesso accade quando la disponibilità di un autista è aggiornata in un calendario che non alimenta il modulo di pianificazione. Le informazioni esistono, soltanto in luoghi che il calcolo non interroga.
L’analisi 2026 di Everest Group sull’IA generativa nei TMS offre un contrappunto attuale: aumenta la capacità dei sistemi di assistere operatori e decisioni, ma resta aperto il problema della base informativa. Un’interfaccia capace di formulare spiegazioni convincenti può rendere meno evidente un dato vecchio. La forma della risposta migliora; la validità del vincolo non cambia.
La checklist da chiudere prima di avviare il calcolo
La verifica deve partire dai mezzi. Per ciascuna risorsa vanno controllati stato operativo, configurazione disponibile, capacità effettiva, eventuali restrizioni e compatibilità con l’ordine. Un codice mezzo attivo non equivale a un mezzo impiegabile per qualsiasi carico e in qualsiasi viaggio.
Segue la disponibilità degli autisti. Il dato deve indicare una possibilità operativa reale, non la semplice presenza in anagrafica. Ferie, assenze, assegnazioni già confermate e limiti applicabili devono raggiungere il motore prima del calcolo. Se l’aggiornamento avviene altrove, serve una regola chiara sulla fonte che prevale.
Le finestre di ritiro e consegna richiedono data di validità, provenienza e natura del vincolo. Una fascia tassativa deve essere distinta da una preferenza. Se il cliente modifica l’orario, la versione precedente va resa inutilizzabile, non lasciata disponibile accanto alla nuova.
Capacità e carico vanno confrontati usando la stessa unità e la stessa configurazione. Poi vengono i costi: percorrenza, impiego del mezzo, attese previste e condizioni economiche devono essere aggiornati con criteri omogenei. Infine si controllano le restrizioni operative, verificando che non siano registrate soltanto in una nota libera che l’algoritmo non può interpretare.
Resta un controllo spesso trascurato: la data dell’ultimo aggiornamento. Un dato può essere formalmente completo e ormai superato. La schermata di lancio dovrebbe quindi mostrare origine, validità e stato delle informazioni che incidono sulla soluzione, così l’operatore può distinguere un valore verificato da uno semplicemente presente.
Solo dopo questa verifica ha senso premere calcola. Se il tema viene ignorato, il gestionale continuerà a produrre piani formalmente ordinati che l’azienda scoprirà troppo tardi di non poter eseguire.