Le supply chain coinvolgono un insieme di software aziendali. Questi strati di software sono stati implementati gradualmente e a volte in modo casuale negli ultimi quattro decenni1. Il venerabile EDI (Electronic data interchange) potrebbe trovarsi accanto a un prototipo di blockchain. Tali sistemi operano principalmente su aspetti banali ma essenziali della supply chain: produzione, stoccaggio, trasporto, fatturazione, conformità, ecc.

Quante persone servono per cambiare una lampadina nella supply chain?

Questi sistemi non sono stati implementati con l’intento di offrire un ambiente dati pulito per scopi di R&S. Questo unico fatto spiega perché la maggior parte delle iniziative di previsione e, più in generale, la maggior parte delle iniziative di data science falliscono nella supply chain. A titolo di prova aneddotica, di solito è più veloce spostare fisicamente tutte le merci detenute da un magazzino in un altro sito che migrare tutta l’infrastruttura IT in un nuovo sito.

Di conseguenza, a causa di questa complessità, l’implementazione di iniziative di supply chain “moderne” coinvolge inevitabilmente troppi specialisti. Per un’azienda di grandi dimensioni, il tipico progetto di supply chain coinvolge:

  • Il consulente che guida il progetto e assiste la top management.
  • Lo specialista dell’infrastruttura IT che valuta i rischi legati all’infrastruttura IT aggiuntiva.
  • L’amministratore del database che identifica le tabelle rilevanti nei sistemi rilevanti.
  • Lo specialista ETL che progetta il flusso di dati che garantisce la logistica dei dati.
  • Il consulente IT che fornisce un aiuto extra per le parti IT complesse.
  • Il coordinatore del progetto che fa da interfaccia tra il team IT e il team della supply chain.
  • L’analista di business che crea la maggior parte dei report per la direzione.
  • Lo scienziato dei dati che si occupa della parte di modellazione predittiva.
  • Il supporto tecnico del fornitore che gestisce i problemi tecnici dell’introduzione della tecnologia.
  • Il venditore che gestisce le aspettative e cerca di vendere “roba” lungo il percorso.
  • Il praticante della supply chain che rappresenta la “voce del cliente”.
  • L’esecutivo della supply chain che sostiene l’iniziativa.

Tuttavia, avere molti specialisti sul caso crea una serie di problemi. Nessuno, nemmeno la top management, capisce davvero cosa sta succedendo. Le parti IT sono inevitabilmente opache per tutti tranne che per il team IT. Al contrario, l’IT sta lottando così tanto e su così tanti fronti - non solo nella supply chain - che ha pochissima capacità residua per risolvere i dettagli dei problemi che sta cercando di risolvere. Infine, la data science esacerba il problema con un’altra disciplina che è in gran parte opaca sia per i consulenti, l’IT che per i praticanti della supply chain.

Inoltre, terze parti, consulenti, aziende IT e fornitori di tecnologia hanno tutti le loro agende, che non sono allineate con quelle dell’azienda. C’è denaro da guadagnare garantendo un po’ di attrito extra2 ad ogni fase del processo. Questo consente di iniziare con un budget provvisorio ridotto, che “sorprendentemente” tende ad aumentare costantemente nel tempo, poiché sempre più risorse devono essere investite nell’iniziativa.

Parte della complessità elencata sopra è irriducibile, ma un’altra parte è abbastanza accidentale. Il vecchio detto che ogni CEO sa che la metà della sua azienda non sta facendo nulla di valore, ma non sa quale metà.

A tal proposito, la strategia di Lokad, in quanto fornitore tecnologico, è stata quella di affrontare frontalmente questa complessità accidentale. L’idea di base è semplice: ridurre in modo drastico il numero di specialisti coinvolti. Una persona, ovvero lo supply chain scientist, si occupa di tutto il processo IT, che parte dai dati di input grezzi e termina con le decisioni sulla supply chain finalizzate. Lo supply chain scientist si assume la piena responsabilità di tutto ciò che accade lungo il processo - inclusi gli aspetti intelligenti, come il machine learning.

Il software aziendale classico non è compatibile con la supply chain perché un ‘configuratore’ non è sufficientemente espressivo per affrontare la vasta diversità di problemi affrontati dalle supply chain. È necessario un linguaggio di programmazione3. Purtroppo, i linguaggi di programmazione generici, come Python, non sono compatibili con il ruolo di supply chain scientist. La barriera delle competenze è troppo alta e tali ruoli, all’interno dell’azienda, si trasformano in ingegneri del software. Non c’è nulla di sbagliato nell’avere ingegneri del software, è solo che l’esperienza nella supply chain deve essere reintrodotta lungo il percorso attraverso specialisti che non sono ingegneri del software. Presto, la maggior parte dei ruoli elencati sopra fa parte dell’iniziativa.

Tuttavia, affinché lo supply chain scientist possa ricoprire così tanti ruoli, è necessario un ambiente di programmazione dedicato: uno che consenta allo scientist di affrontare le sfide dell’ottimizzazione predittiva di una supply chain con il minor numero di complicazioni4. La risposta tecnologica di Lokad a questo problema è stata Envision, un linguaggio specifico del dominio.

Il concetto di Envision si basa sull’idea che è meglio essere approssimativamente corretti che esattamente sbagliati. Un esperto che può tenere in mente l’intera situazione della supply chain ha molte più probabilità di produrre una soluzione sensata rispetto a 10 esperti, ognuno dei quali è familiare solo con un aspetto della situazione. Inoltre, la soluzione prodotta da una singola mente - rispetto alla soluzione prodotta da un comitato - è quasi sempre più semplice e più facile da mantenere.

Nella maggior parte dei settori ingegneristici, il vantaggio di avere un comitato che lavora sul problema mitiga l’attrito extra introdotto dalla stessa esistenza del comitato. Tuttavia, nella supply chain, questo è raramente il caso. La coerenza end-to-end della strategia, ottenuta come prodotto di una singola mente - o almeno di poche di esse - tende a prevalere sulla maggior parte delle ottimizzazioni ’locali’ che un comitato inevitabilmente offre. Allineare domanda e offerta è fondamentalmente una sfida a livello di sistema5.

Il valore principale dello scienziato della supply chain è operare a livello di sistema, comprendendo l’intera supply chain, dai record elettronici grezzi fino alla strategia elaborata dalla massima dirigenza dell’azienda. Tuttavia, lontano dall’essere un solitario, lo scienziato riceve molta assistenza. L’IT facilita l’accesso ai dati pertinenti (senza cercare di preprocessare i dati). Le operazioni documentano i processi in atto, i vincoli operativi e i vari oneri. Il marketing chiarisce i costi opportunità che non possono essere letti dai libri contabili, ad esempio i costi di stock-out. La massima dirigenza cristallizza la visione, chiarendo ciò che lo scienziato dovrebbe ottimizzare in primo luogo, ecc.

Alla fine, le decisioni sulla supply chain6 non sono il prodotto di un “sistema” in cui la responsabilità è diluita su molte persone, spesso decine. Queste decisioni, tutte, sono il prodotto delle ricette numeriche implementate dallo scienziato della supply chain, una singola mente, che si assume la responsabilità delle loro prestazioni rispetto all’azienda nel suo complesso. Questa persona è fallibile, ma riceve molta assistenza, che include colleghi pronti a prendere il controllo se necessario. Dalla mia esperienza, questo è l’unico modo per iniziare anche solo ad ottimizzare una supply chain, anche se qualsiasi comitato di una certa dimensione seppellirà inevitabilmente tutti gli osservatori sotto KPI, grafici e report nel tentativo di provare il contrario.


  1. Per avere un’idea di come potrebbe essere il software di supply chain ingegneristica tra un paio di secoli, consiglio A Deepness in the Sky (1999) uno dei migliori libri di Vernor Vinge. L’avvento degli archeologi programmatori come professione consolidata potrebbe persino accadere nella nostra vita. ↩︎

  2. Spesso, l’attrito extra inizia anche prima dell’iniziativa di supply chain stessa. Avere consulenti che “aiutano” l’azienda con i processi RFI e RFQ raddoppierà sia i ritardi che i budget con quasi certezza. ↩︎

  3. Questa necessità di programmabilità è soddisfatta oggi da Microsoft Excel. La stragrande maggioranza delle supply chain attuali viene gestita tramite fogli di calcolo, anche quando sistemi più sofisticati come APS (pianificazione e programmazione avanzata) sono presumibilmente in atto. ↩︎

  4. Molti concetti IT sono meglio astratti dagli scienziati della supply chain. Ad esempio: programmazione ad oggetti, codifica del testo, gestione dei pacchetti, gestione delle reti, gestione dei dischi, gestione della memoria, amministrazione di Linux, amministrazione di database, ripristino di emergenza, protocolli API, elaborazione distribuita, multithreading, attacchi di iniezione, attacchi a canale laterale, ecc. ↩︎

  5. Russell Ackoff illustra il pensiero a livello di sistema con la progettazione di una macchina. Se il CEO di un produttore di automobili chiedesse al proprio staff di identificare, per ogni parte dell’auto, la migliore parte trovata sul mercato (i migliori freni a disco, i migliori assi, …) mettere insieme tutte quelle parti non porterebbe nemmeno a una vera auto. Le parti non si adatterebbero. La parte “migliore” ha senso solo quando si considera l’auto nel suo complesso, non in isolamento. ↩︎

  6. Quanto acquistare? Quanto produrre? Quando aumentare / diminuire il prezzo? Quanto spostare il magazzino? Etc. ↩︎