Quante persone servono per cambiare una lampadina nella supply chain?

Joannes Vermorel

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 decenni¹. 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.

Questi sistemi non sono stati implementati con l’intento di offrire un ambiente dati pulito per scopi di R&S. Questo semplice 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.

Come conseguenza di questa complessità, l’implementazione di iniziative di supply chain “moderne” coinvolge inevitabilmente troppi specialisti. Per un’azienda di dimensioni considerevoli, 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 pertinenti.
• 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 più complesse dell’IT.
• 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 introdotti.
• Il venditore che gestisce le aspettative e cerca di vendere “roba” lungo il percorso.
• Il praticante di supply chain che rappresenta la “voce del cliente”.
• L’esecutivo di 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, sia per l’IT, sia 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 extra² ad ogni fase del processo. Questo consente di iniziare con un budget provvisorio ridotto, che “sorprendentemente” tende ad aumentare costantemente nel tempo, man mano che sempre più risorse devono essere investite nell’iniziativa.

Parte della complessità elencata sopra è irriducibile, ma un’altra parte è abbastanza accidentale. Il vecchio detto secondo cui ogni CEO sa che 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 di tecnologia, è 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 finali sulla supply chain. 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 grande diversità di problemi che le supply chain devono affrontare. È necessario un linguaggio di programmazione³. 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 complicazioni⁴. La risposta tecnologica di Lokad a questo problema è stata Envision, un linguaggio specifico per il 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 sistema⁵.

Il valore principale dello scienziato della supply chain è operare a livello di sistema, comprendendo l’intera supply chain, dai dati 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 chain⁶ 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.