Perché gli ERP sono lenti e costosi da implementare — per design

Joannes Vermorel

Ogni poche settimane incontro un dirigente che sta ancora «distribuendo l’ERP». Il programma è iniziato sotto una precedente squadra di leadership. Il budget è diventato una cifra che nessuno vuole nominare ad alta voce. E il post‑mortem, già in parte scritto, punta il dito contro il fornitore, l’integratore, la «resistenza al cambiamento» o l’unicità dell’azienda. Quella storia è così comune da essere diventata un rumore di fondo.

La scomoda verità è che la maggior parte delle implementazioni ERP sono lente e costose per ragioni strutturali. Non perché ogni squadra coinvolta sia incompetente. Neanche perché i requisiti siano stati poco chiari. Sono lente e costose perché gli incentivi economici e tecnici che hanno plasmato gli ERP nel corso dei decenni li rendono lenti e costosi come categoria.¹

Nel mio libro Introduction to Supply Chain (Capitolo 5, “Informazioni”, sezione “Sistemi di registrazione”), dedico del tempo a un’idea sorprendentemente trascurata: il software che registra le transazioni è allo stesso tempo indispensabile e fondamentalmente limitato. Il suo compito è quello di essere un registro affidabile—nient’altro. Quando le aziende dimenticano ciò, iniziano a pagare prezzi “strategici” per quella che è, in sostanza, una macchina da ufficio transazionale. È proprio da questa incomprensione che insorge il problema.

La giungla delle entità e il tapis roulant dei fornitori

Cominciamo con ciò che un ERP è in pratica. È un sistema transazionale, costruito su un database relazionale, che monitora le risorse dell’azienda e le operazioni di routine attraverso molti moduli, molti schermi e un ampio catalogo di “entità” (prodotti, clienti, fatture, ordini e così via).¹

Ora, ecco la dinamica che garantisce silenziosamente che le implementazioni degli ERP rimarranno dolorose.

Un fornitore di ERP non sviluppa software “per te”. Sviluppa software per l’insieme della propria base di clienti, nel corso dei decenni. Il prodotto cresce per accumulo. Ogni grande cliente porta con sé una manciata di concetti “must-have”, eccezioni, flussi di lavoro, stranezze regolatorie e vocabolario che saranno richiesti come funzionalità di prima classe. I fornitori possono aggiungere; raramente rimuovono. Non c’è vantaggio commerciale nel potare entità oscure da cui dipende qualche cliente legacy. Il risultato è un prodotto che si espande incessantemente, un’entità alla volta, un modulo alla volta.¹

Questo è importante perché la complessità non scala linearmente. Supportare il doppio delle funzionalità costa molto più del doppio dello sforzo ingegneristico, e la “coesione semantica” interna del prodotto si deteriora nel tempo.¹

Durante la prima implementazione, questa espansione è mascherata dalla strategia commerciale. I fornitori di ERP vendono per moduli; le aziende clienti adottano per moduli. Un modulo ora, un altro tra sei mesi, un altro l’anno prossimo. L’azienda ha l’illusione di un progresso incrementale, e l’integratore riesce a dilatare lo sforzo in fasi.¹

Gli aggiornamenti sono dove collassa l’illusione.

Anche se rimani con lo stesso fornitore, gli aggiornamenti sono notoriamente difficili e spesso si protraggono per molti mesi, a volte anni.¹ La ragione tecnica non è misteriosa: la migrazione è raramente una semplice copia uno-a-uno. Il significato delle entità evolve. Una tabella che una volta significava “ordini dei clienti” viene riproposta per rappresentare anche i resi; la “soluzione” diventa quantità negative, flag extra, join aggiuntive, casi speciali e assunzioni a valle che si rompono silenziosamente.¹

Ecco come si ottiene il vero killer: il problema della mappatura.

La maggior parte del lavoro non consiste nell’“installare” il software. Consiste nel costruire una corrispondenza tra due dizionari incompatibili del business: la semantica dell’ERP vecchio e quella dell’ERP nuovo. E poiché entrambe le semantiche sono plasmate dalla storia del fornitore, non solo dalla tua azienda, il numero di concetti che devi riconciliare riflette l’accumulazione della base clienti del fornitore. La tua azienda paga per navigare in un labirinto costruito da tutti gli altri.

La personalizzazione complica ulteriormente il problema. Quando il cliente e il suo integratore aggiungono entità su misura, schermate su misura, flussi di lavoro su misura—elementi che non erano praticabili per il fornitore—quegli elementi personalizzati diventano un dialetto locale. Successivamente, quando il fornitore effettua un refactoring (anche solo leggermente), l’azienda è costretta a una seconda mappatura, molto più brutta: dal vecchio dialetto personalizzato al nuovo dialetto standard, oltre a qualsiasi nuova personalizzazione necessaria per colmare le lacune.

Questo non è un caso fortuito. È ciò che accade quando il successo commerciale di un prodotto dipende dall’espansione continua del suo ambito mantenendo la compatibilità retroattiva per una base clienti diversificata. È l’inevitabilità in slow motion di una giungla di entità.

Quando un sistema tenta di svolgere tre funzioni

Il secondo problema strutturale è ancora più pervasivo: le aziende richiedono abitualmente all’ERP di svolgere tre funzioni differenti contemporaneamente.

Vogliono che l’ERP registri le transazioni (il registro), fornisca analisi e cruscotti (lo “specchio”) e produca decisioni (il “cervello”). I fornitori incoraggiano volentieri questo perché il pacchetto è redditizio: una volta che l’ERP viene inquadrato come “la piattaforma che gestisce l’azienda,” ogni modulo aggiuntivo diventa un “must-have.”²

Eppure, da un punto di vista della progettazione del software, queste funzioni tirano in direzioni opposte.

L’elaborazione delle transazioni riguarda aggiornamenti veloci, affidabili e una forte consistenza. L’elaborazione analitica riguarda la scansione di grandi set di dati, l’aggregazione, il filtraggio e l’esplorazione. Questi sono carichi di lavoro differenti, spesso implementati con modelli di dati differenti e compromessi di prestazioni differenti; l’industria ha avuto nomi per questa distinzione per decenni (OLTP vs OLAP).³

Quando si tenta di fare entrambe le cose con un unico monolite, si crea un sistema che è in perpetuo conflitto con se stesso. Le operazioni “pesanti”—report, analisi, funzionalità di pseudo-pianificazione—competono con le operazioni transazionali ordinarie. Gli utenti lo sperimentano come lentezza, timeout, batch notturni, integrazioni fragili e il ritornello eterno che “il sistema non può farlo”. Nel frattempo, l’azienda paga un premio per il privilegio di inserire contraddizioni nell’architettura.

Non aiuta il fatto che “ERP” sia un nome fuorviante. Storicamente, la “P” di pianificazione suona come una promessa di intelligenza. In realtà, la pianificazione è nel migliore dei casi una preoccupazione secondaria per gli ERP, e l’analisi predittiva tende ad essere in contrasto con il loro design transazionale di base.¹

Il mio articolo di giugno 2024 sul software aziendale sosteneva che lo spreco cronico dell’industria deriva dalla confusione di queste categorie e dal pagare somme esorbitanti per le cose sbagliate. Il punto fondamentale, senza gergo, è semplice: un registro non è un motore strategico, e chiedergli di esserlo produce complessità senza offrire i benefici.²

Se vuoi una conferma vivida che non sono l’unico a pensare in questo modo, guarda come i principali fornitori di cloud spiegano i sistemi di dati: raccomandano esplicitamente di utilizzare sistemi transazionali per memorizzare e aggiornare i record in modo affidabile, e sistemi analitici per generare report e svolgere analisi complesse. Non fingono che una modalità di database eccella in tutto; descrivono ruoli complementari.³

I fornitori di ERP vendono il sogno opposto: un sistema per farlo tutto. Il sogno è lucrativo. Il postumi è pagato dal cliente.

La trappola chiamata “customization” e il lavoro chiamato “migration”

La letteratura di terze parti e la documentazione dei fornitori convergono su un punto che i professionisti conoscono fin nel profondo: customization e migration sono il luogo in cui i progetti vanno a morire.

Un articolo su ScienceDirect sulla customizzazione degli ERP la descrive come una “spada a doppio taglio”, osservando che, sebbene la customizzazione possa migliorare l’adattamento, essa comporta anche costi maggiori di implementazione, una maggiore complessità e spese per aggiornamenti successivi.⁴ Questa è la versione accademica di ciò che gli integratori inseriscono silenziosamente in ogni proposta: ogni deviazione dal percorso standard è una tassa futura.

Anche quando restiamo nell’orbita dei fornitori mainstream, la storia è la stessa. Le linee guida di Microsoft stesso per le implementazioni di Dynamics 365 affermano in modo schietto che “Migrating data is a complex and time-consuming process,” per poi procedere a elencare i tipi di lavori coinvolti: analisi delle fonti, definizione dell’ambito, mappatura e trasformazione dei campi, caricamento, testing, verifica e validazione della qualità dei dati.⁵

Leggete attentamente quell’elenco. Non si tratta di una tecnologia esotica. Non si tratta di “innovation.” È l’industrializzazione della mappatura e della riconciliazione.

Questo è proprio il motivo per cui i programmi ERP si espandono in impegni pluriennali: il lavoro non consiste nel costruire un nuovo software; consiste nel tradurre un’azienda in vita in uno schema dilagante, in costante mutamento e modellato dal fornitore, per poi ripetere l’esercizio durante gli aggiornamenti. Più l’ERP cerca di essere il registro, lo specchio e il cervello, più quella traduzione diventa un progetto perpetuo piuttosto che un esercizio una tantum.

Un’alternativa più sensata: costruire appositamente un piccolo registro

A questo punto, sorge l’ovvia obiezione: “Fine. ERPs are messy. But we need sophisticated features. We need planning. We need optimization. We can’t just build this ourselves.”

Quell’obiezione contiene lo stesso errore di categoria del discorso degli ERP.

Se si restringe l’ambito al registro — lo strato transazionale semplice che cattura la semantica aziendale e supporta i flussi di lavoro di routine — il problema diventa radicalmente più semplice. Non semplice nel senso che non richiede alcun pensiero, ma semplice nel senso che si tratta per lo più di un’applicazione CRUD disciplinata.

Ed è qui che il 2026 è genuinamente diverso dal 2015.

Esistono ora agenti per la codifica specificamente progettati per prendere una base di codice, un insieme di compiti e produrre modifiche funzionanti in rapido tempo. Claude Code di Anthropic è uno strumento di codifica agentico che risiede nel terminale e aiuta a produrre codice attraverso comandi in linguaggio naturale. Codex di OpenAI è stato posizionato come un agente per l’ingegneria del software in grado di gestire compiti quali scrivere funzionalità, correggere bug e proporre pull request. xAI fornisce modelli Grok orientati alla codifica che possono essere utilizzati con editor di codice tramite flussi di lavoro agentici comuni.

Questi strumenti non sono magia. Uno studio randomizzato controllato pubblicato da METR nel luglio 2025 ha addirittura rilevato che, in un contesto particolare (sviluppatori esperti che lavorano su repository open-source familiari), l’uso degli strumenti AI rallentava in media i sviluppatori, perché il tempo si spostava dalla scrittura alla revisione e correzione.⁶ Quel risultato è un promemoria importante: “agentic” non significa “automatico.”

Tuttavia, chiarisce anche dove il vantaggio è più marcato: quando il lavoro è ripetitivo, ben definito e semanticamente limitato—esattamente ciò che dovrebbe essere un registro volutamente noioso.

Ecco la mia raccomandazione, detta chiaramente: per qualsiasi azienda di dimensioni notevoli—diciamo, con un fatturato annuale superiore a €50M—la posizione predefinita dovrebbe essere quella di costruire internamente il livello del registro anziché acquistare un monolite ERP e pagare un decennio di canone al suo ecosistema.

Perché?

Perché il principale driver di costo della “modernizzazione” ERP è la mappatura degli schemi attraverso migliaia di entità modellate dai fornitori e anni di deriva semantica accumulata. Se parti da zero, puoi costruire un livello di registro allineato con la tua semantica, non un compromesso progettato per adattarsi a ogni azienda nel portafoglio del fornitore. In pratica, il modello di dati risultante è spesso di uno o due ordini di grandezza inferiore. Non perché la tua azienda sia banale, ma perché smetti di pagare per i detriti semantici lasciati da altri clienti.

Anche il rollout cambia forma. Invece di un passaggio eroico dopo anni di specifiche, puoi iterare come un team di ingegneria sensato. Importi un nuovo snapshot dei dati legacy. Permetti ai dipendenti di interagire con il nuovo sistema. Segnalano discrepanze tra il software e i flussi di lavoro reali. Adegui il codice. Reimporti. Ripeti finché il registro non è adeguato. Questo approccio è semplicemente la versione disciplinata di quello che le linee guida di Microsoft già implicano: la migrazione necessita di mappatura, test, validazione e prove.⁵

Sì, richiede competenze di programmazione. Tali competenze possono essere interne o esternalizzate, ma devono essere autentiche. Richiede anche quella che chiamo spesso simpatia meccanica: una comprensione sufficiente da parte della leadership per guidare un progetto tecnico senza essere ipnotizzati dalle teatrali dimostrazioni dei fornitori. L’analogia che ho usato altrove è che i grandi piloti non sono ingegneri meccanici, ma sanno abbastanza della macchina per ottenere il meglio da essa.⁷

Questa è la parte che molte aziende cercano di evitare. Preferiscono esternalizzare il pensiero insieme all’implementazione. Preferiscono acquistare l’illusione della sicurezza.

Ma esternalizzare il registro dell’azienda a un monolite i cui incentivi sono crescere, aggregare e creare lock-in, non è sicurezza. È il modo più lento possibile per acquistare software che, alla fine, dovrai comunque sostituire.

Se desideri pianificazione e ottimizzazione, trattale come questioni separate, stratificate sopra un registro pulito. Non costringere il registro a diventare l’ottimizzatore. Non trascinare l’ottimizzazione nel progetto di migrazione. Prima rendi i record accurati, veloci e noiosi. Poi—e solo allora—costruisci sistemi decisionali che possano essere migliorati senza dover riscrivere l’intera memoria aziendale ogni volta.

I deployment ERP sono lenti e costosi perché la categoria ERP si è evoluta sotto incentivi che li rendono lenti e costosi. La via d’uscita non è una migliore gestione di progetto all’interno della stessa trappola. La via d’uscita è smettere di chiedere a un registro di essere un oracolo, e smettere di pagare il bagaglio storico di un fornitore come se fosse il tuo.