Preparazione dei dati in Supply Chain

00:00:03 Panoramica sulla preparazione dei dati nella scienza dei dati.
00:00:46 Sottovalutare le complessità della preparazione dei dati.
00:02:01 Durata tipica di un progetto di preparazione dei dati.
00:03:19 Sfide nella velocità e precisione della preparazione dei dati.
00:06:07 Importanza della documentazione della preparazione dei dati.
00:08:00 Interpretare la ‘data ordine’ nelle supply chain.
00:09:02 Complicazioni nell’interpretazione dei dati derivanti dagli aggiornamenti del sistema.
00:10:07 Comprendere la semantica dei dati per evitare errori.
00:10:15 Studio di caso: Peculiarità dei sistemi supply chain.
00:14:53 Necessità della documentazione dei dati nelle operazioni aziendali.
00:16:01 Importanza del tracciamento dei dati nelle supply chain.
00:17:24 Allargare l’ambito dei dati nel processo decisionale automatizzato.
00:18:42 Rischi nel fare affidamento su individui per il recupero dei dati.
00:19:02 Sfide ed aspettative nella preparazione dei dati.
00:20:13 La preparazione dei dati come sforzo aziendale complessivo.
00:21:56 Valutare la correttezza dell’interpretazione dei dati attraverso l’efficacia nel mondo reale.
00:23:02 Conseguenze di un’interpretazione errata dei dati e importanza della tracciabilità.
00:24:37 Difficoltà e risultati di una preparazione dei dati insufficiente.
00:24:49 Il concetto di una buona preparazione dei dati.

Riassunto

In questo episodio di Lokad TV, il presentatore Kieran Chandler e il fondatore di Lokad, Joannes Vermorel, stanno discutendo le complessità della preparazione dei dati nella scienza dei dati, un processo spesso sottovalutato ma che attualmente viene prioritizzato a causa della conformità al GDPR. Vermorel sottolinea che la preparazione dei dati, che frequentemente richiede diversi mesi e risorse estese, è vitale per evitare il problema del “garbage in, garbage out”. Ciò richiede la trasformazione di dati incoerenti o incompleti in un formato comprensibile, che necessita di una documentazione accurata. Il processo è complesso, modellato dalla natura multifaccettata dei problemi aziendali e dal contesto storico dei dati. Vermorel promuove un approccio distribuito, coinvolgendo vari team organizzativi, e sostiene che una preparazione dei dati efficace dovrebbe essere accessibile e facilitare un chiaro processo decisionale.

Riassunto Esteso

Nell’episodio di Lokad TV condotto da Kieran Chandler, lui e Joannes Vermorel, il fondatore di Lokad, discutono il ruolo complesso ma fondamentale della preparazione dei dati nel campo della scienza dei dati. Con l’aumento delle normative sulla conformità al GDPR, i dati stanno diventando un punto focale per molti dirigenti, con una stima che le aziende spendano attualmente oltre 450 miliardi di dollari solo per la preparazione dei dati. L’obiettivo della preparazione dei dati è convertire dati grezzi, spesso incoerenti o incompleti, in un formato facile da interpretare e applicare.

Vermorel affronta la frequente sottovalutazione della complessità della preparazione dei dati. Nonostante le aziende investano risorse considerevoli, numerosi progetti si trovano in ritardo o superano il budget. Secondo Vermorel, la maggior parte dei bug nei sistemi IT può essere ricondotta a problemi alla fase di preparazione dei dati. Egli spiega che la natura multifaccettata dei problemi aziendali si manifesta nelle fasi della preparazione dei dati, aumentando la complessità del compito.

Per quanto riguarda i tempi, Vermorel suggerisce che i progetti di preparazione dei dati su larga scala possono richiedere almeno pochi mesi, spesso estendendosi fino a sei mesi. Sebbene si ipotizzi che strumenti migliori o software più scalabili possano velocizzare il processo, egli ritiene che il livello complessivo di maturità dell’ecosistema rallenti il progresso. Per evitare veramente il problema del “garbage in, garbage out”, i dati devono prima essere documentati e chiariti. Questo processo, sostiene, contribuisce all’estensione dei tempi.

Quando gli viene chiesto se sia possibile accelerare questo processo, Vermorel spiega che non è semplice come aggiungere più risorse. I dati trattati non sono stati originariamente prodotti per scopi di preparazione dei dati, ma sono il sottoprodotto dei sistemi aziendali. Ad esempio, descrive come la funzione principale di un sistema di punto vendita sia elaborare i pagamenti dei clienti, e non raccogliere dati. Tuttavia, anche questi sistemi producono dati che possono essere incoerenti o imperfetti a causa di ragioni operative pratiche, come errori di codici a barre. Queste incoerenze richiedono un ampio lavoro preparatorio per un uso efficace nell>ottimizzazione della supply chain.

Vermorel parla anche dell’importanza della documentazione nella preparazione dei dati. In Lokad, un progetto di preparazione dei dati tipicamente inizia con meno di una riga di documentazione per campo per tabella e termina con una pagina di documentazione per campo per tabella. Questa documentazione completa è vitale per prevenire il problema in cui dati di input di scarsa qualità portano a dati di output altrettanto scadenti, o “garbage in, garbage out”. Il traguardo di sei mesi per la preparazione dei dati, dunque, include il processo di creazione di questa documentazione estesa.

Vermorel inizia affrontando le complessità e le possibili interpretazioni errate che possono derivare da un semplice dato: la data di un ordine storico. Spiega che la “data” non è così semplice come può sembrare, poiché ci sono molteplici interpretazioni possibili, come quando il cliente ha cliccato su un prodotto, quando ha convalidato il carrello, quando il pagamento è stato elaborato, o quando la merce è stata resa disponibile nel magazzino.

Egli sottolinea che l’interpretazione di tali dati può cambiare nel tempo a causa degli aggiornamenti dei sistemi o di cambiamenti nelle pratiche aziendali. Pertanto, è fondamentale comprendere non solo i dati stessi, ma anche il contesto storico in cui sono stati prodotti. Se queste complessità non vengono riconosciute, le aziende possono trovarsi ad affrontare un problema di “garbage in, garbage out”, in cui interpretazioni errate portano a decisioni sbagliate.

Vermorel evidenzia uno studio di caso con uno dei clienti di Lokad per illustrare il suo punto. Questo cliente gestisce un impianto industriale esigente con brevi lead times, dove è essenziale ricevere la quantità precisa di merci ordinate. Il sistema del cliente ha una funzionalità per cui se la quantità consegnata non corrisponde esattamente all’ordine, l’intero ordine viene respinto e restituito. Ciò porta a una situazione in cui, se ricevono leggermente più del previsto, devono modificare l’ordine d’acquisto originale nel sistema per farlo corrispondere alla quantità consegnata. Questo workaround consente loro di accettare la consegna e

evitare interruzioni nelle loro operazioni industriali.

Tuttavia, questo processo viene sfruttato da fornitori astuti che ora consegnano leggermente più del previsto, sapendo che sarà accettato. Ciò si traduce in ordini d’acquisto che sembrano gonfiati rispetto alle reali necessità, creando artefatti nei dati che falsano le prestazioni del team di acquisti. Vermorel sottolinea che questa complessità deve essere documentata per evitare interpretazioni errate. Egli insiste sul fatto che i problemi non sono derivati da una scarsa performance del team di acquisti, ma dalle limitazioni del sistema e da come gli utenti hanno gestito tali limitazioni.

Cambiando argomento, Vermorel discute di chi si preoccupa dei dati storici, a parte Lokad, un’azienda che li utilizza per previsioni probabilistiche. Egli sottolinea che le aziende monitorano attentamente il denaro che si aspettano di ricevere o pagare, mentre chi non lo fa scompare col tempo. Questo è, a suo avviso, una forma di “darwinismo” aziendale. Suggerisce che le aziende che prestano attenzione alle loro transazioni finanziarie nel tempo naturalmente si preoccupano dei loro dati storici.

La conversazione si sta orientando verso la preparazione dei dati. Vermorel sottolinea che i dati non sono intrinsecamente “puliti” o pienamente compresi. Egli propone che la preparazione dei dati non sia esclusivamente una questione IT; si tratta di comprendere tutti gli aspetti dei dati aziendali per affrontare ogni angolazione del business. Il dipartimento IT, nota, non può essere chiamato a padroneggiare ogni aspetto del business e non dovrebbe essere l’unico responsabile della preparazione dei dati.

Vermorel suggerisce un approccio distribuito, che coinvolge differenti team con competenze specifiche all’interno dell’organizzazione. I dati rilevanti per gli acquisti, per esempio, dovrebbero coinvolgere i team di acquisto. Allo stesso modo, i dati necessari per una scheda di valutazione dei fornitori dovrebbero coinvolgere i team di approvvigionamento. Questo approccio può sfruttare le intuizioni necessarie per una preparazione dei dati efficace.

Affrontando come essere certi dell’interpretazione dei dati, soprattutto quando le informazioni sono incomplete, Vermorel la paragona alle teorie scientifiche; non è possibile sapere se una teoria è corretta, ma può essere validata se resiste a un esame critico. La correttezza della preparazione dei dati si stabilisce quando le decisioni derivanti dall’interpretazione sono corrette. Se una preparazione errata dei dati porta a decisioni insensate, la causa può essere tracciata, corretta e rivalutata.

Vermorel descrive quindi come dovrebbe essere una buona preparazione dei dati, soprattutto in scenari complessi di supply chain. La paragona a un libro ben scritto, che fornisce intuizioni e prospettive aziendali rilevanti, non solo dettagli tecnici. Dovrebbe essere accessibile e distribuita in tutta l’organizzazione, favorendo una comprensione condivisa. Richiede uno sforzo continuo per documentare, mantenere e comprendere i dati.

Infine, Vermorel sottolinea che la preparazione dei dati dovrebbe rappresentare l’interpretazione di una comprensione valida degli stessi dati. Una volta che questa comprensione è stabilita e mantenuta, le operazioni logiche sui dati risultano piuttosto semplici. Una buona preparazione dei dati, quindi, è al contempo una guida ben scritta e una comprensione condivisa che consente decisioni chiare ed efficaci nella supply chain.

Trascrizione Completa

Kieran Chandler: Nell’episodio di oggi parleremo della preparazione dei dati, uno dei fondamenti della scienza dei dati. Date le recenti normative sulla conformità al GDPR, i dati sono decisamente al centro dell’attenzione di molti dirigenti. È anche un grande business, con un recente sondaggio che stima che le aziende spendano oltre 450 miliardi di dollari solo per la preparazione dei dati. La preparazione dei dati consiste nel prendere dati grezzi e trasformarli in un formato facile da comprendere affinché possano essere utilizzati in modo efficace. Non è un’impresa da poco, considerando che i dati provengono da molteplici fonti e possono spesso essere incoerenti, incompleti e contenere errori. Allora, Joannes, perché parliamo oggi della preparazione dei dati? Voglio dire, se queste aziende stanno investendo oltre 450 miliardi di dollari, dovrebbe essere qualcosa che comprendiamo ormai.

Joannes Vermorel: Sì, assolutamente. La preparazione dei dati è un campo abbastanza noto, eppure sistematicamente sottovalutato in termini di cambiamenti. È interessante perché la maggior parte dei progetti di preparazione dei dati finisce per non rispettare le scadenze e per incorrere in sforamenti di budget. Il problema principale è che molti dei bug effettivi che si riscontrano nei sistemi IT, in particolare nel enterprise software, fanno ritorno a problemi nella fase di preparazione dei dati. È estremamente complesso. Sebbene sia un problema noto, la questione centrale è che le complessità aziendali si ripresentano sotto forma di fasi di preparazione dei dati, rendendo il dominio illimitato. Non esiste una ricetta definitiva per la preparazione dei dati.

Kieran Chandler: Allora, quanto tempo dovrebbe richiedere la preparazione di una grande quantità di dati?

Joannes Vermorel: Non ho mai visto un progetto di preparazione dei dati su larga scala durare meno di alcuni mesi. In genere, si aggira intorno ai sei mesi. Alcuni potrebbero sostenere che con strumenti migliori e software più scalabili dovrebbe essere più rapido. Tuttavia, la realtà è che vi è pochissima maturità nell’ecosistema, tanto che, per quasi ogni azienda ad eccezione di alcuni campioni di dati come Google, i dati devono prima essere documentati e chiariti. Ci sono così tante cose da fare con questi dati per evitare il problema del “garbage in, garbage out”. Quindi ci vogliono un paio di mesi, e sei mesi è un obiettivo ragionevole se è coinvolta una supply chain complessa.

Kieran Chandler: Sei mesi sembrano un periodo piuttosto lungo. C’è un modo per accelerare questo processo? Se sono una grande organizzazione, non posso semplicemente impiegare più persone per risolvere il problema?

Joannes Vermorel: Qui si presenta un problema specifico: puoi avere nove donne per fare un bambino in un mese? La questione riguarda la comprensione del tipo di problemi di cui ci occupiamo. Innanzitutto, i dati di cui disponi non sono stati prodotti per essere dati in primo luogo. Sono un sottoprodotto del tuo sistema aziendale che, per caso, fa funzionare la tua azienda. Prendiamo ad esempio un software di punto vendita, qualcosa in cui puoi pagare in un supermercato. La sua funzione principale è processare i clienti che desiderano uscire dal negozio pagando quanto dovrebbero pagare. Quindi, se per un qualsiasi motivo un codice a barre non viene letto, il cassiere probabilmente scannerà un prodotto simile due volte. Alla fine, pagherai il prezzo corretto, ma in termini di dati, avrai un prodotto conteggiato due volte.

Kieran Chandler: Un prodotto conteggiato zero volte può creare problemi in termini di controllo delle scorte perché i tuoi applicativi aziendali CRUD risultano imprecisi. Questa non è una buona soluzione, ed è consigliabile evitarla. Ma la realtà è che, se hai la scelta tra risolvere un problema legato ai dati e permettere alla tua azienda di operare in modo più fluido, coloro che sono sul campo, le persone che devono gestire fisicamente le supply chain, favoriranno sempre una soluzione che non interrompa il flusso di merci, clienti, servizi e tutto il resto. Far funzionare l’azienda è fondamentale e i dati sono solo un sottoprodotto di secondo ordine. Non vengono mai trattati come cittadini di prima classe. Ecco perché c’è sempre tutto questo lavoro da fare, perché i dati non sono stati raccolti solo per permetterti di ottimizzare la supply chain. Da qui derivano tutte queste sfide?

Joannes Vermorel: Infatti, è da qui che derivano tutti quei cambiamenti.

Kieran Chandler: Parliamo di quella documentazione che hai menzionato prima. Cosa ti aspetti di vedere in questa documentazione e in che modo aiuta? Solo per capire, se torniamo al periodo di sei mesi, di quale volume di documentazione ci aspettiamo?

Joannes Vermorel: Una regola pratica sarebbe che, tipicamente, quando noi di Lokad iniziamo un progetto, abbiamo meno di una riga di documentazione per tabella per campo. Di solito, non abbiamo nemmeno tanto. Iniziamo molti progetti in cui non abbiamo nemmeno una riga di documentazione per tabella nellERP, MRP, WMS, o qualsiasi altro sistema utilizzato per gestire la tua supply chain. Quando abbiamo finito, finiamo per avere una pagina di documentazione per campo per tabella. Quindi, se hai 20 tabelle con 20 campi, parliamo di 400 pagine di documentazione. Sì, ci vogliono sei mesi per produrre quelle 400 pagine di documentazione.

Kieran Chandler: Sembra una quantità enorme di documentazione. È davvero tutto necessario?

Joannes Vermorel: È tutto necessario se vuoi evitare il garbage in, garbage out.

Kieran Chandler: Perché?

Joannes Vermorel: Considera un caso pratico: supponiamo che io abbia una tabella chiamata ‘orders’. Contiene i miei ordini storici e include una data. Ma è semplice? Stiamo davvero parlando di che tipo di data sia? È la data in cui il cliente ha cliccato su un prodotto per inserirlo nel carrello sul sito di ecommerce? Oppure quando il cliente ha confermato il carrello ed effettuato il pagamento? O quando il pagamento è stato validato dal processore della carta di credito? O quando l’inserimento è stato registrato nel sistema? O quando l’ordine di acquisto è stato modificato per l’ultima volta nel sistema? Ci sono circa 20 interpretazioni differenti solo per questo campo “date”.

Plus, se la tua azienda ha più di un decennio di storia, è probabile che la sottile linea interpretativa della data dell’ordine sia cambiata nel corso degli anni. Potresti ritrovarti in una situazione in cui hai aggiornato il sistema e la semantica di questa colonna è mutata.

Non è nemmeno qualcosa che risulta naturalmente omogeneo per tutta la tua storia. Inoltre, possono emergere ulteriori complicazioni, come casi limite. Per esempio, questa data dovrebbe rappresentare il momento in cui il cliente ha confermato il carrello, tranne se il pagamento è stato infine respinto per frode. In questo caso, si tratta della data e dell’ora in cui l’ordine è stato respinto per frode.

Ancora, non si tratta davvero di un design particolarmente valido, ma le aziende che gestiscono complesse supply chain hanno sistemi complicati e una lunga storia. Quindi, l’IT non è stato realizzato perfettamente sin dall’inizio e devi fare i conti con tutte queste complicazioni storiche. Alla fine, queste si riflettono nella documentazione. Se non riconosci tutte queste complicazioni, incontrerai problemi ogni volta che vorrai analizzare questi dati.

Kieran Chandler: Per generare una decisione ottimizzata per la tua supply chain, potresti incorrere in un problema di “garbage in, garbage out” se interpreti erroneamente i dati. Quindi, quello che stai dicendo è che tutto ruota attorno al chiarire la semantica dei dati, giusto?

Joannes Vermorel: Esattamente. Devi capire che i dati sono più di semplici numeri. Rappresentano vari fattori che possono essere combinati in una singola cella. Non si tratta solo di comprendere il software che li produce, ma anche di come le persone interagiscono con quel software. La tua documentazione deve tenere conto dell’angolo umano di ciò che le persone stanno facendo.

Kieran Chandler: Hai un buon esempio di come uno dei tuoi clienti abbia affrontato questo problema in passato e di come ciò abbia influenzato la sua azienda?

Joannes Vermorel: Sì, posso fare un esempio. Abbiamo avuto un cliente che gestiva un’operazione estremamente impegnativa, che richiedeva un alto livello di disponibilità. Inviavano ordini di acquisto con tempi di consegna molto brevi ai propri fornitori. Il loro sistema presentava una caratteristica di design interessante: se la quantità di merci consegnata non corrispondeva a quella originariamente richiesta, allora l’intero ordine di acquisto doveva essere respinto e restituito al fornitore.

Supponiamo, per esempio, che tu ordini 1.000 unità, ma il fornitore consegni 1.050 unità, allora dovresti respingere l’ordine. Il problema è che, se lo respingi, potrebbero insorgere seri problemi operativi. Il sistema non permetteva di modificare la quantità, quindi finiva per accadere che, quando le quantità consegnate non corrispondevano a quelle ordinate, modificavano l’ordine di acquisto originale per riflettere la quantità effettivamente consegnata.

Kieran Chandler: Quindi, quello che stai dicendo è che modificavano l’ordine di acquisto originale per farlo corrispondere a ciò che era stato consegnato?

Joannes Vermorel: Esattamente. Tuttavia, questo ha aperto un altro problema. I fornitori hanno colto in fretta questa pratica. Hanno capito che potevano consegnare più del richiesto, sapendo che l’azienda aveva bisogno di quelle forniture. Non avrebbero consegnato una quantità esorbitante, ma qualcosa che l’azienda avrebbe considerato accettabile.

Nei dati, sembrerebbe che l’ordine iniziale fosse per una quantità maggiore. Ciò ha portato a situazioni in cui gli ordini di acquisto apparivano troppo elevati rispetto al reale fabbisogno, facendo sembrare che il team acquisti fosse scarso nel determinare le quantità corrette. Tuttavia, il problema non era del team acquisti, bensì delle limitazioni del sistema e di come le persone ne cercassero di aggirare queste restrizioni.

Tutti questi dettagli dovevano essere documentati per evitare di giungere a conclusioni errate. Il team acquisti non era scarso nel suo lavoro. Il problema era che avevano un sistema con limitazioni, che stavano semplicemente cercando di gestire.

Kieran Chandler: Il sistema sta generando tutti quegli strani effetti collaterali. Ci vuole una pagina di spiegazioni per dare un senso a tutto ciò, ma non c’è via d’uscita. È semplicemente la complessità del business stesso a riflettersi in questi dati. Allontaniamoci da quei fornitori subdoli. È sicuramente un esempio divertente. Quindi, hai accennato all’aspetto umano. Ovviamente, da Lokad utilizziamo dati storici per fare previsioni probabilistiche sul futuro. Chi, oltre a noi, si preoccupa veramente dei dati storici?

Joannes Vermorel: Tipicamente, tutto ciò che tocca l’ammontare di denaro che ti aspetti di ricevere o pagare attirava molta attenzione. Non è che la gente non facesse caso, ma le aziende che non monitoravano da vicino il denaro che avrebbero dovuto ricevere tendevano a scomparire nel tempo. È come il darwinismo in azione: se non ci fai caso, sparisci. Ecco perché, come cinque secoli fa, la contabilità in doppia entrata fu inventata da alcuni monaci italiani. Se non ci fai attenzione, il tuo monastero crollerà a causa di cattive pratiche contabili. Non è esattamente un problema nuovo, ma ci sono molti dati che in passato non consideravamo mission-critical e che ora stanno diventando mission-critical.

Per farti un esempio, in passato, per tenere conto correttamente degli stock-outs, si considerava ciò che acquistavi, in modo da sapere quanto dovevi pagare ai tuoi fornitori, e ciò che vendevi, così da sapere quanto i tuoi clienti dovevano pagarti. Ma che dire del tracciamento degli stock-outs storici? Finché hai un professionista della supply chain che decide manualmente le quantità da acquistare e ricorda che ci sono stati periodi strani con stock-outs, non hai bisogno di questi record storici. Fanno parte del tuo sistema.

Il problema è che, appena si tenta di passare a qualcosa di più quantitativo, come facciamo noi a Lokad con decisioni automatizzate per tutte quelle mansioni banali, quale decidere quanto ordinare, avere registrazioni accurate degli storici stock levels diventa molto più importante. Altrimenti, la tua automazione interpreterà erroneamente cosa rappresentano le vendite e cosa la mancanza di domanda.

Se vuoi che una maggiore automazione gestisca la tua azienda, devi prestare attenzione a un ambito più ampio di dati, non solo alla contabilità grezza. Il tuo commercialista non si preoccupa dei giorni di stock-outs, ma lo farà il tuo software di ottimizzazione della supply chain. Devi espandere l’insieme di dati che fanno veramente parte del tuo ambito, che sono documentati e per i quali è necessario un controllo e una garanzia sulla qualità.

Kieran Chandler: Quindi, siamo piuttosto dipendenti da questa singola persona che ricorda cosa è successo in passato. Non dovremmo essere meglio preparati per i dati man mano che arrivano? Non dovrebbe il reparto IT o qualcun altro occuparsene, assicurandosi che siano puliti fin dall’inizio? Sembra un modo più semplice di fare le cose.

Joannes Vermorel: Sì, ma il problema non è la competenza IT. Non esiste il concetto di dati “puliti”. Il punto è che i dati non sono intrinsecamente compresi in profondità e non tutti gli aspetti aziendali sono adeguatamente coperti.

Kieran Chandler: Spesso si dice che le aziende stanno investendo miliardi nell’IA, ma la realtà è che è la complessità del business stesso a emerge in questo compito, in questa sfida della preparazione dei dati. E dire “oh, il reparto IT si occuperà di questo” equivale ad aspettarsi che l’IT gestisca l’azienda ed abbia conoscenza di ogni singolo aspetto aziendale.

Joannes Vermorel: Assolutamente, questo crea improvvisamente un problema organizzativo perché ti aspetti che l’IT sia esperto tanto in Risorse Umane, marketing, acquisti e così via. Voglio dire, ti aspetti una completa padronanza di tutti gli aspetti aziendali dal reparto IT. Ma sarebbe chiedere troppo. Il reparto IT ha già a che fare con tutte le modifiche IT, quindi non dovrebbe essere tenuto a risolvere ogni singolo problema aziendale. In alternativa, potresti ridefinire l’IT come l’intera azienda, ma questo vanificherebbe lo scopo.

Tornando al caso in questione, la preparazione dei dati deve essere uno sforzo distribuito all’interno dell’azienda perché, in definitiva, le uniche persone in grado di fornire il livello di intuizione necessario per preparare i dati rilevanti per, diciamo, gli acquisti, sono i team acquisti. Analogamente, se vuoi stabilire una supplier scorecard e avere i dati preparati con sufficiente accuracy in modo che abbiano davvero senso, dovrai parlare con i team responsabili dell’approvvigionamento.

Ogni volta che affronti un problema, è necessario coinvolgere le persone specializzate in quel determinato problema all’interno della tua azienda, perché sono loro a fornirti l’intuizione necessaria affinché la preparazione dei dati abbia senso. Non è strettamente un problema IT. Si tratta di raccogliere tutta la comprensione necessaria affinché, quando processi i dati, non ti ritrovi con informazioni prive di senso rispetto al problema aziendale da risolvere.

Kieran Chandler: Quindi, a quanto pare, non siamo ancora arrivati al punto. Alcune aziende ci sono, ma sono l’eccezione, non la regola. Come puoi essere sicuro, se non hai tutte le informazioni e ci sono delle lacune che interpreti, che la tua interpretazione sia quella corretta? Potrebbero esserci molte possibilità.

Joannes Vermorel: Assolutamente, ed è un punto interessante perché è simile alle teorie scientifiche. Non saprai mai con certezza che la tua teoria sia giusta, sai solo che è abbastanza buona e, quando viene messa alla prova, funziona. Non hai nulla di meglio per farla funzionare meglio.

Quindi, cosa significa questo per la preparazione dei dati? Significa che sai di aver preparato correttamente i dati quando, alla fine della pipeline dei dati, le decisioni che generi automaticamente sulla base di questa interpretazione sono corrette. Se le decisioni risultano corrette, significa che la tua logica di ottimizzazione è efficiente, i tuoi layer di machine learning sono accurati e molte altre cose. Fondamentalmente, non è possibile ottenere decisioni corrette da un’interpretazione errata. Di solito, quando non interpreti e prepari correttamente i dati, i risultati vengono compromessi a tal punto da non dare alcuna possibilità di funzionare.

In sostanza, non c’è altra via se non fare la preparazione, averne fiducia, e poi generare le decisioni. Se le decisioni risultano insensate, torni indietro, tracci il problema fino alla sua causa primaria – spesso la preparazione dei dati – e lo risolvi. Se, alla fine della giornata, le decisioni che escono dal tuo sistema hanno senso per un professionista che utilizza la propria capacità di ragionamento, allora sai di aver fatto bene.

Kieran Chandler: Potresti dire: “Credo che siano stati preparati adeguatamente”, ma di solito si tratta di sfumature di grigio. Il supply chain practitioner potrebbe dire: “È una buona decisione, ma potrebbe essere ulteriormente migliorata. Per esempio, se prendessimo in considerazione il prezzo dei nostri concorrenti, perché questo spiega picchi o cali insoliti nella domanda, e non abbiamo ancora quei dati.” Quindi, non è una situazione in bianco e nero.

Joannes Vermorel: Abbiamo parlato a lungo delle difficoltà della preparazione dei dati e di come appaia una cattiva preparazione. Ma, per riassumere, come si configura una buona preparazione dei dati? In una situazione di supply chain moderatamente complessa, una buona preparazione dei dati assomiglia a un libro ben strutturato. Pensiamolo come un libro di 400 pagine, con una pagina per tabella o venti campi in 20 tabelle. Ma non basta che sia solo un libro, deve essere un libro ben scritto.

Se scrivi qualcosa di incredibilmente noioso, nessuno lo leggerà e non avrà alcun effetto sulla tua organizzazione. Quindi, deve essere ben scritto. Per ben scritto intendo che deve essere leggibile. Inoltre, deve essere redatto da una prospettiva aziendale. Non si tratta di una documentazione IT. La preparazione dei dati non è davvero un problema IT, ma riguarda l’avere tutte le intuizioni aziendali.

La prospettiva valida nel business è sempre qualcosa in evoluzione. Se il panorama competitivo della tua industria cambia, allora anche la prospettiva valida su un determinato problema muta. Quindi questo libro deve essere ben scritto e continuamente aggiornato.

Questo è uno sforzo molto distribuito all’interno della tua azienda, perché, ad esempio, solo il team di merchandising possiede l’intuizione e la prospettiva necessarie per sapere come documentare fin dall’inizio le tabelle di merchandising. Questa preparazione dei dati si traduce in materiali puliti e ben scritti, ampiamente diffusi e accessibili in azienda.

La cosa interessante è che, una volta ottenute tutte quelle intuizioni, la trasformazione dei dati, che è logica, diventa un’interpretazione diretta della corretta comprensione dei dati stessi. Devi mettere un enorme impegno per capire i dati, documentarli, scriverli e mantenerli. Ma una volta fatto tutto ciò, scrivere la logica diventa semplice. Quindi, come si presenta una buona preparazione dei dati? È come un libro ben scritto, una comprensione condivisa, una specie di bibbia della supply chain che è interna alla tua azienda.

Kieran Chandler: Suona bene! Quindi, le sfumature di grigio dei dati, sarà questo un nuovo bestseller proveniente dall’organizzazione?

Joannes Vermorel: Probabilmente, chissà?

Kieran Chandler: Ok, beh, speriamo che tu abbia apprezzato l’episodio di oggi sulla preparazione dei dati. Come sempre, contattaci se hai ulteriori domande e ci vediamo di nuovo la prossima volta su Lokad TV. Arrivederci per ora.