La compilation salverà le supply chains?
Con compilation intendo l’arte di creare compilatori, cioè programmi per computer che traducono il codice sorgente in un’altra lingua. Poche persone al di fuori dei ranghi dei programmatori sanno cosa fa un compilatore, e poche persone all’interno di tali ranghi conoscono come viene progettato un compilatore. In un primo momento, le problematiche relative alla compilation sembrano ben distanti, per non dire altro, dalle questioni delle supply chains. Eppure, oggi, qui a Lokad, è la compilation a salvare la situazione; un progetto supply chains dopo l’altro.
Autopromozione senza pudore: ingegneri del software con competenze in compilation non crescono sugli alberi, e stiamo assumendo. Vuoi lavorare su cose che contano? Beh, la prossima volta che il tuo aereo è in ritardo perché mancava una parte, o la prossima volta che il farmaco che cerchi è esaurito, ricordati che avresti potuto fare la differenza entrando in Lokad :-)
Le supply chains sono complesse, esasperantemente complesse. La globalizzazione ha moltiplicato le opportunità di approvvigionamento, ma i ritardi sono più lunghi e più imprevedibili che mai. I canali di vendita si stanno moltiplicando anche: 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 per le supply chains sono più alte che mai.
Affrontare i problemi delle supply chains con qualcosa di meno della piena espressività di un linguaggio di programmazione non funziona. Proprio come la programmazione con Lego non avverrà, le supply chain challenges non possono essere contenute in caselle di controllo e menu a tendina. Questo, però, non impedisce ai software vendors di provarci. Soluzioni che includono più di 1000 tabelle, ciascuna con una media di circa 100 campi, sono fin troppo comuni. E, mentre l’azienda cliente utilizza solo circa l'1% delle funzionalità della soluzione, deve comunque far fronte alla sua complessità pervasiva.
La compilation salva la situazione perché offre un enorme bagaglio di conoscenze e know-how nella creazione di astrazioni di alta qualità, concepite come strumenti potenti per risolvere problemi statistici e combinatori (e molto altro, in realtà). E la maggior parte delle sfide delle supply chains risulta proprio essere di natura statistica e combinatoria. Ad esempio, qui a Lokad, introducendo un’algebra delle distribuzioni, siamo riusciti a debellare complicati problemi di lead time che resistevano ai nostri approcci più diretti tramite funzionalità software confezionate.
Ciò che distingue le funzionalità del linguaggio dalle, ad esempio, solite funzionalità delle app (wysiwyg), è che quelle del linguaggio sono molto meno sensibili alle specificità di una determinata sfida rispetto alle corrispettive funzionalità delle app. Ad esempio, consideriamo una situazione in cui la logica di rilevamento degli stock-out si ritorce contro nel caso specifico di prodotti ultra-stagionali. Se la funzionalità viene erogata tramite un costrutto del linguaggio, puoi sempre restringere l’ambito dei dati finché la funzionalità non operi esattamente dove dovrebbe; possibilmente regolando dinamicamente l’ambito grazie a un’analisi numerica ad hoc. Al contrario, con una funzionalità dell’app sei vincolato alle opzioni di filtraggio integrate in essa. Le funzionalità delle app sono adatte solo se i tuoi problemi sono ristretti e ben definiti, il che è in netto contrasto con l’ottimizzazione delle supply chains.
In supply chains, la programmabilità brilla perché:
- I problemi sono sia altamente numerici che molto strutturati
- Le supply chains sono modulari e tale modularità va sfruttata
- Il numero di variabili è significativo ma non travolgente
- Adattare la forma precisa dei problemi è fondamentale
È alquanto divertente vedere come molti fornitori di software tendano a reinventare gradualmente la programmabilità. Man mano che l’interfaccia utente cresce in profondità e complessità, con la possibilità di aggiungere filtri, opzioni, hook per il pre-processo o il post-processo, avvisi a template, monitor KPI, l’interfaccia utente gradualmente diventa qualcosa di programmabile, fino a raggiungere il punto in cui solo un programmatore riesce davvero a capirla (proprio grazie alle sue pregresse competenze di programmazione). Programmabile sì, ma in maniera estremamente contorta.
La compilation è l’arte di amplificare le capacità ingegneristiche: bisogna creare astrazioni e costrutti di linguaggio che semplifichino il pensiero nella risoluzione dei problemi. Come scrisse famosamente Brian Kernighan: Tutti sanno che fare il debug è due volte più difficile che scrivere un programma in primo luogo. Quindi, se sei tanto intelligente quanto puoi esserlo quando lo scrivi, come farai mai a fare il debug? La stessa logica vale per l’ottimizzazione delle supply chains, perché in sostanza è identica al processo di scrivere codice. Beh, qui a Lokad, lo è letteralmente.
La saggezza informatica convenzionale afferma che bisognerebbe automatizzare prima le parti semplici, lasciando agli esperti umani il compito di gestire gli elementi più complessi. Eppure, nelle supply chains, questo approccio si ritorce contro in modo clamoroso ogni singola volta. Le parti più complesse delle supply chains sono quasi sempre quelle più costose, quelle che richiedono un’attenzione urgente. Le parti semplici possono gestirsi da sole tramite l’inventario min/max o Kanban. Proprio come non costruiresti software per auto autonome perfezionando software per il funzionamento automatico dei treni, non puoi affrontare problemi difficili delle supply chains raffinando software concepito inizialmente per risolvere sfide banali.
Naturalmente, la compilation da sola non è sufficiente per far fronte alle sfide delle supply chains. Anche il machine learning, il processamento dei big data e una notevole quantità di competenze umane meritano di essere menzionati. Tuttavia, in ogni caso, aver creato con cura astrazioni di alta qualità aiuta notevolmente. Il machine learning è immensamente più semplice quando i dati in ingresso sono ben preparati. Il processamento dei big data diventa anche molto più lineare quando i calcoli si prestano facilmente a un elevato grado di parallelizzazione.
