Preparazione dei dati nella 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 nell’accuratezza della preparazione dei dati.
00:06:07 Importanza della documentazione nella preparazione dei dati.
00:08:00 Interpretazione della ‘data di ordine’ nelle supply chain.
00:09:02 Complicazioni nell’interpretazione dei dati a seguito di aggiornamenti di sistema.
00:10:07 Comprendere la semantica dei dati per evitare errori.
00:10:15 Studio di caso: particolarità dei sistemi di supply chain.
00:14:53 Necessità di documentazione dei dati nelle operazioni aziendali.
00:16:01 Importanza del tracciamento dei dati nelle supply chain.
00:17:24 Ampliare la portata dei dati nella presa di decisioni automatizzata.
00:18:42 Rischi di affidarsi alle persone per il richiamo dei dati.
00:19:02 Sfide e aspettative nella preparazione dei dati.
00:20:13 La preparazione dei dati come sforzo aziendale a livello aziendale.
00:21:56 Giudicare la correttezza dell’interpretazione dei dati tramite l’efficacia nel mondo reale.
00:23:02 Conseguenze dell’interpretazione errata dei dati e importanza della tracciabilità.
00:24:37 Difficoltà e risultati di una cattiva preparazione dei dati.
00:24:49 Il concetto di una preparazione dei dati ‘buona’.

Riassunto

In questo episodio di Lokad TV, l’ospite Kieran Chandler e il fondatore di Lokad, Joannes Vermorel, discutono delle complessità della preparazione dei dati nella scienza dei dati, un processo spesso sottovalutato ma attualmente prioritario a causa della conformità al GDPR. Vermorel sottolinea che la preparazione dei dati, che spesso richiede diversi mesi e risorse considerevoli, è fondamentale per evitare il problema del “spazzatura dentro, spazzatura fuori”. Ciò richiede la trasformazione di dati inconsistenti o incompleti in un formato comprensibile, il che richiede una documentazione approfondita. Il processo è complesso, plasmato dalla natura sfaccettata dei problemi aziendali e dal contesto storico dei dati. Vermorel sostiene un approccio distribuito, coinvolgendo vari team organizzativi, e sostiene che una preparazione dei dati efficace dovrebbe essere accessibile e facilitare una chiara presa di decisioni.

Riassunto Esteso

Nell’episodio di Lokad TV condotto da Kieran Chandler, lui e Joannes Vermorel, il fondatore di Lokad, discutono del ruolo complesso ma fondamentale della preparazione dei dati nel campo della scienza dei dati. Con l’aumento delle leggi sulla conformità al GDPR, i dati stanno diventando un punto focale per molti dirigenti, con una stima che le aziende stiano attualmente spendendo oltre 450 miliardi di dollari solo per la preparazione dei dati. L’obiettivo della preparazione dei dati è convertire dati grezzi, spesso inconsistenti 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 non rispettano i tempi o superano i budget previsti. Secondo Vermorel, la maggior parte dei bug dei sistemi IT può essere ricondotta a problemi nella fase di preparazione dei dati. Spiega che la natura sfaccettata dei problemi aziendali si manifesta come passaggi di preparazione dei dati, aggiungendo complessità al compito.

Per quanto riguarda i tempi, Vermorel suggerisce che i progetti di preparazione dei dati su larga scala possono richiedere almeno alcuni mesi, spesso fino a sei mesi. Sebbene si assuma che strumenti migliorati o software più scalabili dovrebbero velocizzare il processo, suggerisce che il livello di maturità complessivo dell’ecosistema sta rallentando i progressi. Per evitare veramente il problema del “spazzatura dentro, spazzatura fuori”, i dati devono prima essere documentati e chiariti. Questo processo, sostiene, contribuisce alla durata più lunga.

Quando gli viene chiesto sulla fattibilità di accelerare questo processo, Vermorel spiega che non è semplice come aggiungere più risorse. I dati con cui si sta lavorando non sono stati originariamente prodotti per scopi di preparazione dei dati, ma sono invece un sottoprodotto dei sistemi aziendali. Ad esempio, descrive come la funzione principale di un sistema di punto vendita sia elaborare i pagamenti dei clienti, non raccogliere dati. Tuttavia, anche questi sistemi producono dati che possono essere inconsistenti o difettosi per ragioni operative pratiche, come errori di codice a barre. Queste incongruenze richiedono un lavoro preparatorio esteso per un uso efficace nell’ottimizzazione della supply chain.

Vermorel parla anche dell’importanza della documentazione nella preparazione dei dati. Presso Lokad, un progetto di preparazione dei dati inizia tipicamente con meno di una riga di documentazione per campo per tabella e termina con una pagina di documentazione per campo per tabella. Questa documentazione esaustiva è fondamentale per evitare il problema di dati di input di scarsa qualità che portano a dati di output di scarsa qualità, o “spazzatura dentro, spazzatura fuori”. Il periodo di sei mesi per la preparazione dei dati, quindi, 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 potrebbe sembrare, poiché ci sono molteplici interpretazioni possibili, come quando il cliente ha cliccato su un prodotto, quando ha convalidato il suo carrello, quando il pagamento è stato elaborato o quando la merce è stata resa disponibile nel magazzino.

Sottolinea che l’interpretazione di tali dati può cambiare nel tempo a causa di aggiornamenti di sistema o 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 di fronte a un problema di “spazzatura dentro, spazzatura fuori” in cui interpretazioni errate portano a decisioni sbagliate.

Vermorel sta evidenziando uno studio di caso con uno dei clienti di Lokad per illustrare il suo punto di vista. Questo cliente gestisce un’impostazione industriale impegnativa con tempi di consegna brevi, in cui ricevere la quantità precisa di merci ordinate è essenziale. Il sistema del cliente ha una funzionalità in 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ù di quanto ordinato, devono modificare l’ordine di acquisto originale nel sistema per corrispondere alla quantità consegnata. Questa soluzione alternativa consente loro di accettare la consegna e

evitare disruzioni nelle loro operazioni industriali.

Tuttavia, questo processo viene sfruttato da fornitori esperti che ora consegnano leggermente più di quanto ordinato, sapendo che sarà accettato. Ciò comporta ordini di acquisto che sembrano gonfiati rispetto alle effettive necessità, creando artefatti di dati che falsano le prestazioni del team di acquisti. Vermorel sottolinea che questa complessità deve essere documentata per evitare interpretazioni errate. Insiste sul fatto che i problemi sono sorti non a causa di una cattiva performance del team di acquisti, ma a causa di limitazioni nel sistema e di come gli utenti hanno affrontato queste limitazioni.

Cambiando argomento, Vermorel sta discutendo di chi si interessa ai dati storici, a parte Lokad, un’azienda che li utilizza per previsioni probabilistiche. Sottolinea che le aziende monitorano attentamente i soldi che si aspettano di ricevere o pagare, e quelle che non lo fanno scompaiono nel tempo. Questo è, secondo lui, una forma di “darwinismo” aziendale. Suggerisce che le aziende che prestano attenzione alle loro transazioni finanziarie nel tempo si preoccupano naturalmente dei loro dati storici.

La conversazione si sta spostando verso la preparazione dei dati. Vermorel sottolinea che i dati non sono intrinsecamente “puliti” o completamente compresi. Propone che la preparazione dei dati non sia solo un problema informatico; si tratta di comprendere tutti gli aspetti dei dati aziendali per affrontare tutti gli angoli aziendali. Il reparto informatico, osserva, non può essere considerato in grado di padroneggiare ogni angolo aziendale e non dovrebbe essere l’unico responsabile della preparazione dei dati.

Vermorel suggerisce un approccio distribuito, coinvolgendo diverse squadre con competenze diverse all’interno dell’organizzazione. I dati pertinenti per gli acquisti, ad esempio, dovrebbero coinvolgere le squadre di acquisto. Allo stesso modo, i dati richiesti per una valutazione dei fornitori dovrebbero coinvolgere le squadre di approvvigionamento. Questo approccio può sfruttare le conoscenze necessarie per una preparazione efficace dei dati.

Affrontando il problema di come essere sicuri dell’interpretazione dei dati, specialmente quando le informazioni sono incomplete, Vermorel lo collega alle teorie scientifiche; non è possibile sapere se una teoria è corretta, ma può essere validata quando resiste alla verifica. La correttezza della preparazione dei dati si stabilisce quando le decisioni derivate dall’interpretazione sono corrette. Se una preparazione errata dei dati porta a decisioni senza senso, la causa può essere individuata, corretta e rivalutata.

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

Infine, Vermorel sottolinea che la preparazione dei dati dovrebbe essere un’interpretazione di una comprensione valida dei dati stessi. Una volta stabilita e mantenuta questa comprensione, le operazioni logiche sui dati sono piuttosto semplici. Una buona preparazione dei dati, quindi, è sia un manuale ben scritto che 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 leggi sulla conformità al GDPR, i dati sono molto presenti nella mente di molti dirigenti. È un grande affare anche dal punto di vista economico, 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 in modo che possano essere utilizzati in modo utile. Questo non è affatto semplice se si considera che i dati provengono da molte fonti diverse e spesso possono essere inconsistenti, incompleti e contenere errori. Quindi Joannes, perché stiamo parlando della preparazione dei dati oggi? Voglio dire, se queste aziende investono oltre 450 miliardi di dollari, dovrebbe essere qualcosa che comprendiamo ormai.

Joannes Vermorel: Sì, assolutamente. La preparazione dei dati è un campo abbastanza noto, ma sistematicamente sottovalutato in termini di cambiamenti. È interessante perché la maggior parte dei progetti di preparazione dei dati finisce per non rispettare le scadenze e superare i budget. Il problema principale è che molti bug effettivi che si vedono nei sistemi informatici, nel software aziendale in generale, risalgono a problemi a livello di preparazione dei dati. È estremamente complesso. Anche se è un problema ben noto, il problema principale è che le complessità aziendali riemergono come passaggi di preparazione dei dati, rendendolo un dominio illimitato. Non esiste una ricetta finale per la preparazione dei dati.

Kieran Chandler: Quanto tempo dovrebbe richiedere la preparazione di una quantità considerevole di dati?

Joannes Vermorel: Non ho mai visto un progetto di preparazione dei dati su larga scala che richiedesse meno di qualche mese. Tipicamente, sono più simili a sei mesi. Le persone potrebbero sostenere che con strumenti migliori e software più scalabili dovrebbe essere più veloce. Tuttavia, la realtà è che c’è così poca maturità nell’ecosistema che, per praticamente qualsiasi azienda tranne alcune campionesse dei 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 “spazzatura dentro, spazzatura fuori”. Quindi ci vogliono un paio di mesi, e sei mesi è un obiettivo ragionevole se hai una catena di approvvigionamento complessa coinvolta.

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

Joannes Vermorel: Ti trovi di fronte a un problema specifico qui: puoi avere nove donne per fare un bambino in un mese? Il problema è capire il tipo di problemi con cui stiamo trattando. Innanzitutto, i dati che hai non sono stati prodotti per essere dati in primo luogo. Sono un sottoprodotto del tuo sistema aziendale che semplicemente gestisce la tua azienda. Prendiamo ad esempio un software di punto vendita, qualcosa in cui puoi pagare in un supermercato. La sua funzione principale è elaborare i clienti che vogliono uscire dal negozio pagando ciò che dovrebbero pagare. Quindi, se un codice a barre non viene letto per qualsiasi motivo, il cassiere probabilmente scannerizzerà due volte un prodotto di prezzo simile. Alla fine, pagherai il prezzo giusto, ma in termini di dati, avrai un prodotto contato due volte.

Kieran Chandler: Un prodotto contato zero volte può creare problemi in termini di gestione delle scorte perché i tuoi registri elettronici diventano errati. Questa non è una buona soluzione ed è consigliabile evitarla. Ma la realtà è che, se hai la scelta tra risolvere un problema di dati e far funzionare la tua azienda in modo più fluido, coloro che sono sul campo, le persone che devono gestire fisicamente le catene di approvvigionamento, 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 allo scopo di permetterti di ottimizzare la catena di approvvigionamento. È da lì che derivano tutte queste sfide?

Joannes Vermorel: Infatti, è da lì che derivano tutti questi cambiamenti.

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

Joannes Vermorel: Una regola pratica sarebbe, tipicamente, quando iniziamo un progetto presso Lokad, abbiamo meno di una riga di documentazione per tabella per campo. Di solito, non abbiamo nemmeno quello. Iniziamo molti progetti in cui non abbiamo nemmeno una riga di documentazione per tabella nell’ERP, MRP, WMS o qualsiasi altro sistema utilizzato per gestire la tua catena di approvvigionamento. Quando abbiamo finito, finiamo con una pagina di documentazione per campo per tabella. Quindi, se hai 20 tabelle con 20 campi, stiamo parlando 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 spazzatura in entrata, spazzatura in uscita.

Kieran Chandler: Perché?

Joannes Vermorel: Considera un caso pratico: diciamo che ho una tabella chiamata ‘ordini’. Contiene i miei ordini storici e ha una data. Ma è semplice? Stiamo davvero parlando di che tipo di data è? È la data in cui il cliente ha cliccato su un prodotto per metterlo nel carrello sul sito di e-commerce? O quando il cliente ha convalidato il carrello e ha effettuato il pagamento? O quando il pagamento è stato convalidato dal processore della carta di credito? O quando l’ingresso è stato registrato nel sistema? O quando l’ordine di acquisto è stato modificato per l’ultima volta nel sistema? Ci sono circa 20 diverse interpretazioni solo per questo campo ‘data’.

Inoltre, se la tua azienda ha più di un decennio di storia, è probabile che la sottile linea di interpretazione della ‘data dell’ordine’ sia cambiata nel corso degli anni. Potresti trovarsi in una situazione in cui hai effettuato un aggiornamento di un sistema e la semantica di questa colonna è cambiata.

Inoltre, non è naturalmente qualcosa di completamente omogeneo per tutta la tua storia. Poi, puoi avere ulteriori complicazioni, come casi limite. Ad esempio, questa data dovrebbe essere la data in cui il cliente ha convalidato il carrello, tranne se il pagamento è stato infine respinto come frode. In questo caso, è la data e l’ora in cui l’ordine è stato respinto come frode.

Di nuovo, non è effettivamente un design molto buono, ma le aziende che gestiscono catene di approvvigionamento complesse hanno sistemi complessi e molta storia. Quindi, l’IT non è stato necessariamente fatto perfettamente fin dall’inizio e devi far fronte a tutte queste complicazioni storiche. Queste finiscono per essere riflesse in questa documentazione. Se non riconosci tutte queste complicazioni, avrai problemi ogni volta che vorrai analizzare questi dati.

Kieran Chandler: Per generare una decisione ottimizzata per la tua catena di approvvigionamento, puoi trovarsi con un problema di ‘spazzatura in entrata, spazzatura in uscita’ se interpreti erroneamente i dati. Quindi, quello che stai dicendo è che si tratta di chiarire la semantica dei dati, giusto?

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

Kieran Chandler: Hai un buon esempio di come uno dei tuoi clienti ha affrontato questo problema in passato e come ha influenzato la loro azienda?

Joannes Vermorel: Sì, posso darti un esempio. Avevamo un cliente che gestiva un’operazione molto impegnativa che richiedeva un alto livello di disponibilità. Inviavano ordini di acquisto con tempi di consegna molto brevi ai loro fornitori. Il loro sistema aveva una caratteristica di progettazione interessante. Se la quantità di merci consegnate non corrispondeva alle quantità richieste originariamente, allora l’intero ordine di acquisto doveva essere respinto e rispedito al fornitore.

Supponiamo, ad esempio, che tu ordini 1.000 unità, ma il fornitore ne consegna 1.050, allora dovresti rifiutarlo. Il problema è che se lo rifiuti, potrebbe causare seri problemi operativi. Il sistema non permetteva loro di modificare la quantità, quindi alla fine quello che succedeva era che quando le quantità consegnate non corrispondevano alle quantità ordinate, modificavano l’ordine di acquisto originale per riflettere la quantità 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 si sono accorti di questa pratica. Hanno capito che potevano consegnare più di quanto fosse stato ordinato, sapendo che l’azienda aveva bisogno di quelle forniture. Non consegnavano una quantità esagerata, ma qualcosa che l’azienda avrebbe considerato accettabile.

Nei dati, sembrava che l’ordine iniziale fosse per una quantità maggiore. Questo ha portato a dei dati strani in cui gli ordini di acquisto sembravano troppo grandi rispetto a quanto era necessario, facendo sembrare che il team degli acquisti fosse incapace di scegliere le giuste quantità. Tuttavia, il problema non era nel team degli acquisti, ma nelle limitazioni del sistema e nel modo in cui le persone facevano i conti con queste limitazioni.

Tutti questi dettagli dovevano essere documentati per evitare di arrivare alla conclusione sbagliata. Il team degli acquisti non era incompetente nel loro lavoro. Il problema era che avevano un sistema con delle limitazioni che stavano solo cercando di gestire.

Kieran Chandler: Il sistema sta generando tutti questi strani effetti collaterali. Ha bisogno di una pagina di spiegazione se vuoi capirlo, ma non c’è scampo. È solo la complessità del business stesso che si riflette in questi dati. Allontaniamoci da quei fornitori furbi. È sicuramente un esempio divertente. Quindi, hai menzionato il tipo di persona coinvolta. Ovviamente, da Lokad utilizziamo dati storici per fare previsioni probabilistiche per il futuro. Chi altro si interessa effettivamente ai dati storici, oltre a noi?

Joannes Vermorel: Tipicamente, tutto ciò che riguardava l’importo di denaro che ci si aspettava di ricevere o pagare attirava molta attenzione. Non è che le persone non prestassero attenzione, ma le aziende che non monitoravano attentamente i soldi che avrebbero dovuto ricevere tendevano a scomparire nel tempo. È come il darwinismo in azione. Se nemmeno presti attenzione a questo, scompari semplicemente. Ecco perché, circa cinque secoli fa, la contabilità a partita doppia è stata inventata da alcuni monaci italiani. Se non presti attenzione, il tuo monastero collassa semplicemente a causa di pratiche contabili scadenti. Non è esattamente un problema nuovo, ma ci sono molti dati che in passato non consideravamo critici per la missione che ora stanno diventando critici per la missione.

Per darti un esempio, per contabilizzare correttamente le rotture di stock nel passato, tenevi conto di ciò che acquistavi, in modo da sapere quanto dovresti pagare ai tuoi fornitori, e di ciò che vendevi, in modo da sapere quanto i tuoi clienti dovrebbero pagarti. Ma cosa succede con il tracciamento delle rotture di stock storiche? Finché hai un esperto di supply chain che decide le quantità da acquistare a mano e si ricorda che ci sono stati periodi strani con rotture di stock, allora non hai bisogno di avere quei record storici. Fanno parte del tuo sistema.

Il problema è che non appena vuoi passare a qualcosa di più quantitativo, come facciamo noi in Lokad con decisioni automatizzate per tutte quelle mansioni banali come decidere quanto ordinare, avere registri accurati sui livelli di stock storici diventa molto più importante. Altrimenti, la tua automazione interpreta male cosa sono le vendite e cosa è stata la mancanza di domanda.

Se vuoi automatizzare di più la tua azienda, allora devi prestare attenzione a un’ampia gamma di dati, non solo alla contabilità grezza. Al tuo contabile non importa dei tuoi giorni di rotture di stock, ma al tuo software di ottimizzazione della supply chain sì. Devi ampliare i cerchi di dati che fanno davvero parte del tuo ambito, che sono documentati e in cui hai bisogno di controllo e garanzia di qualità.

Kieran Chandler: Quindi, siamo abbastanza 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 dipartimento IT o qualcun altro preparare quei dati e assicurarsi che siano puliti fin dall’inizio? Sembra un modo più semplice per fare le cose.

Joannes Vermorel: Sì, ma il problema non è la competenza IT. Non esiste una cosa del genere come dati puliti. Il punto è che i dati non sono naturalmente compresi con sufficiente profondità e non tutti gli aspetti aziendali sono adeguatamente coperti.

Kieran Chandler: Si dice spesso che le aziende investono miliardi in intelligenza artificiale, ma la realtà è che è la complessità stessa dell’azienda che emerge in questo compito, questa sfida di preparare i dati. E dire “oh, il dipartimento IT dovrebbe occuparsene”, è come aspettarsi che l’IT gestisca l’azienda e conosca ogni singolo aspetto aziendale.

Joannes Vermorel: Assolutamente, questo crea improvvisamente un problema organizzativo perché ti aspetti che l’IT sia un esperto di risorse umane, marketing, acquisti e così via. Voglio dire, ti aspetti una padronanza completa di tutti gli aspetti aziendali da parte del dipartimento IT. Ma è chiedere troppo. Il dipartimento IT deve già occuparsi di tutti i cambiamenti IT, quindi non dovrebbe essere previsto che affronti ogni singolo problema aziendale. In alternativa, potresti ridefinire l’IT come l’intera azienda, ma questo vanifica lo scopo.

Tornando al caso in questione, la preparazione dei dati deve essere uno sforzo abbastanza distribuito all’interno dell’azienda perché, alla fine, le uniche persone che possono fornire il livello di approfondimento necessario per preparare i dati rilevanti per, diciamo, gli acquisti, sono i team di acquisto. Allo stesso modo, se vuoi stabilire una scheda di valutazione dei fornitori e avere i dati preparati con sufficiente accuratezza in modo che abbia davvero senso, dovrai parlare con i tuoi team responsabili degli approvvigionamenti.

Ogni volta che affronti un problema, devi coinvolgere le persone che sono specialiste in quel problema all’interno della tua azienda perché sono loro le persone che ti daranno le informazioni necessarie per la preparazione dei dati in modo che abbiano senso. Non è strettamente un problema IT. Si tratta di raccogliere tutta la comprensione necessaria in modo che, quando elabori i dati, non finisci con dati che non hanno senso rispetto al problema aziendale che deve essere risolto.

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

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

Quindi, cosa significa per la preparazione dei dati? Significa che sai che la tua preparazione dei dati è corretta quando, alla fine del flusso di dati, le decisioni che generi automaticamente basate su questa interpretazione sono corrette. Se hai decisioni corrette, significa che la tua logica di ottimizzazione è efficiente, i tuoi livelli di machine learning sono accurati e molte altre cose. Fondamentalmente, non è possibile ottenere decisioni corrette generate da un’interpretazione errata. Di solito, quando non interpreti e prepari correttamente i tuoi dati, i risultati saranno così scadenti che non ci sarà possibilità che funzionino.

La cosa principale è che non ci sono scorciatoie se non fare la preparazione, essere fiduciosi al riguardo, quindi generare le decisioni. Se le decisioni non hanno senso, torni indietro, risali al problema alla sua causa radice - 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 usa la propria mente umana per valutarle, allora sai di aver fatto giusto.

Kieran Chandler: Potresti dire, credo che siano state preparate correttamente, ma di solito si tratta di sfumature di grigio. Il professionista della supply chain potrebbe dire: “È una buona decisione, ma potrebbe essere migliorata ulteriormente. Ad esempio, se tenessimo conto del prezzo dei nostri concorrenti perché spiega picchi o cali insoliti nella domanda, e non abbiamo ancora questi dati.” Quindi, non è una situazione bianco e nero.

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

Se scrivi qualcosa incredibilmente noioso, nessuno lo leggerà e non avrà alcun effetto sulla tua organizzazione. Quindi, deve essere ben scritto. E con ben scritto intendo che dovrebbe essere leggibile. Deve anche essere scritto da una prospettiva aziendale. Non è una documentazione IT. La preparazione dei dati non è davvero un problema IT, ma riguarda piuttosto avere tutte le intuizioni aziendali.

La prospettiva valida in azienda è sempre qualcosa che cambia. Se il panorama competitivo nella tua industria cambia, anche la prospettiva valida su un determinato problema cambia. Quindi questo libro deve essere ben scritto e mantenuto.

Questo è uno sforzo molto distribuito nella tua azienda perché, ad esempio, solo il team di merchandising ha la giusta intuizione e prospettiva per sapere come documentare le tabelle di merchandising in primo luogo. Questa preparazione dei dati assomiglia a materiali puliti e ben scritti che sono ampiamente distribuiti e accessibili nella tua azienda.

La cosa interessante è che una volta che hai tutte queste intuizioni, la trasformazione dei dati, che è logica, diventa un’interpretazione diretta della comprensione valida dei dati stessi. Devi mettere un enorme sforzo per capire i dati, documentarli, scriverli e mantenerli. Ma una volta fatto tutto questo, scrivere la logica diventa semplice. Quindi, come appare una buona preparazione dei dati? È come un libro ben scritto, una comprensione condivisa, una sorta di bibbia della supply chain interna alla tua azienda.

Kieran Chandler: Sembra buono! Quindi, sfumature di grigio dei dati, sarà un nuovo bestseller che arriva dall’organizzazione?

Joannes Vermorel: Possibilmente, chi lo sa?

Kieran Chandler: Ok, speriamo che abbiate apprezzato l’episodio di oggi sulla preparazione dei dati. Come sempre, contattateci se avete ulteriori domande e ci vediamo alla prossima puntata su Lokad TV. Arrivederci per ora.