Il prossimo divario AI: perché le aziende logistiche di medio mercato devono sistemare la loro infrastruttura prima di poter sfruttare l’IA

La conversazione sull’IA spesso si concentra sull’accesso, con l’assunzione che una volta che un’azienda ha accesso ai modelli e agli strumenti giusti, la prossima sfida è capire come usarli. Per le aziende logistiche di medio mercato, non è necessariamente lì che inizia il problema.

In molti magazzini e fornitori di logistica di terze parti (3PL), il divario raramente è un sistema mancante. La maggior parte ha già un sistema di gestione del magazzino (WMS), un software di pianificazione delle risorse aziendali (ERP) o un pacchetto contabile, connessioni ai vettori e EDI con i loro clienti più grandi. Il problema è ciò che accade tra questi sistemi.

Le connessioni punto‑a‑punto si accumulano nel tempo. Un cliente o partner commerciale viene collegato in un modo, un altro partner in un altro modo e alla fine nessuno ha una visione completa di chi comunica con chi. L’integrazione dipende anche dalle persone, ad esempio quando qualcuno reinserisce manualmente gli ordini da un portale cliente o riconcilia le spedizioni di ieri in un foglio di calcolo ogni mattina. Un 3PL potrebbe non sapere che una transazione è fallita finché un cliente non chiama per chiedere dove si trovi il suo ordine.

Nessuna di queste informazioni compare in un elenco di asset IT, ed è per questo così facile sottovalutare il problema. 

Il problema è nei passaggi

I più grandi problemi operativi tendono a verificarsi nei passaggi, dove un ordine, una ricevuta o una spedizione passa da un sistema o azienda all’altro:

• Un ordine in ingresso che arriva in ritardo o in forma errata può comportare una ondata persa e una data di spedizione mancata. 
• Un avviso di spedizione anticipato che non corrisponde a quanto arriva fisicamente può interrompere la ricezione mentre i dipendenti indagano su ogni pallet. 
• Una conferma di spedizione che non raggiunge mai il sistema del cliente può creare un ritardo nella fatturazione e portare a un addebito, dove un rivenditore detrae una penalità per una non conformità.

Per un 3PL, questi problemi si moltiplicano perché ogni cliente ha i propri formati, regole e aspettative. Il piano di magazzino di solito funziona bene, ma il flusso di informazioni intorno ad esso si interrompe. 

Questa distinzione diventa più importante man mano che le aziende introducono l’IA nelle loro operazioni, poiché può lavorare solo con le informazioni a sua disposizione. Collegare un chatbot o un copilota a un singolo sistema può essere una buona dimostrazione, ma non conferisce a quel sistema la visibilità su un’operazione che si estende su più sistemi.

Nella logistica, le domande utili spesso attraversano tali confini, quindi una risposta su un ordine può richiedere informazioni dal WMS, dall’ERP e da un sistema di trasporto o cliente. Uno strumento di IA che può vedere solo una parte di quel processo opera con un quadro incompleto.

C’è un divario crescente tra le aziende la cui infrastruttura consente all’IA di lavorare con le informazioni di cui ha bisogno e le aziende i cui sistemi rimangono disconnessi, e lì è dove sta emergendo il prossimo divario AI. 

L’IA ha bisogno di una base con cui possa effettivamente lavorare

Un’infrastruttura realmente pronta per l’IA dovrebbe essere descritta in termini operativi piuttosto che tecnologici. Ogni evento importante, come un ordine, una ricevuta, uno spostamento di inventario o una spedizione, dovrebbe passare attraverso un hub comune anziché una raccolta di connessioni separate. Il formato inviato da un partner commerciale non dovrebbe più essere un problema del magazzino. X12, EDIFACT, XML o JSON dovrebbero normalizzarsi allo stesso ordine prima che chiunque a valle debba pensare al formato.

I team devono sapere quando qualcosa fallisce entro pochi minuti, prima che il problema raggiunga il cliente. Le stesse informazioni che i dipendenti usano per identificare e risolvere tali problemi dovrebbero essere accessibili anche a software e agenti IA tramite API pulite che mantengono le autorizzazioni esistenti. È inoltre necessario un registro di quanto accaduto affinché, quando l’IA propone qualcosa, una persona possa verificare il motivo. 

Quando queste condizioni sono soddisfatte, aggiungere l’IA diventa molto più semplice. Ciò non significa che un’azienda di medio mercato debba sostituire l’intero stack tecnologico. In realtà, un 3PL di medio mercato quasi mai necessita di un nuovo WMS o ERP semplicemente per diventare pronto per l’IA. L’approccio più pratico è lasciare intatti i sistemi core e sistemare le connessioni tra di essi.

Un hub unico a cui tutti i sistemi e i partner si collegano è molto più facile da gestire rispetto a una rete di collegamenti puntuali.

L’IA può aiutare a costruire l’infrastruttura

Questo è anche il punto in cui l’IA può essere particolarmente utile per le aziende di medio mercato. Tradizionalmente, l’integrazione ha richiesto che le persone leggessero le specifiche dei partner, mappassero i campi manualmente e testassero quelle mappature un partner commerciale alla volta. Una singola mappa partner può richiedere settimane di lavoro pratico, test e scambi continui con il partner.

I modelli IA attuali sono in grado di leggere specifiche e file di esempio, proporre una mappatura e testarla contro transazioni reali. Una persona può quindi revisionare e approvare il risultato.

L’IA può ridurre il lavoro pratico necessario per produrre la prima versione di una mappatura EDI. Lo specialista può partire da una bozza, quindi rivederla e correggerla prima di inviarla attraverso il ciclo di revisione esistente del partner, consentendo agli specialisti di dedicare meno tempo alla costruzione delle mappature campo per campo mantenendo il controllo sul risultato finale.

Ma esiste una distinzione importante tra usare l’IA per l’integrazione e fidarsi dell’IA per l’integrazione.

Quando lo faccio, utilizzo un approccio che chiamo “Proponi, Fondamenta, Verifica, Conferma”.

L’IA propone la configurazione del partner e la mappatura dei campi. È basata sulla specifica reale e sui file di esempio, anziché inventare campi o codici. Un processo di verifica separato confronta la mappatura campo per campo con un documento reale. Poi una persona conferma il risultato prima che raggiunga un flusso cliente attivo.

Abbiamo capito perché quella disciplina è importante testando le mappe generate dall’IA su documenti di produzione reali.

In un test, una mappa generata dall’IA ha letto un documento di trasferimento di magazzino senza errori ma ha comunque omesso tutti i 15 articoli. In un altro, ha mantenuto tutte e sei le parti di un ordine di spedizione ma ha perso il codice che identifica quale parte è il destinatario, insieme all’indirizzo. Il nostro controllo automatico ha considerato la mappa pulita, e un esperto EDI ha individuato la lacuna.

Anche i dati di riferimento possono essere errati. Un file di standard che affermava di essere stato verificato incrociato non corrispondeva allo standard pubblicato su ogni segmento contestato che abbiamo testato.

La lezione è che un risultato parziale può essere più difficile da individuare rispetto a uno mancante. La verifica deve confrontare ogni campo di un documento reale con ciò che la mappa ha catturato. Confermare che un documento venga analizzato non è sufficiente.

Risultati affidabili dipendono dalla disciplina che circonda il modello, dal modo in cui viene utilizzato a come i suoi output vengono revisionati.

Il valore inizia prima che l’IA prenda una decisione

Il lavoro di infrastruttura ha valore anche molto prima che un agente IA fornisca raccomandazioni operative. Un 3PL con cui abbiamo collaborato eseguiva SAP insieme al suo sistema di magazzino. Ogni ricezione in ingresso richiedeva da tre a cinque minuti di inserimento manuale, e l’inventario in SAP era circa 20 minuti indietro rispetto al dock.

Una volta che i due sistemi furono collegati direttamente, quel ritardo divenne quasi in tempo reale. L’operazione ha risparmiato più di 980 ore di lavoro all’anno, incluse 775 ore sul lavoro in uscita. Il tracciamento tramite fogli di calcolo è scomparso, mentre etichette, polizze di carico e liste di imballaggio hanno iniziato a generarsi automaticamente. Il magazzino ha mantenuto i flussi di lavoro esistenti, quindi nessuno sul pavimento ha dovuto essere riaddestrato.

La lezione che abbiamo tratto da quel progetto è stata più ampia dei risparmi di lavoro. Una volta che due sistemi condividono un’unica immagine aggiornata, quella stessa immagine è ciò di cui un agente IA ha bisogno per essere utile.

Collegarli è il passaggio che rende possibile tutto ciò che segue.

La prontezza dell’IA inizia con l’integrazione

Per le aziende che decidono da dove partire, l’integrazione dovrebbe venire prima, con l’IA che svolge gran parte del lavoro di integrazione. Troppo spesso l’errore che le operazioni commettono è trattare l’IA come qualcosa che appartiene solo alla fine del processo. Può aiutare a rendere il lavoro di integrazione più veloce e meno costoso all’inizio, poi aiutare nelle decisioni una volta che quella base è in atto.

Le aziende logistiche di medio mercato non hanno necessariamente bisogno di più tecnologia. Molte hanno già i sistemi di cui hanno bisogno. L’opportunità è far funzionare insieme quei sistemi. È qui che l’IA può svolgere un ruolo che va oltre la generazione di un’altra risposta su uno schermo.