I tuoi dati sono migliori di quanto pensi

00:00:00 Dati migliori di quanto pensi
00:03:43 Perché i “dati cattivi” diventano un capro espiatorio
00:07:26 Fatti transazionali contro la spazzatura dei parametri
00:11:09 Il “cake” del livello di reporting rompe il processo decisionale
00:14:52 Una visione in cui le decisioni hanno la priorità nelle informazioni utili
00:18:35 Automatizzare i parametri: tempi di consegna, stagionalità, novità
00:22:18 La complessità dell’ERP non significa dati cattivi
00:26:01 I campi data nascondono molteplici significati nel mondo reale
00:29:44 La semantica dimostrata dalle decisioni generate
00:33:27 Gli outlier rivelano metodi difettosi, non dati cattivi
00:37:10 I data lakes dovrebbero copiare, non “migliorare”
00:40:53 La qualità dei dati misurata in dollari
00:44:36 AI readiness: transazioni affidabili, semantica prima
00:48:19 Il dual-run richiede un’esecuzione completamente senza supervisione
00:52:02 I giochi del biasimo dei fornitori: il caso Lidl-SAP ammonitore
00:55:45 La qualità equivale all’idoneità alle decisioni

Riepilogo

“I dati cattivi” sono spesso un capro espiatorio. La maggior parte dei record transazionali delle aziende – ciò che è stato acquistato, venduto, spedito, restituito – sono sufficienti, altrimenti non sopravviverebbero. Il vero caos è la montagna di parametri mantenuti manualmente e la confusione su cosa i campi effettivamente significhino (semantica), specialmente nei vasti ERPs. Non “pulire” la realtà per salvare metodi deboli: gli outlier sono spesso il business. Valuta i dati in base ai risultati: se le decisioni migliorano in modo redditizio, i dati erano sufficienti; se i risultati sono assurdi, correggi l’interpretazione.

Riepilogo Esteso

Un lamento familiare nel supply chain è che i “bad data” bloccano il progresso. Eppure gran parte di ciò che viene definito bad data non è né cattivo né centrale al problema. Spesso è una scusa conveniente—talvolta per i fornitori che hanno bisogno di incolpare qualcun altro quando il loro software fallisce, e talvolta per analisti abituati a dataset ordinati da aula che rimangono sbalorditi dall’immensa complessità dei reali sistemi aziendali. Un ERP con migliaia di tabelle non è la prova di bad data; è la prova della complessità.

La discussione traccia una netta distinzione tra due tipi di “dati.” Il primo è la realtà transazionale: ciò che è stato acquistato, venduto, spedito, restituito, rottamato, pagato—eventi con conseguenze finanziarie. Queste informazioni sono solitamente affidabili, per una semplice ragione: le aziende che non riescono a mantenere intatta la verità transazionale di base non durano a lungo. I mercati puniscono rapidamente tale confusione. Gli errori esistono, ma solitamente a tassi bassi.

Il secondo tipo è una montagna di parametri mantenuti manualmente—obiettivi di livello di servizio, coefficienti di scorta di sicurezza, flag di stagionalità, lead times inseriti dagli impiegati. Questi “artefatti numerici” sono di solito obsoleti, inconsistenti e costosi da mantenere su larga scala (milioni di SKUs per moltiplici parametri). Ma il punto importante è che spesso non sono necessari. Molti di questi input dovrebbero essere dedotti dalla storia osservata o automatizzati tramite metodi migliori. Trattarli come “dati core” crea un onere auto-inflitto.

Un grosso problema nascosto è la semantica: ciò che un campo significa. La stessa colonna può cambiare significato nel tempo, attraverso processi aziendali, o addirittura in base al segno (vendita vs restituzione). La documentazione è solitamente scarsa all’inizio. L’unico modo affidabile per validare la semantica non è attraverso infiniti workshop, ma mettendo alla prova le interpretazioni: generare decisioni reali—cosa acquistare, produrre, stoccare, prezzare—e vedere se i risultati diventano assurdi. Quando ciò accade, si retroingegnerizza la pipeline per trovare l’ipotesi errata.

Questo ridefinisce anche il concetto di “dati rumorosi.” Se i clienti talvolta ordinano 1 e talvolta 100, non si tratta di bad data—è il business. I metodi che crollano di fronte agli outlier sono difettosi; i dati non dovrebbero essere falsificati per salvare una matematica debole.

Infine, riguardo alla “AI readiness”: il parametro non è la purezza morale dei dati. È l’idoneità allo scopo. Se sai cosa acquisti, produci e vendi, puoi iniziare. Il vero lavoro consiste nel mappare la semantica, sistema per sistema, e poi iterare rapidamente finché le decisioni non diventano sensate. Alla fine, la qualità non è uno slogan; è misurata dalla performance economica delle decisioni.

Trascrizione Completa

Conor Doherty: Questo è Supply Chain Breakdown, e oggi analizzeremo perché i tuoi dati sono, in effetti, migliori di quanto pensi. Molte aziende ci dicono che i loro dati sono ciò che impedisce loro di avviare i progetti che desiderano. Beh, oggi siamo qui per mettere in discussione quell’idea. Siamo costruttivi.

Chi siamo? Beh, io sono Conor, Direttore Marketing qui a Lokad. Alla mia sinistra, come sempre, il fondatore di Lokad, Joannes Vermorel. Ora, prima di iniziare, fateci sapere qui sotto: prima, da dove nel mondo ci state guardando? Noi siamo a Parigi. E seconda, siete d’accordo, o pensate addirittura, che i master data siano in realtà un collo di bottiglia per i progetti di trasformazione digitale, quelli in cui le aziende vogliono davvero impegnarsi in questi giorni? Inserite i vostri commenti e le vostre domande qui sotto. Ne parleremo un po’ più avanti.

E con questo, Joannes, passiamo alla discussione. Ora, prima di entrare nel merito, un piccolo contesto su come è nata questa discussione. Come sapete, solleviamo il sipario: alla fine di ogni episodio dico, “Ehi, se volete continuare la conversazione, contattate privateamente me e Joannes. Siamo felici di parlare.” Tutto ciò è vero. Beh, alcune persone lo fanno. Vogliono parlare.

E recentemente, sia collettivamente che individualmente, abbiamo avuto discussioni, e un tema ricorrente per i professionisti è una sorta di lamento sullo stato dei dati: tipo, “I miei master data sono spaghetti,” “Il mio ERP è formaggio svizzero,” e così via. Ma vedi, questo è il problema. Questo è ciò che mi impedisce di fare tutte le cose interessanti che vorrei fare. Ed è così che siamo arrivati all’argomento di oggi.

Allora, Joannes, perché i dati hanno una così cattiva reputazione nella supply chain?

Joannes Vermorel: Riesco a pensare a diverse ragioni, a seconda del pubblico.

Per software vendors, i dati scadenti sono il perfetto capro espiatorio. È un modo per incolpare i clienti in modo educato ma deciso per qualsiasi difetto del prodotto software. Quindi è estremamente conveniente, e i buoni fornitori, fornitori talentuosi, riusciranno a convincere i clienti che tutto è colpa loro se l’intera cosa è andata in pezzi perché avevano pratiche di gestione dati, assicurazione della qualità e così via.

Ma secondo me: si tratta davvero di capro espiatorio. Il secondo pubblico sono i data scientists, in particolare quei data scientists che provengono da… che hanno partecipato, direi, a competizioni su Kaggle. Sono abituati, soprattutto all’università, a set di dati super ordinati e puliti, e pensano che questo sia lo standard. Credono che avere un set di dati con cinque tabelle, ogni tabella con cinque campi, e con una documentazione estesa per ogni campo, e tutto molto, molto chiaro—va bene. Questo, per me, è un problema di aspettative selvaggiamente irrealistiche.

Nelle aziende, voglio dire, se prendiamo gli ERP di fascia media, si parla di 10.000 tabelle. Alcune tabelle hanno 50 campi. È di questo che stiamo parlando. Quindi qui abbiamo un problema di data scientists che hanno aspettative completamente irragionevoli su cosa siano effettivamente i dati aziendali.

E c’è un terzo segmento, quello dei professionisti. Il fatto è: quello a cui prestano attenzione è, tipicamente, la parametrizzazione del loro sistema gestionale. Non guardano a nulla di reale, per esempio: un’unità venduta in una determinata data, a un certo prezzo. Questo non è solitamente il punto focale. Non si tratta di quegli eventi transazionali chiave del passato.

Quello a cui prestano attenzione è: “Oh, ma guarda, le impostazioni di stagionalità che abbiamo inserito nell’APS due anni fa ora sono completamente sbagliate a causa di questo, a causa di quello.” “Guarda, abbiamo così tanti coefficienti correttivi per la formula della scorta di sicurezza, e anche quelli sono completamente fuori calibro,” ecc. Quindi, in realtà, quando quei professionisti si lamentano dei dati scadenti, lo fanno in modo molto specifico in riferimento agli artefatti numerici—elementi che non rappresentano il passato o il futuro. Rappresentano una sorta di parametrizzazione delle politiche aziendali.

E secondo me: se torniamo al primo caso, quello del software vendor, il problema è che se la soluzione software che hai utilizzato dipende in maniera così pesante da questa parametrizzazione, che è mantenuta manualmente, allora è garantito che ti dirigerai dritto verso i guai. Quindi, l’unica soluzione è smettere di trattare quelle cose come se lo fossero. Non dovrebbero nemmeno far parte del quadro, in modo da non doverne fare i conti.

Conor Doherty: Quindi, correggimi se sbaglio, ma sembra che tu stia dicendo che esistono fondamentalmente due categorie di dati. Quando la gente usa il termine “data”, in realtà pensa a due categorie. Una è quella che tu chiami artefatti numerici—le cose che hanno stabilito per sé, certi obiettivi—ma l’altra è il vero dato transazionale grezzo, che consideri molto, molto più importante.

Joannes Vermorel: Già. Voglio dire, i dati reali delle transazioni sono le cose che sono accadute. In altre parole: hai venduto o non hai venduto. Hai pagato il fornitore, hai passato un ordine, hai prelevato un’unità dallo stock, hai distrutto un’unità che era in realtà deperibile e ha superato la sua durata di conservazione, ecc., ecc. Questi sono dati transazionali, e di solito sono eccellenti.

Tuttavia, in molte soluzioni aziendali, hai anche una montagna di parametri che dovrebbero essere mantenuti dagli impiegati—persone che semplicemente gestiscono il sistema. E il fatto è: perché hai persino bisogno di avere quei zillioni di parametri? Perché molto frequentemente si parla di una quantità enorme di parametri.

Solo per avere un’idea della scala: un’azienda che ha un milione di SKU, che in realtà non è poi così enorme—se hai, diciamo, 10 parametri per SKU, e io sono conservativo, potrebbe essere anche di più—10 parametri per SKU, quindi stiamo parlando di 10 milioni di parametri da mantenere più o meno manualmente. E questo è follia.

Poi la gente dice, “Oh, questo è una schifezza perché non riusciamo davvero a mantenerlo.” Io direi: sì, assolutamente. Ma la realtà è che non ne hai davvero bisogno. E tutte quelle cose, in effetti, non trasmettono informazioni, perché il modo in cui quei parametri sono stati impostati è stato comunque basato sull’osservazione del resto dei dati.

Quando la gente imposta, ad esempio, un target di service level, lo fa osservando la cronologia transazionale. Quindi, vedi, queste informazioni sono completamente transitorie e non dovrebbero essere considerate parte del nucleo dei tuoi dati. È per questo che dico: i dati scadenti sono un problema molto, molto più piccolo di quanto la gente si aspetti. È solo perché trattano come dati una grande quantità di elementi che in realtà non dovrebbero esserlo.

C’è anche una seconda prospettiva, ma è un problema a parte. È quando le persone vogliono fare ulteriori analisi basate su dati pre-elaborati, in particolare quelli ottenuti dallo strato di reporting.

Ancora una volta, divido il software enterprise in tre categorie: sistemi di record—ovvero gli ERP meno la parte di pianificazione, perché in questi non è prevista la pianificazione—, sistemi di report, che sarebbero il business intelligence e tutti quei sistemi per il dashboarding e il reporting, e infine sistemi di intelligence, quelli che si occupano di decision-making.

L’unica fonte di verità per i dati risiede nei sistemi di record. Ma molto frequentemente, perché le persone a volte sono fuorviate, occupate o altro, vogliono sfruttare i dati così come sono presentati dallo strato di reporting. E qui ci troviamo in una situazione che, per analogia, è molto simile a quella di un cuoco.

Immagina di avere una cucina, di avere tutti gli ingredienti grezzi—farina, zucchero, sale—e questi sono il sistema di record, gli ingredienti grezzi. E poi il cuoco, attraverso lo strato di report, può preparare una torta. Hai una torta, è bella, puoi consumarla. È pensata per il consumo umano, quindi funziona.

Ora chiedi al cuoco: “Prendi questa torta e falla trasformare in qualcos’altro.” Ed è esattamente ciò che accade quando cerchi di utilizzare i dati provenienti dallo strato di reporting per, ad esempio, guidare i processi decisionali. Va molto, molto male. Non è che il cuoco sia un cattivo cuoco; è solo che se parti dalla torta, non puoi fare altro. È già il prodotto finito. Cercare di separare lo zucchero, la farina e così via—tutto si perde.

Quindi devi tornare agli ingredienti grezzi se vuoi fare qualcos’altro. Questo è anche un errore tipico che ho visto commettere a molte aziende: guardano ai dati nello strato di reporting, che è pensato per il consumo umano, e cercano di estrarre questi dati per rielaborarli a fini differenti. Questo è un errore. Devi tornare agli ingredienti grezzi.

Conor Doherty: Bene, ancora su questo tema—l’idea di ritornare agli ingredienti grezzi, di tornare ai dati fondamentali—in realtà ho un… chiamalo come vuoi riguardo alla fonte. Lo uso solo come contesto di base per dimostrare che non stiamo semplicemente speculando qui.

Sto guardando un rapporto Gartner ora, che ha sondato centinaia di aziende molto grandi, e ha confermato che la maggior parte delle aziende non misura nemmeno la qualità dei dati in modo coerente. Quello che accade in realtà è che c’è solo questa sensazione che i nostri dati siano scadenti, ma non è necessariamente un fatto misurato.

Quindi ci sono due domande qui. Una: ti sorprende in generale? E due: come potrebbero le persone diagnosticare rapidamente lo stato di salute dei loro dati?

Joannes Vermorel: In primo luogo, se guardiamo ai dati transazionali, la risposta è semplice: la tua azienda è profittevole? Se sì, la tua azienda dispone di dati di alta qualità. Perché? Perché non ho mai incontrato un’azienda che, non sapendo cosa acquistasse, vendesse o producesse, fosse sopravvissuta.

Se neanche lo sai, andrai in bancarotta alla velocità della luce. Se non sai cosa ti hanno inviato i tuoi fornitori, allora ti verrà addebitato più volte. Se non sai cosa i tuoi clienti hanno effettivamente acquistato, allora non li stai addebitando correttamente. È molto veloce. È il darwinismo in azione. I mercati eliminano spietatamente quelle aziende; scompaiono.

Quindi, come regola pratica: se lavori in un’azienda che non è sull’orlo della bancarotta a causa di una cattiva gestione, la storia transazionale è probabilmente di altissima qualità. Sì, un errore amministrativo può capitare, come una riga su mille — tipicamente l’ordine di grandezza che posso osservare nella maggior parte delle aziende. Avrai tra, diciamo, lo 0,1% e talvolta fino allo 0,5% di errori amministrativi, ma è molto, molto basso. Molte aziende sono addirittura al di sotto di quella soglia.

Ora, se parliamo di tutti i dati opzionali — per esempio, hai una parametrizzazione nel tuo sistema che ti permette di decidere il livello di servizio target per una SKU — cosa significa avere dati di alta qualità qui? È un’assurdità.

Se dovessi fare l’avvocato del diavolo, dovrei esaminare quanto questa impostazione si avvicini a massimizzare il tasso di rendimento dell’investimento in inventario dell’azienda quando questo parametro è in atto. Non lo faremo mai. È decisamente troppo complicato. Se in effetti abbracci l’idea che la tua supply chain debba massimizzare il tasso di rendimento, ben venga, ma allora eliminerai molto, molto rapidamente tutti quegli approcci non economici.

In definitiva: in questa parametrizzazione, sì, tendono ad esserci molte spazzature. La realtà è che le aziende possono convivere con ciò perché, diciamo, un pianificatore di inventario consulterà semplicemente il riapprovvigionamento raccomandato, e questo potrebbe non avere molto senso, ma lo stesso pianificatore analizzerà la storia recente, alcune cose, e in un minuto la persona dirà, “Ok, ordina 50 unità,” e subito dopo passerà alla SKU successiva.

Quindi sì, se vuoi robotizzare o fare qualsiasi cosa in maniera automatizzata, basandoti su questi dati di parametrizzazione, la qualità dei dati è molto, molto bassa. Ma l’unica soluzione è considerare i sistemi software come sistemi di intelligenza che non fanno affidamento su questa parametrizzazione, che serve solo a supportare le capacità di un processo incentrato sul flusso di lavoro.

Conor Doherty: Beh, sto semplicemente annotando un pensiero da approfondire in merito, perché, ancora una volta, dove possibile mi piace amplificare ogni spunto di pensiero costruttivo.

La nostra prospettiva, come ben sanno tutti coloro che ci seguono, è che lo scopo dei dati, lo scopo perfino di andare a lavorare in un’azienda, è prendere decisioni migliori — decisioni migliori che in realtà producono più denaro. Ora, hai sottolineato che le decisioni migliori non risiedono nel sistema di report; sono già presenti nei tuoi dati transazionali.

Quindi, sostanzialmente, affinché le persone possano prendere decisioni migliori — definisci “migliori” come preferisci, poiché noi intendiamo massimizzare il tasso di rendimento — per tutti voi che ascoltate, se avete dati transazionali, potete già iniziare a prendere decisioni positive.

Joannes Vermorel: Quello che ho notato per praticamente tutta la clientela di Lokad — e parliamo di oltre 20 miliardi di flusso annuo di merci che Lokad gestisce — è che il 99% delle informazioni proviene, anzi, probabilmente il 99,99% della massa informativa, dai sistemi transazionali.

Inoltre, probabilmente avrai qualche decina di meta-parametri — driver economici — che devono essere mantenuti manualmente. Ma qui dobbiamo essere molto conservativi, e in pratica sono solo qualche decina. Quindi la qualità dei dati qui deve essere elevata. È difficile, ma stiamo parlando di un numero molto ridotto di parametri importanti — parametri che sono sufficientemente rilevanti da valere diverse riunioni per ciascuno.

Ma alla fine deve trattarsi di un parametro strategico, economico, di alto livello, non di qualcosa a livello di SKU. Tutto ciò deve essere completamente automatizzato, e si può fare.

Ecco perché dico che i dati sono solitamente eccellenti, perché ciò che serve è la storia transazionale. Se affronti un problema nel modo giusto, non hai bisogno di avere milioni di parametri che vivono nel tuo sistema, che devono essere mantenuti manualmente e che possono assumere così tante forme.

Molti sistemi chiedono ai professionisti di inserire il lead time. Ma perché devi inserire il lead time? Osservi i lead time dal tuo fornitore. Quindi i lead time devono essere previsti, non inseriti manualmente dall’utente.

Molti sistemi chiedono all’utente di classificare e dire, per esempio, “Questo è un articolo stagionale?” Perché dovresti fare manualmente queste cose che dovrebbero essere completamente automatizzate, anche se l’unica informazione a disposizione è l’etichetta del prodotto? Al giorno d’oggi, con i LLM, non è mai stato così facile automatizzare questo tipo di rilevamento. “Ho un nuovo prodotto; questo oggetto presenterà schemi stagionali?” È piuttosto semplice.

Non serve l’intervento di un umano che dica, “Oh sì, una combinazione da sci, oh sì, sarà stagionale. Ok, grazie.” Questa è la realtà: si tratta di domande davvero elementari, e tutti i sistemi chiedevano ai professionisti di continuare a inserire così tante cose che sono del tutto ovvie e che possono essere automatizzate.

Anche cose che a volte sono davvero sconcertanti: i professionisti devono inserire manualmente se si tratta di un nuovo prodotto. Perché è necessario che qualcuno dica al sistema che si tratta di un nuovo prodotto? Puoi vedere che nella storia non c’è alcuna transazione. Il prodotto è stato creato di recente nel sistema, non ci sono transazioni — perché impostarlo manualmente come nuovo prodotto? È una montagna di assurdità.

Ma ancora, secondo me, tutta la spazzatura in quest’area, in questa parametrizzazione per tutte quelle politiche, riflette un modo obsoleto di guardare alla supply chain. Quindi, qualunque cattivo dato tu abbia su questo fronte, è irrilevante. Ciò che conta sono i dati transazionali, e questi sono buoni, e lo sono perché la tua azienda è viva.

Conor Doherty: Beh, a proposito — e ancora, questo serve a scavare un po’ più a fondo nelle cause di questa percezione — perché è inutile limitarsi a dire, “Ho un problema.” È più una questione di, “Ok, quali sono le cause di questo? Qual è la radice di questo?”

Quindi, ascoltandoti, sembra che ci sia… ok, darò un esempio concreto e poi potrai ripartirne. Ho sentito, e so che anche tu hai sentito, qualche versione di questo: “Il mio ERP è un disastro.” E si tratta del sistema di registrazioni di cui si parla, il libro dei dati transazionali: “Ho tabelle duplicate, colonne etichettate in modo errato, è un disastro.”

Tecnicamente, tutti i dati transazionali, i dati transazionali grezzi, sono lì. Il problema — se si può parlare di un problema — è: ok, la migrazione ERP che hai effettuato ha prodotto un disastro. E che sia chiaro: non vendiamo un ERP, possiamo lavorare con qualsiasi cosa, quindi non abbiamo interesse personale in questo.

Ma la mia domanda per te è: quanto gioca un ruolo la scelta del software nel produrre questa epidemia di cattivi dati?

Joannes Vermorel: Anche qui, direi che si tratta di aspettative sbagliate. È esattamente il mio caso quando ho menzionato il secondo pubblico: data scientists, competizioni su Kaggle. Non ho detto che l’ERP, i sistemi di registrazione, sarebbero stati ordinati e puliti. La complessità sarà fuori scala, e va benissimo così.

Non si tratta di cattivi dati. Si tratta semplicemente di dati molto complessi e molto opachi — problemi differenti. Ora sì, quando hai 10.000 tabelle, è molto difficile individuare dove si trovi il livello di stock. È complicato, e può richiedere settimane rintracciare dove una certa informazione risiede effettivamente nel sistema. Ma ancora, non si tratta di cattivi dati.

Allora, in effetti, hai un altro problema: la semantica per una qualsiasi colonna può essere eterogenea. Cosa intendo? Intendo che la semantica che puoi avere per una determinata colonna di dati potrebbe variare a seconda della riga. È una complicazione.

Solo un esempio: alcuni ERP vendor maldestri, anni fa, decisero, ad esempio, che nella tabella degli ordini, se la quantità era positiva, si trattava di una vendita, quindi stai vendendo a un cliente, e la data rappresentava la data di transazione della vendita. Ma se la quantità era negativa, si trattava di un reso, quindi è la data del reso dell’articolo. Ciò significa che ho una colonna chiamata “order date,” tranne il fatto che non è una data d’ordine quando la quantità è negativa: è in realtà una data di reso.

Questo è quello che intendo: semantica eterogenea — cioè, nella stessa colonna, a seconda della riga, in base a certe condizioni, a volte è come se l’ERP avesse subito un aggiornamento e, dal 1° gennaio 2020, la order date significasse qualcos’altro. A causa di un aggiornamento del sistema, la semantica cambiava nel tempo.

A volte sono persino i team all’interno dell’azienda a decidere, a un certo punto, di cambiare il processo e a ridefinire la semantica di un determinato campo, dotandolo di una nuova semantica. Quindi è molto complesso, sì, e scoprirlo lo è altrettanto.

Ma ancora, sono dati scadenti? Se conosci il tuo ERP vendor, magari perché erano un po’ incompetenti in termini di design software, e decisero che “order date” potesse essere sia la data della vendita sia la data del reso — sì, è stato un approccio maldestro, ma sono davvero dati scadenti? Sostengo che i dati siano validi. È solo una questione di semantica confusa.

Torniamo al fatto che è un lavoro enorme da rifare, e io sono d’accordo. Ma quando la gente mi dice “dati scadenti,” molto frequentemente rispondo: no, i tuoi dati vanno bene. È solo che dobbiamo impegnarci seriamente a ricostruire la vera semantica dei tuoi dati, e questo richiede un grande sforzo.

Di solito, quando iniziamo con i clienti, normalmente non abbiamo nemmeno una riga di documentazione per campo, per tabella. Quando abbiamo finito, di solito abbiamo una pagina di documentazione per campo, per tabella, per i campi che sono effettivamente rilevanti per l’iniziativa Lokad, che è supply chain optimization.

Tuttavia, 20 tabelle, 20 campi — stiamo parlando di 400 pagine di documentazione. Non documentazione IT: supply chain documentation, perché dobbiamo avere la semantica di ciò che questo campo significa e implica da una prospettiva supply chain. Quindi sì, è un lavoro immenso.

Credo che, ancora una volta, sotto il vessillo dei dati scadenti, molto spesso sia semplicemente dovuto al fatto che molte persone non si rendono conto della quantità di sforzo necessaria per questa qualificazione semantica. In aggiunta, abbiamo fornitori di software incompetenti che usano felicemente questo aspetto come capro espiatorio per i dati, il che è un modo educato per dire al cliente: “È colpa tua.”

Conor Doherty: Beh, a proposito, in realtà… non sapevi che lo avrei fatto, ma ovviamente il tuo nuovo libro c’è, e in preparazione di questo sono infatti tornato al tuo vecchio libro.

E per i veterani che hanno già letto entrambi i libri di Joannes, potete tirar fuori la vostra copia ora. Ovviamente il codice nelle ultime poche centinaia di pagine di questo libro potrebbe non essere così rilevante oggi, ma le prime… direi che le prime cento pagine sono ancora molto, molto rilevanti.

E per chiunque abbia la propria copia a portata di mano: a pagina 60, sul tema della semantica — e ancora, questo è solo per dimostrare che non si tratta di filosofia astratta — sto per dare un esempio molto concreto e porvi una domanda altrettanto concreta, ma mi limiterò a leggere brevemente da questo perché lo trovo davvero illuminante.

Quindi qui, a pagina 60: quando facciamo riferimento alla quantità per giorno relativo a una data specifica, la data da sola porta con sé il suo insieme di ambiguità. Potrebbe essere la data in cui il cliente ha effettuato un ordine. Il cliente ha confermato un pre-ordine. Il prodotto è stato spedito al cliente. L’inserimento dell’ordine è finalmente arrivato nell’ERP. L’inserimento dell’ordine è stato modificato l’ultima volta all’interno dell’ERP. Il pagamento da parte del cliente è stato infine ricevuto. Hai detto, ecc. Ma potresti anche dire che è la data in cui la garanzia o il periodo di reso è scaduto.

Ora, questi sono tutti significati semantici concreti per una semplice data.

Joannes Vermorel: Sì. Per una semplice data.

Conor Doherty: Esattamente. Ma il mio punto è: qual è il danno, cioè, se scelgo uno di questi? È come un albero decisionale in cui, all’improvviso, le decisioni che posso prendere differiscono radicalmente? È questa la portata del danno? Spiega il perché, così che lo capiscano.

Joannes Vermorel: Sì. La parte complicata della semantica è che, quando sbagli, l’unico modo affidabile per renderti conto dell’errore è che, alla fine della pipeline, genererai decisioni assurde.

Fino a quando non avrai una pipeline completamente robotizzata che generi decisioni finali — allocazione delle risorse per supply chain: cosa acquistare, cosa produrre, dove stoccare le cose, i tuoi punti prezzo per ogni articolo che vendi — finché non avrai una data pipeline completamente autonoma, una ricetta numerica che generi quelle decisioni, ti mancherà lo strumento necessario per valutare, per mettere in discussione la tua semantica.

Se, nella tua documentazione, la scrivi in modo errato — pensi che questa order date fosse quella in cui il pagamento è stato approvato; in realtà non lo è. È il momento in cui sei pronto a spedire l’articolo al cliente — la documentazione è sbagliata. Non sarai in grado di accorgertene. Nessuno se ne accorgerà.

Forse, se ti dedichi a un’analisi approfondita di questo campo dopo due giorni di lavoro, sarai in grado di correggerlo. Ma devi sapere che c’era un errore fin dall’inizio. Stiamo parlando, anche per una piccola iniziativa, di centinaia di campi. Farai workshop di più giorni per ogni singolo campo per assicurarti che la tua semantica sia corretta? Non è ragionevole.

Quindi, l’approccio ragionevole è fare il massimo sforzo, il miglior tentativo, e poi lasciare che la decisione venga generata in base a questa interpretazione. Ed ecco, occasionalmente le decisioni saranno assurde. Quando avviamo iniziative, generiamo molte decisioni addirittura assurde.

Quindi diamo un’occhiata, e le persone dicono, “Oh, questo numero è insensato.” Va bene. Fai ingegneria inversa su ciò che ci ha portato a questa decisione senza senso, e poi, risalendo, fai ingegneria inversa. Devi disporre degli strumenti per farlo.

Finirai per dire, “Ah, questa data — oh, abbiamo frainteso.” In effetti, il lead time applicabile in questa situazione è completamente diverso perché abbiamo frainteso la data. Va bene, rigeneriamo la decisione con un’interpretazione corretta per questa data. Oh, ora sembra molto più ragionevole. Bene. Avanti.

Fondamentalmente, l’unico modo per valutare se la tua semantica è corretta è metterla alla prova nel mondo reale: genera una decisione e lascia che i praticanti dicano, “Ha senso?” Se non è così, devi tornare indietro.

L’errore che molti strumenti alternativi commettono è che, quando i dati generati sono insensati, dicono, “Oh, devi modificare i parametri.” Io dico: assolutamente no. Devi modificare i parametri solo se si ritiene che siano la causa principale del problema che stai riscontrando. In caso contrario, questa non è la soluzione.

Molto, molto frequentemente, il problema… non posso sottolineare abbastanza l’importanza della semantica. È davvero, davvero complicata. L’unico modo per affrontarla è osservare le decisioni generate, il che è ancor più problematico poiché molti strumenti nello spazio della pianificazione non generano mai decisioni definitive, e quindi si privano – i fornitori di software che lo fanno – dello strumento stesso che permetterebbe loro di valutare se hanno la semantica corretta.

Conor Doherty: Giusto. Bene, ancora una volta, in termini di collegarsi a quanto hai appena sottolineato: l’idea dei dati – usiamo i dati per prendere decisioni, che tu usi o meno la previsione probabilistica – è ciò che un approccio Lokad sosterebbe. Ma fondamentalmente, i dati vengono utilizzati per facilitare almeno un passaggio: la previsione, per poi arrivare a una decisione.

Ma una delle lamentele comuni che sentiamo dai praticanti è: “C’è troppo rumore nei dati.” Nel contesto della previsione, i dati rumorosi sono un problema?

Joannes Vermorel: Assolutamente no. Se, per esempio, il tuo business è irregolare – hai clienti che a volte ordinano uno, altre volte 100 – quella è la realtà del tuo business.

Molti metodi per la supply chain, metodi numerici, sono estremamente difettosi. Quando si trovano di fronte a qualcosa che potrebbe qualificarsi come un outlier statistico, numericamente la ricetta si comporta male. Quindi hai un outlier e la cosa deraglia e ti dà un completo non-senso.

Poi la gente dice, “Oh, dobbiamo tornare indietro e modificare questa storia, potare gli outlier.” Dicono, “Quegli outlier sono cattivi, sono sintomi di qualcosa di sbagliato…” Qui sono completamente in disaccordo. Se i tuoi clienti hanno ordinato, per davvero, 100 unità in passato, questo può essere un outlier ma questa è la realtà. È successo.

Ovviamente, se hai un record nel tuo sistema che dice che sono state ordinate un milione di unità ma nessun ordine di questo tipo è mai stato creato, ok, quelli sono cattivi dati. Torniamo ai dati transazionali: i dati transazionali sono accurati.

Ma se hai un metodo numerico che ti dà risultati folli perché si trova di fronte a un outlier nei dati storici, il problema non sono i dati. Il problema è il metodo numerico che è semplicemente una merda. Stai affrontando un metodo difettoso. Dovresti scartare questo metodo e adottare qualcosa che si comporti meglio numericamente. Questa è l’essenza.

Questa è tipicamente una situazione in cui i dati sono perfettamente a posto, e dove i fornitori che propongono metodi altamente difettosi convinceranno i loro stessi clienti che devono correggere manualmente i loro cattivi dati, mentre in realtà i dati sono assolutamente corretti e il difetto risiede nella ricetta numerica stessa.

Conor Doherty: Beh, questa è in realtà un’opportunità perfetta per passare a… quindi c’erano alcuni… ok, due mi sono arrivati in privato. Mi dispiace, dammi un secondo, organizzo, e inquadro questa come una domanda.

Quindi, a proposito, da praticante: “Abbiamo già costruito un data lake e ovviamente abbiamo il nostro catalogo, eppure i nostri utenti, gli utenti finali, dicono che i dati sono sbagliati. A tuo parere, il collo di bottiglia è la tecnologia o la semantica? E come fa Joannes, o come fa Lokad, a evitare una rietichettatura infinita?”

Perché, ancora una volta, hai parlato molto della semantica e della sua importanza. Dipende da come costruisci il tuo data lake. Il tuo data lake è una copia perfetta one-to-one dei tuoi record nel sistema dei record? Nessun pre-processamento, nessun miglioramento, nessuna join, nessun filtro di alcun tipo. È letteralmente uno a uno. Possibilmente con un piccolo ritardo perché i dati potrebbero non essere copiati in tempo reale dall’ERP, ma mettendo da parte il ritardo per la copia, è esattamente una copia dei dati come esistono.

Joannes Vermorel: Quando la gente si lamenta di ciò, torniamo al secondo problema con i data scientist: “Oh, i dati non sono ordinati e puliti. Questo non è proprio come gli esperimenti su Kaggle. Siamo confusi.” Io dico: sfortunatamente, questo è il mondo in cui vivi. Vivi in un mondo dove l’informazione contenuta nei tuoi sistemi aziendali è molto complessa. Non c’è via di scampo. Non c’è alternativa.

Quindi potresti lamentarti di ciò, ma è come lamentarsi della gravità. È semplicemente un dato di fatto dell’universo. Devi convivere con esso.

Molto frequentemente, ciò che accade è che non si ha lo scenario ideale che ho descritto per il data lake, ovvero una semplice replica pura dei vari sistemi aziendali. E potresti chiederti: perché hai un data lake se è solo una copia? La risposta breve è perché non vuoi creare carico sul tuo sistema ERP, sul tuo sistema transazionale. Il tuo sistema transazionale deve rimanere estremamente reattivo.

Se hai persone che interrogano, “Voglio tutti gli ordini di vendita degli ultimi cinque anni, scaricatemi tutto,” rallenterà il sistema. Significa che qualcuno che sta cercando di far partire qualcosa dovrà aspettare diversi secondi perché le risorse saranno prosciugate a causa di questa massiccia query di estrazione dati. Ecco perché è una best practice creare una replica e lasciare che quelle query massicce vengano eseguite sulla replica, e non sull’istanza primaria del sistema dei record.

Tornando al punto originale: quello che osservo in molti data lake è che il team IT commette un errore molto grave. Rielaborano i dati originali. Vogliono migliorarli.

Qual è il trucco? Il trucco è: non generano le decisioni. Quindi, non conoscono la semantica. Così il tipo di trasformazione che applicano ai dati è destinato a essere fuorviante, errata, e di conseguenza finisci con dei dati che non sono ciò che ti aspetti, non sono ciò di cui hai bisogno, e non c’è soluzione.

Non importa quanto siano competenti, non importa quanto siano dedicati, manca loro lo strumento stesso, che è l’ingegnerizzazione inversa delle decisioni insensate. Per definizione, questo non è il ruolo dell’IT, generare quelle decisioni aziendali. Quindi, l’IT può occuparsi solo dell’infrastruttura: impostare i database, assicurarsi che le istanze siano sicure, garantire che le istanze abbiano abbastanza RAM, larghezza di banda del disco, infrastruttura – sì.

Ma se vuoi la semantica, l’IT non può occuparsene. La semantica è troppo specifica per ogni settore. Non ci si può aspettare che sia uno specialista in contabilità, marketing, Supply Chain Scientist, legale, e via dicendo. Ecco perché la semantica può essere nelle mani dei praticanti. Per definizione, sovraccaricherà l’IT se cerchi di farlo combattere per te in questa battaglia.

Conor Doherty: Beh, ancora una volta, ci sono due commenti precedenti che ho ricevuto, sia personalmente in chiamate che in riunioni, e sto scegliendo quale sarebbe il miglior seguito.

Costruirò sull’idea del conflitto tra IT e operazioni. Letteralmente, il commento era: “L’IT dice che i nostri dati sono terribili, eppure le mie operazioni, i praticanti che li usano, dicono che vanno bene,” perché, come hai sottolineato in precedenza, se stai prendendo decisioni e facendo soldi, per l’azienda va bene.

Quindi la domanda è: come fate voi – essendo noi – a valutare oggettivamente la qualità e a scegliere cosa necessita di essere corretto ora, più tardi o semplicemente lanciato?

Joannes Vermorel: Rendimento delle decisioni generate. Se hai dati che si suppone siano scadenti, ma le decisioni che generi risultano buone, sono davvero scadenti? Forse no. Forse sono completamente irrilevanti. Non ci interessa.

Se hai un pezzo di dato che è fondamentalmente irrilevante, il fatto che sia corretto o meno è irrilevante. Non ci interessa. Ecco perché, per noi in Lokad, valutiamo davvero la qualità dei dati in termini di dollari: qual è il ritorno dell’investimento nel migliorare—qualsiasi cosa significhi, e questo varia a seconda del caso—quel pezzo di dato?

Se migliorare questi dati significa guadagnare milioni di dollari all’anno grazie a decisioni migliori, incredibile. Questo dovrebbe essere una priorità. Probabilmente dovremmo investire. Se questi dati potrebbero essere anche peggiori e non fa differenza, allora non ci interessa.

Ecco perché dico: l’unico modo per valutare la qualità dei dati… ecco perché l’IT non può fare questa valutazione, perché essa è radicata nelle decisioni che la tua azienda genera in ultima analisi. Sono scadenti o no? Beh, dipende.

Per esempio, puoi avere un campo che, nell’aviazione, abbiamo innumerevoli campi, un campo che è incompleto per il 99% degli articoli, e molto frequentemente c’è una nota che dice qualcosa come, “Il numero C si trova in questo punto sul componente.” È un dato buono o cattivo?

La realtà è che per quasi la totalità dei pezzi di aerei, individuare il numero C è super ovvio. Non serve una nota che ti dica dove si trova il numero C. Lo prendi, è ovvio, lo leggi. Ma in alcuni rari casi è complicato e si trova in un posto un po’ difficile da raggiungere, spesso per ragioni meccaniche. In questo caso potresti avere una breve nota che ti dica dove guardare.

Se lo guardi dalla prospettiva IT, diresti, “Oh, sei così incoerente con le tue immissioni di dati. Guarda questo campo: è solo, tipo, lo 0,5% degli articoli in cui questo attributo viene impostato.” Ma la realtà è: sì, ma è per gli unici articoli in cui effettivamente conta.

Quindi, ancora una volta, dico: l’unico modo per valutare se i dati sono buoni o cattivi è metterli alla prova nel processo decisionale.

Conor Doherty: Beh, questo potrebbe, in effetti, rispondere al commento successivo. Ancora una volta, questo è molto, molto specifico, ma tocca un argomento che penso sia l’elefante nella stanza: oggi la gente vuole usare i propri dati per l’IA. Vogliono progetti di IA, ecc.

Quindi, questo viene da un amico del canale: “Gestiamo oltre 40 paesi. Usiamo diversi ERP e WMS per gestire l’inventario in 40 paesi. Quando sono sufficientemente buoni i nostri dati per iniziare l’IA e cosa fate effettivamente nei primi 90 giorni, suppongo il primo trimestre in sostanza?”

Joannes Vermorel: Se hai un paese in cui sai cosa stai acquistando, sai cosa stai producendo, sai cosa stai vendendo, per l’IA va bene. Ecco tutto. Per noi è sempre stato così. Quindi la soglia non è alta. Questa è la cosa interessante.

La soglia per poter robotizzare il processo decisionale—con qualcosa che chiami AI o meno, con l’etichetta che preferisci—è sufficiente. È questo che stiamo facendo. Per questo, molto frequentemente, la manutenzione dei parametri che governano tutti gli aspetti sottili del flusso di lavoro per permettere alle persone di svolgere il lavoro manualmente—quelle cose sono irrilevanti perché non le useremo.

Fondamentalmente, l’IA sfida completamente la divisione del lavoro. L’intero flusso di lavoro, dove hai previsori seguiti da pianificatori seguiti da responsabili di budget seguiti da responsabili dell’inventario seguiti da bla bla bla—sai, con un flusso di lavoro—non ha senso nell’era dell’IA.

L’IA elaborerà semplicemente, come un monolite, i dati grezzi provenienti dal sistema dei record, e produrrà direttamente le decisioni, con tutta l’instrumentazione di supporto per sostenerle. Quelli saranno i driver economici per spiegare perché è stata presa quella decisione. Perfetto.

Il tuo sistema IA—quello che io chiamo sistemi di intelligence—è fondamentalmente qualcosa come un monolite che prende i record in ingresso e genera decisioni in uscita con l’instrumentazione di supporto, e basta.

Quando la gente mi dice, “Abbiamo 40 ERP,” direi: non penso che qualcuno ne abbia 40. Sarebbe… Ho visto aziende… Ho visto un’azienda che aveva 17 ERP nello stesso paese. Quella è la recordman. Non nominerò questa azienda. È una realtà davvero, davvero grande. Stessa azienda, stesso paese. È qui che le cose erano veramente fuori di testa.

In sostanza: dovrai portare questo sforzo per riconfigurare la semantica ERP, ERP per ERP. Sarà un vero dolore. Ovviamente.

Ha chiesto per i primi 90 giorni. Tipicamente ci vogliono due mesi per stabilire la semantica. Questo è qualcosa che facciamo per un insieme di sistemi aziendali che operano, per esempio, in un paese. Ma i veri confini non sono necessariamente il paese. Sono molto più legati a quali sistemi IT dobbiamo includere nell’ambito: ERP, WMS, piattaforma e-commerce, e via dicendo.

Il nostro ambito è fortemente guidato dai confini dei sistemi IT, molto frequentemente proprio perché lo sforzo riguarda stabilire la semantica. Poi, una volta che abbiamo la semantica, la prima pipeline di dati, inizieremo a iterare sulle decisioni, e tipicamente ciò richiede circa due mesi.

Quindi: due mesi per stabilire la pipeline di dati, per avere una prima opinione informata sulla semantica di ogni campo. Ma poi occorrono altri due mesi di iterazioni extra per eliminare tutta l’insanità, molto frequentemente identificando la semantica che hai sbagliato nella prima iterazione.

Quindi in 90… tipicamente non sono 90 giorni; saranno, diciamo, 120 giorni. Puoi ottenere, senza alcuna follia, decisioni adatte alla produzione. Questa è un’iniziativa tipica di Lokad.

Ma il succo è: devi essere in grado di iterare molto rapidamente, tipicamente più volte al giorno, su quelle decisioni insensate, perché identificherai così tanti problemi con la semantica dei dati.

Conor Doherty: Beh, ancora una volta, e lo dico solo perché l’hai menzionato tu: fornisci l’esempio esplicito di come potremmo farlo. Un punto fondamentale qui è che quelle cose, cioè quella che stai descrivendo, l’implementazione, dovrebbe girare in parallelo con quello che chiamiamo un doppio run. Gira in parallelo con ciò che stai attualmente facendo, in modo che tu possa vedere con i tuoi occhi la differenza.

Joannes Vermorel: Sì. È qui che è assolutamente fondamentale avere qualcosa che sia completamente automatizzato. Perché? Perché se il tuo processo parallelo, il tuo doppio run, se il secondo richiede molta manodopera, da dove proviene questa manodopera?

L’azienda, supponiamo che abbia 15 pianificatori, sono tutti occupati al 100% del tempo. Se non fossero occupati quasi al 100%, l’azienda avrebbe solo 12 pianificatori o 10. Per definizione, le aziende non hanno dipendenti in più a meno di circostanze speciali. Di norma, per la maggior parte dei lavori, non ci sono dipendenti di riserva che non facciano nulla, solo lì come backup per testare il sistema extra.

Quelle persone impiegano già otto ore di lavoro solo per svolgere il loro compito quotidiano. Possono forse concedersi mezz’ora al giorno per dare una rapida occhiata a un altro sistema, solo per identificare gli outlier, le decisioni sbagliate, quelle assurde, ma non possono passare otto ore sul loro sistema e poi altre otto ore su un altro sistema in cui devono seguire lo stesso flusso di lavoro.

È per questo che dico che è assolutamente fondamentale che questo nuovo sistema decisionale debba essere completamente non sorvegliato; altrimenti, operativamente, non sarai in grado di implementarlo. Questo è qualcosa che Lokad ha appreso un decennio fa.

Conor Doherty: Va bene. Ancora una volta, ho esaurito la lista dei commenti che sono stati sollevati, o mi è stato esplicitamente chiesto, “Per favore, intervieni in diretta.”

In termini di chiusura su una nota costruttiva: abbiamo trattato molto. Cosa prevedi per la prossima settimana—oppure scegli un qualsiasi orizzonte temporale, ma non dire un anno—nei prossimi 30 giorni, per esempio, cambiamenti facili da implementare che le persone possano effettivamente realizzare, se non per migliorare la qualità, almeno per migliorare la percezione interna del potenziale dello stato attuale dei loro dati?

Joannes Vermorel: Non sono sicuro che ci sia qualcosa da fare a breve termine. Per me, si tratta veramente di comprendere cosa dovresti considerare come genuina fonte primaria di informazione rispetto ad un artefatto numerico. Non sono la stessa cosa.

Una volta effettuata questa segregazione e osservati freddamente i tuoi dati reali, cioè quelli guidati dagli eventi—i dati che rappresentano gli eventi veri che hanno un impatto finanziario per l’azienda—noterai molto probabilmente che questi dati sono eccellenti. Sì, saranno disordinati, ma sono eccellenti. Quindi, questo non è il problema.

Questo è il mio messaggio: dati scadenti nelle aziende che sono state digitalizzate per un decennio o più non sono mai il problema. Lokad ha eseguito oltre 100 implementazioni nell’ultimo decennio e mezzo.

A volte abbiamo avuto problemi con sistemi troppo lenti nell’estrazione dei dati. Talvolta questo rappresentava un problema. A proposito, ed è per questo che conviene aggiungere un data lake, perché a volte eseguivamo, tipo, “SELECT * FROM table X”, e il sistema in realtà lanciava un’eccezione per esaurimento della memoria quando lo facevamo.

Quindi, va bene, abbiamo incontrato situazioni in cui, a volte, estrarre i dati era estremamente complicato perché il sistema collassava nel tentativo di estrarli. Questa è una preoccupazione reale. Spero sinceramente che tu non ti trovi in una situazione simile, ma potrebbe succedere. Ecco perché conviene avere un data lake.

Ma, al di là di quei problemi puramente tecnici legati a infrastrutture ormai obsolete, non abbiamo mai avuto dati veramente scadenti. Quello che avevamo in abbondanza erano dati estremamente opachi, oscuri, ma fondamentalmente era qualcosa da risolvere dal lato di Lokad.

Quindi sì, è stato un grosso problema per noi, ma fondamentalmente non era un problema del cliente. Il cliente stava semplicemente utilizzando il proprio sistema come avrebbe dovuto. Il risultato era: per chi desidera implementare un sistema decisionale automatizzato su questa base, si tratta di una sfida. Ma ancora, la sfida risiede nella corretta interpretazione dei dati, non nel biasimare il cliente per aver raccolto tali dati in primo luogo.

Conor Doherty: Ancora, siamo in diretta da un’ora, quindi penso di essere giustificato con un piccolo commento in termini di marketing, ma è un punto fondamentale da trasmettere.

Una delle cose che ho imparato personalmente da molte delle conversazioni recenti è che non sempre è chiaro alle persone che, quando diciamo, “Ehi, guarda, i tuoi dati sono abbastanza buoni così come sono,” non si rendono conto che, se decidessi di lavorare con Lokad, o con un qualsiasi fornitore competente, questi si farebbe carico di quel peso.

Quindi: tu fornisci loro i dati, ci fornisci i dati. Non è che devi elaborare tutto tu. E loro dovrebbero… di nuovo, se il fornitore…

Joannes Vermorel: Se il fornitore non si assume questo onere, è una ricetta per trovare un capro espiatorio.

Conor Doherty: Esattamente.

Joannes Vermorel: Il fornitore si limiterà a incolparti, e finirai in una situazione in cui l’azienda spreca mezzo miliardo in sette anni. Alla fine, il rapporto concluderà che è tutta colpa di… e il fornitore dirà semplicemente: “No, qui non c’è niente di cui preoccuparsi. Non è colpa mia. Dai.”

A proposito, nel caso Lidl, è molto interessante, perché hanno incolpato il fatto che i dati fossero difettosi su un punto specifico. SAP ha detto, “Oh, Lidl, guidano la loro analisi sul prezzo d’acquisto, e noi conduciamo tutta la nostra analisi sul prezzo di vendita, ed è questa la causa.”

Per me, dico: ragazzi, questa è semantica 101. Innanzitutto, il problema è banale: è il prezzo di vendita o il prezzo d’acquisto? Sì, c’è una sfida semantica qui: di quale prezzo stiamo parlando? Ma chiariamo: non si tratta di una sottile distinzione. In termini di differenza semantica, è una questione molto, molto facile da risolvere.

La cosa ancora più sconcertante è che, a mio avviso, sono necessari entrambi. Ti serve sia il prezzo d’acquisto che il prezzo di vendita così da poter calcolare il margine.

Quindi l’idea che il fornitore possa, dopo sette anni, riuscire a incolpare il cliente dicendo, “Oh, sai che fanno tutta la loro supply chain intorno al prezzo d’acquisto, ed è una tale complicazione per noi perché noi ci aspettiamo il prezzo di vendita,” è esattamente il genere di marachelle che si verificano se il fornitore non è impegnato a fornire decisioni economicamente performanti.

Questo dovrebbe essere il punto di partenza; altrimenti, nel settore della supply chain, otterrai molte assurdità. Alla fine della giornata, dopo aver speso tanti soldi, il fornitore riuscirà a scaricare la colpa su di te trovando dei dati scadenti.

Ancora: se non accettiamo il fatto che solo le decisioni contano, ci sono così tanti dati che risultano completamente irrilevanti. Ovviamente, quei dati irrilevanti saranno di qualità molto bassa, ed è del tutto accettabile.

Un ERP ha 10.000 tabelle. Ogni tabella contiene decine di campi. Tutti questi dati dovrebbero essere ordinati e perfetti? È follia. Perché mai lo vorresti? Sarebbe troppo costoso.

Quindi, se giochi questo gioco dei dati scadenti con il fornitore, quest’ultimo sarà sempre il vincitore, perché ci saranno sempre molte tabelle e molti campi che, oggettivamente, sono scadenti e irrilevanti. Questa è la chiave: irrilevanti.

Conor Doherty: Va bene. Quindi, in conclusione: scegli il tuo fornitore con cura, se vuoi evitarlo.

Joannes Vermorel: Sì. E cerca di capire veramente: quando parli della qualità dell’ERP, qual è l’intento? Qual è l’intento? Non esiste una purezza dell’ERP in un senso morale per un’azienda. Serve a uno scopo.

La qualità è l’idoneità allo scopo, e basta.

Conor Doherty: Esatto. Grazie mille. Non ho più domande. Siamo in diretta da un’ora, quindi penso di aver esaurito il tempo.

Come sempre, grazie per il vostro contributo, e grazie a tutti per aver partecipato e per i vostri messaggi privati. Come ho detto dall’inizio, e da dove è nato questo argomento, se volete proseguire la conversazione, contattate personalmente Joannes e me. Siamo sempre felici di parlare.

Come ho detto la scorsa settimana, e lo ripeterò ogni settimana, siamo persone adorabili. Guardaci. Detto ciò, ci vediamo la prossima settimana. Ho un argomento speciale per la prossima settimana, quindi lo annunceremo lunedì. Ma per ora, torna al lavoro.