Perché le implementazioni ERP falliscono nelle operazioni industriali

Gartner prevede che entro il 2027 oltre il 70% delle iniziative ERP recentemente implementate non riuscirà a soddisfare pienamente i propri obiettivi di business originali. Il 2026 ERP Report di Panorama Consulting ha rilevato che oltre il 25% delle organizzazioni ha superato il budget previsto. Un’analisi del 2026 condotta da Godlan (partner Infor, da considerare come indicativa) ha stimato il tasso di fallimento degli ERP nel manifatturiero al 73%, con sforamenti medi del 215%.

Se gestisci un porto, uno yard, una miniera o qualsiasi operazione guidata dal campo, questi numeri sembrano bassi. Il tasso di fallimento non è un problema di project management. È strutturale. Gli stessi cinque errori si ripetono, nello stesso ordine, in ogni progetto che analizzo a posteriori.

In breve

• Gartner: oltre il 70% dei progetti ERP recenti manca i propri obiettivi di business originali entro il 2027.
• Panorama: oltre il 25% delle implementazioni ERP sfora il budget a causa di ulteriori esigenze tecnologiche.
• Godlan: il 73% dei progetti ERP nel manifatturiero discreto fallisce gli obiettivi, con sforamenti di costo del 215%.
• Cinque pattern di fallimento si ripetono nei progetti industriali: mismatch dei template, debito di integrazione OT, il “burrone” dell’adozione, calo tra pilota e produzione, blocco da costi già sostenuti.
• Hershey (100 milioni di dollari in ordini non evasi), Lidl (500 milioni di euro svalutati) e Revlon (64 milioni di dollari di mancato fatturato nel primo trimestre) mostrano il pattern su larga scala.
• Circa il 60% della realtà operativa vive fuori dai sistemi, in radio, WhatsApp e note di turno che l’ERP non vede mai.

Panoramica dei dati sul fallimento delle implementazioni ERP

Ogni numero riportato nelle sezioni seguenti è verificato da fonte. Questa tabella raccoglie le prove principali in un unico punto di riferimento rapido.

Fonte	Risultato chiave
Gartner	Oltre il 70% delle iniziative ERP recentemente implementate manca gli obiettivi di business originali entro il 2027
Panorama Consulting 2026	Oltre il 25% dei progetti ERP supera il budget, a causa di ulteriori esigenze tecnologiche
Godlan 2026	Il 73% dei progetti ERP nel manifatturiero fallisce gli obiettivi, con uno sforamento medio di costo del 215%
CIO su Hershey	Circa 100 milioni di dollari di ordini di Halloween 1999 non evasi dopo un go-live SAP affrettato
Handelsblatt su Lidl	Riportati circa 500 milioni di euro svalutati dopo il collasso di un progetto SAP durato sette anni
Dolfing su Revlon	64 milioni di dollari di ordini del primo trimestre 2018 non evadibili dopo la migrazione SAP
10-K Revlon 2018	Perdita netta di 294,2 milioni di dollari per l’intero anno 2018, dichiarata nel bilancio annuale

Fonti primarie citate sopra:

I cinque modi in cui i progetti ERP falliscono nelle operazioni industriali

Cinque pattern si ripetono costantemente. Si presentano in combinazioni diverse a seconda delle operazioni e dei fornitori. Ogni implementazione fallita che ho analizzato ne ricalca almeno tre. Ognuno di questi pattern ha la propria sezione qui sotto.

1. Scope creep dovuto a template generici

Ogni ERP importante è costruito su template di processo. Esiste un modo standard di modellare un ordine d’acquisto, e un ordine di lavoro standard. Un record di magazzino standard. Questi template sono stati progettati per la base clienti più ampia possibile.

Si adattano a quella base clienti tanto quanto un capo d’abbigliamento taglia unica si adatta a un corpo umano reale.

Il team di implementazione mappa il processo del cliente sul template. Ovunque non collimi, devono scegliere: personalizzare il sistema o modificare il processo. La personalizzazione è costosa e crea un debito tecnico permanente. Modificare il processo chiede agli operatori di lavorare in modo diverso da come sanno lavorare.

In pratica accadono entrambe le cose contemporaneamente. L’ambito si espande per coprire la personalizzazione. Agli operatori viene comunque chiesto di adattarsi. Il costo di sviluppo cresce in modo significativo prima del go-live. Il risultato non è né un template pulito né una riproduzione fedele del workflow.

Il software su misura parte dal tuo workflow, non da un template del fornitore. Non c’è alcun livello di traduzione tra il modo in cui l’operazione funziona e il modo in cui il sistema si aspetta che funzioni.

2. Debito di integrazione OT

Per tecnologia operativa si intendono SCADA, PLC, MES, telematica e reti di sensori. È ciò che fa funzionare l’operazione fisica. Non parla il linguaggio dell’ERP.

I sistemi ERP sono stati costruiti per dati di business: transazioni, record, approvazioni. L’OT genera segnali in tempo reale a un volume che la maggior parte dei modelli dati ERP non è mai stata progettata per gestire.

La soluzione tipica è un connettore. Un middleware traduce i segnali OT in record compatibili con l’ERP, e i connettori funzionano bene nelle demo. In produzione diventano un progetto di manutenzione pluriennale a sé stante.

Un connettore costruito per un firmware PLC si rompe quando il PLC viene aggiornato. Uno calibrato per 100 eventi al secondo non regge a 10.000. Il backlog di integrazione di sei mesi è ancora aperto due anni dopo. Il team operativo gestisce un processo parallelo su fogli di calcolo perché il sistema connesso è effettivamente collegato solo circa il 60% delle volte.

Ho visto questo pattern ripetersi sul campo, tra porti e yard. I connettori non sono software scadenti. Sono l’architettura sbagliata per il problema.

Il software su misura tratta l’OT come un requisito di prima classe fin dal primo giorno, non come un middleware aggiunto in seguito. Quando il tuo livello di integrazione gestisce SCADA, PLC e telematica come flussi di dati nativi, non c’è alcun debito da connettori da accumulare.

3. Il burrone dell’adozione

Il burrone dell’adozione si presenta quando le persone che usano il sistema ogni giorno decidono di essere più produttive ignorandolo piuttosto che imparandolo. Operatori di terminal, supervisori di turno, dispatcher, squadre di manutenzione.

Non è irrazionale. È una risposta razionale a un sistema progettato in una sala riunioni da un team di progetto che non ha mai gestito un turno.

Il burrone si manifesta entro 90 giorni dal go-live. Il team di progetto se n’è andato. Il team operativo torna a WhatsApp, radio e fogli di calcolo per le decisioni che contano davvero. L’ERP viene usato per i report richiesti dalla finanza.

Il sistema di registrazione diventa un sistema di conformità.

L’adozione non è un problema di formazione. Più formazione su un workflow sbagliato resta più formazione su un workflow sbagliato. L’adozione è un problema di design. Le persone che avrebbero dovuto usare il sistema non erano nella stanza quando il workflow è stato progettato.

Il software su misura si costruisce imparando il campo. Sedendosi con le persone che gestiscono il turno. Mappando le eccezioni reali e i casi limite. Costruendo workflow attorno a ciò che già sanno fare.

Il risultato è un sistema che si adatta al lavoro, così gli operatori lo usano davvero. La vista delle operazioni live assomiglia all’operazione perché è stata costruita a partire dall’operazione.

4. Il calo tra pilota e produzione

I pilota ERP hanno successo. La proof-of-concept gira su dati puliti e curati, e un piccolo gruppo di utenti seguiti passo passo. Un set ristretto di processi che il team di implementazione sa gestire.

Lo sponsor esecutivo vede la demo. Il progetto riceve il via libera, e inizia il rollout completo.

La produzione è un animale diverso. Ha dati legacy disordinati mai completamente ripuliti prima della migrazione. Ha casi limite che il pilota non ha mai toccato. Un vettore con un formato di polizza di carico non standard. Attrezzature con uno storico manutenzioni in un sistema non incluso. Un passaggio di consegne di turno che passa via radio e WhatsApp perché è sempre stato così.

L’ambiente pilota pulito e l’ambiente di produzione live non sono lo stesso posto.

Il calo non è un problema di dati isolato. È ciò che accade quando si pilota su una versione semplificata della realtà, per poi distribuire sulla versione completa senza adattare il sistema.

Il software su misura viene validato in base a come l’operazione si comporta davvero, incluso il dato off-system. Il livello di status capture gestisce ciò che arriva via radio, WhatsApp ed email, non solo ciò che arriva tramite integrazioni strutturate. L’ambiente di produzione è l’ambiente di design.

5. Il blocco da costi già sostenuti

Una volta che un’organizzazione industriale ha speso da due a cinque milioni di dollari in licenze ERP, consulenza e personalizzazione, fare marcia indietro diventa politicamente impossibile.

Il CFO ha approvato la cifra. Il board ha visto la presentazione. Gli operatori che avevano sollevato dubbi in anticipo sono stati messi in minoranza. Quando diventa chiaro che il sistema non manterrà le promesse, l’organizzazione è già dentro da 18 mesi.

Nessuno vuole essere la persona che firma il memo che dichiara l’investimento una perdita.

Quindi l’organizzazione rilancia, e più personalizzazione. Più consulenza, e più change management. Il costo totale cresce, e il go-live slitta. Il sistema che alla fine viene rilasciato è un compromesso che nessuno ha l’autorità di sostituire.

Ho visto team operativi gestire sistemi paralleli per anni, e l’ERP per la conformità. WhatsApp e fogli di calcolo per tutto ciò che davvero contava.

Il software su misura inverte il modello di rischio. Non si spendono due milioni di dollari prima di sapere se il sistema funziona. Si vede una soluzione reale e funzionante sui propri dati, per un problema che si sceglie, e si paga solo se si guadagna il proprio posto. Il primo rischio è nostro.

Come si manifestano i fallimenti ERP su larga scala

I prossimi tre casi sono fallimenti documentati, e numeri reali. Organizzazioni con nome. Ognuno corrisponde a uno o più dei pattern sopra descritti.

Hershey, 1999. Hershey ha effettuato un go-live simultaneo di SAP, Manugistics e Siebel nell’estate del 1999. Il piano è stato compresso di circa sei mesi per arrivare in tempo per Halloween. Il sistema è entrato in produzione mentre affluivano gli ordini di Halloween. Non è riuscito a evadere in tempo circa 100 milioni di dollari di Kisses e Jolly Ranchers. Il titolo Hershey è crollato di circa l’8% in un solo giorno. La causa è stato il calo tra pilota e produzione su scala da 100 milioni di dollari.

Lidl, 2018. Dopo circa sette anni e una spesa stimata di 500 milioni di euro, Lidl ha abbandonato la propria implementazione SAP. Secondo quanto riportato da Handelsblatt, il problema di fondo era una discrepanza nel modello dati. Il modello standard di inventario retail di SAP funziona sui prezzi al dettaglio. L’operazione di Lidl funziona sui prezzi di acquisto. Lidl ha rifiutato di modificare il proprio processo, così SAP è stato personalizzato al suo posto. La personalizzazione è andata avanti per anni senza generare valore. Né Lidl né SAP hanno confermato ufficialmente le cifre riportate. Scope creep da template generici, su scala da 500 milioni di euro.

Revlon, 2018. La migrazione SAP di Revlon presso il proprio stabilimento di Oxford, NC, ha compromesso le spedizioni del primo trimestre. L’azienda non è riuscita a evadere circa 64 milioni di dollari di ordini nel solo primo trimestre. La cifra è emersa in cause collettive di investitori basate su comunicazioni sugli utili. Revlon ha riportato una perdita netta di 294,2 milioni di dollari per l’intero anno 2018 nel proprio 10-K annuale. La cifra di 64 milioni di dollari viene talvolta confusa su LinkedIn con il debito da 3 miliardi di dollari che ha preceduto il successivo fallimento di Revlon. Sono due eventi distinti. Il fallimento ERP del 2018 è stato un fallimento di integrazione OT e di prontezza produttiva.

Il filo conduttore: nessuno di questi era un problema tecnologico. Erano problemi di architettura e di validazione. Ogni organizzazione ha distribuito un sistema che funzionava in un ambiente controllato e si è rotto sotto operazioni reali.

La terza via

Ci sono due risposte ovvie all’elenco di fallimenti sopra descritto.

La prima è costruire internamente, assumendo un team di ingegneria. Definire i requisiti da zero. Costruire software che si adatta esattamente all’operazione, e a volte funziona. Richiede anche un impegno ingegneristico pluriennale, una leadership tecnica che la maggior parte degli operatori non ha, e un investimento continuo per mantenere ciò che è stato costruito.

Se il proprio compito principale è gestire un porto, uno yard o una miniera, costruire software internamente è una distrazione.

La seconda è acquistare un ERP migliore o un SaaS verticale più specializzato e gestire l’implementazione con più attenzione. È la stessa scommessa ripetuta con una governance di progetto migliore. I problemi strutturali non spariscono perché il project manager ha più esperienza.

La terza via è diversa per natura, non per grado. Software su misura: costruito per obiettivi specifici, collegato a sistemi e dati specifici, validato in base a come l’operazione si comporta davvero. Mantenuto attivo e in miglioramento lungo tutto il suo ciclo di vita.

Questa è la terza via di cui abbiamo già scritto. Affronta i pattern di fallimento alla radice, non nei sintomi.

Il modello Opsima rende tutto questo concreto. Impariamo come funziona davvero l’operazione, casi limite inclusi. Costruiamo software progettato attorno a quel workflow. Si integra con l’ERP, l’EAM, il TMS, il TOS o il WMS già in uso, invece di sostituirlo. Gestiamo i dati che non arrivano mai ai sistemi di registrazione: le chiamate radio, i thread WhatsApp, gli appunti scritti a mano durante il turno. È circa il 60% della realtà operativa nella maggior parte degli impianti che ho visitato.

Opsima è la software factory nativa IA per le operazioni industriali. Costruisce il software CMMS, TMS, TOS, EAM, ERP, di monitoraggio attrezzature e di elaborazione documenti su cui gira la vostra operazione, su misura per come ogni operazione lavora davvero.

Due modalità di servizio: (1) personalizzazione sopra il vostro stack esistente (SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) senza nessun rip-and-replace, oppure (2) costruzione da zero quando il sistema legacy ha esaurito il proprio potenziale. Distribuisce in settimane. Si paga solo quando si vede il valore.

Poi andiamo in produzione, validiamo rispetto al comportamento reale in produzione, e manteniamo il sistema attivo e in miglioramento man mano che l’operazione cambia.

Il modello commerciale riflette l’inversione del rischio. Non ci si impegna in un contratto di licenza multimilionario prima di aver visto il sistema funzionare. Costruiamo una soluzione reale e funzionante per un problema scelto dal cliente, sui suoi dati, sulla sua infrastruttura. La si vede funzionare. La si valuta rispetto alla propria operazione, e poi si decide.

I dettagli sono sulla pagina dei prezzi. La versione breve: il primo rischio lo prendiamo noi.

I case study mostrano come questo si traduce nella pratica. Uno di questi è PNCT.

Come si presenta quando funziona

Port Newark Container Terminal gestisce circa 1,65 milioni di TEU l’anno con una flotta di oltre 100 straddle carrier. La flotta opera 24 ore su 24, sette giorni su sette. La disponibilità degli straddle carrier è il vincolo. Quando un mezzo è fermo, il throughput cala. Ogni ora di fermo non pianificato ha un costo reale.

Il problema che PNCT ha portato a Opsima non era esotico. I dati sulle attrezzature, lo storico manutenzioni e i log operativi risiedevano in sistemi che non comunicavano tra loro. I tecnici prendevano decisioni di manutenzione su informazioni incomplete. I guasti erano reattivi, non anticipati.

Opsima ha costruito una soluzione collegata ai sistemi già in uso da PNCT. Telemetria, registri di manutenzione e dati operativi confluiti in un livello di operazioni live che il team di manutenzione poteva davvero usare.

Il risultato: +5% di disponibilità della flotta di straddle carrier e circa il 15% di riduzione dei guasti non pianificati.

Su una flotta di 100 mezzi, il 5% di disponibilità corrisponde a circa cinque unità aggiuntive online per ogni turno. Quelle cinque unità non richiedono nuovi acquisti di attrezzature. Non richiedono nuove spese in conto capitale. Non richiedono nuovo personale. Sono capacità di throughput recuperata dalla flotta esistente grazie a informazioni migliori.

Il team di PNCT lo ha detto chiaramente: “Non siete stati semplicemente un altro grande fornitore di software. Siete arrivati già con un concetto e con un atteggiamento risolutivo.”

Questa è la differenza tra un sistema costruito per mille clienti e uno costruito per te.

Un problema definito con precisione, e un sistema rilasciato. Settimane, non anni.

Un diagnostico ERP fit in 10 domande

Prima di impegnarsi in un’implementazione ERP, o prima di accettare che quella attuale sia la migliore opzione disponibile, rispondi onestamente a queste dieci domande. Ognuna corrisponde a uno dei cinque pattern di fallimento sopra descritti.

Sull’adattamento al template:

1. Il vostro team operativo riesce a descrivere un workflow che l’ERP gestisce esattamente come progettato, senza personalizzazioni o soluzioni di ripiego?
2. Quando un processo cambia sul campo, quanto tempo serve per riflettere quel cambiamento nel sistema? Ore, settimane o mesi?

Sull’integrazione OT:

1. I vostri flussi SCADA e PLC sono trattati come dati di prima classe, oppure vengono acquisiti tramite un connettore esterno all’architettura principale?
2. Il vostro progetto di integrazione è “quasi completo” da più di sei mesi?

Sull’adozione:

1. Le persone che gestiscono i vostri turni hanno avuto un contributo concreto nella progettazione del workflow? O sono state coinvolte solo per lo UAT dopo che la progettazione era già bloccata?
2. Che percentuale delle decisioni operative viene effettivamente presa dentro il sistema rispetto a quelle prese a lato, tramite chiamate radio, WhatsApp e fogli di calcolo?

Dal pilota alla produzione:

1. Il vostro pilota è stato eseguito su un dataset ripulito e curato, oppure su uno snapshot reale e disordinato dei dati di produzione?
2. Il sistema gestisce i casi eccezionali con la stessa efficacia del caso standard? Il vettore non standard, la cronologia di manutenzione incompleta, il passaggio di consegne via radio?

Sul rischio commerciale:

1. Avete visto una soluzione funzionante sui vostri dati prima di impegnarvi nella spesa? O vi siete impegnati sulla base di una demo del fornitore eseguita sui dati del fornitore?
2. Il prezzo dipende dal fatto che il sistema funzioni per la vostra operazione, oppure il fornitore viene pagato comunque?

Se avete risposto no a tre o più domande, non state descrivendo un problema di adattamento dell’ERP. State descrivendo un problema di software su misura.

In sintesi

Le implementazioni ERP falliscono nelle operazioni industriali per ragioni strutturali, e queste ragioni si ripetono.

I template generici costringono le operazioni ad adattarsi, e il debito di integrazione OT si accumula. L’adozione crolla quando le persone che gestiscono l’operazione non erano presenti al momento della progettazione del workflow. I pilot hanno successo su dati puliti e falliscono di fronte alla realtà della produzione. I costi già sostenuti rendono politicamente impossibile cambiare rotta.

L’alternativa è un software costruito attorno alla vostra operazione. Il vostro workflow, i vostri sistemi, i vostri dati. Mantenuto attivo e migliorato lungo il suo ciclo di vita, non consegnato e dimenticato.

Software su misura, costruito per il vostro workflow, pagato solo dopo averne visto il valore. Questo è ciò che l’ERP avrebbe dovuto essere.

Diteci qual è il processo che avete rinunciato a sistemare. Costruiamo una soluzione reale e funzionante sui vostri dati, per un problema che scegliete voi. Pagate solo se si guadagna il suo posto. Per ridurre il rischio della prossima implementazione con un software su misura costruito attorno alla vostra operazione, prenotate una sessione di lavoro con Opsima.