Quando si parla di migrazione ERP — verso piattaforme come SAP S/4HANA, per esempio — la discussione si concentra quasi sempre sugli stessi elementi: mapping dei dati, configurazioni, test, cut-over e go-live. Sono tutti passaggi necessari. Ma dopo aver osservato diversi progetti, una cosa emerge con chiarezza: le migrazioni non falliscono per motivi tecnici. Falliscono per motivi organizzativi e umani.
La governance che manca
Un ERP non è un’attività IT — è un progetto complesso che attraversa l’intera organizzazione. Quando mancano una governance chiara, un’allocazione reale delle risorse, una gestione strutturata dei rischi e una sponsorship operativa credibile, il progetto si frammenta in urgenze contingenti. L’attenzione resta sul sistema, ma il modello di delivery resta debole. Il risultato è che si lavora molto senza avanzare davvero.
Il personale amministrativo vive il progetto come un terremoto
Chi lavora in amministrazione è strutturalmente orientato alla continuità operativa: chiusure mensili, scadenze fiscali, quadrature, pagamenti. Il progetto ERP si innesta sopra questo carico senza alleggerirlo. Se non si libera tempo o non si crea una struttura di supporto dedicata, il risultato è prevedibile: stress, resistenza silenziosa, delega progressiva ai consulenti. Il progetto diventa un doppio lavoro invece di una trasformazione. E un doppio lavoro, prima o poi, viene sabotato — non per malevolenza, ma per sopravvivenza.
La qualità dei dati è il vero campo di battaglia
Clienti o fornitori duplicati, dati incoerenti o incompleti, piani dei conti stratificati nel tempo, decimali e arrotondamenti gestiti per convenzione storica. Il data cleansing non è un’attività tecnica — è una decisione organizzativa che richiede responsabilità e priorità chiare. Senza un lavoro preventivo serio, le riconciliazioni esplodono a fine progetto, le quadrature diventano emergenze e il go-live si trasforma in una corsa contro il tempo. La qualità dei dati è un progetto nel progetto, e va trattata come tale fin dall’inizio.
Il nuovo ERP è più rigoroso del passato
Molti sistemi legacy tollerano eccezioni implicite accumulate nel tempo. Un ERP moderno introduce univocità, obbligatorietà dei campi, controlli di coerenza e strutture contabili formalizzate. Il sistema non è più permissivo — e questo non è un difetto, è una caratteristica. Ma se questo cambiamento non viene spiegato con chiarezza, viene percepito come rigidità ostile. Le persone non smettono di fare eccezioni: trovano modi per aggirarle fuori dal sistema.
I consulenti non possono sostituire la responsabilità aziendale
Le società di consulenza portano metodo ed esperienza. Non conoscono però le dinamiche interne, le eccezioni storiche, le abitudini operative che si sono sedimentate negli anni. Quando il progetto diventa “configurate voi, decidiamo noi”, si crea una frattura che si paga cara nelle fasi finali. Serve co-progettazione, non delega. Il consulente può guidare il percorso, ma non può camminare al posto di chi deve abitare il sistema ogni giorno.
Ripensare i processi: trasformazione umanamente accettabile
Migrare un ERP senza ripensare i processi significa replicare inefficienze, irrigidire problemi esistenti e generare rigetto silenzioso. Ripensare i processi significa distinguere ciò che è davvero necessario da ciò che è solo abitudine consolidata. La trasformazione deve essere progressiva, spiegata, condivisa e sostenibile — perché quando le persone non accettano un processo, lo aggirano. E nessun ERP può difendersi dall’aggiramento umano.
Conclusione
Un ERP può essere tecnicamente impeccabile. Ma se non è sostenibile per le persone che lo devono usare ogni giorno, è destinato a generare attrito cronico. La vera differenza non la fa il software. La fa il modo in cui si accompagna il cambiamento.