Data engineering per la supply chain: fondamenta prima dell’AI

Un’azienda manifatturiera mi ha contattato lo scorso anno con un progetto di previsione della domanda già pianificato: il modello scelto, il fornitore identificato, il dashboard di monitoring già abbozzato. Quando abbiamo guardato i dati, ci siamo fermati. I codici prodotto nel gestionale non corrispondevano a quelli nel sistema di magazzino, le date degli ordini erano registrate in tre formati diversi a seconda del reparto, le unità di misura non erano mai state standardizzate tra gli stabilimenti. Il progetto di AI era pronto. I dati per farlo girare, no.

Questo scenario si ripete con una frequenza che non sorprende chi lavora con dati industriali, ma che continua a sorprendere chi gestisce i budget. L’attenzione va agli algoritmi e alle piattaforme, non all’infrastruttura che li alimenta. Eppure la regola è semplice: un modello è buono quanto i dati su cui viene addestrato. Dati sporchi, aggregati male o mal integrati producono previsioni sbagliate — anche con il miglior algoritmo disponibile.

Chi lavora con dati a scala industriale usa spesso una proporzione pratica: il 90% del tempo in un progetto di data science è data engineering — pulizia, preparazione, costruzione di pipeline — e solo il 10% è modellazione. Non è una lamentela: è la descrizione di dove si trova il lavoro reale. Il punto di partenza è capire l’architettura dei dati disponibili, poi le fonti concrete di una supply chain — ERP e MES — e infine il passaggio che assorbe la maggior parte del tempo: la qualità del dato.

Architettura dati nella supply chain

Un’architettura dati per la supply chain non è un software che si installa: è un modo di organizzare il flusso di informazioni tra sistemi diversi con l’obiettivo di renderle utilizzabili per l’analisi. Il punto di partenza è definire le entità rilevanti — quali oggetti vuoi capire e monitorare — e costruire intorno a ciascuna una vista completa dei dati disponibili.

In una supply chain, le entità fondamentali sono quattro: il prodotto (o SKU), l’ordine, il fornitore, la spedizione. Per ogni prodotto vuoi avere lo storico delle vendite, i movimenti di magazzino, il lead time dai fornitori, le promozioni attive. Per ogni ordine, lo stato in ogni fase del processo, i tempi di avanzamento, le quantità confermate e quelle effettivamente consegnate. Per ogni fornitore, l’affidabilità storica, la varianza sui tempi di consegna, le eccezioni ricorrenti. L’obiettivo è costruire una vista unica per entità che aggreghi informazioni provenienti da sistemi diversi — non una serie di report separati che qualcuno deve collegare manualmente ogni mese.

Un principio operativo spesso trascurato riguarda la granularità: è quasi sempre meglio conservare i dati al livello più dettagliato disponibile e aggregare solo quando serve per una specifica analisi. Un dataset di vendite aggregato a livello mensile non può rispondere a domande che richiedono granularità giornaliera, e non si può disaggregare ex-post. Il costo aggiuntivo di storage per mantenere la granularità massima è marginale rispetto al costo di non poter rispondere a domande future che oggi non si sanno ancora formulare. Log di magazzino, transazioni singole, eventi di spedizione: tienili tutti, alla risoluzione originale.

La struttura tipica di una pipeline dati si articola in tre strati. Il primo è il livello grezzo: i dati vengono estratti dai sistemi sorgente e memorizzati senza modifiche, esattamente come arrivano. Il secondo è il livello trasformato: i dati vengono puliti, standardizzati e integrati tra fonti diverse. Il terzo è il livello analitico: viste pre-calcolate ottimizzate per le analisi ricorrenti — modelli di previsione, dashboard operativi, report di eccezione. Questa separazione è importante perché permette di ripartire da qualsiasi punto del flusso in caso di errore, senza perdere i dati originali e senza dover ricominciare da capo ogni volta che qualcosa va storto a valle.

Le fonti dati

In una supply chain industriale, i dati provengono da sistemi diversi progettati per scopi diversi. L’integrazione tra questi sistemi è quasi sempre il collo di bottiglia principale di qualsiasi progetto di analisi — non la scelta del modello, non la potenza computazionale.

ERP

Il sistema ERP (Enterprise Resource Planning) è la fonte principale di dati transazionali in un’azienda manifatturiera. Contiene gli ordini di acquisto e di vendita, le anagrafiche prodotto e fornitore, i movimenti di magazzino contabili, i dati di fatturazione, le distinte base. È il sistema di record per le operazioni commerciali e finanziarie.

Dal punto di vista del data engineering, l’ERP presenta alcune caratteristiche che complicano l’analisi. Le anagrafiche vengono aggiornate nel tempo ma spesso senza versionamento: un codice prodotto può essere riutilizzato per articoli diversi, un fornitore può cambiare ragione sociale, un’unità di misura può essere modificata senza che nessun sistema registri la data del cambiamento. Questo rende difficile ricostruire la storia corretta di un’entità senza conoscere le regole implicite applicate negli anni. Un altro problema ricorrente è la normalizzazione spinta del database: i dati sono distribuiti su decine di tabelle collegate da chiavi relazionali, e costruire una vista analitica richiede join complessi che i sistemi di reporting tradizionali gestiscono male su grandi volumi storici.

MES

Il sistema MES (Manufacturing Execution System) monitora la produzione in tempo reale: ordini di produzione, avanzamento per fase operativa, tempi di ciclo, fermate macchina, scarti, controlli qualità in linea. Se l’ERP dice quanti pezzi sono stati ordinati, il MES dice quanti ne sono stati prodotti, in quanto tempo, e con quale percentuale di difetti.

I dati MES sono tipicamente più granulari e più ad alta frequenza rispetto a quelli ERP: eventi a livello di singola operazione, con timestamp al minuto o al secondo. Questa granularità è preziosa per analisi di efficienza produttiva e manutenzione predittiva, ma comporta volumi di dati molto più alti e richiede pipeline progettate per ingestione continua, non batch giornalieri. Il punto critico è l’integrazione con l’ERP: in molte aziende manifatturiere i due sistemi sono stati implementati in momenti diversi e da fornitori diversi. I codici prodotto nel MES non sempre corrispondono a quelli nell’ERP — una discrepanza che rende impossibile collegare automaticamente i dati di produzione con quelli commerciali senza un lavoro manuale di mappatura che nessuno ha mai completato formalmente.

Oltre a ERP e MES, una supply chain genera dati da altri sistemi: WMS (Warehouse Management System) per i movimenti fisici di magazzino, sistemi dei trasportatori per il tracking delle spedizioni, sensori IoT su linee e impianti. E poi c’è una categoria che tende a essere sottovalutata: i dati semi-strutturati che vivono fuori dai sistemi ufficiali — file Excel condivisi via email tra reparti, fogli Google usati come workaround, export manuali copiati in cartelle di rete. Questi dati informali sono spesso i più aggiornati e i più vicini alla realtà operativa. Integrarli è la parte più difficile, ma ignorarli significa costruire modelli su una versione incompleta di ciò che succede davvero.

Qualità dei dati

Il 90% del tempo in un progetto di data science si spende qui. Non è una scelta: è la conseguenza del fatto che i sistemi aziendali sono stati progettati per la gestione operativa quotidiana, non per l’analisi. Raccolgono i dati che servono a loro, nel formato che conviene a loro, con le assunzioni che erano vere quando sono stati configurati. Usarli per scopi analitici richiede di capire queste assunzioni e di gestirle esplicitamente.

I problemi di qualità più comuni in una supply chain sono prevedibili una volta che li conosci. I codici prodotto non sono consistenti tra sistemi: lo stesso articolo ha identificativi diversi nell’ERP, nel WMS e nel catalogo del fornitore, e la mappatura esiste solo nella testa del responsabile magazzino che lavora lì da vent’anni. Le date sono ambigue: “data ordine” può significare la data di inserimento nel sistema, la data di conferma del fornitore, o la data di consegna prevista, a seconda di chi ha compilato il campo e quando. Le unità di misura non sono standardizzate: quantità espresse in pezzi in un sistema e in confezioni nell’altro, senza un fattore di conversione documentato da nessuna parte. I dati mancanti seguono pattern sistematici, non casuali: certi reparti compilano certi campi, altri no, e il pattern riflette processi organizzativi non scritti che cambiano ogni volta che cambia un responsabile.

C’è un principio più sottile che vale la pena tenere a mente: il dato non è un fatto oggettivo, è il prodotto di un sistema di raccolta. Ogni dataset riflette le assunzioni del sistema che lo ha generato — il suo scopo, i suoi vincoli, i suoi artefatti tecnici. Prima di costruire qualsiasi pipeline o modello, serve capire come il dato è stato prodotto, non solo come è strutturato. Un esempio concreto: i dati di vendita in un ERP registrano gli ordini ricevuti, non la domanda reale di mercato. Se ci sono stati stockout in certi periodi, le vendite in quei mesi risultano artificialmente basse — non perché la domanda fosse bassa, ma perché il prodotto non era disponibile. Un modello di previsione addestrato su questi dati senza correggere questo effetto impara a prevedere le vendite vincolate dalle scorte, non la domanda del mercato. Il risultato è un modello che sembra preciso sui dati storici e che sottostima sistematicamente la domanda nelle situazioni in cui il prodotto si esaurisce.

La qualità del dato non è un problema da risolvere una volta sola all’inizio del progetto. Le pipeline di data engineering devono includere controlli continui: range check sui valori attesi, monitoraggio dei volumi giornalieri (una giornata con zero transazioni è quasi sempre un problema di pipeline, non una giornata effettivamente vuota), alerting automatico su anomalie. Un modello di previsione che smette silenziosamente di ricevere dati aggiornati produce output sempre più datati — e il problema diventa visibile solo quando le decisioni operative iniziano ad andare storte in modo inspiegabile.

Conclusioni

Investire in AI prima di avere un’architettura dati affidabile è come costruire su fondamenta che non reggono il carico reale. La domanda corretta da porre a un progetto di AI in supply chain non è “quale modello usiamo?” ma “abbiamo i dati per addestrarlo, e sono affidabili?”. Rispondere richiede un’analisi concreta delle fonti disponibili — ERP, MES, WMS, fonti informali — di come si integrano tra loro, e di quanti problemi di qualità vanno risolti prima di poter fare qualsiasi analisi utile.

Questo lavoro di fondamenta non finisce nei comunicati stampa. Ma è la differenza tra un progetto di data science che produce valore reale e uno che rimane un esercizio tecnico chiuso nel server di qualcuno. Se stai valutando come avviare un percorso di questo tipo nella tua azienda, richiedi una consulenza per capire da dove conviene partire.