Perché l'ERP non gestirà mai la supply chain

Joannes Vermorel

I fornitori di software aziendale amano definire le loro piattaforme la “spina dorsale digitale” dell’azienda. Nel mondo della supply chain, questa spina dorsale solitamente significa ERP, accompagnato da MRP, WMS, TMS, CRM e sistemi simili. Per molte organizzazioni, il prossimo passo naturale sembra ovvio: se l’ERP già gestisce le transazioni, perché non lasciargli gestire anche le decisioni? Aggiungi alcuni moduli di pianificazione, un motore di previsione, alcune funzionalità di AI, e la supply chain dovrebbe più o meno prendersi cura di se stessa.

Dopo quasi due decadi trascorse a costruire software che fa esattamente il contrario, sono giunto a una conclusione alquanto sgarbata: i fornitori tradizionali di sistemi transazionali sono strutturalmente inadatti a fornire sistemi decisionali soddisfacenti per la supply chain. Non si tratta di una critica alle loro competenze. Si tratta della tipologia di software che vendono, degli incentivi economici a cui sono sottoposti e delle aspettative che il mercato ha riposto in loro.

Esploro questo argomento in dettaglio nel mio libro Introduction to Supply Chain, ma voglio tirare fuori un punto qui: perché “dove risiede il cervello” nel tuo panorama software conta più di quanto la maggior parte della letteratura sia disposta ad ammettere.

Cosa stiamo veramente chiedendo al software di fare

Le moderne supply chain non riguardano solo lo spostamento efficiente delle scatole. Si tratta di scommettere in condizioni di incertezza, ogni singolo giorno.

Dovremmo acquistare un container o tre? Rimandare una promozione o anticiparla? Spedire scorte scarse in Europa o negli Stati Uniti? Accettare la quantità minima d’ordine di questo fornitore, oppure opporci e rischiare una rottura? Ogni decisione è una piccola scommessa con conseguenze asimmetriche. Alcuni errori costano poco; altri costano molto e continuano a costare per mesi.

Cinquanta anni fa, gli esseri umani potevano plausibilmente gestire la maggior parte di queste scommesse nella loro testa, assistiti da registri e fogli di calcolo. Oggi, anche le aziende di medie dimensioni gestiscono decine di migliaia di SKU, centinaia di sedi, tempi di consegna volatili e modelli di domanda che reagiscono a prezzi, condizioni meteo, marketing, concorrenti e interruzioni della supply chain. Le combinazioni sono semplicemente al di là del giudizio umano non supportato.

Quindi chiediamo al software di aiutare. Ma “software” non è una cosa univoca. In un’azienda tipica, coesistono tre tipi molto diversi di sistemi:

In primo luogo, ci sono i sistemi transazionali: ERP, MRP, WMS, TMS, OMS. Il loro compito è catturare tutto ciò che accade: ordini, ricevute, spedizioni, fatture, movimenti dentro e fuori dalle sedi. Sono registri glorificati con flussi di lavoro. Le loro virtù principali sono l’affidabilità, la tracciabilità, i permessi e l’auditabilità. Se una spedizione viene eseguita due volte o un pagamento scompare, tutto il resto diventa irrilevante.

In secondo luogo, ci sono i sistemi di reporting e analisi: strumenti BI, dashboard, portali KPI, fogli di calcolo alimentati da data warehouse. Il loro compito è riassumere e visualizzare ciò che è accaduto, e talvolta ciò che potrebbe accadere. Sono progettati per essere ispezionati dagli esseri umani: grafici, tabelle, elenchi di eccezioni, report sulle variazioni.

Infine, c’è qualcosa che nella pratica è per lo più assente: un vero motore decisionale. Con questo intendo un software il cui compito principale è prendere tutti quei dati grezzi, comprenderne i pattern, valutare le opzioni, e poi emettere decisioni concrete e verificabili: ordini di acquisto, movimenti di allocazione, piani di produzione, variazioni di prezzo, modifiche dell’assortimento. Queste decisioni dovrebbero essere prodotte in modo routinario e senza supervisione, e poi reintegrate nei sistemi transazionali come se un pianificatore molto costante e molto veloce avesse svolto il lavoro.

La visione convenzionale tende a confondere questi tre ruoli insieme. Se la “spina dorsale” ERP integra già i dati e gestisce i processi, sicuramente può anche pianificare e ottimizzare. In caso contrario, un’altra piattaforma polivalente lo farà: un “core digitale”, una “torre di controllo” o una “suite di pianificazione unificata.” Nella letteratura si trova abitualmente l’ERP descritto come il cuore dell’elaborazione delle informazioni aziendali e la spina dorsale dell’impresa, con la pianificazione e l’esecuzione della supply chain presentate come estensioni naturali di quella stessa piattaforma.

Su carta, questo è attraente. Nella pratica, è proprio qui che le cose iniziano ad andare storte.

Perché i fornitori transazionali sono nel business sbagliato per costruire il cervello

Per comprendere il disallineamento, è utile prendere le distanze dal branding e osservare cosa sono realmente l’ERP e i suoi simili.

Nel loro cuore, questi sistemi sono grandi database multiutente con regole rigorose su chi può modificare cosa, e in quale sequenza. Sono ottimizzati per molte piccole operazioni semplici e ben strutturate che avvengono contemporaneamente: registrare quest’ordine, contabilizzare quella fattura, confermare questa ricevuta. Quando i manuali di ERP li chiamano la “spina dorsale” dell’impresa, lo intendono letteralmente: trasportano i nervi e i vasi sanguigni delle operazioni quotidiane.

Un vero motore decisionale, invece, non è ottimizzato per migliaia di clic leggeri. È ottimizzato per un pensiero approfondito.

Deve assimilare grandi quantità di dati, spesso provenienti da diversi sistemi. Deve esplorare molteplici futuri possibili, non limitarsi ad estrapolare una singola previsione. Deve valutare le opzioni secondo criteri economici, non solo livelli di servizio o obiettivi di lead time. Deve eseguire calcoli che, a volte, sono costosi: modelli probabilistici, simulazioni, ottimizzazioni combinatorie. E deve fare tutto questo in modo da poter essere verificato in seguito: perché abbiamo acquistato venti pallet di questo articolo in quel giorno, anziché quindici o nessuno?

Non si tratta di una questione di linguaggio di programmazione o di ottimizzazione astuta. È un profilo di esecuzione diverso, compromessi ingegneristici differenti e forme diverse di responsabilità. Collocare questo tipo di motore all’interno dello stesso ambiente che gestisce le tue fatture quotidiane e gli schermi del magazzino è come installare un motore a reazione all’interno di un autobus urbano. Non è semplicemente eccessivo; interferisce attivamente con il compito dell’autobus.

Da qui, emergono diversi problemi strutturali.

Il primo è operativo. Se tenti di eseguire analisi pesanti e grandi lavori di ottimizzazione direttamente sulla tua piattaforma transazionale, o limiti il lavoro analitico per evitare di rallentare le operazioni, oppure rischi di compromettere i tempi di risposta quando gli esseri umani cercano di svolgere il loro lavoro. Più riesci a integrare “intelligenza,” più degradi la missione primaria del sistema: non perdere mai una transazione e non bloccare mai un utente.

Il secondo è semantico. Le aziende moderne raramente operano con un unico monolito. Hanno un ERP per la finanza e le operazioni principali, WMS per i magazzini, TMS per il trasporto, CRM per le interazioni con i clienti, piattaforme e‑commerce, a volte sistemi specializzati per la produzione o il retail. Ciascuno di questi sistemi ha il proprio vocabolario e la propria versione della verità. Tuttavia, un utile motore decisionale deve saper interrogare tutti questi sistemi. La naturale tendenza dei fornitori di ERP, tuttavia, è trattare il proprio schema come il centro dell’universo. Tutto il resto viene o mappato in esso in modo imperfetto o ignorato.

Il terzo è economico. I grandi fornitori di sistemi transazionali vengono principalmente pagati per licenze, postazioni, moduli e spazio di archiviazione; nell’era del cloud, si aggiungono livelli di abbonamento e consumo. Non vengono pagati in base al numero di decisioni che possono automatizzare in sicurezza o a quanto denaro reinvestono nel tuo conto economico. Al contrario, un motore decisionale veramente efficace ridurrebbe il numero di postazioni per i “planner” e semplificherebbe molti flussi di lavoro. Questo non è ciò che il loro modello di prezzo è destinato a premiare.

Sovrapponendo questo all’ecosistema di certificazioni, il quadro diventa ancora più chiaro. Il programma APICS/ASCM CPIM, per esempio, è presentato esplicitamente come lo standard globale per la pianificazione e la gestione degli inventari, e il materiale formativo nota apertamente che i sistemi ERP incorporano regole aziendali derivanti da questo corpus di conoscenza.

In altre parole: si assume che la logica standard di pianificazione risieda all’interno dell’ERP. Si prevede che i fornitori la codifichino; i professionisti la configurino e la seguano. La missione è allineare la pratica al canone, non ripensare l’architettura del software o l’economia delle decisioni.

Infine, c’è la cultura. La costruzione di sistemi di registrazione tende ad attirare, premiare e promuovere una mentalità ingegneristica particolare: quella che valorizza la stabilità, la compatibilità retrospettiva e la copertura degli casi limite. Nel corso dei decenni, questi sistemi accumulano strati di funzionalità, moduli, personalizzazioni e integrazioni. Diventano estremamente capaci, ma anche estremamente complessi. Aggiungere un ulteriore modulo di pianificazione o una funzione di AI è culturalmente più semplice che rimuovere qualcosa. Il risultato è una massa in continuo aumento di schermate di configurazione e parametri, intrecciati in flussi di lavoro che sono già fragili.

Chiedere a questa macchina di reinventarsi come un motore decisionale acuto e con idee decise è, nella migliore delle ipotesi, ottimistico.

La narrativa mainstream, nelle sue stesse parole

Se leggi il materiale dei fornitori, i white paper e gran parte della letteratura accademica e professionale, vedrai la stessa storia ripetuta con piccole variazioni.

L’ERP è presentato come una piattaforma unificatrice che integra tutti i dati e i processi, “armonizzando” approvvigionamento, inventario, elaborazione degli ordini e distribuzione, integrando strumenti di analisi e pianificazione. Viene descritto come la base software dell’azienda, il “core digitale” che supporta tutto, dalla finanza alla produzione fino alla supply chain. Sopra questo core, ci vengono promesse funzionalità sempre più avanzate: previsioni della domanda basate su analisi predittive, modellazione di scenari, pianificazione aziendale integrata e altro ancora.

Parallelamente, il canone della gestione operativa fornisce i modelli mentali: il corpus di conoscenze CPIM, i framework S&OP, le formule per lo stock di sicurezza, la logica MRP. Questi sono codificati come best practice, programmi d’esame e modelli di maturità. La promessa implicita è semplice: se implementi l’ERP giusto, lo configuri secondo questi standard e formi adeguatamente i tuoi planner, la tua supply chain funzionerà.

Se la realtà non corrisponde alla promessa, le spiegazioni usuali sono familiari: qualità dei dati, gestione del cambiamento, ambito del progetto, mancanza di sostegno esecutivo, formazione insufficiente. La soluzione è sempre la stessa: implementazioni più attente, processi più disciplinati, adozione più completa del corpo standard di conoscenza.

Nota ciò che raramente viene messo in discussione: l’assunto che il “cervello” della supply chain debba risiedere all’interno degli stessi sistemi che registrano gli ordini e stampano le fatture.

Ciò che accade realmente sul campo

Sul campo, la maggior parte delle organizzazioni finisce con un modello tristemente coerente tra settori e aree geografiche.

I sistemi transazionali svolgono il loro lavoro in modo ragionevolmente efficiente. Gli ordini scorrono, le scorte si spostano, le fatture vengono emesse, si chiudono i conti finanziari. Ci sono sempre stranezze e frustrazioni, ma in generale i registri funzionano.

Intorno a questo nucleo, il reporting prolifera. Gli strumenti BI si collegano ai data warehouse, che estraggono dati dall’ERP e dai suoi satelliti. I team costruiscono dashboard, scorecard, cockpit e torri di controllo. I planner trascorrono una frazione crescente del loro tempo a navigare in queste schermate, riconciliare le discrepanze tra di esse, esportare dati in fogli di calcolo e reimportare numeri “aggiustati”.

I moduli di pianificazione e ottimizzazione esistono in molti di questi sistemi. Generano previsioni, propongono quantità di riapprovvigionamento, inviano allerte. Eppure, la maggior parte del lavoro pesante rimane manuale. Le previsioni vengono sovrascritte. Gli ordini suggeriti vengono “rivisti” uno per uno. Le liste di eccezioni diventano così lunghe che nessuno può ragionevolmente svuotarle in una giornata lavorativa, così le persone sviluppano euristiche locali: fidarsi di questi indicatori, ignorare quelli, favorire sempre questo fornitore, non toccare mai quei prodotti.

L’automazione assume per lo più la forma di logica condizionale all’interno dei sistemi transazionali: se la disponibilità è superiore a un certo livello, rilascia questo ordine; se inferiore, mettilo in coda come eccezione. Da lontano, questo può sembrare un comportamento intelligente. Da vicino, si tratta di regole fragili accompagnate da strategie umane di gestione.

A volte chiamo questa situazione “automazione come burocrazia”: i sistemi sono elaborati, impegnati, persino impressionanti, ma raramente si assumono la piena responsabilità per una decisione che ha un impatto finanziario reale. C’è sempre un essere umano a dover cliccare “OK” da qualche parte, anche se quel clic è diventato un rituale.

Questo non è l’aspetto di un motore decisionale maturo.

Una diversa separazione delle responsabilità

Se prendiamo sul serio l’idea che la supply chain sia una pratica quotidiana di decisione economica in condizioni di incertezza, allora dovremmo progettare il panorama software in modo da riflettere ciò.

In quel panorama, i sistemi transazionali continuano a fare ciò che sanno fare meglio: rimanere il registro autorevole di ciò che è accaduto e di ciò che è attualmente impegnato. I loro schemi e flussi di lavoro continueranno ad evolversi e rimarranno fondamentali. Ma smettiamo di chiedere loro di essere intelligenti.

I sistemi di reporting continuano a fare ciò che sanno fare meglio: aiutare gli esseri umani a vedere, comprendere e discutere ciò che sta accadendo. Buone dashboard e analisi rimarranno inestimabili. Ma smettiamo di confondere la visualizzazione con l’ottimizzazione.

Poi, separatamente, introduciamo un motore decisionale dedicato.

Questo motore riceve flussi regolari di dati grezzi da tutti i sistemi transazionali rilevanti: ordini, posizioni di stock, capacità, tempi di consegna, prezzi, vincoli. Non gli importa se questi dati provengono da ERP, WMS, TMS o da altro. Ricostruisce una visione coerente del mondo a partire da questi fatti, riconosce esplicitamente l’incertezza nella domanda e nell’offerta, e valuta le azioni alternative in base alle loro conseguenze finanziarie: margine atteso, rischio di esaurimento delle scorte, costo dell’obsolescenza, costi opportunità in risorse limitate.

L’output di questo motore non è una dashboard. È un flusso di azioni proposte: acquistare questa quantità di quel SKU da quel fornitore in quella data; spedire questi pallet da questo magazzino a quello stanotte; aumentare il prezzo di questo articolo del due percento; eliminare gradualmente quella variante nel corso del prossimo mese. Ogni azione è accompagnata da un contesto sufficiente affinché un essere umano possa verificarla, se necessario: quali dati sono stati utilizzati, quali pattern sono stati dedotti, quali compromessi sono stati fatti.

Fondamentalmente, queste azioni vengono riscritte nei sistemi transazionali utilizzando interfacce ben definite. L’ordine d’acquisto viene creato in ERP come se un pianificatore lo avesse digitato. Il trasferimento di stock appare nel WMS come se un responsabile del magazzino lo avesse avviato. La variazione di prezzo viene registrata nel sistema di pricing con una data di validità chiara.

Gli esseri umani non scompaiono dal circuito. Il loro ruolo cambia. Diventano custodi della ricetta numerica: decidono quali costi includere, come valutare il rischio, quali vincoli sono reali e quali scenari sono accettabili. Revisionano e perfezionano il comportamento del motore, anziché microgestire ogni riga che esso produce.

Questa architettura può sembrare esotica solo se hai trascorso troppo tempo nella narrazione incentrata su ERP. Dal punto di vista dell’ingegneria del software e dell’economia, rappresenta semplicemente una chiara separazione delle responsabilità: registri per i fatti, dashboard per la comprensione, motori per le decisioni.

Come questo si confronta con la visione dominante

Visto da questo punto di vista, la narrazione tradizionale non è tanto “sbagliata” quanto incompleta.

È perfettamente ragionevole desiderare una spina dorsale transazionale integrata. Le aziende hanno tratto enormi benefici dal passaggio da sistemi frammentati di contabilità, inventario e produzione a un ERP integrato. È altresì ragionevole richiedere una buona reportistica e standardizzare la terminologia e i processi in tutta la professione. Iniziative come CPIM hanno svolto un ruolo importante nel fornire a tutti un linguaggio comune e un set di strumenti di base.

Dove mi discosto dalla visione tradizionale è nell’assunzione implicita che, se continueremo ad arricchire la spina dorsale transazionale con ulteriori moduli di pianificazione, più funzionalità di previsione, maggiori capacità analitiche e ulteriori opzioni di configurazione, alla fine giungeremo a decisioni di supply chain efficaci e automatizzate.

Non credo che questa convergenza avverrà.

Finché il “cervello” sarà destinato a risiedere all’interno di sistemi la cui missione principale e il cui modello di business sono la conservazione dei registri, i flussi di lavoro basati sui ruoli e le best practice generiche, rimarremo intrappolati in un modello di interfacce impressionanti e automazione timida. Continueremo a vedere organizzazioni in cui i pianificatori trascorrono le loro giornate a gestire elenchi di avvisi anziché modellare la logica economica che li genera.

L’alternativa non è abbandonare l’ERP o ignorare i metodi consolidati. È trattarli per quello che sono: infrastruttura necessaria e prezioso patrimonio professionale, ma non il luogo in cui dovrebbero essere prese le decisioni autentiche.

Una volta accettata questa distinzione, diventa possibile una conversazione più onesta. Possiamo chiedere ai nostri fornitori transazionali registri eccellenti e interfacce chiare, anziché l’“ottimizzazione AI-powered”. Possiamo richiedere ai nostri team di BI viste semplici e veritiere della realtà, anziché dashboard animate che fingono di essere sale di controllo. E possiamo chiedere ai nostri motori decisionali—e alle persone che li costruiscono e li gestiscono—di rispettare standard più elevati: decisioni notturne, non supervisionate, responsabili in termini finanziari, continuamente migliorate.

Questa è la direzione che abbiamo perseguito a Lokad per molti anni. Non è l’unica via, ma è quella che parte da un’osservazione semplice: quando la tua supply chain è effettivamente delimitata dal software, allora il luogo in cui posizioni il cervello di quel software fa tutta la differenza.