Sì. In misura significativa. E non avrei mai osato esprimere questa opinione quando ho fondato Lokad quasi dieci anni fa.

Con il termine “compilazione” mi riferisco all’arte di creare compilatori, ovvero programmi informatici che traducono il codice sorgente in un’altra lingua. Pochi al di fuori della cerchia dei programmatori sanno cosa faccia un compilatore, e pochi tra i programmatori sanno come sia progettato un compilatore. Inizialmente, le questioni relative alla compilazione sembrano distanti (per non dire altro) dalle questioni relative alla supply chain. Eppure, al giorno d’oggi, da Lokad, è proprio la compilazione che continua a salvare la situazione; un progetto di supply chain dopo l’altro.

Pubblicità sfacciata: gli ingegneri del software con competenze di compilazione non crescono sugli alberi, e stiamo assumendo. Vuoi lavorare su cose che contano? Beh, la prossima volta che il tuo aereo sarà in ritardo perché mancava una parte, o la prossima volta che il farmaco che cerchi è esaurito, ricorda che avresti potuto fare la differenza unendoti a Lokad :-)

Le supply chain sono complesse, incredibilmente complesse. La globalizzazione ha moltiplicato le opportunità di approvvigionamento, ma i ritardi sono più lunghi e più erratici che mai. Anche i canali di vendita sono stati moltiplicati: ci sono negozi fisici, negozi online, marketplace, rivenditori, grossisti, … E ora, grazie ad Amazon, tutti, ovunque, si aspettano che tutto venga ordinato e ricevuto durante la notte. Le aspettative della supply chain sono più alte che mai.

Affrontare i problemi della supply chain con qualcosa di meno espressivo di un linguaggio di programmazione non funziona. Proprio come la programmazione con i Lego non accadrà, le sfide della supply chain non si adatteranno a caselle di controllo e menu a discesa. Ciò non impedisce ai fornitori di software di provarci, sia chiaro. Soluzioni che includono più di 1000 tabelle, ognuna delle quali si aggira mediamente intorno ai 100 campi, sono troppo comuni. E mentre l’azienda cliente sta utilizzando solo circa l'1% dell’area delle funzionalità della soluzione, deve comunque fare i conti con la sua complessità pervasiva.

La compilazione salva la situazione perché fornisce un’enorme quantità di conoscenze e know-how quando si tratta di creare astrazioni di alta qualità destinate a essere strumenti potenti per risolvere problemi statistici e combinatori (e molto altro ancora). E la maggior parte delle sfide della supply chain si rivelano essere proprio problemi statistici e combinatori. Ad esempio, da Lokad, introducendo un’algebra delle distribuzioni, siamo riusciti a “risolvere” problemi complicati di tempo di consegna che resistevano ai nostri approcci più diretti attraverso le funzionalità del software confezionato.

Ciò che rende le caratteristiche del linguaggio diverse, ad esempio, dalle solite caratteristiche delle app (wysiwyg), è che le caratteristiche del linguaggio sono molto meno sensibili alle specificità di una determinata sfida rispetto alle loro controparti delle caratteristiche delle app. Ad esempio, consideriamo una situazione in cui la logica di rilevamento delle rotture di stock si rivela inefficace nel caso specifico di prodotti ultra stagionali. Se la funzionalità viene fornita attraverso una costruzione del linguaggio, è sempre possibile restringere l’ambito dei dati fino a quando la funzionalità funziona esattamente dove è destinata a farlo; eventualmente regolando dinamicamente l’ambito attraverso un’analisi numerica ad hoc. Al contrario, con una funzionalità dell’app, sei limitato alle opzioni di filtraggio che sono state incorporate in questa funzionalità. Le funzionalità dell’app sono adatte solo se i tuoi problemi sono ristretti e ben definiti, il che è molto diverso dall’ottimizzazione della supply chain.

Nella supply chain, la programmabilità brilla perché:

  • I problemi sono sia altamente numerici che molto strutturati
  • Le supply chain sono modulari e questa modularità deve essere sfruttata
  • Il numero di variabili è significativo ma non schiacciante
  • È fondamentale adattare la forma precisa dei problemi

È un po’ divertente vedere quanti fornitori di software tendono a reinventare gradualmente la programmabilità. Man mano che l’interfaccia utente diventa più approfondita e complessa, con la possibilità di aggiungere filtri, opzioni, pre-elaborazioni o post-elaborazioni, avvisi con modelli, monitor KPI, l’interfaccia utente diventa gradualmente una cosa programmabile, e raggiunge il punto in cui solo un programmatore può effettivamente comprenderla (grazie alle sue competenze di programmazione preesistenti). Programmabile sì, ma in modo estremamente contorto.

La compilazione è l’arte di amplificare le competenze ingegneristiche: bisogna creare astrazioni e costrutti di linguaggio che semplifichino la risoluzione dei problemi. Come ha scritto famosamente Brian Kernighan: Tutti sanno che il debug è due volte più difficile della scrittura di un programma iniziale. Quindi, se sei il più intelligente possibile quando lo scrivi, come farai mai a debuggarlo? La stessa logica si applica all’ottimizzazione della supply chain, perché è essenzialmente la stessa cosa della scrittura di codice. Beh, da Lokad, è letteralmente la stessa cosa.

La saggezza convenzionale dell’IT afferma che si dovrebbero automatizzare prima le parti facili, lasciando agli esperti umani la gestione degli elementi più complessi. Eppure, nella supply chain, questo approccio fallisce miseramente ogni singola volta. Le parti più complesse della supply chain sono quasi sempre quelle più costose, quelle che necessitano urgentemente di attenzione. Le parti facili possono occuparsi da sole dell’inventario min/max o del Kanban. Proprio come non costruiresti un software per auto autonome raffinando il software per le operazioni automatiche dei treni, non puoi affrontare problemi difficili della supply chain raffinando un software inizialmente progettato per risolvere sfide semplici.

Naturalmente, la compilazione da sola non è sufficiente per affrontare le sfide della supply chain. Vale la pena menzionare anche l’apprendimento automatico, l’elaborazione dei big data e una notevole quantità di competenze umane. Tuttavia, in tutti i casi, avere abstrazioni di alta qualità attentamente realizzate aiuta considerevolmente. L’apprendimento automatico è molto più semplice quando i dati di input sono ben preparati. Anche l’elaborazione dei big data è molto più semplice quando i calcoli si prestano facilmente a un alto grado di parallelizzazione.