Più veloce di “one‑click”: perché le supply chain programmabili vincono in velocità

Joannes Vermorel

In supply chain, si parla molto di velocità. Velocità di approvvigionamento. Velocità di risposta. Velocità di recupero quando qualcosa va storto. Eppure, quando si tratta dei sistemi destinati a supportare queste decisioni, la conversazione sulla velocità si riduce rapidamente a un’unica metrica: quante settimane ci vogliono per andare in produzione dopo aver firmato un contratto software?

La maggior parte dei grandi fornitori di software per la supply chain ha una risposta molto chiara a questa domanda. Promettono un rapido time‑to‑value grazie a contenuti preconfigurati, modelli di dati standard e “industry best practices.” Se si guarda al marketing delle suite di integrated business planning e dei sistemi di advanced planning, la narrazione risulta notevolmente coerente: partendo dal loro modello di riferimento, applica una serie di template, e potrai essere in produzione in “alcune settimane” o “entro ben 12 settimane,” a volte esplicitamente “da Excel alla pianificazione avanzata in settimane.”

Recentemente, ho cercato di prendere le distanze da questa narrazione nel mio libro Introduction to Supply Chain, in cui inquadramento la supply chain come l’attività di prendere decisioni profittevoli in condizioni di incertezza, giorno dopo giorno. Se consideriamo seriamente questo punto di vista, la domanda “quanto velocemente possiamo distribuire il software?” diventa “quanto rapidamente possiamo mettere in produzione decisioni automatizzate di alta qualità — e mantenerle allineate con l’azienda man mano che essa cambia?” Questa è una domanda molto diversa.

Da qui, arrivo a una conclusione che contrasta con il pensiero comune: per le iniziative serie di supply chain, un approccio programmabile non è solo più potente del tradizionale software confezionato; è in realtà più veloce nel portare risultati significativi in produzione.

Permettetemi di spiegare il motivo.

La rassicurante promessa del software per la supply chain preconfigurato

I fornitori tradizionali di enterprise planning offrono una narrazione rassicurante.

Partono da un modello di dati canonico per la supply chain: locations, products, hierarchies, bills of material, calendars, lead times, constraints. Su questo modello, forniscono processi preconfigurati (“best practices”), sample datasets, template dashboards, alerts, standard algorithms e configuration guides. Tutto questo materiale è esplicitamente progettato per accelerare l’implementazione e ridurre il rischio del progetto.

La logica è perfettamente coerente. Se i dati e i processi di ogni cliente possono essere descritti come una modesta variazione di un template comune, allora la maggior parte del lavoro dovrebbe essere riutilizzabile. Il progetto di implementazione diventa una questione di mappare i campi ERP nel modello di pianificazione, attivare le funzionalità rilevanti, regolare i parametri e insegnare alle persone come utilizzare le schermate.

In quel contesto, la personalizzazione è un male necessario. È accettata per casi “speciali”, ma è anche riconosciuta come la principale fonte di ritardi, sforamenti di budget e complessità a lungo termine. Così, si spinge per la “configuration, not customization” — e più recentemente, per strumenti low‑code e no‑code — per rimanere all’interno del perimetro sicuro di ciò che il software sa già fare.

Sotto queste ipotesi, l’idea che il software confezionato sia più veloce da implementare è del tutto ragionevole.

La difficoltà è che le reali supply chain si adattano raramente a tali ipotesi.

Dove i progetti rallentano davvero: la semantica, non le schermate

Osservando attentamente dove viene effettivamente speso il tempo nelle implementazioni di grandi sistemi per la supply chain, non si tratta di installare il software o addirittura formare gli utenti. Si tratta di capire cosa significano i dati.

La maggior parte delle aziende di grossa taglia dispone di uno o più ERP, oltre a una serie di altri sistemi—CRM, WMS, TMS, PIM, e‑commerce, e così via. Insieme, contengono migliaia di tabelle. Ufficialmente, questi elementi hanno significati documentati; in pratica, la loro semantica reale è il risultato di anni di workarounds, convenzioni locali, compromessi e pulizie parziali. Il vero funzionamento del sistema è codificato nel modo in cui le persone lo utilizzano, e non in come il fornitore originale intendeva che venisse usato.

Quando arriva una planning suite, essa porta con sé il proprio modello di dati e le proprie aspettative. Anche quando proviene dallo stesso fornitore dell’ERP, la semantica non combacia perfettamente. Un campo denominato “location type” o “safety stock” non significa la stessa cosa in configurazione, nelle operazioni quotidiane, nel reporting e nel planning engine.

Qualcuno deve riconciliare tutto questo.

Quel qualcuno è solitamente un team misto di IT, consulenti e business stakeholders. Devono decidere quali tabelle sono autorevoli, quali campi sono affidabili, come gestire le eccezioni e come mappare la caotica realtà dell’azienda nelle strutture chiare attese dal software di pianificazione. Scrivono job di estrazione e trasformazione; aggiungono custom flags e attributi; inventano convenzioni per codificare vincoli che il modello standard non può esprimere.

Questo è il punto in cui quella che supponiamo sia una deployment “one‑click” si trasforma spesso in un vasto sforzo di integrazione. Il software stesso può essere operativo dal primo giorno, ma i dati di cui ha bisogno—quelli precisi, affidabili e aggiornati quotidianamente che un serio optimization engine richiede—ci vogliono mesi o anni per stabilizzarsi veramente.

Questa non è una falla di implementazione. È il sintomo di un fatto più profondo: la semantica è locale, e non esiste una rappresentazione universale e pronta all’uso della supply chain di una data azienda.

La supply chain come software, non come configurazione

Se accettiamo che la semantica è locale, e che continua a evolversi man mano che l’azienda cambia, allora la solita distinzione tra “configuration” e “customization” diventa fuorviante.

Sotto la superficie, un’ambiziosa iniziativa per la supply chain è sempre un esercizio di software. È l’atto di specificare, in forma precisa ed eseguibile, come l’azienda intende prendere decisioni riguardanti acquisti, produzione, inventory, pricing, allocation, e così via, dati i dati e i vincoli disponibili.

Nel tradizionale modello di software confezionato, questo software è composto da tabelle di configurazione, parametri, workflow diagrams, custom connectors e occasional “user exits” scritti in un linguaggio di uso generale. Si spera che la maggior parte della logica possa essere espressa mediante la configurazione, e che solo le parti marginali richiedano codice.

Dalla mia esperienza, specialmente in contesti complessi, accade il contrario. La logica più critica e distintiva finisce per essere implementata in modi fragili: sovraccaricando i campi, stratificando fogli Excel e Python notebooks accanto al sistema ufficiale, insegnando ai pianificatori a interpretare cruscotti in un modo specifico che in realtà non è codificato da nessuna parte.

Il risultato netto è che il “system” è parzialmente nel software e parzialmente nella mente delle persone.

Da Lokad, più di un decennio fa, abbiamo deciso di abbracciare la natura software del problema invece di combatterla. Abbiamo creato il nostro linguaggio specifico di dominio, Envision, rivolto agli operatori della supply chain piuttosto che a ingegneri del software professionisti. L’idea è semplice: rappresentare tutte le trasformazioni dei dati, tutte le previsioni, tutti i vincoli e tutte le decisioni come script che possano essere letti, versionati, testati e modificati in modo controllato.

Dall’esterno, questo sembra un ambiente di programmazione. Internamente, è la nostra risposta al problema semantico: invece di forzare una realtà complessa in un modello preconfezionato, ci forniamo un linguaggio flessibile per descrivere quella realtà com’è in realtà.

Questo ci riporta alla velocità.

Cosa significa essere “veloci” in supply chain?

Se la velocità viene definita come “tempo necessario affinché il fornitore del software possa dichiarare il go‑live secondo la propria checklist”, allora le suite preconfigurate appariranno spesso più veloci. Il piano di progetto è ottimizzato per quella pietra miliare. Il modello canonico è progettato per essere popolato rapidamente. Il materiale di formazione e le migliori pratiche sono allineati a quell’obiettivo specifico.

Tuttavia, se la velocità viene definita come “tempo necessario per disporre di un flusso decisionale automatizzato e operativo di cui ci fidiamo con denaro reale”, il quadro cambia.

In un approccio programmabile, la sequenza del progetto tipicamente appare così:

Innanzitutto, configura estrazioni giornaliere affidabili dai sistemi esistenti, senza cercare di forzarli in un nuovo modello canonico. Questo è comunque un lavoro duro, ma riguarda principalmente l’impiantistica: estrai i dati grezzi, così come sono, con tutta la loro bruttezza.

Successivamente, nell’ambiente programmabile, esprimi la logica di business passo dopo passo: pulizia e riconciliazione dei dati; espressione di vincoli e priorità; modellazione dell’incertezza; e infine calcolo di decisioni concrete come quantità d’ordine, piani di produzione o scelte di allocazione. Poiché questa logica è scritta in un linguaggio su misura, il ciclo di cambiamento è breve: un supply chain scientist può perfezionarla quotidianamente o settimanalmente man mano che emergono casi limite e nuovi requisiti.

Infine, metti queste decisioni in dual‑run: confronta ciò che propongono gli script e ciò che effettivamente fanno i pianificatori, misura l’impatto finanziario e adatta di conseguenza. Quando la fiducia è sufficientemente alta, lascia che gli script prendano il controllo per parti ben selezionate del portafoglio.

Il punto cruciale è che questa sequenza è iterativa. In nessun momento ci aspettiamo che la prima versione della logica sia perfetta. Né ci aspettiamo che l’ambiente rimanga immobile. Invece, assumiamo che le regole decisionali dovranno essere riscritte sostanzialmente ogni anno o due man mano che l’assortimento, la rete, le promesse di servizio e il panorama competitivo evolvono.

In un tale contesto, il principale determinante della “velocità” non è la data del primo go‑live. È il tempo medio per cambiare: quanto tempo occorre per adeguare il sistema quando l’azienda decide di modificare il proprio modo di operare.

Se una politica dei prezzi richiede sei mesi per essere codificata in una suite di pianificazione monolitica, è irrilevante che l’implementazione originale sia terminata in tempo tre anni fa.

Perché la programmabilità diventa più veloce durante l’intera vita del sistema

Visto dall’esterno, la programmabilità sembra un peso. Sicuramente scrivere codice deve essere più lento che configurare una schermata esistente?

In casi semplici, può esserlo. Se la supply chain è relativamente piccola, stabile e vicina al modello di riferimento del fornitore, allora una soluzione preconfigurata potrebbe effettivamente raggiungere rapidamente uno stato stazionario accettabile. Molte aziende non spingono al limite i loro strumenti di pianificazione; li usano come fogli di calcolo strutturati con interfacce utente più gradevoli e alcuni avvisi. In quel contesto, l’approccio confezionato può essere adeguato e, in un senso ristretto, più veloce.

La situazione cambia in modo drammatico non appena ci spostiamo in ambienti che sono:

• grandi ed eterogenei (molti ERP, diverse unità aziendali, molti tipi di prodotti e canali),
• volatili (assortimenti, tempi di consegna e promesse di servizio che cambiano frequentemente),
• e ambiziosi (mirando a elevati gradi di automazione, non solo supporto decisionale).

In tali casi, le soluzioni preconfigurate si trovano ad affrontare tre sfide strutturali.

Prima di tutto, il divario semantico è troppo ampio. Più eccezioni e convenzioni locali ci sono, tanto più il modello canonico deve essere adattato per accoglierle. Ogni adattamento diventa un trucco di configurazione, un’estensione personalizzata o un processo secondario. Col tempo, il sistema accumula strati di casi speciali difficili da comprendere e ancor più difficili da ripulire.

In secondo luogo, il costo del cambiamento è controllato esternamente. Modificare la logica di una grande suite di pianificazione di solito implica molteplici livelli: IT interna, consulenti esterni, a volte anche il fornitore stesso. Esistono cicli di rilascio, protocolli di test e processi di governance progettati per la sicurezza, non per l’agilità. Questo è comprensibile, ma significa che anche cambiamenti sensati e moderati possono richiedere mesi.

In terzo luogo, la logica stessa invecchia rapidamente. Le regole della supply chain che avevano senso tre anni fa sono raramente ottimali oggi. Quando il costo di rivederle è elevato, le organizzazioni tendono a rimandare l’impegno. Si accontentano di soluzioni tampone con fogli di calcolo, sovrascritture e interventi d’emergenza.

Al contrario, un approccio programmabile comporta la maggior parte dei costi in anticipo: bisogna accettare che si sta sostanzialmente scrivendo del software. Ma una volta che si dispone di un ambiente dedicato per questo software—uno sufficientemente specializzato da essere accessibile agli esperti di supply chain, eppure abbastanza espressivo da descrivere la realtà dell’azienda—l’economia del cambiamento si inverte.

Aggiungere un nuovo vincolo, integrare una nuova fonte di dati o rivedere il modo in cui gestisci le promozioni diventa questione di modificare gli script, piuttosto che negoziare una nuova fase di implementazione. Poiché la logica decisionale è esplicita, puoi versionarla, testarla e ripristinarla. Poiché è centralizzata anziché dispersa tra tabelle di configurazione e file secondari, puoi analizzarla nel suo insieme.

Nel corso della vita del sistema, questa capacità di cambiare rapidamente tende a dominare il beneficio una tantum di un go‑live iniziale veloce.

Questo non è un rifiuto del software mainstream

Sarebbe un errore interpretare questo come un argomento contro tutto il software supply chain preconfezionato. Questi sistemi risolvono molti problemi in modo efficace. Forniscono un’elaborazione delle transazioni robusta; si integrano con un ampio ecosistema; offrono interfacce utente, modelli di sicurezza, auditabilità e funzionalità di conformità che sarebbero costose da riprodurre da zero.

Né si tratta di un invito a ogni azienda a costruire tutto internamente utilizzando linguaggi di programmazione generali. Quel percorso porta rapidamente a un proprio tipo di fragilità, con script su misura che proliferano senza disciplina.

Quello che propongo è diverso: un nucleo programmatico per la logica decisionale, circondato dal meglio dei sistemi preconfezionati per tutto il resto.

In altre parole, utilizza il tuo ERP, WMS e TMS per ciò in cui eccellono: registrare ciò che è effettivamente accaduto, far rispettare regole di business semplici e orchestrare i flussi di lavoro. Utilizza suite di pianificazione specializzate dove le loro funzionalità standard si adattano veramente alle tue esigenze. Ma non aspettarti che quegli strumenti preconfezionati siano il luogo in cui risiede la tua logica decisionale più importante, più dinamica e che fa la differenza.

Per questo, hai bisogno di qualcosa che accetti fin dall’inizio che la tua supply chain è unica, che cambierà, e che ogni iniziativa seria alla fine si imbatterà in dettagli semantici che nessun modello aveva previsto.

Un linguaggio specifico di dominio come Envision è una possibile risposta. È quello che abbiamo costruito e perfezionato in Lokad per molti anni, proprio per dare agli esperti della supply chain la capacità di esprimere e mantenere direttamente la propria logica, senza dover passare attraverso strati di intermediari.

Altri fornitori hanno perseguito idee simili in forme diverse; ciò che conta non è l’etichetta “DSL”, ma il principio sottostante: la logica decisionale deve essere di prima classe, programmabile e nelle mani delle persone che comprendono l’economia dell’azienda.

Ripensare la velocità

Se ridefiniamo la velocità come “quanto rapidamente possiamo mettere in produzione decisioni robuste e automatizzate, e quanto rapidamente possiamo revisionarle ogni volta che è necessario?”, la conclusione è inevitabile.

Nel breve termine, le suite preconfigurate sembrano spesso più veloci perché minimizzano il lavoro visibile all’inizio e sono ottimizzate per un avvio cerimoniale. Nel medio e lungo termine, la loro rigidità e il costo del cambiamento le rendono più lente proprio dove la velocità è più necessaria: quando l’ambiente aziendale cambia.

Un approccio programmatico richiede più lavoro inizialmente, ma ripaga ogni volta che la realtà si discosta dalle ipotesi iniziali—cioè, continuamente. In un mondo in cui l’incertezza è la norma piuttosto che l’eccezione, quel tipo di velocità conta più del numero di settimane in una fase di implementazione.

La domanda, quindi, non è se tu voglia scrivere software per la supply chain. Se la tua azienda è sufficientemente grande e complessa, lo stai già facendo—attraverso configurazioni, fogli di calcolo, script locali e convenzioni manuali. L’unica vera domanda è se desideri che quel software sia esplicito, coerente e sotto il tuo controllo.

La mia risposta è chiara: se ci interessa la velocità in un senso significativo, la supply chain deve essere programmabile.