Quante persone ci vogliono per cambiare una lampadina della supply chain?

Joannes Vermorel

Le supply chain coinvolgono un mosaico di enterprise software. Questi livelli di software sono stati progressivamente, e talvolta in modo casuale, implementati negli ultimi quattro decenni¹. Il venerabile EDI (Electronic data interchange) può trovarsi accanto a un prototipo di blockchain. Tali sistemi gestiscono prevalentemente aspetti ordinari, 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 singolo 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 aneddotico, solitamente è più veloce spostare fisicamente tutte le merci detenute da un warehouse in un altro sito, piuttosto che migrare tutta l’infrastruttura IT in un nuovo sito.

A conseguenza di questa complessità, il rollout delle iniziative “modern” della supply chain coinvolge invariabilmente troppi specialisti. Per un’azienda di considerevoli dimensioni, il tipico progetto di supply chain coinvolge:

• Il consulente che guida il progetto e assiste il top management.
• Lo specialista di infrastruttura IT che valuta i rischi legati all’infrastruttura IT aggiuntiva.
• L’amministratore di database che individua le tabelle rilevanti nei sistemi pertinenti.
• Lo specialista ETL che progetta la pipeline che assicura la logistica dei dati.
• Il consulente IT che fornisce un aiuto extra per le parti IT delicate.
• Il coordinatore di progetto che fa da tramite tra il personale IT e quello della supply chain.
• L’analista di business che crea la maggior parte dei report per il management.
• Il data scientist che si occuperà della parte di modellazione predittiva.
• Il supporto tecnico del fornitore che gestisce i bug della tecnologia introdotta.
• Il venditore del fornitore che gestisce le aspettative e incrementa le vendite lungo il percorso.
• Il professionista della supply chain che rappresenta la “voce del cliente”.
• Il dirigente della supply chain che sostiene l’iniziativa.

Tuttavia, avere tanti specialisti coinvolti genera una serie di problemi. Nessuno, nemmeno il top management, riesce davvero a capire cosa stia accadendo. Le parti IT sono invariabilmente opache per tutti, ad eccezione del personale IT. Al contrario, l’IT è talmente in difficoltà e su così tanti fronti - non solo nella supply chain - che ha pochissima disponibilità per occuparsi dei dettagli dei problemi che stanno cercando di risolvere. Infine, la data science peggiora il problema con un’altra disciplina che è per lo più opaca sia per i consulenti, che per l’IT e i professionisti della supply chain.

Inoltre, terze parti, consulenti, aziende IT e fornitori di tecnologia hanno tutti i loro interessi, che non sono allineati con quelli dell’azienda. Si può guadagnare assicurando un po’ di frizione extra² in ogni fase del processo. Questo permette di iniziare con un budget provvisorio esiguo, il quale, “sorprendentemente”, tende a crescere costantemente nel tempo man mano che sempre più risorse devono essere investite nell’iniziativa.

Parte della complessità sopra elencata è irriducibile, mentre un’altra parte è del tutto accidentale. La vecchia battuta secondo cui ogni CEO sa che metà della sua azienda non fa nulla di valore, ma non sa quale metà.

A questo proposito, la strategia di Lokad, in qualità di fornitore di tecnologia, è stata quella di affrontare frontalmente questa complessità accidentale. Il succo è semplice: ridurre in modo drastico il numero di specialisti coinvolti. Una sola persona, ossia il supply chain scientist, si occupa dell’intera pipeline IT, che inizia con i dati grezzi di input e termina con le supply chain decisions finalizzate. Il supply chain scientist si assume la piena responsabilità di tutto ciò che accade lungo la pipeline - inclusi i componenti intelligenti, come il machine learning.

Il software aziendale classico è non compatible with supply chain perché un ‘configuratore’ non è abbastanza espressivo da gestire la pura diversità dei problemi affrontati dalle supply chain. È necessario un linguaggio di programmazione³. Sfortunatamente, i linguaggi di programmazione generici, come Python, sono non compatible with the role of supply chain scientist. Il livello di competenza richiesto è troppo alto, e quei ruoli, all’interno dell’azienda, finiscono per diventare ingegneri del software. Non c’è nulla di male nell’avere ingegneri del software, però, è solo che l’expertise nella supply chain deve essere reintrodotta lungo il percorso attraverso specialisti che non sono ingegneri del software. Ben presto, la maggior parte dei ruoli elencati sopra diventerà parte dell’iniziativa.

Tuttavia, affinché il supply chain scientist possa indossare così tanti cappelli, è necessario un ambiente di programmazione dedicato: uno che permetta allo scientist di affrontare le sfide dell’ottimizzazione predittiva della supply chain con il minimo fastidio⁴. La risposta tecnologica di Lokad a questo problema è stata Envision, a domain-specific language.

Il concetto di Envision si basa sull’idea che è meglio essere approssimativamente corretti che esattamente sbagliati. Un esperto in grado di comprendere l’intera situazione della supply chain è di gran lunga più probabile che produca una soluzione sensata rispetto a 10 esperti, ognuno dei quali è a conoscenza solo di una sfaccettatura della situazione. Inoltre, la soluzione prodotta da una singola mente - rispetto a quella prodotta da un comitato - è quasi sempre più semplice e facile da mantenere.

In molti campi dell’ingegneria, il vantaggio di avere un comitato che lavora sul problema compensa l’ulteriore frizione introdotta dalla mera presenza del comitato. Tuttavia, nella supply chain, questo raramente accade. La coerenza end-to-end della strategia, ottenuta come prodotto di una singola mente - o perlomeno, di poche - tende a superare la maggior parte delle ottimizzazioni “locali” che un comitato fornisce invariabilmente. Allineare offerta e domanda è fondamentalmente una sfida a livello di sistema⁵.

Il principale valore del supply chain scientist consiste nell’operare a livello di sistema, abbracciando l’intera supply chain, dai dati elettronici grezzi fino alla strategia ideata dal top management dell’azienda. Tuttavia, lontano dall’essere un solitario, lo scientist riceve molta assistenza. L’IT facilita l’accesso ai dati rilevanti (senza cercare di preprocessare i dati). Le operations 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 es. i costi di stock-out . Il top management cristallizza la visione, chiarendo ciò che lo scientist dovrebbe ottimizzare in primo luogo, ecc.

Alla fine, le supply chain decisions⁶ non sono il prodotto di un “sistema” in cui la responsabilità è diluita tra molte, frequentemente decine, di persone. Queste decisioni, tutte, sono il risultato delle ricette numeriche implementate dal supply chain scientist, un’unica mente, che si assume la piena responsabilità delle loro prestazioni con riguardo all’azienda nel suo complesso. Questa persona è fallibile, ma riceve molta assistenza, che include colleghi pronti a prendere il controllo se necessario. Nella mia esperienza, questo è l’unico modo per iniziare ad ottimizzare una supply chain, anche se qualsiasi comitato di dimensioni rilevanti inesorabilmente sommergerà tutti gli osservatori con KPI, grafici e report nel tentativo di dimostrare il contrario.