The Supply Chain Scientist - Lezione 7.3

00:00 Introduzione
02:52 Contesto e avvertenza
07:39 Razionalismo ingenuo
13:14 La storia finora
16:37 Scienziati, abbiamo bisogno di voi!
18:25 Uomo + Macchina (il problema 1/4)
23:16 L’allestimento (il problema 2/4)
26:44 La manutenzione (il problema 3/4)
30:02 Il backlog IT (il problema 4/4)
32:56 La missione (il lavoro dello scienziato 1/6)
35:58 Terminologia (il lavoro dello scienziato 2/6)
37:54 Prodotti consegnabili (il lavoro dello scienziato 3/6)
41:11 L’ambito (il lavoro dello scienziato 4/6)
44:59 Routine quotidiana (il lavoro dello scienziato 5/6)
46:58 Proprietà (il lavoro dello scienziato 6/6)
49:25 Una posizione nella catena di approvvigionamento (HR 1/6)
51:13 Assumere uno scienziato (HR 2/6)
53:58 Formare lo scienziato (HR 3/6)
55:43 Valutare lo scienziato (HR 4/6)
57:24 Trattenere lo scienziato (HR 5/6)
59:37 Da uno scienziato all’altro (HR 6/6)
01:01:17 Sull’IT (dinamiche aziendali 1/3)
01:03:50 Sulle Finanze (dinamiche aziendali 2/3)
01:05:42 Sulla Leadership (dinamiche aziendali 3/3)
01:09:18 Pianificazione vecchia scuola (modernizzazione 1/5)
01:11:56 Fine del S&OP (modernizzazione 2/5)
01:13:31 Business Intelligence vecchia scuola (modernizzazione 3/5)
01:15:24 Fine della Scienza dei Dati (modernizzazione 4/5)
01:17:28 Un nuovo accordo per l’IT (modernizzazione 5/5)
01:19:28 Conclusioni
01:22:05 7.3 The Supply Chain Scientist - Domande?

Descrizione

Al centro di un’iniziativa di Catena di Approvvigionamento Quantitativa, c’è il Supply Chain Scientist (SCS) che esegue la preparazione dei dati, la modellazione economica e la segnalazione dei KPI. L’automazione intelligente delle decisioni della catena di approvvigionamento è il prodotto finale del lavoro svolto dal SCS. Il SCS si appropria delle decisioni generate. Il SCS offre intelligenza umana amplificata attraverso la potenza di elaborazione delle macchine.

Trascrizione completa

Benvenuti a questa serie di lezioni sulla catena di approvvigionamento. Sono Joannes Vermorel e oggi presenterò il Supply Chain Scientist dal punto di vista della catena di approvvigionamento quantificata. Il Supply Chain Scientist è la persona o eventualmente il piccolo gruppo di persone responsabile di guidare l’iniziativa della catena di approvvigionamento. Questa persona supervisiona la creazione e successiva manutenzione delle ricette numeriche che generano le decisioni di interesse. Questa persona è anche responsabile di fornire tutte le prove necessarie al resto dell’azienda, dimostrando che le decisioni generate sono valide.

Il motto della catena di approvvigionamento quantificata è sfruttare al massimo ciò che l’hardware e il software moderni possono offrire alle catene di approvvigionamento. Tuttavia, il sapore incarnato di questa prospettiva è ingenuo. L’intelligenza umana è ancora una pietra angolare dell’intero progetto e, per una serie di motivi, non può ancora essere confezionata in modo adeguato per quanto riguarda una catena di approvvigionamento. L’obiettivo di questa lezione è capire perché e come il ruolo del Supply Chain Scientist sia diventato, nell’ultimo decennio, una soluzione collaudata per sfruttare al massimo il software moderno per scopi di catena di approvvigionamento.

Per raggiungere questo obiettivo, è necessario comprendere i grandi ostacoli che il software moderno sta ancora affrontando nel tentativo di automatizzare le decisioni della catena di approvvigionamento. Sulla base di questa nuova comprensione, introdurremo il ruolo del Supply Chain Scientist, che è, per tutti gli effetti, una risposta a questi ostacoli. Infine, vedremo come questo ruolo modifica, in piccoli e grandi modi, l’azienda nel suo complesso. Infatti, il Supply Chain Scientist non può operare come un silos all’interno dell’azienda. Proprio come lo scienziato deve collaborare con il resto dell’azienda per ottenere qualcosa, anche il resto dell’azienda deve collaborare con lo scienziato perché ciò accada.

Prima di procedere oltre, vorrei ribadire una dichiarazione che ho fatto nella prima lezione di questa serie. La presente lezione si basa quasi interamente su un esperimento unico della durata di un decennio condotto presso Lokad, un fornitore di software aziendale specializzato nell’ottimizzazione della catena di approvvigionamento. Tutte queste lezioni sono state plasmate dal percorso di Lokad, ma per quanto riguarda il ruolo del Supply Chain Scientist, il legame è ancora più forte. In larga misura, il percorso di Lokad stesso può essere letto attraverso le lenti della nostra scoperta graduale del ruolo del Supply Chain Scientist.

Questo processo è ancora in corso. Ad esempio, solo cinque anni fa abbiamo abbandonato la prospettiva del data scientist di punta con l’introduzione di paradigmi di programmazione per scopi di apprendimento e ottimizzazione. Attualmente, Lokad impiega tre dozzine di Supply Chain Scientist. I nostri scienziati più capaci, attraverso i loro track record, sono diventati affidabili per decisioni su larga scala. Alcuni di loro sono responsabili individualmente di parametri che superano il valore di mezzo miliardo di dollari di inventario. Questa fiducia si estende a una vasta gamma di decisioni, come ordini di acquisto, ordini di produzione, ordini di allocazione dell’inventario o prezzi.

Come potreste immaginare, questa fiducia doveva essere guadagnata. Infatti, poche aziende si fiderebbero dei propri dipendenti con poteri del genere, figuriamoci un fornitore terzo come Lokad. Guadagnare questo grado di fiducia è un processo che di solito richiede anni, indipendentemente dai mezzi tecnologici. Eppure, a distanza di dieci anni, Lokad sta crescendo più velocemente che mai nei suoi primi anni, e una parte consistente di questa crescita proviene dai nostri clienti esistenti che stanno ampliando la portata delle decisioni affidate a Lokad.

Questo mi riporta al mio punto iniziale: questa lezione quasi certamente è accompagnata da tutti i tipi di pregiudizi. Ho cercato di ampliare questa prospettiva attraverso esperienze simili al di fuori di Lokad; tuttavia, non c’è molto da raccontare su quel fronte. A mia conoscenza, ci sono alcune grandi aziende tecnologiche, più specificamente alcune grandi aziende di e-commerce, che raggiungono un grado di automazione delle decisioni paragonabile a quello che Lokad raggiunge.

Tuttavia, queste grandi aziende di solito allocano due ordini di grandezza di risorse in più rispetto a quelle che le normali grandi aziende possono permettersi, con centinaia di ingegneri. La fattibilità di questi approcci rimane poco chiara per me, poiché potrebbero funzionare solo in aziende estremamente redditizie. Altrimenti, i costi del personale potrebbero superare i benefici derivanti da una migliore esecuzione della supply chain.

Inoltre, attirare talenti ingegneristici su questa scala diventa una sfida a sé stante. Assumere un talentuoso ingegnere del software è già abbastanza difficile; assumerne 100 richiede un marchio aziendale piuttosto notevole. Fortunatamente, la prospettiva presentata oggi è molto più snella. Molte iniziative di supply chain portate avanti da Lokad vengono realizzate con un solo Supply Chain Scientist, con un secondo che agisce come sostituto. Oltre ai risparmi sul costo del personale, la nostra esperienza indica che ci sono notevoli vantaggi legati alla supply chain associati a un numero inferiore di dipendenti.

La prospettiva dominante sulla supply chain adotta l’atteggiamento della matematica applicata. I metodi e gli algoritmi vengono presentati in modo tale da rimuovere completamente l’operatore umano dall’immagine. Ad esempio, la formula per il stock di sicurezza e la formula per la quantità economica di ordinazione vengono presentate come una pura questione di matematica applicata. L’identità della persona che utilizza queste formule, le sue competenze o il suo background, ad esempio, non sono solo irrilevanti, ma non fanno nemmeno parte della presentazione.

Più in generale, questa posizione viene adottata ampiamente nei libri di supply chain e di conseguenza nei software di supply chain. Certamente sembra più oggettivo rimuovere il componente umano dall’immagine. Dopotutto, la validità di un teorema non dipende dalla persona che enuncia la dimostrazione, e allo stesso modo, le prestazioni di un algoritmo non dipendono dalla persona che preme l’ultimo tasto della sua implementazione. Questo approccio mira a raggiungere una forma superiore di razionalità.

Tuttavia, sostengo che questa posizione sia ingenua e rappresenti un’altra istanza di razionalismo ingenuo. La mia proposta è sottile ma importante: non sto sostenendo che l’esito di una ricetta numerica dipenda dalla persona che alla fine esegue la ricetta, né che il carattere di un matematico abbia qualcosa a che fare con la validità dei suoi teoremi. Invece, la mia proposta è che l’atteggiamento intellettuale associato a questa prospettiva sia inappropriato per affrontare le supply chain.

Una ricetta di supply chain del mondo reale è un pezzo complesso di artigianato, e l’autore della ricetta non è affatto neutrale o irrilevante come potrebbe sembrare. Illustreremo questo punto considerando due ricette numeriche identiche che differiscono solo nella denominazione delle loro variabili. A livello numerico, le due ricette producono output identici. Tuttavia, la prima ricetta ha nomi di variabili ben scelti e significativi, mentre la seconda ricetta ha nomi criptici e inconsistenti. In produzione, la seconda ricetta (quella con nomi di variabili criptici e inconsistenti) è un disastro in attesa di accadere. Ogni evoluzione o correzione di bug applicata alla seconda ricetta richiederà sforzi di gran lunga superiori rispetto allo stesso compito svolto sulla prima ricetta. In effetti, i problemi legati alla denominazione delle variabili sono così frequenti e gravi che molti libri di ingegneria del software dedicano un intero capitolo a questa singola questione.

Né la matematica, né l’algoritmica, né la statistica dicono nulla sull’adeguatezza dei nomi delle variabili. L’adeguatezza di quei nomi risiede ovviamente nell’occhio di chi guarda. Sebbene abbiamo due ricette numericamente identiche, una è considerata molto superiore all’altra per ragioni apparentemente soggettive. La proposta che sto difendendo qui è che esista una razionalità anche in quelle preoccupazioni soggettive. Queste preoccupazioni non dovrebbero essere respinte a priori perché dipendenti da un soggetto o da una persona. Al contrario, l’esperienza di Lokad indica che, dati gli stessi strumenti software, strumenti matematici e libreria di algoritmi, certi scienziati delle supply chain ottengono risultati superiori. In effetti, l’identità dello scienziato responsabile è uno dei migliori predittori che abbiamo per il successo dell’iniziativa.

Presumendo che il talento innato non possa spiegare interamente le discrepanze nel successo della supply chain, dovremmo abbracciare gli elementi che contribuiscono alle iniziative di successo, che siano oggettivi o soggettivi. Ecco perché, presso Lokad, abbiamo dedicato molto impegno negli ultimi decenni a perfezionare il nostro approccio al ruolo dello scienziato delle supply chain, che è proprio l’argomento di questa lezione. Le sfumature associate alla posizione di uno scienziato delle supply chain non devono essere sottovalutate. L’entità dei miglioramenti apportati da questi elementi soggettivi è paragonabile alle nostre conquiste tecnologiche più importanti.

Questa serie di lezioni è destinata come materiale di formazione per gli scienziati delle supply chain di Lokad. Tuttavia, spero anche che queste lezioni possano interessare un pubblico più ampio di professionisti delle supply chain o persino studenti di supply chain. È meglio guardare queste lezioni in sequenza per una comprensione approfondita di ciò con cui gli scienziati delle supply chain devono confrontarsi.

Nel primo capitolo abbiamo visto perché le supply chain devono diventare programmatiche e perché è altamente desiderabile essere in grado di mettere una ricetta numerica in produzione. La crescente complessità delle supply chain rende l’automazione più pressante che mai. Inoltre, c’è un’imperativa finanziaria nel rendere le pratiche di supply chain capitalistiche.

Il secondo capitolo è dedicato alle metodologie. Le supply chain sono sistemi competitivi e questa combinazione sconfigge le metodologie ingenuamente applicate. Il ruolo degli scienziati può essere visto come un antidoto alla metodologia matematica applicata ingenuamente.

Il terzo capitolo analizza i problemi affrontati dal personale della supply chain. Questo capitolo cerca di caratterizzare le classi di sfide decisionali che devono essere affrontate. Mostra che prospettive semplicistiche come scegliere la giusta quantità di stock per ogni SKU non si adattano alle situazioni del mondo reale; c’è sempre una profondità nella presa di decisioni.

Il quarto capitolo analizza gli elementi necessari per comprendere una pratica moderna di supply chain, in cui gli elementi software sono ubiqui. Questi elementi sono fondamentali per comprendere il contesto più ampio in cui opera la supply chain digitale.

I capitoli 5 e 6 sono dedicati rispettivamente alla modellazione predittiva e alla presa di decisioni. Questi capitoli coprono i “pezzi intelligenti” della ricetta numerica, che includono l’apprendimento automatico e l’ottimizzazione matematica. In particolare, questi capitoli raccolgono le tecniche che si sono dimostrate efficaci nelle mani degli scienziati della supply chain.

Infine, il settimo e presente capitolo è dedicato all’esecuzione di un’iniziativa quantitativa di supply chain. Abbiamo visto cosa serve per avviare un’iniziativa ponendo le basi adeguate. Abbiamo visto come attraversare il traguardo e mettere in produzione la ricetta numerica.

Oggi vedremo che tipo di persona serve per far accadere tutto ciò.

Il ruolo dello scienziato mira a risolvere i problemi presenti nella letteratura accademica. Esamineremo il lavoro dello scienziato della supply chain, comprese la sua missione, l’ambito, la routine quotidiana e gli argomenti di interesse. Questa descrizione del lavoro riflette la pratica attuale presso Lokad.

Una nuova posizione all’interno dell’azienda crea una serie di preoccupazioni, quindi è necessario assumere, formare, valutare e trattenere gli scienziati. Affronteremo queste preoccupazioni da una prospettiva delle risorse umane. Si prevede che lo scienziato collabori con altri dipartimenti all’interno dell’azienda oltre al proprio dipartimento di supply chain. Vedremo che tipo di interazioni sono previste tra gli scienziati e l’IT, la finanza e persino la dirigenza aziendale.

Lo scienziato rappresenta anche un’opportunità per l’azienda di modernizzare il proprio personale e le proprie operazioni. Questa modernizzazione è la parte più difficile del percorso, poiché è molto più sfidante rimuovere una posizione che ha smesso di essere rilevante anziché introdurne una nuova.

La sfida che ci siamo posti in questa serie di lezioni è il miglioramento sistematico delle supply chain attraverso metodi quantitativi. L’idea generale di questo approccio è sfruttare al massimo ciò che l’informatica moderna e il software possono offrire alle supply chain. Tuttavia, è necessario chiarire cosa appartiene ancora al campo dell’intelligenza umana e cosa può essere automatizzato con successo.

La linea di demarcazione tra intelligenza umana e automazione dipende ancora molto dalla tecnologia. Si prevede che una tecnologia superiore meccanizzi un’ampia gamma di decisioni e produca risultati migliori. Da una prospettiva di supply chain, ciò significa prendere decisioni più diverse, come decisioni di prezzo oltre alle decisioni di riapprovvigionamento dell’inventario, e produrre decisioni migliori che migliorano ulteriormente la redditività dell’azienda.

Il ruolo dello scienziato è l’incarnazione di questa frontiera tra intelligenza umana e automazione. Sebbene gli annunci di routine sull’intelligenza artificiale possano dare l’impressione che l’intelligenza umana sia sull’orlo di essere automatizzata, la mia comprensione dello stato dell’arte indica che l’intelligenza artificiale generale rimane lontana. Infatti, le intuizioni umane sono ancora molto necessarie quando si tratta di progettare metodi quantitativi di rilevanza per la supply chain. Stabilire anche una semplice strategia di supply chain rimane in gran parte al di là di ciò che il software può offrire.

Più in generale, non abbiamo ancora tecnologie capaci di affrontare problemi mal formulati o problemi non identificati, che sono comuni nella supply chain. Tuttavia, una volta isolato un problema specifico e ben definito, è concepibile che un processo automatizzato apprenda la sua soluzione e automatizzi anche questa soluzione con poca o nessuna supervisione umana.

Questa prospettiva non è nuova. Ad esempio, i filtri anti-spam sono diventati ampiamente adottati. Questi filtri svolgono un compito impegnativo: separare ciò che è rilevante da ciò che non lo è. Tuttavia, la progettazione della prossima generazione di filtri è ancora in gran parte affidata agli esseri umani, anche se i nuovi dati possono essere utilizzati per aggiornare tali filtri. Infatti, gli spammers che vogliono eludere i filtri anti-spam continuano a inventare nuovi metodi che sconfiggono gli aggiornamenti basati solo sui dati di quei filtri.

Pertanto, sebbene siano ancora necessarie intuizioni umane per progettare l’automazione, non è chiaro perché un fornitore di software come Lokad, ad esempio, non potrebbe progettare un grande motore di supply chain che affronti tutte queste sfide. Certamente, l’economia del software è molto favorevole all’ingegnerizzazione di un tale grande motore di supply chain. Anche se l’investimento iniziale è elevato, poiché il software può essere replicato a un costo trascurabile, il fornitore guadagnerà una fortuna in commissioni di licenza rivendendo questo grande motore a un gran numero di aziende.

Lokad, nel 2008, si è impegnata in un tale percorso per creare un grande motore che avrebbe potuto essere distribuito come prodotto software confezionato. Più precisamente, Lokad si stava concentrando in quel momento su un grande motore di previsione piuttosto che su un grande motore di supply chain. Tuttavia, nonostante queste ambizioni relativamente più modeste, poiché la previsione è solo una piccola parte della sfida globale della supply chain, Lokad non è riuscita a creare un tale grande motore di previsione. La prospettiva quantitativa della supply chain presentata in questa serie di lezioni è nata dalle ceneri di questa grande ambizione del motore.

Per quanto riguarda la supply chain, si è scoperto che ci sono tre grandi ostacoli da affrontare. Vedremo perché questo grande motore era destinato a fallire fin dal primo giorno e perché è molto probabile che ci vorranno ancora decenni per realizzare un tale risultato ingegneristico.

Il paesaggio applicativo tipico della supply chain è una giungla che è cresciuta in modo casuale negli ultimi due o tre decenni. Questo paesaggio non è un giardino formale francese con linee geometriche ordinate e arbusti ben curati; è una giungla, vibrante ma anche piena di spine e fauna ostile. Più seriamente, le supply chain sono il prodotto della loro storia digitale. Potrebbero esserci molteplici ERP semi-ridondanti, personalizzazioni interne non finite, integrazioni batch, specialmente con sistemi provenienti da aziende acquisite, e piattaforme software sovrapposte che competono per le stesse aree funzionali.

L’idea che un grande motore possa essere semplicemente collegato è illusoria, considerando lo stato attuale delle tecnologie software. Riunire tutti i sistemi che gestiscono la supply chain è un’impresa considerevole completamente dipendente dagli sforzi di ingegneria umana.

L’analisi delle spese collettive indica che la manipolazione dei dati rappresenta almeno tre quarti dello sforzo tecnico complessivo associato a un’iniziativa di supply chain. Al contrario, la creazione degli aspetti intelligenti della ricetta numerica, come la previsione e l’ottimizzazione, rappresenta non più del qualche percento degli sforzi complessivi. Pertanto, la disponibilità di un grande motore confezionato è in gran parte insignificante in termini di costi o ritardi. Perché questo motore si integri automaticamente nel paesaggio IT spesso casuale comune nelle supply chain, richiederebbe un’intelligenza di livello umano integrata.

Inoltre, qualsiasi grande motore rende questa impresa ancora più impegnativa a causa della sua esistenza. Invece di occuparsi di un sistema complesso, il paesaggio applicativo, ora abbiamo due sistemi complessi: il paesaggio applicativo e il grande motore. La complessità di integrazione di questi due sistemi non è la somma delle rispettive complessità, ma il prodotto di quelle complessità.

L’impatto di questa complessità sul costo di ingegneria è altamente non lineare, un punto che è già stato evidenziato nel primo capitolo di questa serie di lezioni. Il primo grande ostacolo per l’ottimizzazione della supply chain è la configurazione della ricetta numerica, che richiede uno sforzo di ingegneria dedicato. Questo ostacolo elimina in gran parte i benefici che potrebbero essere concepibilmente associati a qualsiasi tipo di grande motore di supply chain confezionato.

Sebbene la configurazione richieda uno sforzo di ingegneria considerevole, potrebbe essere un investimento unico, simile al pagamento di un biglietto d’ingresso. Sfortunatamente, le supply chain sono entità vive in continua evoluzione. Il giorno in cui una supply chain smette di cambiare è il giorno in cui l’azienda fallisce. I cambiamenti sono sia interni che esterni.

Internamente, il panorama applicativo cambia costantemente. Le aziende non possono congelare il loro panorama applicativo anche se volessero, poiché molti aggiornamenti sono richiesti dai fornitori di software aziendale. Ignorare queste richieste solleverebbe i fornitori dai loro obblighi contrattuali, il che non è un risultato accettabile. Oltre agli aggiornamenti puramente tecnici, ogni supply chain di una certa dimensione è destinata a introdurre e rimuovere pezzi di software man mano che l’azienda stessa cambia.

Esternamente, i mercati cambiano continuamente. Nuovi concorrenti, canali di vendita e potenziali fornitori emergono continuamente, mentre alcuni scompaiono. Le normative cambiano continuamente. Sebbene gli algoritmi possano catturare automaticamente alcuni dei cambiamenti più evidenti, come la crescita della domanda per una classe di prodotti, non disponiamo ancora di algoritmi in grado di affrontare i cambiamenti di mercato in modo diverso, oltre che in termini di entità. I problemi stessi che l’ottimizzazione della supply chain cerca di affrontare stanno cambiando.

Se il software responsabile dell’ottimizzazione della supply chain non riesce a gestire questi cambiamenti, i dipendenti si affidano alle tabelle di calcolo. Le tabelle di calcolo possono essere rudimentali, ma almeno i dipendenti possono mantenerle pertinenti per il compito in questione. Aneddoticamente, la stragrande maggioranza delle supply chain opera ancora con tabelle di calcolo a livello decisionale, non a livello transazionale. Questa è la prova vivente che la manutenzione del software è fallita.

Dagli anni ‘80, i fornitori di software aziendale hanno fornito prodotti software per automatizzare le decisioni della supply chain. La maggior parte delle aziende che operano grandi supply chain ha già implementato diverse di queste soluzioni negli ultimi decenni. Tuttavia, i dipendenti finiscono sempre per tornare alle tabelle di calcolo, dimostrando che anche se l’implementazione è stata originariamente considerata un successo, qualcosa è andato storto con la manutenzione.

La manutenzione è il secondo grande ostacolo dell’ottimizzazione della supply chain. La ricetta richiede una manutenzione attiva, anche se l’esecuzione può essere lasciata in gran parte senza supervisione.

A questo punto, abbiamo dimostrato che l’ottimizzazione della supply chain richiede non solo risorse iniziali di ingegneria del software, ma anche risorse continue di ingegneria del software. Come già evidenziato in questa serie di lezioni, solo le capacità programmatiche possono avvicinarsi realisticamente alla diversità dei problemi affrontati dalle supply chain del mondo reale. Le tabelle di calcolo contano come strumenti programmabili e la loro espressività, rispetto ai pulsanti e ai menu, è ciò che li rende così attraenti per i professionisti della supply chain.

Poiché le risorse di ingegneria del software devono essere garantite nella maggior parte delle aziende, è naturale rivolgersi al dipartimento IT. Sfortunatamente, la supply chain non è l’unico dipartimento con questa linea di pensiero. Ogni singolo dipartimento, compresi vendite, marketing e finanza, si rende conto che l’automazione dei rispettivi processi decisionali richiede risorse di ingegneria del software. Inoltre, devono anche occuparsi del livello di transazione e di tutta l’infrastruttura sottostante.

Di conseguenza, la maggior parte delle aziende che operano grandi supply chain ha i loro dipartimenti IT sommersi da anni di arretrato. Pertanto, aspettarsi che il dipartimento IT assegni ulteriori risorse continue alla supply chain peggiora solo l’arretrato. L’opzione di allocare più risorse al dipartimento IT è già stata esplorata e di solito non è più fattibile. Queste aziende si trovano già di fronte a gravi diseconomie di scala quando si tratta del dipartimento IT. L’arretrato del dipartimento IT rappresenta il terzo grande ostacolo per l’ottimizzazione della supply chain.

Sono necessarie risorse continue di ingegneria, ma la maggior parte di queste risorse non può provenire dall’IT. È possibile immaginare un certo supporto da parte dell’IT, ma deve essere una questione a basso profilo.

Questi tre grandi ostacoli definiscono perché è necessario un ruolo specifico: lo scienziato della supply chain è il nome che stiamo dando a quelle risorse continue di ingegneria del software necessarie per automatizzare le decisioni banali della supply chain e i processi decisionali impegnativi.

Procediamo con una definizione più precisa basata sulla pratica di Lokad. La missione dello scienziato della supply chain è creare ricette numeriche che generano le decisioni banali necessarie quotidianamente per far funzionare la supply chain. Il lavoro dello scienziato inizia con gli estratti del database raccolti da tutto il panorama applicativo. Lo scienziato è tenuto a codificare la ricetta che elabora questi estratti del database e a portare tali ricette in produzione. Lo scienziato si assume la piena responsabilità della qualità delle decisioni generate dalla ricetta. Le decisioni non sono generate da qualche tipo di sistema ambientale; sono l’espressione diretta delle intuizioni dello scienziato trasmesse attraverso una ricetta.

Questo singolo aspetto rappresenta una differenza critica rispetto a ciò che di solito si intende per il ruolo di un data scientist. Tuttavia, la missione non si ferma qui. Ci si aspetta che lo scienziato della supply chain sia in grado di presentare prove a sostegno di ogni singola decisione generata dalla ricetta. Non si tratta di un sistema opaco responsabile delle decisioni; è la persona, lo scienziato. Lo scienziato dovrebbe essere in grado di incontrare il responsabile della supply chain o addirittura il CEO e fornire una motivazione convincente per qualsiasi decisione generata dalla ricetta.

Se lo scienziato non è in grado di potenzialmente causare molti danni all’azienda, allora qualcosa non va. Non sto sostenendo di concedere a chiunque, e certamente non allo scienziato, grandi poteri senza supervisione o responsabilità. Sto solo sottolineando l’ovvio: se non hai il potere di influire negativamente sulla tua azienda, non importa quanto male ti comporti, non hai il potere di influire positivamente sulla tua azienda, non importa quanto bene ti comporti.

Le grandi aziende sono sfortunatamente avverse al rischio per natura. Pertanto, è molto tentante sostituire lo scienziato con un analista. Contrariamente allo scienziato responsabile delle decisioni stesse, l’analista è responsabile solo di fare un po’ di luce qua e là. L’analista è per lo più innocuo e non può fare molto oltre a sprecare il proprio tempo e alcune risorse di calcolo. Tuttavia, essere innocuo non è ciò che riguarda il ruolo dello scienziato della supply chain.

Discutiamo per un attimo il termine “scienziato della supply chain”. Purtroppo, questa terminologia è imperfetta. Ho coniato originariamente questa espressione come una variazione di “data scientist” circa dieci anni fa, con l’idea di marchiare questo ruolo come una variazione di data scientist ma con una forte specializzazione nella supply chain. L’intuizione sulla specializzazione era corretta, ma quella sulla scienza dei dati non lo era. Tornerò su questo punto alla fine della lezione.

Un “ingegnere della supply chain” potrebbe essere stata una formulazione migliore, in quanto enfatizza il desiderio di padroneggiare e controllare il dominio, a differenza della pura comprensione. Tuttavia, gli ingegneri, come comunemente intesi, non sono tenuti ad essere all’avanguardia dell’azione. Il termine corretto sarebbe probabilmente stato supply chain quant, come praticanti quantitativi della supply chain.

Nella finanza, un quant o un trader quantitativo è uno specialista che sfrutta algoritmi e metodi quantitativi per prendere decisioni di trading. I quants possono rendere una banca estremamente redditizia o, al contrario, estremamente non redditizia. L’intelligenza umana viene amplificata attraverso le macchine, sia nel bene che nel male.

In ogni caso, spetterà alla comunità nel suo complesso decidere la terminologia corretta: analista, scienziato, ingegnere, operativo o quant. Per una questione di coerenza, continuerò a utilizzare il termine scienziato nel resto di questa lezione.

Il principale risultato atteso da uno scienziato della supply chain è un pezzo di software, più precisamente, la ricetta numerica responsabile della generazione delle decisioni giornaliere di supply chain di interesse. Questa ricetta è una collezione di tutti gli script coinvolti dalle prime fasi di preparazione dei dati alle fasi finali di validazione aziendale delle decisioni stesse. Questa ricetta deve essere di qualità produttiva, il che significa che può essere eseguita senza supervisione e che le decisioni che genera sono affidabili per impostazione predefinita. Naturalmente, questa fiducia deve essere guadagnata in primo luogo e una supervisione continua deve garantire che questo livello di fiducia rimanga giustificato nel tempo.

Consegnare una ricetta di qualità produttiva è fondamentale per trasformare la pratica della supply chain in un asset produttivo. Questo aspetto è già stato discusso nella precedente lezione sulla consegna orientata al prodotto.

Oltre a questa ricetta, ci sono numerosi risultati secondari. Alcuni di essi sono anche software, anche se non contribuiscono direttamente alla generazione delle decisioni. Questo include, ad esempio, tutta l’attrezzatura che lo scienziato deve introdurre per creare e successivamente mantenere la ricetta stessa. Altri elementi sono destinati ai colleghi all’interno dell’azienda, compresa tutta la documentazione dell’iniziativa stessa e della ricetta.

Il codice sorgente della ricetta risponde al “come” - come viene fatto? Tuttavia, il codice sorgente non risponde al “perché” - perché viene fatto? Il “perché” deve essere documentato. Spesso, la correttezza della ricetta dipende da una comprensione sottile dell’intento. La documentazione fornita deve facilitare il più possibile il passaggio agevole da uno scienziato all’altro, anche se il primo scienziato non è disponibile per supportare il processo.

Presso Lokad, la nostra procedura standard consiste nella produzione e nel mantenimento di un grande libro dell’iniziativa, chiamato Joint Procedure Manual (JPM). Questo manuale non è solo un manuale operativo completo della ricetta, ma anche una raccolta di tutte le intuizioni strategiche che sottendono alle scelte di modellazione fatte dagli scienziati.

A livello tecnico, il lavoro dello scienziato parte dal punto di estrazione dei dati grezzi e termina con la generazione delle decisioni finalizzate della supply chain. Lo scienziato deve operare a partire dai dati grezzi estratti dai sistemi aziendali esistenti. Poiché ogni sistema aziendale ha la propria infrastruttura tecnologica, l’estrazione stessa è di solito meglio affidata a specialisti IT. Non è ragionevole aspettarsi che lo scienziato diventi competente in mezza dozzina di dialetti SQL o mezza dozzina di tecnologie API solo per accedere ai dati aziendali. D’altra parte, non si dovrebbe aspettare nulla dagli specialisti IT tranne che estrazioni di dati grezzi, né trasformazione dei dati né preparazione dei dati. I dati estratti resi accessibili allo scienziato devono essere il più possibile vicini ai dati come si presentano all’interno dei sistemi aziendali.

All’altro capo del processo, la ricetta creata dallo scienziato deve generare le decisioni finalizzate. Gli elementi associati all’implementazione delle decisioni non rientrano nell’ambito dello scienziato. Sono importanti ma sono anche in gran parte indipendenti dalla decisione stessa. Ad esempio, quando si considerano gli ordini di acquisto, stabilire le quantità finali rientra nell’ambito dello scienziato, ma generare il file PDF - il documento d’ordine previsto dal fornitore - non lo è. Nonostante questi limiti, l’ambito è piuttosto ampio. Di conseguenza, è tentatore ma sbagliato frammentare l’ambito in una serie di sottoscopi. Nelle grandi aziende, questa tentazione diventa molto forte e deve essere resistita. Frammentare l’ambito è il modo più sicuro per creare numerosi problemi.

A monte, se qualcuno cerca di aiutare gli scienziati manipolando l’input, questo tentativo finisce inevitabilmente in problemi di “spazzatura dentro, spazzatura fuori”. I sistemi aziendali sono abbastanza complessi; trasformare i dati in anticipo non fa altro che aggiungere un ulteriore livello accidentale di complessità. A metà strada, se qualcuno cerca di aiutare gli scienziati occupandosi di una parte complessa della ricetta, come la previsione, gli scienziati si trovano di fronte a una scatola nera nel mezzo della loro stessa ricetta. Una tale scatola nera mina gli sforzi di trasparenza degli scienziati. E a valle, se qualcuno cerca di aiutare lo scienziato ottimizzando ulteriormente le decisioni, questo tentativo crea inevitabilmente confusione e le logiche di ottimizzazione a due livelli possono persino funzionare in modo contrario.

Ciò non implica che lo scienziato debba lavorare da solo. Può essere formato un team di scienziati, ma l’ambito rimane lo stesso. Se viene formato un team, deve esserci una proprietà collettiva della ricetta. Ciò implica, ad esempio, che se viene identificato un difetto nella ricetta, qualsiasi membro del team dovrebbe essere in grado di intervenire e correggerlo.

L’esperienza di Lokad indica che un sano mix per uno scienziato della supply chain comporta il 40% del tempo dedicato alla codifica, il 30% al dialogo con il resto dell’azienda e il 30% alla scrittura di documenti, materiali di formazione e allo scambio con altri professionisti della supply chain o altri scienziati della supply chain.

La codifica è ovviamente necessaria per implementare la ricetta stessa. Tuttavia, una volta che la ricetta è in produzione, la maggior parte degli sforzi di codifica non è diretta alla ricetta stessa, ma piuttosto alla sua strumentazione. Per migliorare la ricetta, lo scienziato ha bisogno di ulteriori approfondimenti e, a sua volta, tali approfondimenti richiedono una strumentazione dedicata che deve essere implementata.

Il dialogo con il resto dell’azienda è fondamentale. A differenza del S&OP, lo scopo di queste discussioni non è quello di orientare la previsione verso l’alto o verso il basso. Si tratta di assicurarsi che le scelte di modellizzazione incorporate nella ricetta riflettano ancora fedelmente sia la strategia dell’azienda che tutti i suoi vincoli operativi.

Infine, coltivare la conoscenza istituzionale che l’azienda ha sull’ottimizzazione della supply chain, sia attraverso la formazione diretta degli stessi scienziati che attraverso la produzione di documenti destinati ai colleghi, è fondamentale. Le prestazioni della ricetta sono, in larga misura, un riflesso della competenza dello scienziato. Avere accesso a colleghi e cercare feedback è sorprendentemente uno dei mezzi più efficienti per migliorare la competenza degli scienziati.

La differenza più grande tra uno scienziato della supply chain, come immaginato da Lokad, e uno scienziato dei dati tradizionale è l’impegno personale verso i risultati concreti nel mondo reale. Potrebbe sembrare una cosa piccola e insignificante, ma l’esperienza dice il contrario. Dieci anni fa, Lokad ha imparato a sue spese che l’impegno per la consegna di una ricetta di produzione di qualità non era scontato. Al contrario, l’atteggiamento predefinito delle persone formate come scienziati dei dati sembra essere quello di considerare la produzione come una preoccupazione secondaria. Lo scienziato dei dati tradizionale si aspetta di gestire gli aspetti intelligenti, come l’apprendimento automatico e l’ottimizzazione matematica, mentre occuparsi di tutte le banalità casuali che accompagnano la supply chain del mondo reale viene troppo spesso percepito come qualcosa di al di sotto di loro.

Tuttavia, l’impegno per una ricetta di produzione di qualità implica occuparsi delle cose più casuali. Ad esempio, nel luglio 2021, molti paesi europei hanno subito inondazioni catastrofiche. Un cliente di Lokad con sede in Germania ha avuto metà dei suoi magazzini allagati. Lo scienziato della supply chain responsabile di questo account ha dovuto riprogettare la ricetta quasi da un giorno all’altro per sfruttare al massimo questa situazione gravemente compromessa. La soluzione non era un grande algoritmo di apprendimento automatico, ma piuttosto un insieme di euristiche decodificate. Al contrario, se lo scienziato della supply chain non prende le decisioni, allora questa persona non sarà in grado di creare una ricetta di produzione di qualità. È una questione di psicologia. Consegnare una ricetta di produzione di qualità richiede un immenso sforzo intellettuale e gli interessi devono essere reali per raggiungere il livello di concentrazione necessario da parte di un dipendente.

Dopo aver chiarito il lavoro di uno scienziato della supply chain, discutiamo di come funziona dal punto di vista delle risorse umane. Innanzitutto, tra le preoccupazioni aziendali, lo scienziato deve riportare al responsabile della supply chain o almeno a qualcuno che possa essere considerato un dirigente senior della supply chain. Non importa se lo scienziato è interno o esterno, come spesso accade con Lokad. Il punto è che lo scienziato deve essere sotto la supervisione diretta di qualcuno che ha il potere di un dirigente della supply chain.

Un errore comune è far riportare lo scienziato al responsabile dell’IT o al responsabile dell’analisi dei dati. Poiché creare una ricetta è un esercizio di programmazione, la leadership della supply chain potrebbe non sentirsi completamente a suo agio nel supervisionare un tale compito. Tuttavia, questo è sbagliato. Lo scienziato ha bisogno di una supervisione da parte di qualcuno che possa approvare se le decisioni generate sono accettabili o meno, o che possa almeno far sì che questa approvazione avvenga. Mettere lo scienziato ovunque tranne che sotto la supervisione diretta della leadership della supply chain è una ricetta per operare continuamente attraverso prototipi che non arrivano mai alla produzione. In questa situazione, il ruolo inevitabilmente si riduce a quello di un analista e le ambizioni iniziali dell’iniziativa quantitativa della supply chain vengono abbandonate.

I migliori scienziati della supply chain generano rendimenti superiori rispetto a quelli medi. Questa è stata l’esperienza di Lokad e riflette il modello identificato decenni fa nell’industria del software. Le aziende di software hanno da tempo osservato che i migliori ingegneri del software hanno almeno 10 volte più produttività rispetto a quelli medi e gli ingegneri medi possono persino avere una produttività negativa, rendendo il software peggiore per ogni ora trascorsa sulla base di codice.

Nel caso degli scienziati della supply chain, una competenza superiore non solo migliora la produttività, ma, cosa più importante, migliora le prestazioni finali della catena di fornitura. Con gli stessi strumenti software e strumenti matematici, due scienziati non ottengono lo stesso risultato. Pertanto, assumere qualcuno con il potenziale per diventare uno dei migliori scienziati è di primaria importanza.

L’esperienza di Lokad, basata sull’assunzione di oltre 50 scienziati, indica che i profili di ingegneria non specializzati sono di solito abbastanza buoni. Sebbene controintuitivo, le persone con una formazione formale in data science, statistica o informatica di solito non sono la scelta migliore per le posizioni di scienziato della supply chain. Queste persone troppo spesso complicano eccessivamente la ricetta e non prestano sufficiente attenzione agli aspetti banali ma critici della supply chain. La capacità di prestare attenzione a una moltitudine di dettagli e la capacità di perseverare all’infinito nel perseguire artefatti numerici marginali sembrano essere le qualità principali dei migliori scienziati.

Anedotticamente, presso Lokad, c’è stato un buon track record con giovani ingegneri che hanno trascorso alcuni anni come revisori contabili. Oltre alla familiarità con la finanza aziendale, sembra che gli auditor talentuosi sviluppino la capacità di navigare attraverso un oceano di documenti aziendali, il che si allinea con la realtà quotidiana di uno scienziato della supply chain.

Mentre l’assunzione assicura che i nuovi assunti abbiano il potenziale giusto, il passo successivo è assicurarsi che siano adeguatamente formati. La posizione predefinita di Lokad è che non si aspettano che le persone sappiano qualcosa sulla supply chain in anticipo. Avere conoscenze sulla supply chain è un vantaggio, ma l’accademia rimane in qualche modo carente in questo senso. La maggior parte dei corsi di laurea sulla supply chain si concentra sulla gestione e sulla leadership, ma per i giovani laureati è essenziale avere una conoscenza di base adeguata su argomenti come quelli trattati nel secondo, terzo o quarto capitolo di questa serie di lezioni. Purtroppo, questo non è spesso il caso e le parti quantitative di questi corsi possono essere deludenti. Di conseguenza, gli scienziati della supply chain devono essere formati dai loro datori di lavoro. Questa serie di lezioni riflette il tipo di materiali di formazione utilizzati presso Lokad.

Le valutazioni delle prestazioni per gli scienziati della supply chain sono importanti per una serie di motivi, come assicurarsi che i soldi dell’azienda siano ben spesi e determinare le promozioni. Si applicano i criteri usuali: attitudine, diligenza, competenza, ecc. Tuttavia, c’è un aspetto controintuitivo: i migliori scienziati ottengono risultati che rendono le sfide della supply chain quasi invisibili, con un minimo di drammi.

Formare uno scienziato per mantenere le ricette esistenti mantenendo il livello precedente di performance della supply chain richiede circa sei mesi, mentre formare uno scienziato per implementare una ricetta di previsione da zero richiede circa due anni. La retention del talento è fondamentale, soprattutto perché l’assunzione di scienziati della supply chain esperti non è ancora un’opzione.

In molti paesi, la permanenza media per gli ingegneri sotto i 30 anni nel settore del software e settori adiacenti è piuttosto bassa. Lokad raggiunge una permanenza media più elevata concentrandosi sul benessere dei dipendenti. Le aziende non possono portare felicità ai propri dipendenti, ma possono evitare di rendere i propri dipendenti infelici attraverso processi insensati. La sanità mentale va molto lontano nella retention dei dipendenti.

Non si può pretendere che uno scienziato competente ed esperto della supply chain prenda rapidamente il controllo di una ricetta esistente, poiché la ricetta riflette la strategia unica dell’azienda e le particolarità della supply chain. La transizione da una supply chain all’altra può richiedere circa un mese nelle migliori condizioni. Non è ragionevole che una grande azienda dipenda da un solo scienziato; Lokad si assicura che due scienziati siano competenti con qualsiasi ricetta utilizzata in produzione in qualsiasi momento. La continuità è essenziale e un modo per raggiungerla è attraverso un manuale creato congiuntamente con i clienti, che può facilitare transizioni non pianificate tra gli scienziati.

Il ruolo dello scienziato della supply chain richiede un livello insolito di cooperazione con più dipartimenti, in particolare con l’IT. L’esecuzione corretta della ricetta dipende dal processo di estrazione dei dati, che è responsabilità dell’IT.

C’è una fase relativamente intensa di interazione tra l’IT e lo scienziato all’inizio della prima iniziativa quantitativa della supply chain, che dura circa due o tre mesi. Successivamente, una volta che il processo di estrazione dei dati è in atto, l’interazione diventa meno frequente. Questo dialogo assicura che lo scienziato rimanga consapevole della roadmap dell’IT e di eventuali aggiornamenti o modifiche del software che possono influire sulla supply chain.

Nella fase iniziale di un’iniziativa quantitativa della supply chain, c’è un’interazione relativamente intensa tra l’IT e gli scienziati. Durante i primi due o tre mesi, lo scienziato deve interagire con l’IT diverse volte alla settimana. Successivamente, una volta che il processo di estrazione dei dati è in atto, l’interazione diventa molto meno frequente, circa una volta al mese o meno. Oltre a risolvere eventuali problemi occasionali nel processo, questo dialogo assicura che lo scienziato rimanga consapevole della roadmap dell’IT. Eventuali aggiornamenti o sostituzioni del software possono richiedere giorni o addirittura settimane di lavoro per lo scienziato. Per evitare tempi di inattività, la ricetta deve essere modificata per adattarsi ai cambiamenti nel panorama applicativo.

La ricetta, come implementata dallo scienziato, ottimizza i dollari o gli euro di ritorno. Abbiamo affrontato questo aspetto nelle prime lezioni di questa serie. Tuttavia, non ci si dovrebbe aspettare che lo scienziato decida come modellare i costi e i profitti. Sebbene dovrebbero proporre modelli per riflettere i driver economici, è in ultima analisi compito della finanza decidere se tali driver sono considerati corretti o meno. Molte pratiche della supply chain evitano il problema concentrandosi su percentuali, come i livelli di servizio e l’accuratezza delle previsioni. Tuttavia, queste percentuali hanno quasi nessuna correlazione con la salute finanziaria dell’azienda. Pertanto, lo scienziato deve regolarmente confrontarsi con la finanza e far sì che essa metta in discussione le scelte di modellazione e le ipotesi fatte nella ricetta numerica.

Le scelte di modellazione finanziaria sono transitorie, poiché riflettono la strategia in evoluzione dell’azienda. Si prevede anche che lo scienziato crei alcuni strumenti collegati alla ricetta per il dipartimento finanziario, come l’importo massimo previsto di capitale circolante associato all’inventario per l’anno in corso. Per un’azienda di medie o grandi dimensioni, è ragionevole avere una revisione trimestrale da parte di un dirigente finanziario del lavoro svolto dallo scienziato della supply chain.

Una delle più grandi minacce alla validità della ricetta è tradire accidentalmente l’intento strategico dell’azienda. Troppre pratiche della supply chain evitano la strategia nascondendosi dietro le percentuali utilizzate come indicatori di performance. Gonfiare o sgonfiare la previsione attraverso la pianificazione delle vendite e delle operazioni (S&OP) non è un sostituto per chiarire l’intento strategico. Lo scienziato non è responsabile della strategia aziendale, ma la ricetta sarà errata se non la comprende. L’allineamento della ricetta con la strategia deve essere progettato.

Il modo più diretto per valutare se lo scienziato comprende la strategia è farlo spiegare nuovamente alla dirigenza. Ciò consente di individuare più facilmente eventuali fraintendimenti. In teoria, questa comprensione è già documentata dallo scienziato nel manuale dell’iniziativa. Tuttavia, l’esperienza indica che i dirigenti hanno raramente il tempo di esaminare dettagliatamente la documentazione operativa. Una semplice conversazione accelera il processo per entrambe le parti.

Questo incontro non è inteso affinché lo scienziato spieghi tutto sui modelli della supply chain o sui risultati finanziari. Lo scopo principale è garantire una corretta comprensione della persona che tiene la penna digitale. Anche in un’azienda di grandi dimensioni, è ragionevole che lo scienziato incontri il CEO o un dirigente rilevante almeno una volta all’anno. I benefici di una ricetta più in sintonia con l’intento della dirigenza sono vasti e spesso sottovalutati.

Miglioramenti della supply chain fanno parte di una modernizzazione digitale in corso. Ciò richiede una certa riorganizzazione dell’azienda stessa. Anche se i cambiamenti potrebbero non essere drastici, eliminare pratiche obsolete è una battaglia in salita. Quando eseguita correttamente, la produttività di uno scienziato della supply chain è significativamente superiore a quella di un pianificatore tradizionale. Non è raro che un singolo scienziato sia responsabile di un valore di inventario superiore a mezzo miliardo di dollari o euro.

È possibile una drastica riduzione del personale della supply chain. Alcune aziende clienti di Lokad, che erano storicamente sotto una pressione competitiva immensa, hanno adottato questo approccio e sono sopravvissute in parte grazie a questi risparmi. La maggior parte dei nostri clienti, tuttavia, opta per una riduzione più graduale del personale, poiché i pianificatori si spostano naturalmente verso altre posizioni.

I pianificatori che rimangono riorientano i loro sforzi verso i clienti e i fornitori. Il feedback che raccolgono si rivela molto utile per gli scienziati della supply chain. Infatti, il lavoro dello scienziato è di natura interna. Operano sui dati dell’azienda ed è difficile capire cosa manca semplicemente guardando.

Molte voci aziendali hanno da tempo sostenuto la necessità di creare legami più forti sia con i clienti che con i fornitori. Tuttavia, è più facile a dirsi che a farsi, soprattutto se gli sforzi vengono neutralizzati a causa di continui interventi d’emergenza, rassicurazione dei clienti e pressione sui fornitori. Gli scienziati della supply chain possono fornire un sollievo molto necessario su entrambi i fronti.

S&OP (Sales and Operations Planning) è una pratica diffusa volta a favorire l’allineamento aziendale attraverso una previsione della domanda condivisa. Tuttavia, non importa quali fossero le ambizioni originali, i processi S&OP che ho mai osservato erano caratterizzati principalmente da una serie infinita di riunioni improduttive. A parte le implementazioni ERP e la conformità, non riesco a pensare a nessuna pratica aziendale che danneggi l’anima come S&OP. L’Unione Sovietica può essere scomparsa, ma lo spirito del Gosplan vive ancora attraverso S&OP.

Una critica approfondita di S&OP meriterebbe una lezione a sé stante. Tuttavia, per motivi di brevità, dirò semplicemente che uno scienziato della supply chain è un’alternativa superiore a S&OP in ogni dimensione che conta. A differenza di S&OP, lo scienziato della supply chain si basa su decisioni del mondo reale. L’unica cosa che impedisce a uno scienziato di essere un altro agente di una burocrazia aziendale ingombrante non è il suo carattere o la sua competenza; è avere un coinvolgimento diretto attraverso quelle decisioni del mondo reale.

I pianificatori, i responsabili dell’inventario e i responsabili della produzione sono frequentemente grandi consumatori di tutti i tipi di report aziendali. Questi report sono solitamente prodotti da prodotti software aziendali comunemente definiti strumenti di business intelligence. La pratica tipica della supply chain consiste nell’esportare una serie di report in fogli di calcolo e quindi utilizzare una raccolta di formule di foglio di calcolo per combinare tutte queste informazioni e generare in modo semiautomatico le decisioni di interesse. Tuttavia, come abbiamo visto, la ricetta dello scienziato sostituisce questa combinazione di business intelligence e fogli di calcolo.

Inoltre, né la business intelligence né i fogli di calcolo sono adatti a supportare l’implementazione di una ricetta. La business intelligence manca di espressività, poiché i calcoli rilevanti non possono essere espressi attraverso questa classe di strumenti. I fogli di calcolo mancano di manutenibilità e talvolta di scalabilità, ma soprattutto di manutenibilità. Il design dei fogli di calcolo è in gran parte incompatibile con qualsiasi tipo di correttezza progettuale, che è molto necessaria per scopi di supply chain.

Nella pratica, l’implementazione di una ricetta come quella implementata dallo scienziato include numerosi report aziendali. Questi report sostituiscono quelli che sono stati generati finora tramite business intelligence. Questa evoluzione non implica necessariamente la fine della business intelligence, poiché altri dipartimenti potrebbero ancora trarne vantaggio. Tuttavia, per quanto riguarda la supply chain, l’introduzione dello scienziato della supply chain segna la fine dell’era della business intelligence.

Se mettiamo da parte alcuni giganti tecnologici che possono permettersi di affrontare ogni problema software con centinaia, se non migliaia, di ingegneri, il risultato tipico dei team di data science nelle aziende ordinarie è disastroso. Di solito, quei team non riescono mai a realizzare nulla di sostanziale. Tuttavia, la data science, come pratica aziendale, è solo l’ultima iterazione di una serie di mode aziendali.

Negli anni ‘70, l’operational research era molto popolare. Negli anni ‘80, le regole e gli esperti di conoscenza erano molto richiesti. Alla svolta del secolo, il data mining e i data miner erano molto ricercati. Dagli anni 2010, la data science e i data scientist sono considerati la prossima grande cosa. Tutte queste tendenze aziendali seguono lo stesso schema: si verifica un’innovazione software genuina, le persone ne diventano entusiaste e decidono di incorporare forzatamente questa innovazione nell’azienda attraverso la creazione di un nuovo dipartimento dedicato. Questo perché è sempre molto più facile aggiungere divisioni a un’organizzazione anziché modificare o rimuovere quelle esistenti.

Tuttavia, la data science come pratica aziendale fallisce perché non è saldamente radicata nell’azione. Questa è la differenza fondamentale tra uno scienziato della supply chain, che si impegna fin dal primo giorno a essere responsabile della generazione di decisioni nel mondo reale, e il dipartimento IT.

Se riusciamo a mettere da parte gli ego e i feudi, lo scienziato della supply chain rappresenta un accordo molto migliore rispetto allo status quo precedente. Il tipico dipartimento IT è sommerso da anni di backlog e cercare di ottenere più risorse non è una proposta ragionevole, poiché si traduce in un aumento delle aspettative degli altri dipartimenti e dell’accumulo di lavoro in sospeso.

Al contrario, lo scienziato della supply chain apre la strada a una diminuzione delle aspettative. Lo scienziato si aspetta solo che vengano resi disponibili estratti di dati grezzi e le battaglie di analisi sono di sua responsabilità. Non si aspetta nulla dal dipartimento IT a questo riguardo. Lo scienziato della supply chain non dovrebbe essere visto come una versione aziendale di shadow IT. Si tratta di rendere il dipartimento della supply chain responsabile e responsabile della propria competenza principale. Il dipartimento IT gestisce l’infrastruttura di basso livello e il livello transazionale, mentre il livello decisionale della supply chain dovrebbe essere interamente responsabilità del dipartimento della supply chain.

Il dipartimento IT deve essere un facilitatore, non un decision-maker, ad eccezione delle parti veramente incentrate sull’IT del business. Molti dipartimenti IT sono consapevoli del loro backlog e accettano questo nuovo accordo. Tuttavia, se l’istinto di proteggere ciò che viene percepito come il loro territorio è troppo forte, potrebbero rifiutarsi di rinunciare al livello decisionale della supply chain. Queste situazioni sono dolorose e possono essere risolte solo attraverso l’intervento diretto del CEO.

Da lontano, la nostra conclusione potrebbe essere che il ruolo dello scienziato della supply chain può essere visto come una variante più specializzata dello scienziato dei dati. Storicamente, questo è stato il modo in cui Lokad ha cercato di risolvere i problemi associati alla pratica aziendale della data science. Tuttavia, abbiamo capito dieci anni fa che questo non era sufficiente. Ci sono voluti anni per scoprire gradualmente tutti gli elementi che sono stati presentati oggi.

Lo scienziato della supply chain non è un’aggiunta alla supply chain dell’azienda; è una precisazione sulla proprietà delle decisioni quotidiane banali della supply chain. Per ottenere il massimo da questo approccio, la supply chain, o almeno il suo componente di pianificazione, deve essere ristrutturata. Dipartimenti adiacenti come finanza e operazioni devono anche adattarsi a qualche cambiamento, sebbene in misura molto minore.

Coltivare un team di scienziati della supply chain è un impegno considerevole per un’azienda, ma se fatto correttamente, la produttività è elevata. In pratica, ogni scienziato finisce per sostituire da 10 a 100 pianificatori, previsionisti o responsabili dell’inventario, ottenendo enormi risparmi sulla retribuzione anche se gli scienziati percepiscono salari più alti. Lo scienziato della supply chain illustra un nuovo accordo con l’IT, riposizionando l’IT come un abilitatore anziché un fornitore di soluzioni, eliminando molti, se non la maggior parte, dei collo di bottiglia legati all’IT.

Più in generale, questo approccio può essere replicato in tutti gli altri dipartimenti non IT dell’azienda, come marketing, vendite e finanza. Ogni dipartimento ha le proprie decisioni quotidiane banali da affrontare, che trarrebbero ampio beneficio dalla stessa automazione. Tuttavia, proprio come lo scienziato della supply chain è prima di tutto un esperto di supply chain

Tuttavia, proprio come uno scienziato della supply chain è prima di tutto un esperto di supply chain, uno scienziato del marketing o un quant del marketing dovrebbe essere un esperto di marketing. La prospettiva dello scienziato apre la strada per sfruttare al massimo la combinazione di intelligenza artificiale e umana in questo primo ventunesimo secolo.

La prossima lezione si terrà il 10 maggio, un mercoledì, alla stessa ora di oggi, alle 15:00 ora di Parigi. La lezione di oggi è stata non tecnica, ma la prossima sarà principalmente tecnica. Presenterò tecniche per l’ottimizzazione dei prezzi. I manuali di supply chain di base di solito non considerano i prezzi come elemento della supply chain; tuttavia, i prezzi contribuiscono in modo sostanziale all’equilibrio tra offerta e domanda. Inoltre, i prezzi tendono ad essere altamente specifici del settore, poiché è molto facile affrontare in modo errato la sfida nel complesso quando si pensa in termini astratti. Pertanto, limiteremo le nostre indagini al mercato dei ricambi automobilistici. Sarà l’occasione per riprendere gli elementi presentati con Stuttgart, una delle personae della supply chain che ho introdotto nel terzo capitolo di questa serie di lezioni.

E ora, procederò con le domande.

Domanda: Ci sono voluti quasi dieci anni all’accademia per capire che il campo della data science è emerso e che dovrebbero insegnarlo alle scuole superiori. Vedi già la stessa cosa accadere nei circoli accademici della supply chain con l’adozione della prospettiva delle scienze della supply chain?

Innanzitutto, non sono a conoscenza che la data science venga insegnata nelle scuole superiori in Francia. A scuola superiore insegnano a malapena qualcosa che riguarda il computer, figuriamoci la data science. Non sono nemmeno sicuro di dove troverebbero i professori o gli insegnanti per farlo. Ma posso capire che si voglia che gli studenti delle scuole superiori abbiano una certa competenza digitale. Credo che familiarizzare con la programmazione sia una cosa molto positiva, e si può fare anche prima, dalla mia esperienza personale, a partire dall’età di sette o otto anni, a seconda della maturità del bambino. Si può fare anche nella scuola primaria, ma stiamo parlando solo di concetti di programmazione di base: variabili, elenchi di istruzioni e cose del genere. Credo che la data science superi di gran lunga le cose che dovrebbero essere insegnate a scuola superiore, a meno che non si abbiano dei prodigi o qualcosa del genere. Per me è chiaramente qualcosa per persone a livello universitario, sia a livello di laurea che di laurea magistrale.

Infatti, ci è voluto un decennio all’accademia per mettere in primo piano la data science, ma fermiamoci un attimo. Ho descritto la data science come una pratica aziendale, che è praticamente la versione speculare di ciò che fa l’accademia nell’insegnamento della data science. Quindi, dobbiamo riflettere sul problema e qui, penso che uno dei problemi sia che è incredibilmente difficile insegnare qualcosa che non si pratica. Almeno a livello universitario, se non al di sotto di quello. Quello che vedo è che abbiamo già un problema con la data science, poiché le persone che insegnano la data science non sono le persone che effettivamente la praticano nei luoghi che contano, come Microsoft, Google, Facebook, OpenAI e così via.

Per la supply chain, abbiamo un problema simile e avere accesso a persone con l’esperienza giusta è semplicemente incredibilmente difficile. Spero, e questo è un mio sfacciato plug, che Lokad inizierà, nelle prossime settimane, a cercare di fornire alcuni materiali destinati ai corsi di laurea in supply chain. Inizieremo a diffondere alcuni materiali confezionati in modo da renderli adatti ai professori dell’accademia, in modo che possano diffondere queste conoscenze. Ovviamente, dovranno usare il loro giudizio per valutare se i materiali che Lokad sta diffondendo valgono effettivamente la pena di essere insegnati agli studenti.

Domanda: Il linguaggio specifico di dominio di Lokad non viene utilizzato altrove? Oltre a Lokad, come motivi i potenziali nuovi assunti a imparare qualcosa che probabilmente non useranno mai di nuovo nel loro prossimo lavoro?

Questo è esattamente il punto che stavo facendo riguardo al problema che avevo con i data scientist. Le persone si presentavano letteralmente dicendo: “Voglio fare TensorFlow, sono un esperto di TensorFlow” o “Sono un esperto di PyTorch”. Questa non è l’attitudine giusta. Se confondi la tua identità con un insieme di strumenti tecnici, stai perdendo il punto. La sfida consiste nel comprendere i problemi della supply chain e come affrontarli quantitativamente per generare decisioni di produzione di qualità.

In questa lezione, ho menzionato che ci vogliono sei mesi per un supply chain scientist per acquisire competenza nel mantenere una ricetta e due anni per creare una ricetta da zero. Quanto tempo ci vuole per essere completamente competenti in Envision, il nostro linguaggio di programmazione proprietario? Dalla nostra esperienza, ci vogliono tre settimane. Envision è un piccolo dettaglio rispetto alla sfida complessiva, ma è un dettaglio importante. Se i tuoi strumenti sono scadenti, affronterai enormi problemi accidentali. Tuttavia, siamo realisti: è solo un piccolo pezzo del puzzle generale.

Le persone che trascorrono del tempo presso Lokad imparano immensamente sui problemi della supply chain. Il linguaggio di programmazione potrebbe essere riscritto in altri linguaggi, ma potrebbe richiedere più righe di codice. Quello che le persone, soprattutto i giovani ingegneri, spesso non capiscono è quanto siano transitori molte tecnologie. Non durano a lungo, di solito solo un paio di anni prima di essere sostituite da qualcos’altro.

Abbiamo visto una serie infinita di tecnologie venire e andare. Se un candidato dice: “Mi interesso davvero dei dettagli tecnici”, probabilmente non è un buon candidato. Questo era il mio problema con i data scientist: volevano le cose di moda e all’avanguardia. Le supply chain sono sistemi immensamente complessi e quando si commette un errore, può costare milioni. Hai bisogno di strumenti di produzione di qualità, non dell’ultimo pacchetto non testato.

I migliori candidati hanno un interesse genuino nel diventare professionisti della supply chain. La parte importante è la supply chain, non i dettagli del linguaggio di programmazione.

Domanda: Sto conseguendo una laurea triennale in gestione della supply chain, dei trasporti e della logistica. Come posso diventare un supply chain scientist?

Innanzitutto, ti incoraggio a candidarti presso Lokad. Abbiamo posizioni aperte tutto il tempo. Ma più seriamente, la chiave per diventare un supply chain scientist è avere un’opportunità presso un’azienda disposta ad automatizzare le sue decisioni sulla supply chain. L’aspetto più importante è la proprietà delle decisioni. Se riesci a trovare un’azienda disposta a provare questo, ti aiuterà molto nel diventare uno scienziato.

Mentre affronti le sfide della presa di decisioni di produzione di qualità, ti renderai conto dell’importanza degli argomenti che sto discutendo in questa serie di lezioni. Quando ti occupi di previsioni che guideranno milioni di dollari di inventario, ordini e movimenti di stock, capirai l’immensa responsabilità e la necessità di correttezza nel design. Sono abbastanza sicuro che altre aziende cresceranno e acquisiranno molte più opportunità. Ma anche nei miei sogni più sfrenati, non penso di poter sperare che ogni singola azienda sulla Terra utilizzi Lokad. Ci saranno molte aziende che decideranno sempre di farlo a modo loro, e andranno bene lo stesso.

Domanda: Poiché il 40% della routine giornaliera di un supply chain scientist è dedicato alla programmazione, quale linguaggio di programmazione suggeriresti agli studenti universitari di apprendere per primi, in particolare quelli che studiano management?

Direi quello che è facilmente accessibile. Python è un buon punto di partenza. Il mio suggerimento è di provare effettivamente diversi linguaggi di programmazione. Quello che ti aspetti da un ingegnere della supply chain è praticamente l’opposto di quello che ti aspetti da un ingegnere del software. Per gli ingegneri del software, il mio consiglio predefinito è di scegliere un linguaggio e approfondirlo molto, capendo davvero tutte le sfumature. Ma per le persone che sono fondamentalmente generaliste, direi di fare l’opposto. Prova un po’ di SQL, un po’ di Python, un po’ di R. Presta attenzione alla sintassi di Excel e magari dai un’occhiata a linguaggi come Rust, solo per vedere come sono fatti. Quindi, scegli quello a cui hai accesso. A proposito, Lokad ha dei piani per rendere Envision facilmente accessibile agli studenti gratuitamente, quindi rimani sintonizzato.

Domanda: Pensi che i database a grafo abbiano un impatto significativo sulle previsioni della supply chain?

Assolutamente no. I database a grafo esistono da più di due decenni e, sebbene siano interessanti, non sono potenti come i database relazionali come PostgreSQL e MariaDB. Per le previsioni della supply chain, avere operatori simili a grafi non è ciò che serve. Nelle competizioni di previsione, nessuno dei primi 100 partecipanti ha utilizzato un database a grafo. Tuttavia, ci sono cose che possono essere fatte con il deep learning applicato ai grafi, che illustrerò nella mia prossima lezione sulla determinazione dei prezzi.

Riguardo alla questione se i supply chain scientist dovrebbero essere coinvolti nella definizione degli obiettivi nei progetti di data science dei clienti, credo che ci sia un problema con l’assunzione sottostante di concentrarsi sulla data science prima di capire il problema che stiamo cercando di risolvere. Tuttavia, riformulando la domanda, i supply chain scientist dovrebbero essere coinvolti nella definizione degli obiettivi dell’ottimizzazione della supply chain? Sì, assolutamente. Far emergere ciò che vogliamo veramente è difficile e richiede una stretta collaborazione con gli stakeholder per garantire che vengano perseguite le giuste finalità. Quindi, i ricercatori dovrebbero essere a bordo per questo? Assolutamente, è fondamentale.

Tuttavia, chiarisco che questa non è un’iniziativa di data science; è un’iniziativa di supply chain che ha la capacità di utilizzare i dati come ingrediente adatto. Abbiamo davvero bisogno di partire dai problemi e dalle ambizioni della supply chain e poi, poiché vogliamo sfruttare al massimo il software moderno, abbiamo bisogno di questi scienziati. Ti aiuteranno a perfezionare ulteriormente la comprensione del problema perché la linea di demarcazione tra ciò che è fattibile nel software e ciò che rimane strettamente nel dominio dell’intelligenza umana è un po’ sfocata. Hai bisogno degli scienziati per navigare questa linea di demarcazione.

Spero di vedervi tra due mesi, il 10 maggio, per la prossima lezione, in cui discuteremo dei prezzi. Ci vediamo allora.