La data science ha fallito

Riepilogo

Una sessione mirata su perché la data science aziendale ha spesso sottoperformato nelle supply chains e su come risolvere il problema rapidamente. Esploreremo il vero scopo dei team di data science, come utilizzarli efficacemente e come potenziare il loro impatto a partire da oggi.

Trascrizione completa

Conor Doherty: Questa è Supply Chain Breakdown, e oggi analizzeremo perché crediamo che la data science aziendale abbia fallito.

Un ulteriore punto di vista non controverso qui su Lokad. Mi chiamo Conor; sono il Direttore della Comunicazione qui a Lokad.

E alla mia sinistra, come sempre, il fondatore di Lokad, Joannes Vermorel. Ora, prima di iniziare la discussione, commentate qui sotto: siete immediatamente in disaccordo con la nostra opinione? La data science aziendale, in generale, ha fallito?

Scopriremo la risposta nel corso della discussione. Inviate le vostre domande e commenti. Oggi Alexey gestisce la chat in diretta—date un saluto ad Alexey.

E con questo, Joannes, andiamo direttamente al punto. Quindi, innanzitutto: la data science aziendale—scusami—ha fallito. Questa è un’affermazione provocatoria. È molto in linea con il nostro stile, ma è un’esagerazione?

Joannes Vermorel: Dal mio punto di vista, non lo è. Ho avuto l’opportunità di parlare con, credo, circa 200 aziende—per quanto riguarda le loro supply chain e l’approccio ai dati—e finora direi che quasi nessuna di esse ha ottenuto un successo clamoroso con la data science.

Più specificamente, parlo di aziende non tecnologiche—tralasciando le grandi aziende tecnologiche come Microsoft, Amazon, ecc. Intendo aziende non tecnologiche che gestiscono supply chains di notevoli dimensioni. E quando dico “la data science ha fallito”, intendo il team aziendale che opera sotto il nome di team di data science.

Questo team ha prodotto qualcosa che contribuisce realmente alla redditività dell’azienda? Un banco di prova è: se queste aziende dovessero eliminare questo team da un giorno all’altro, la loro redditività ne sarebbe sostanzialmente compromessa—al limite, arriverebbero addirittura al fallimento?

Se la data science stesse davvero apportando un valore significativo, allora eliminare il team dovrebbe gravemente danneggiare l’azienda. Secondo me, per letteralmente tutte le aziende che ho visto, potremmo rimuovere il team di data science e ciò costituirebbe a malapena un disagio.

Conor Doherty: Ok, ma definisci il problema come lo vedi tu. Come immagini una divisione di data science? Qual è il mandato—il campo d’azione—che secondo te non riescono a portare a termine?

Joannes Vermorel: Questo è il problema: la data science è un mezzo, non un fine. Se consideriamo un’analogia—alla fine del XIX secolo—questa grande novità, l’elettricità. L’elettricità è fantastica; puoi fare così tante cose con essa. È un’invenzione che definirà il secolo successivo.

Ora immagina un’azienda che crea un “dipartimento di elettricità.” Puoi vedere che introdurre un dipartimento di elettricità è sbagliato—non perché l’elettricità sia cattiva, ma perché il dipartimento di elettricità in sé è sbagliato. Questo è il mio punto riguardo la data science.

Non sto dicendo che la data science, come sottocampo dell’informatica, abbia fallito. Stanno accadendo cose incredibili con i modelli, le tecniche e le prospettive per affrontare i dati—questo è un razzo, e la GenAI è solo l’ultima iterazione di questo razzo.

Tuttavia, se introduci una divisione di data science, finisci per avere lo stesso tipo di assurdità di un dipartimento di elettricità nella tua azienda. Questo è un mezzo, non un fine. Non vuoi l’elettricità per l’elettricità; vuoi ciò che puoi fare con essa—e sarà estremamente diffusa.

Avrà un significato completamente diverso per le fabbriche rispetto alla finanza. Le persone in fabbrica direbbero, “L’elettricità è fantastica; possiamo avere motori che muovono cose pesanti.” La finanza direbbe, “Se abbiamo una macchina computer molto sofisticata—tipo IBM—forse possiamo fare i conti per noi.” È di nuovo elettricità, ma completamente diversa.

Lo stesso vale per la data science. La data science aziendale fallisce perché se la isoli in una divisione a parte, finisci con qualcosa che non riesce mai a fornire qualcosa di veramente d’impatto—perché non gli viene mai dato il mandato per farlo. Non sono all’interno di una divisione che ha già una missione.

Non fanno parte della finanza; non fanno parte del marketing. E i casi in cui funziona sono quelli in cui le persone operano all’interno di un dipartimento esistente con un mandato chiaro.

Conor Doherty: Ci sono due modi per inquadrare la questione: negativo e positivo. Iniziamo con ciò che è sbagliato, in particolare. Come vedi attualmente l’impiego dei team di data science—e perché è sbagliato?

Joannes Vermorel: L’archetipo è questo: il top management vede sui media che la data science è una cosa. La gente si entusiasma: “Portatemi dell’IA!” Il consiglio si riunisce e dice, “Non possiamo perderci quest’opportunità. Abbiamo bisogno di questa cosa.”

Assumono un sacco di persone molto intelligenti e con attitudine tecnica, e quelle persone dicono, “Guardate tutti quei progetti open‑source scintillanti: pandas, PyTorch—you name it.” Ci sono tutti quei giocattoli scintillanti. Portiamo questi progetti open‑source; sono di incredibile alta qualità e aggiungono sofisticazione.

Quegli strumenti sono stati fondamentali nel permettere alle grandi aziende tecnologiche di ottenere successi clamorosi. Quindi la gente dice, “Abbiamo tutti gli ingredienti: progetti open‑source incredibili e persone intelligenti—imiteremo le grandi aziende tecnologiche.” La conseguenza: non funziona.

La gente costruisce cose. Il modello tipico è un prototipo estremamente sofisticato e promettente—in solo un paio di settimane. Tre settimane dopo: bam, un prototipo molto sofisticato, impressionante. Un anno dopo, non è ancora in produzione. Cinque anni dopo, non c’è ancora nulla di grado industriale proveniente da questo dipartimento—e certamente nulla che rivoluzioni il settore.

Sì, qua e là ci saranno cose minori guidate dai dati, ma in francese si direbbe che è la ruota di scorta della macchina: qualcosa di non essenziale.

Conor Doherty: Hai menzionato “produzione”, e vorrei tornare al limbo dei progetti pilota. Ma hai anche parlato di scopo, obiettivo, direzione, funzione—parole che si avvicinano alla teleologia. Quindi, ancora, qual è a tuo avviso lo scopo di un team di data science—perché esiste, se esiste?

Joannes Vermorel: Questo è il problema: esiste per lo stesso scopo per cui esisterebbe un “dipartimento di elettricità” nella tua azienda. Inquadralo in questo modo e puoi capire il problema: suona male perché è un mezzo, non un fine—anche se sei un fornitore di elettricità.

Anche EDF, un fornitore nazionale di elettricità in Francia, non ha un “dipartimento di elettricità.” L’intero business è l’elettricità. Devi pensare a cosa vuoi ottenere. Ad esempio, se il marketing dice, “Vogliamo ottimizzare la spesa per Google Ads,” allora esegui l’ottimizzazione della spesa per Google Ads.

Non “fanno data science”; fanno quell’ottimizzazione. Si scopre che sono coinvolti molti dati. Non appena adotti una prospettiva operativa, non si chiama più data science. È per questo che dico che la data science aziendale ha fallito: ogni volta che vedo un team ancora chiamato “data science”, riflette persone che sono disorientate. Non hanno uno scopo—e di solito non c’è nulla di significativo in produzione.

Hanno qualche gadget qua e là, ma se sono in attività da un decennio e guardiamo oltre le grandi aziende tecnologiche, non ho mai visto quei team avere il destino dell’azienda nelle loro mani. Al meglio, è estremamente secondario.

Conor Doherty: Hai verificato aziende tecnologiche e operato in aziende più piccole—non FAANG. Presumibilmente hai visto team di data science di successo. Cosa distingue quelli buoni dal fallimento complessivo della data science aziendale?

Joannes Vermorel: Ho verificato oltre 100 startup. È completamente diverso quando verifico un’azienda che si occupa di rilevamento delle frodi.

Ovvio, questo è l’obiettivo: il rilevamento delle frodi. Poi segmentano i tipi di frode; potrebbero avere un team che si occupa di truffe di tipo pig‑butchering, con euristiche specifiche e algoritmi per rilevarle, affrontarle e segnalarle efficacemente alle autorità competenti.

La data science in quelle aziende tecnologiche funziona perché è letteralmente la loro raison d’être. Partono da un problema che vogliono risolvere—ad esempio, il rilevamento delle frodi o l’individuazione di anomalie in ingegneria meccanica. Per affrontare il problema, a un certo punto si ricorre a strumenti sofisticati.

Non iniziano dicendo, “Abbiamo questo interessante pacchetto open‑source; dovremmo usarlo.” Partono da un grande problema poco affrontato. Vedono che le soluzioni semplici falliscono, e dopo averlo verificato, tirano fuori le bombe per risolverlo.

Spesso, si rendono conto che il problema non è risolto perché tutto ciò che è disponibile è inadeguato. Open source è fantastico, ma inadeguato per il loro problema specifico. Così sviluppano la propria soluzione tecnologica e, come sottoprodotto, componenti open‑source che sono sottosegmenti della loro soluzione.

Esattamente come fanno le grandi aziende tecnologiche con i grandi problemi—poi decidono di rendere open‑source parti della loro soluzione. Per esempio, Airflow—di Facebook—è un sistema di pianificazione distribuita di attività su larga scala con dipendenze; l’hanno sviluppato internamente, e a un certo punto era solo un pezzo di una soluzione più grande che hanno reso open‑source.

Tipicamente, questo è il percorso per quelle tecnologie. Ciò che è sbagliato è pensare che si possano semplicemente prendere quelle componenti e riutilizzarle in una grande azienda, anche se il vostro percorso è completamente diverso. Queste componenti tecnologiche sono eccellenti ma provengono da percorsi specifici.

La maggior parte delle volte non saranno appropriate per una grande corporazione che ha problemi completamente diversi per natura rispetto alle aziende tecnologiche come Meta. La stragrande maggioranza delle aziende sulla Terra non ha nulla a che fare con i problemi di Meta.

Conor Doherty: Chiunque conosca i contenuti di Lokad sa che spesso sei in disaccordo su come il budget venga speso nelle corporazioni. C’è qualcosa di unicamente pernicioso—unicamente negativo—nel modo in cui i soldi vengono spesi per la data science, oltre il semplice spreco?

Joannes Vermorel: No—ancora, mancanza di conseguenze. A causa dello stereotipo dei team di data science estremamente isolati, quasi non ci sono conseguenze secondarie. Non inquinano il resto dell’azienda; il danno è largamente limitato ai soldi sprecati per il team.

Sono così isolati che non consumano nemmeno molta attenzione dal top management; forse una o due riunioni all’anno. La buona notizia è che è un problema contenuto: una spesa sprecona che non va oltre.

Conor Doherty: Sono così isolati—cosa intendi?

Joannes Vermorel: Potresti immaginare altri fenomeni—tendenze di virtue‑signaling—che tengono tutti occupati, esaurendo la capacità mentale del team esecutivo. Questo è molto dannoso. La data science non è così. È super isolata e non rappresenta un carico cognitivo per il top management.

Per me, questa è una lunga tradizione; si ripete con i cambi di buzzword. Venticinque anni fa, la parola chiave era “data mining.” Le aziende creavano team di data mining. Poi team di “digitalizzazione”, team di “innovazione”, ora team di “data science”—e presto, team di “generative AI”.

Se hai un team aziendale chiamato come un mezzo—come “elettricità”—invece che come un fine—come “rilevamento delle frodi”—questo è sbagliato. Non dovresti avere un team chiamato come un mezzo; dovrebbe essere chiamato in base al fine.

Il nome ha importanza: definisce come le persone affrontano il loro lavoro, il tipo di persone che assumi, e come elaborano la loro roadmap. Se hai un team di “data science”, loro elaboreranno—indovina un po’—una roadmap di data science. Se dici “team di rilevamento delle frodi”, la roadmap diventa, “Come eliminiamo quelle frodi?”

Da Lokad, abbiamo effettivamente smesso di assumere “data scientists” un decennio fa. Ora assumiamo “supply chain scientists.” Può sembrare un piccolo cambiamento, ma al momento dell’assunzione stiamo letteralmente dicendo ai candidati: se vi unite a noi, la vostra missione sarà far funzionare le supply chains dei nostri clienti nel modo più fluido possibile.

Vi daremo i migliori strumenti e formazione; non sarete lasciati soli. Ma alla fine, se riuscite a farlo con aritmetica di base e qualche euristica—ottimo. Non siamo qui per pubblicare articoli su algoritmi sofisticati. Se un’euristica incredibilmente semplice risolve il problema, ottimo; la manutenzione diventa più semplice.

Al contrario, quando assumevamo “data scientists”, la gente obiettava: “Non possiamo risolvere questo con un metodo super‑semplice—non è all’avanguardia. Ho bisogno di deep learning per il mio curriculum.” Per noi: no, non lo serve. Se qualcosa di infinitamente più semplice del deep learning lo risolve, non ti serve il deep learning.

Conor Doherty: Prima di continuare, stiamo assumendo supply chain scientists. Se siete interessati, inviate il vostro CV al nostro responsabile del reclutamento.

Per dare un po’ di contesto: fonti come Gartner riportano che solo il 48% delle iniziative digitali raggiunge o supera gli obiettivi di business, e svariati sondaggi mostrano che i progetti AI/ML rimangono bloccati in fase pre‑produzione. C’è chiaramente un “limbo dei progetti pilota.” Non si tratta di un problema univariato—ma in quel problema multivariato, quanta importanza dai alle divisioni di data science in questo fenomeno?

Joannes Vermorel: È travolgente. Di solito, quando si avvia un’iniziativa digitale che mira alla digitalizzazione—a implementare un sistema di registrazione—funziona. Ad esempio, le spese gestite tramite fogli di calcolo ed email: si installa un sistema di gestione delle spese. Sei mesi dopo, l’app e le pratiche sono in atto, e funziona.

I sistemi di registrazione sono iniziative a rischio quasi zero—anche se talvolta i fornitori sono estremamente scadenti. Al contrario, nel campo dei sistemi di intelligence, la quasi totalità fallisce. Se proviene da un team di data science, la mia esperienza è che fallisce sempre.

Da Lokad, abbiamo avuto anche clienti con configurazioni affiancate: Lokad genera decisioni per la supply chain e il team interno di data science, che lo faceva da mezzo decennio prima di noi—ancora presente, generando cose non utilizzate, semplicemente ignorate. La complessità aziendale li mantiene in essere.

La data science è estremamente utile—come l’elettricità. È uno strumento versatile ovunque ci siano dati—e al giorno d’oggi questo è ovunque. È degno di interesse? Assolutamente. Ma non giustifica un team a sé. Deve essere presente in ogni team dove esistono dati: marketing, finanza, produzione, acquisti, pianificazione, ecc.

Conor Doherty: Sii costruttivo. Basandoti su quanto detto, stai suggerendo che ogni membro del team si specializzi in data science; oppure che ogni team debba avere un membro di data science; oppure che un team centrale presti membri su base ticket? Quale mondo stai consigliando?

Joannes Vermorel: Per ogni funzione in azienda, c’è un potenziale nell’utilizzo dei dati per migliorare e velocizzare ciò che la funzione fa—in modo migliore e più rapido. Prendi un esempio più semplice rispetto a supply chain: la spesa in Google Ads per il marketing.

Google Ads sono complessi: puoi fare offerte diverse per migliaia di parole chiave; monitorare le prestazioni, il costo per clic, il costo per risultato. È abbastanza tecnico. Puoi sviluppare questa competenza internamente con veri esperti, oppure esternalizzarla completamente a un’agenzia che gestisca l’ottimizzazione.

Entrambi gli approcci sono validi purché esista una competenza autentica da qualche parte—internamente o esternamente. Hai bisogno di persone con una vera affinità per tutto ciò che rientra nell’ambito del data science. Non puoi eludere una comprensione profonda—ma questa va vista attraverso la lente della funzione che stai ottimizzando.

Conor Doherty: Una domanda che ho ricevuto privatamente—facendo da avvocato del diavolo a Joannes: non è troppo severo definire “failure” se le analisi informano ancora riunioni e report? Se il management si sente meglio informato, ciò non aggiunge valore?

Joannes Vermorel: Questo è esattamente il tipo di situazione in cui il data science è isolato e non comporta conseguenze negative—tranne che qui è peggio: stai distraendo i dirigenti con report che fanno sentire bene. Se quello che ti serve sono statistiche descrittive per il top management, quello è il ruolo della BI.

Hai già un team di Business Intelligence; non è necessario raddoppiare il budget per il data science. A proposito, anche le divisioni BI hanno i loro problemi. Il marketing dovrebbe avere la responsabilità di creare i propri indicatori; non dovrebbe esternalizzare questo compito al data science.

Se l’unico risultato sono metriche che fanno stare bene il management—nel migliore dei casi, è ridondante rispetto alla BI. Uniscilo nuovamente alla BI; non serve una divisione separata. Il mio criterio è severo: l’azienda verrebbe misurabilmente danneggiata, finanziariamente, se il team di data science scomparisse?

Migliorare il morale del management è positivo, ma io mi preoccupo del conto economico—quanti dollari in più portiamo all’azienda. Produrre migliaia o milioni di numeri al giorno è estremamente facile e divertente; produrre dieci numeri al giorno che vale davvero la pena leggere è estremamente difficile.

Stai producendo quei dieci numeri? Dalla mia esperienza: no. Producono muri di metriche, sì—ma non quelle di grande valore che, se eliminate, danneggerebbero l’azienda.

Conor Doherty: Molte di queste metriche vengono dall’alto. Il marketing è un dipartimento; le vendite sono un dipartimento. Non sono responsabili degli indicatori che vengono loro imposti. E se hai già la BI che produce statistiche descrittive…

Joannes Vermorel: Esattamente—nel migliore dei casi è ridondante. Uniscilo alla BI; non serve una divisione separata.

Conor Doherty: Un’altra domanda da un messaggio privato: “Non posso semplicemente licenziare il mio team di data science. Come posso migliorare le cose fin dal primo giorno?” Realisticamente, cosa si può fare?

Joannes Vermorel: L’ho fatto per alcuni operatori di e‑commerce piuttosto grandi. Ho suggerito di dividere il team e ridistribuirlo in altre divisioni. Se hai mezza dozzina di persone: metti due in finanza, due in marketing, due nella pianificazione. Dì a quei manager che ora sono responsabili di queste persone competenti e del loro utilizzo produttivo.

Se gestisci questa unità e vuoi essere un eroe, convince il top management a dividere e disperdere la competenza tra le divisioni. L’approccio migliore che ho visto—ma funziona solo per aziende molto grandi—è trasformare il team centrale in coach e mentori per il data science all’interno di ogni dipartimento.

Dimentica la consegna di un prototipo funzionante per il marketing; voi cinque farete da coach per il marketing affinché possano realizzare cose interessanti con i dati; fai lo stesso per le vendite. Questo funziona in aziende da €5B in su—grandi a sufficienza da supportare un team dedicato esclusivamente all’evangelizzazione. Dovrebbe essere transitorio—12, 18, 24 mesi, non più di due anni—e poi dissolversi.

Altrimenti, finisci con una burocrazia semi-nascosta che spreca denaro.

Conor Doherty: Domande dalla chat. Da Neil Knight: Pensi che i data scientists vengano ignorati perché sono interni—o perché non sono utili? Ho notato che i consulenti vengono spesso ascoltati perché possono giungere alle stesse conclusioni del management (McKinsey, Bain, Accenture, ecc.). Quali sono le tue opinioni?

Joannes Vermorel: Esiste un proverbio francese: nessuno è profeta in patria. Essere un outsider aiuta, ma a credito dei consulenti, non è solo questo. Una cosa in cui hanno ragione è concentrarsi con fermezza su problemi autentici e importanti.

Possiamo non essere d’accordo sulle competenze tecniche per la risoluzione, ma quando si tratta di concentrarsi su ciò che è veramente importante per il top management, loro sono bravi. È proprio quello che il data science non sta facendo. Poiché sono isolati, non riescono ad affrontare problemi con un grande ritorno economico—quelli richiedono trasformazioni importanti.

Ho visto team di data science scegliere progetti “preferiti” che sono irrilevanti. Facciamo un calcolo sommario e concordiamo che c’è un problema venti volte più grande proprio accanto. Dicono, “Sì, ma quel problema è delicato; avremmo bisogno di approvazioni a più livelli; potremmo creare attriti.”

E qui è dove vincono i bravi consulenti: si concentrano su ciò che conta, non sui progetti preferiti che temiamo di toccare. Anche se quello che fanno è crude, si concentrano su cose molto reali. Il data science, essendo ai margini—non facente parte del marketing, della finanza, ecc.—non ottiene mai l’autorità per trasformare l’azienda sfruttando i dati.

Prendi il rilevamento delle frodi: quando ne rilevi una, hai bisogno dell’autorità per dire, “Non serviremo questo cliente; rifiuta immediatamente il pagamento.” Ci saranno falsi positivi—clienti onesti danneggiati. La questione è l’equilibrio tra falsi positivi e veri positivi.

Se dici al team di data science, “Finché ci sarà anche un solo falso positivo all’anno, non possiamo mettere questo in produzione,” non lo metteranno mai in produzione. Si tratta di un compromesso. Hai bisogno dell’autorità per dire, “Nel complesso va molto bene; i lati negativi sono sotto controllo,” e poi affinare i metodi.

Conor Doherty: Grazie, Joannes. Passando a Amarinder: qual è la tua opinione sul ruolo del product manager o del product scientist? È questo un mezzo migliore per fornire il valore finale di cui parli?

Joannes Vermorel: I product manager operano nettamente nell’ambito dei systems of record. Il product management è fondamentale lì perché il cielo è il limite in termini di funzionalità; hai bisogno di una roadmap, di una gestione delle priorità e di saper dire “no” per evitare un’app mostruosa.

Per i systems of intelligence—processi decisionali automatizzati come il rilevamento dello spam—ci sono falsi positivi/falsi negativi da migliorare. Non puoi migliorare questo semplicemente discutendo con gli utenti o arbitrando le funzionalità. Un altro esempio è il ranking dei motori di ricerca—come si migliora la pagina dei risultati di Google? Molto difficile; non si tratta di funzionalità.

Il product management è importante, ma appartiene ai systems of record. Il data science che ha un impatto reale deve riguardare le decisioni—quindi i systems of intelligence. Il product management o i “management scientists” hanno un ruolo da svolgere, ma è minore e dal lato dei systems of record.

Conor Doherty: Anticipazione per la prossima settimana: dedicheremo l’episodio ai systems of record, ai systems of reports e ai systems of intelligence. Tenete d’occhio il promo e partecipate.

Pensiero conclusivo, Joannes. Un invito all’azione per coloro che sono d’accordo con te: qual è il mio primo passo dal giorno uno—cosa devo fare ora per apportare un cambiamento?

Joannes Vermorel: Fondamentalmente: c’è molto che puoi fare con i tuoi dati. La stragrande maggioranza delle aziende sfrutta poco i propri dati. L’intuizione alla base del data science nasce da un ottimo presupposto: hai così tanti dati non sfruttati per migliorare l’azienda.

Da Lokad si occupa di predictive optimization delle supply chains—è questo che facciamo—ma ci sono molte altre cose. Un altro ambito interessante è la “simpatia meccanica”: persone che abbracciano la tecnicità, così non si tratta solo di ipotesi educate—persone con una reale affinità per la sfida.

Ciò che non va è prendere tutto ciò e dire, “Ho bisogno di creare una divisione.” È sbagliato—un anti-pattern; un modo pigro di affrontare il problema. Pensa alla “divisione elettricità.” L’elettricità sarebbe stata estremamente importante per tutte le divisioni—lo stesso vale per il data science.

Come leader, sfida ogni singola divisione a sfruttare al massimo i dati esistenti in azienda per la loro funzione. Ogni responsabile di divisione deve essere incaricato di ottenere il massimo per la propria funzione. Questo richiederà competenze in stile data science—interne, esterne, con o senza consulenti.

È un messaggio più difficile perché i leader saranno messi alla prova su qualcosa di scomodo. Pensa all’elettricità e alle fabbriche: con le lampadine puoi operare di notte. Cambia tutto. Lo farai? Tante domande—ma devi trovare le risposte all’interno della funzione.

Coinvolgi le persone, ma non puoi sfuggire al fatto che la tecnologia trasforma ciò che fai in modi così profondi che non puoi realisticamente esternalizzare il problema a un’altra divisione e dichiararlo risolto.

Conor Doherty: Scelta finale, Joannes: possiamo fermarci qui, oppure rispondere a una domanda di qualcuno che so essere un fan di lunga data. Andiamo. Joshua chiede: dalla tua esperienza nel gestire “supply chain as a service,” se la maggior parte dei clienti ha ancora ERPs, fogli di calcolo e politiche che gestiscono silenziosamente le operazioni quotidiane, quanto realmente sposta Lokad il focus decisionale? Cosa serve affinché il livello analitico diventi il decisore anziché essere solo un consulente in più?

Joannes Vermorel: Da Lokad restiamo fermi nel fornire decisioni automatiche. Abbiamo numerical recipes che generano decisioni in maniera autonoma. Finché è necessario modificare i numeri, continuiamo a iterare sulla ricetta in modo da non dover intervenire; poi facciamo manutenzione per fare in modo che continui a funzionare in autonomia.

Ci vogliono mesi di esecuzione parallela, specialmente per le grandi aziende, per guadagnarsi la fiducia—decisioni a livello di produzione giorno dopo giorno. In una grande azienda, ci vorranno mesi. Col passare del tempo, tutti iniziano a rendersi conto che ora abbiamo domande molto più interessanti da porre: ad esempio, cos’è la qualità del servizio?

Se mi dici che la qualità del servizio è il “service level,” io non sono d’accordo—non è service level. Per il DoD, sarebbe la “operational readiness.” Per un dato budget, quale spettro di operazioni è fattibile e quale no? Queste sono domande difficili.

Quando implementiamo questo approccio, le persone hanno il tempo di riflettere più a fondo su queste questioni. L’analisi dei dati porta molti elementi alla discussione: intere nuove classi di domande possono trovare risposte nei dati.

A differenza di un team di data science che cerca di trovare risposte da solo, qui tutto è guidato dall’operatività: “Vogliamo fare questo; abbiamo un collo di bottiglia.” Guarda i dati; analizza il collo di bottiglia; ottieni una migliore allocazione; poi il collo successivo. Se isoli il data science, ottieni una soluzione alla ricerca di un problema.

Le persone elaborano una soluzione e poi cercano un problema che ci si adatti approssimativamente. Con una funzione operativa—ad esempio, allocare fondi per parti di aeromobili—hai una sfida concreta. Iteri per ottenere soluzioni migliori per un problema reale.

Conor Doherty: Un seguito da parte di Joshua: quando quel cambiamento avviene secondo la tua prospettiva, quanta modifica nelle politiche è tipicamente necessaria affinché un cliente si impegni? Di solito si tratta di una piccola modifica, o di un ripensamento fondamentale su come vengono governate le decisioni in ambito supply chain?

Joannes Vermorel: È quest’ultimo, ma non devi fare tutto in un solo giorno. Per alcune industrie abbiamo persino testimonianze—trasformazioni iniziate un decennio fa e ancora in corso.

Per organizzazioni complesse—la manutenzione dei jet è estremamente complessa—ci vuole tempo. Con Air France Industries, la trasformazione è massiccia in un decennio. Abbiamo affrontato gli ambiti decisionali uno alla volta; penso che ce ne siano oltre venti diversi lì.

Tipicamente, ogni ambito ha richiesto un paio di mesi per essere implementato e raggiungere il livello di produzione. Questo è di dominio pubblico—studi di caso e interviste con i direttori.

Conor Doherty: Spero che sia stato utile. Siamo un po’ fuori tempo, ma è stato positivo rispondere a tutte le domande. Grazie, Joannes, per il tuo tempo—e a tutti gli altri, grazie per la partecipazione e per le vostre domande.

Alcune persone preferiscono inviare messaggi privati; mi contattano in diretta e, come vedi, li porrò a Joannes esattamente con le parole che mi sono state fornite. Se hai domande, mandaci un DM o pubblica nei commenti.

Rimarremo per rispondere. Buona serata. Ci vediamo la prossima settimana per il prossimo episodio. E… torna al lavoro.