Supply Chain ha bisogno di sistemi programmabili, non di prodotti configurabili

Joannes Vermorel

Ho recentemente pubblicato Introduction to Supply Chain come libro gratuito online. In esso, sostengo che le decisioni della supply chain dovrebbero essere prodotte da sistemi programmabili, anziché da prodotti software “configurabili”. Poiché il libro è volutamente ampio, voglio utilizzare questo post per concentrarmi su un’idea specifica: perché Lokad ha adottato una posizione profondamente programmatica, e perché ciò ci pone in contrasto con la visione mainstream dei software per la supply chain.

Non discuterò di fornitori specifici. Ciò che mi interessa è la filosofia di base: che tipo di software è davvero adeguato per la supply chain?

Perché il software generico fatica con le supply chain concrete

La maggior parte del software venduto nella supply chain oggi segue una storia simile.

Innanzitutto, si parte da una spina dorsale transazionale: qualcosa che registra ordini, ricevute, movimenti di stock, fatture, spedizioni. Questo livello è relativamente standardizzato. Opera con entità familiari: clienti, ordini di acquisto, SKU, ubicazioni. Ci si aspetta che sia generico e riutilizzabile in molte industrie, cosa che in larga misura è.

Sopra questa spina dorsale, si aggiungono moduli di “planning” o “ottimizzazione”. Questi moduli promettono di trasformare i dati passati e presenti in decisioni migliori: ordini di acquisto, trasferimenti, piani di produzione, allocazioni, prezzi, e così via. I fornitori tipicamente presentano queste capacità come applicazioni configurabili. Non scrivi la logica; la configuri. Definisci regole. Imposti parametri. Affini i modelli. Adotti processi di “best-practice”.

A prima vista, questo approccio sembra del tutto ragionevole. Dopotutto, vediamo problemi più o meno simili ovunque: quanto comprare, dove posizionarlo, quando spostarlo, cosa promettere, cosa scontare. Sicuramente una piattaforma generica può affrontare questi problemi in modo riutilizzabile.

Tuttavia, quando si osservano da vicino le supply chain reali, qualcosa di ostinato si frappone: le idiosincrasie.

Un distributore di cavi scopre che diecimila metri di cavo non sono “un numero”; dipende da come quei metri sono distribuiti tra i rocchetti, quali lunghezze i clienti ordinano effettivamente, quale spreco nel taglio è accettabile e quali tagli possono essere promessi senza rovinare i margini.

Un’azienda aerospaziale scopre che “un pezzo in stock” può nascondere un componente serializzato con la propria storia di manutenzione, vincoli di certificazione e regole di sostituzione complesse.

Un rivenditore di moda apprende che la domanda non è solo per “SKU” ma per assortimenti: certe combinazioni di taglia e colore devono essere presenti insieme, altrimenti l’intera categoria va in performance inferiore, indipendentemente da quanti singoli pezzi siano in stock.

Quando proviamo a incasellare queste situazioni in un motore decisionale generico, esse non si comportano come casi marginali. Sono il cuore del business. Ogni azienda ha la sua versione di questi “cavi”: vincoli ed elementi economici che non si adattano a un modello predefinito, eppure determinano la redditività dell’intera operazione.

Il risultato, in pratica, è familiare: moduli di planning configurabili al centro, fogli di calcolo ai margini, e pianificatori umani costantemente impegnati a colmare le lacune.

Perché la configurazione non è sufficiente

Il sogno alla base del software di planning configurabile è che la complessità possa essere domata dalle opzioni: più parametri, più interruttori, più tipi di regole, più modelli. Non dovresti dover programmare; dovresti essere in grado di “insegnare” al software cosa fare attraverso la configurazione.

Purtroppo, la configurazione ha limiti precisi.

La configurazione funziona quando si conosce già la natura del problema. Se ogni azienda condividesse la stessa struttura di vincoli ed elementi economici, lo stesso modello concettuale di come si comporta la domanda e come risponde l’inventario, allora scegliere valori per un insieme predefinito di regole sarebbe sufficiente.

Ma una supply chain reale non è un puzzle fisso in attesa dei parametri giusti. È un bersaglio mobile, modellato dai concorrenti, dalle normative, dalle reti logistiche e dalle abitudini dei clienti che cambiano costantemente. Inoltre, i vincoli più impattanti sono spesso proprio quelli che non si adattano al modello standard di nessuno.

Quando il modello del mondo incorporato nel software non corrisponde al mondo in cui operi, hai solo due opzioni.

Oppure cambi il tuo business per conformarti al software. Questo può essere ragionevole per processi puramente amministrativi, ma pericoloso quando influisce sul tuo vantaggio competitivo.

Oppure compensi al di fuori del sistema: fogli di calcolo aggiuntivi, aggiustamenti manuali, gestione delle eccezioni, interventi dell’ultimo minuto. Il software centrale diventa una sorta di elaborato motore di suggerimenti, mentre il vero controllo torna nelle mani degli esseri umani e nei file Excel.

Più cerchi di estendere un prodotto di planning generico per adattarlo alle tue specificità, più finisci per avere una configurazione intricata che nessuno comprende appieno, e che è difficile da evolvere. Non sei sfuggito alla complessità; l’hai sepolta nei metadati.

Perché la programmabilità è inevitabile

Se la configurazione non è sufficiente, ciò che resta è la programmazione.

La parola “programming” è spesso fraintesa qui. Non sto sostenendo che ogni pianificatore debba diventare un ingegnere del software, né che ogni azienda debba costruire un intero stack da zero. Sto semplicemente affermando qualcosa che ritengo ineludibile:

Se vuoi che un sistema si assuma la responsabilità delle decisioni della supply chain, devi essere in grado di esprimere, precisamente, la logica con cui tali decisioni vengono prese.

Quella logica include:

• Come viene gestita l’incertezza: domanda, tempi di consegna, affidabilità dei fornitori, promozioni, interruzioni.
• Come vengono codificati gli aspetti economici: costo delle rotture di stock, costo dell’eccesso, costi di mantenimento, vincoli di capitale, impegni di servizio, penalità.
• Come vengono applicati i vincoli: imballaggio, quantità minime d’ordine, capacità di camion e container, durata di conservazione, regole di sostituzione, restrizioni normative.
• Come vengono equilibrati i compromessi tra obiettivi contrastanti.

Ognuno di questi elementi è specifico per la tua azienda. Ciascuno cambia nel tempo. E ognuno interagisce con gli altri in modi che nessun catalogo di opzioni di configurazione può anticipare.

Per questo dico che la programmabilità non è una scelta stilistica. È un riconoscimento della realtà. La domanda non è “Dovremmo programmare?” ma “Dove, e usando quale tipo di strumenti?”

I fogli di calcolo sono una forma di programmazione. Sono estremamente popolari nella supply chain proprio perché consentono ai professionisti di esprimere una logica che non si adatta a nessuna applicazione standard. Purtroppo, non scalano bene, incoraggiano la duplicazione della logica e non si prestano a un’automazione robusta.

I linguaggi di programmazione generali possono esprimere qualsiasi cosa, ma comportano un altro problema: se provi a costruire tutta la tua intelligenza della supply chain in uno stack generico, ti ritrovi rapidamente a gestire, in incognito, un’azienda di prodotti software. Devi assemblare e mantenere database, calcolo distribuito, interfacce, sicurezza e pipeline di distribuzione che hanno poco a che fare con il tuo vero business.

La sfida, dunque, è abbracciare la programmazione evitando sia la fragilità dei fogli di calcolo sia l’onere di costruire, da zero, una piattaforma generica.

Come questo modella le scelte tecnologiche di Lokad

Nel 2012, abbiamo fatto una scelta deliberata: non avremmo cercato di produrre un “prodotto di planning” universale che pretendesse di funzionare subito con la sola configurazione.

Invece, ci siamo messi in viaggio per costruire un ambiente in cui la logica decisionale della supply chain possa essere espressa come codice, in modo tale da essere:

• Abbastanza potente da codificare la reale complessità di un’azienda.
• Abbastanza compatto da essere comprensibile e verificabile.
• Abbastanza operativo da funzionare ogni giorno, su larga scala, sopra i sistemi transazionali esistenti.

Concretamente, questo ci ha portato ad alcuni principi.

In primo luogo, trattiamo i dati provenienti dagli ERP e da altri sistemi transazionali come materia prima, non come qualcosa di cui limitarsi a fare rapporti. Supponiamo che il vero valore derivi dal trasformare quei dati in decisioni concrete: ordini di acquisto, trasferimenti di stock, pianificazioni di produzione, politiche di prezzo e sconto, decisioni sull’assortimento.

In secondo luogo, esprimiamo quella trasformazione come una raccolta di script, scritti in un linguaggio specifico per il dominio progettato specificamente per la supply chain: grandi set di dati tabulari, domanda probabilistica, ottimizzazione economica, e così via. Questo linguaggio non è un linguaggio di programmazione aziendale generico; è un ambiente mirato a rendere le ricette decisionali numeriche concise e leggibili.

In terzo luogo, insistiamo che l’output dei nostri calcoli non sia un cruscotto, ma un insieme di azioni proposte che possano essere applicate ai sistemi transazionali. Se il nostro lavoro non si traduce in ordini modificati, stock modificati, prezzi modificati, allora non ha ragione di esistere in produzione.

Infine, strutturiamo tutto in modo che possa essere riscritto. Se il mondo cambia, se una pandemia rimodella la domanda, se una nuova categoria di prodotto si comporta in modo inaspettato, miriamo a cambiare il codice rapidamente e in sicurezza, senza dover aspettare anni per una nuova versione di un prodotto.

Questa è una mentalità molto diversa dal cercare di accumulare sempre più “funzionalità” generiche in un prodotto software. Non cerchiamo di essere tutto per tutti. Cerchiamo di fornire uno strumento affilato che possa essere usato per esprimere la logica che conta veramente per una determinata azienda.

La visione mainstream e dove ci differenziamo

L’approccio mainstream alla tecnologia della supply chain si basa su un’aspirazione ragionevole: standardizzare e industrializzare i processi di planning. Sottolinea suite integrate, best practice predefinite e configurazione user-friendly. Promette una distribuzione più rapida e una ridotta dipendenza da competenze tecniche scarse.

Ci sono situazioni in cui questo approccio offre valore, soprattutto quando il business è relativamente vicino ai modelli standard presunti dal software, e dove gli obiettivi principali sono visibilità, governance e coordinamento di base.

Dove ci differenziamo è nella risposta a una domanda specifica:

Dove dovrebbe un’azienda collocare l’intelligenza che decide realmente cosa fare?

La risposta mainstream è: all’interno di un prodotto configurabile, mantenuto dal fornitore, adattato tramite parametri, flussi di lavoro ed estensioni.

La nostra risposta in Lokad è: all’interno di uno strato compatto e programmabile, gestito da un piccolo team che possiede la logica decisionale e può modificarla man mano che la realtà cambia.

Da questa differenza derivano molte conseguenze pratiche.

In una visione incentrata sul prodotto, la difficoltà centrale è scegliere e implementare il prodotto giusto, per poi allineare l’organizzazione ai suoi processi e funzionalità. Una volta che il prodotto è in atto, l’attenzione si sposta sul suo corretto utilizzo: assicurarsi che le persone guardino i cruscotti, seguano i flussi di lavoro, compilino gli input.

In una visione programmatica, la difficoltà centrale è costruire e mantenere una buona ricetta numerica: una che rispecchi i veri aspetti economici dell’azienda, gestisca l’incertezza in modo significativo e possa essere rivista rapidamente quando necessario. La piattaforma software viene valutata in base a quanto bene supporti questo sforzo: possiamo esprimere vincoli complessi senza trasformare la logica in spaghetti? Possiamo rieseguire le decisioni di ieri per capire cosa è successo? Possiamo sperimentare in sicurezza nuove idee?

Entrambi gli approcci includono algoritmi, previsioni, ottimizzazione e interfacce attraenti. La differenza sta in chi controlla in ultima analisi la logica e in quanto sia adattabile tale logica.

Un percorso ristretto, ma necessario

Il percorso programmatico non è il più facile da spiegare. “Avrete del codice che esprime le vostre decisioni della supply chain” suona meno affascinante di “Avrete un sistema intelligente con best practice configurabili.” Richiede anche una certa disciplina: una chiara attribuzione, una rigorosa gestione delle versioni, una corretta strumentazione, un rilascio attento.

Eppure, dopo quasi due decenni passati ad osservare il software per la supply chain in pratica, non vedo alcuna alternativa valida se prendiamo seriamente l’automazione.

Se vogliamo sistemi che facciano più che suggerire e visualizzare; se vogliamo che si assumano la responsabilità di decisioni che movimentano merci per miliardi di dollari; se vogliamo che sopravvivano agli shock e si adattino a vincoli appena scoperti, allora dobbiamo darci i mezzi per esprimere la logica in modo preciso e per rivederla senza timore.

Questo è ciò che offre la programmabilità.

Lokad esiste perché credo che la supply chain sia troppo importante per essere lasciata a configurazioni opache e prodotti rigidi. Merita un software che riconosca la realtà caotica e peculiare di ogni business, e che fornisca a chi gestisce la supply chain gli strumenti necessari per codificare la propria comprensione in una forma che possa realmente agire.

Questa prospettiva spiega sia le scelte tecnologiche che abbiamo fatto, sia il modo in cui lavoriamo con i nostri clienti. Non vendiamo una scatola che pretende di contenere intelligenza. Forniamo un modo per costruirla, perfezionarla e mantenerla in vita.