10 errori da evitare nella modernizzazione dell'ERP

Gli errori di modernizzazione dell'ERP che fanno più male sono strategici, non tecnici: considerare il go-live come il traguardo, copiare i processi legacy nel nuovo sistema, avviare troppo tardi il lavoro su dati e change, costruire tutto dentro l'ERP e firmare le licenze senza un modello quinquennale. Raramente si vedono in tempo reale. Emergono dopo il go-live, quando le efficienze promesse non arrivano e i workaround tornano.

Questo articolo è per CIO, CFO e programme director che pianificano o recuperano una modernizzazione S/4HANA o di un altro ERP. Ogni errore qui sotto è descritto con l'aspetto che ha nella pratica e con la soluzione. Seguono una checklist di segnali d'allarme di una pagina e ciò che comportano le novità SAP del 2026.

Ho visto progetti ben finanziati, con team esperti e una squadra completa di advisor, non raggiungere comunque l'obiettivo. La causa raramente è il sistema. Sono i vuoti di responsabilità, di pianificazione dell'integrazione e di comunicazione tra team che prendono decisioni dipendenti le une dalle altre.

1. Considerare il go-live come il traguardo

Una volta che il sistema è attivo, molti team danno per finito il lavoro più pesante. È allora che inizia la pressione vera: l'operatività quotidiana, i requisiti che cambiano e il comportamento reale degli utenti mettono alla prova il design.

Ho visto progetti in cui lo steering committee si scioglie subito dopo il go-live. Sei mesi dopo l'adozione è ferma e nessuno è responsabile del backlog.

La soluzione: finanziare un periodo di governance post go-live da 6 a 12 mesi. Estendere il mandato dello steering committee. Monitorare l'adozione dei processi, non solo l'uptime. Fissare quality gate post go-live con responsabili nominati.

2. Migrare i processi legacy senza ripensarli

Ho visto intere catene approvative ricostruite esattamente com'erano, anche quando metà delle persone coinvolte non c'entrava nulla con il processo attuale. Nessuno si era chiesto se i passaggi servissero ancora. Il risultato era un ERP moderno che eseguiva vecchi workflow: una versione più costosa di ciò che avevano già.

La versione S/4HANA di questo errore: job batch custom trasferiti così come sono da ECC, costruiti su strutture di tabelle che non esistono più. La migrazione è tecnicamente pulita. La logica di business è rotta.

La soluzione: ridisegnare i processi prima della build. Ripercorrere insieme a operations, finance e delivery ogni workflow e mettere in discussione ogni passaggio.

Area legacy	Che cosa va spesso storto	Che cosa fare invece
Custom code da ECC	Codice custom inutilizzato trasferito su S/4HANA	Eseguire l'analisi di utilizzo e i custom code check di SAP; dismettere il codice non usato
Vecchi workflow	Flussi approvativi ricostruiti quando oggi l'automazione è possibile	Riesaminarli con i responsabili di business; usare le app Fiori standard o SAP Build Process Automation
Dati anagrafici non standard	I setup legacy flessibili non superano la validazione di S/4HANA	Ripulire e armonizzare prima della migrazione, con SAP MDG dove ha senso
Report su tabelle legacy	L'accesso diretto alle tabelle non corrisponde al modello dati di S/4HANA	Ricostruire su CDS view
Workaround manuali nascosti	I processi paralleli riappaiono dopo il go-live	Usare il process mining prima della migrazione e digitalizzare le lacune

3. Avviare troppo tardi la migrazione dei dati

Portare dati sbagliati in un nuovo ERP è come traslocare senza buttare via niente. Il disordine si trasferisce con tutto il resto, ed è più difficile da eliminare una volta dentro un sistema strutturato.

Una volta ho visto un go-live fallire perché nessuno si era accorto che un dataset centrale conteneva voci provenienti da cinque business unit diverse, ciascuna con la propria logica di codifica. La migrazione tecnica era corretta. I dati non erano utilizzabili. I report si sono rotti, gli utenti hanno perso fiducia e la pulizia su un sistema già in produzione è durata mesi.

La soluzione: fare dei dati un workstream con responsabilità di business. Assegnare i process owner, non solo i consulenti tecnici. Decidere che cosa portare, archiviare o ricostruire prima che parta la migrazione. Eseguire almeno due mock load completi, con una mappa delle dipendenze per la sequenza di caricamento e un rollback definito per ciascun caricamento. Il mio articolo su perché la migrazione dei dati SAP fallisce approfondisce il tema.

4. Trattare il change management come un'attività secondaria

La versione abituale: il change management è «già gestito», il che significa qualche slide, una demo e una sessione di formazione prima del go-live.

Le persone non si oppongono perché detestano il cambiamento. Si oppongono quando nessuno spiega perché le cose cambiano o in che modo le aiuta. Seguono il sistema quel tanto che basta per superare la checklist, poi tornano ai fogli di calcolo.

Il motivo scatenante abituale è la pressione sul calendario: la formazione viene compressa per recuperare tempo, gli utenti sono sopraffatti al go-live e l'hypercare aggiuntivo costa più della formazione tagliata.

La soluzione: dare al change management un budget, un calendario e un responsabile senior propri fin dall'inizio. Mappare presto i ruoli, individuare i champion locali e seguire i KPI di adozione accanto alle milestone tecniche. La mia guida al piano di change management ne descrive la struttura.

5. Pianificare in base alle roadmap dei vendor

Ho visto team basare la propria strategia di integrazione sul rilascio futuro di un vendor, per poi vederlo slittare di 12 mesi. Nel frattempo si sono ritrovati a costruire workaround temporanei, e i workaround sono diventati permanenti.

I vendor costruiscono le roadmap per ampi gruppi di clienti. La sua azienda raramente è al centro di quel disegno.

La soluzione: trattare la roadmap come un input tra gli altri. Progettare attorno a ciò che è oggi disponibile in via generale, provare le nuove funzionalità in una sandbox prima di pianificare su di esse e contare i benefici della roadmap come un potenziale extra, non come budget.

6. Nessun piano di dismissione per i sistemi legacy

Una volta ho visto un'azienda pagare sei cifre all'anno per tenere in funzione un vecchio sistema per sei utenti che dovevano estrarre report due volte l'anno. Nessuno aveva costruito un piano di dismissione.

La soluzione: inserire la dismissione nel project charter fin dal primo giorno, coinvolgendo legale, compliance e data governance, non solo l'IT. Concordare i periodi di conservazione e un approccio di archiviazione prima del go-live, mappare e scollegare ogni interfaccia verso il vecchio sistema e affidare a un solo team il compito di spegnerlo.

7. Sottovalutare la complessità dell'integrazione

Quando l'integrazione fallisce, il business se ne accorge prima dell'IT, perché i workflow si fermano a metà processo in produzione, non in un sistema di test.

Lo schema ricorrente: IT e business danno ciascuno per scontato che l'altro abbia definito i requisiti di integrazione. Nessuno dei due l'ha fatto. Quando le lacune emergono nei test, non c'è più tempo per riprogettare.

La soluzione: avviare la progettazione dell'integrazione già nel blueprint. Definire ogni scenario, il middleware, la mappatura e i volumi di messaggi, e chiarire con il business, interfaccia per interfaccia, tempo reale o batch. Nominare prima del go-live un responsabile di interfaccia con uno SLA. Per i nuovi programmi SAP il middleware è SAP Integration Suite; SAP PI/PO esce dalla manutenzione mainstream a fine 2027.

8. Dare per scontato che l'ERP possa gestire tutto

Ho lavorato a progetti in cui i team hanno forzato dentro l'ERP workflow di servizio complessi (ticket IT, richieste di asset, instradamento delle escalation) perché non volevano coinvolgere sistemi esterni come ServiceNow. Il risultato sono stati campi custom ovunque, workaround manuali e utenti incastrati in un processo che non è mai calzato.

L'ERP è bravo con i processi strutturati, transazionali e ancorati alla finanza. Le piattaforme dedicate gestiscono meglio richieste di servizio IT, orchestrazione dei workflow e knowledge management.

La soluzione: decidere in modo deliberato che cosa non costruire nell'ERP. Usare estensioni side-by-side su SAP BTP per le eccezioni, e ServiceNow o strumenti simili per l'orchestrazione fuori dal nucleo transazionale. Il mio articolo sulla modernizzazione dell'ERP con SAP e ServiceNow tratta questa suddivisione.

9. Sottovalutare il costo delle licenze nel lungo periodo

Conosco un team che nel secondo anno ha raddoppiato la spesa per le licenze perché serviva una sola funzionalità disponibile solo con una licenza di livello superiore. Il business case aveva modellato soltanto il costo al go-live.

Le licenze ERP si pagano per utenti, moduli, transazioni e utilizzo delle API, e il costo cresce con il business, lo si sia pianificato o no. Su SAP, il modello Digital Access fa sì che i documenti creati da sistemi di terze parti possano comportare un costo di licenza che non era nel modello commerciale originale. Con RISE e SAP GROW, il conteggio dei Full User Equivalent (FUE) cresce con l'adozione.

La soluzione: costruire, prima di firmare, un modello di licenze da tre a cinque anni. Associare i ruoli ai tipi di licenza, modellare la crescita dei FUE su una curva di adozione realistica, capire l'accesso indiretto prima di collegare sistemi esterni e fare l'audit degli utenti inattivi dopo il go-live.

10. Trattare l'ERP come un progetto IT

Lo schema più comune e più dannoso. La pianificazione parte dall'IT, è guidata dall'IT e risolve problemi dell'IT.

Ho visto team centrare ogni milestone sulla carta mentre il business continua a chiedersi perché non cambi nulla in meglio. Di solito significa che l'ERP è stato costruito per i processi di ieri, senza i responsabili di operations, finance o commerciale nel design.

La soluzione: portare fin dall'inizio nello steering committee i responsabili commerciali, finance e operations. Scrivere l'allineamento strategico nel charter, non solo il perimetro tecnico. Verificare gli obiettivi del programma rispetto ai risultati attesi dal consiglio di amministrazione prima che inizi il design.

Usi questa checklist a ogni steering committee. Se un segnale d'allarme è presente, il responsabile nominato ne riferisce finché non è sparito.

1. CharterResponsabilità e costiNessun responsabile di operations o finance, nessun modello di licenze quinquennale, nessuna data di dismissione
2. BlueprintDesign di processi e integrazioniIl processo di oggi copiato, interfacce ancora non progettate
3. Primo mock loadDatiAncora nessun report sulla qualità dei dati
4. Go-liveChe cosa succede dopoNessuna governance finanziata per i 12 mesi successivi

Errore	Segnale d'allarme precoce	Responsabile
1. Go-live come traguardo	Nessun piano di governance finanziato per i 12 mesi successivi al go-live	Sponsor
2. Processi legacy copiati	I workshop di design partono dalle schermate di «come lavoriamo oggi»	Process owner
3. Dati affrontati tardi	Nessun report sulla qualità dei dati prima del primo mock load	Responsabile della migrazione dei dati
4. Change come attività secondaria	Il piano di change è un calendario di formazione	Change lead
5. Dipendenza dalla roadmap	Una decisione di design aspetta una funzionalità non ancora rilasciata	Solution architect
6. Nessuna dismissione	Nel charter non c'è una data di dismissione per alcun sistema legacy	PMO
7. Integrazione sottovalutata	Interfacce non progettate entro la fine del blueprint	Integration lead
8. ERP per tutto	Oggetti custom per workflow non transazionali	Enterprise architect
9. Licenze	Nessun modello di licenze quinquennale nel business case	CFO
10. Programma solo IT	Lo steering committee non ha un responsabile di operations o finance	Sponsor

Deployment. Per i nuovi programmi SAP il default è RISE with SAP su SAP Cloud ERP Private, oppure SAP GROW sull'edizione public (SAP Cloud ERP) per le aziende di medie dimensioni. I nuovi deployment on-premise sono rari. I clienti ECC si trovano di fronte alla fine della manutenzione mainstream il 31 dicembre 2027, che riduce il tempo disponibile per correggere gli errori 2, 3 e 7.

Clean Core. SAP ora classifica le estensioni su quattro livelli di Clean Core, dal livello A (solo API rilasciate, side by side su BTP o in-system con ABAP Cloud) al livello D (non pulito). L'edizione public consente solo il livello A, il che impone la discussione alla base dell'errore 2. L'edizione private consente ancora le estensioni classiche, quindi la disciplina deve venire dalla governance. Il codice custom classico è ciò che rende ogni upgrade un progetto. Il mio articolo sulla strategia Clean Core approfondisce il tema.

L'AI negli strumenti di delivery. Joule è ora presente in SAP Cloud ALM e nello SAP Activate Roadmap Viewer, e SAP Build Code usa Joule per lo sviluppo delle estensioni. Chieda ai partner come l'AI sia riflessa nel loro listino tariffe. Se non lo è, o il prezzo è alto, o il risparmio finisce nel loro margine.

Strumenti per il ciclo di vita. SAP Cloud ALM è lo strumento di lifecycle management per i programmi cloud. Solution Manager 7.2 esce dalla manutenzione mainstream a fine 2027, quindi gli ambienti che usano entrambi hanno bisogno di un piano per il passaggio.

I dieci errori non sono cambiati. È cambiato il costo di commetterli. In un programma RISE, la decisione sul Clean Core, il modello di deployment e il modello FUE si fissano tutti nelle prime settimane di mobilitazione. La finestra per influenzarli è breve.

Perché gli sforzi di modernizzazione dell'ERP non raggiungono l'obiettivo dopo il go-live?

La maggior parte dei team pianifica fino al go-live e si ferma. Nessuno si occupa di miglioramenti, feedback, correzioni di processo o backlog. Lo steering committee che si scioglie al go-live è il segnale di guai più affidabile. Finanzi da 6 a 12 mesi di governance post go-live fin dal primo giorno.

Qual è il rischio di copiare i processi legacy in un nuovo ERP?

Il nuovo sistema eredita le vecchie inefficienze a un costo più alto. Nelle migrazioni a S/4HANA in particolare, il codice custom e i job batch costruiti per le tabelle ECC spesso non funzionano, quindi la migrazione può essere tecnicamente pulita mentre la logica di business è rotta.

In che modo la scarsa qualità dei dati danneggia una modernizzazione dell'ERP?

Fornitori duplicati, dati anagrafici incoerenti, codici legacy e record incompleti passano tutti nel nuovo sistema se nessuno li ripulisce prima. I report si rompono, gli utenti smettono di fidarsi dei numeri e la pulizia su un sistema già in produzione richiede mesi.

Perché il change management è così spesso sottovalutato nei progetti ERP?

Perché in un piano di progetto non si vede come la configurazione. I dirigenti pensano che bastino un paio di sessioni di formazione. Il change management consiste nel preparare le persone a ciò che cambierà davvero nel loro lavoro quotidiano, prima del go-live. Gli strumenti di digital adoption come WalkMe, oggi di proprietà di SAP, aiutano con la guida in-app, ma non sostituiscono la spiegazione del perché.

Perché i sistemi legacy restano attivi per anni dopo il go-live dell'ERP?

Perché nessuno ha pianificato di spegnerli. Tutti sono concentrati sul mettere in produzione il nuovo ERP, e i vecchi sistemi restano per compliance, consultazione o per tranquillità. La dismissione deve rientrare nel perimetro fin dal primo giorno, con legale e compliance coinvolti.

Come cambiano questi errori con RISE with SAP e il Clean Core?

Nell'edizione public, le regole del Clean Core rendono impossibile la personalizzazione profonda, il che impone la discussione sui processi alla base dell'errore 2. Nell'edizione private le estensioni classiche sono ancora consentite, quindi il Clean Core dipende dalla governance. L'integrazione passa a SAP Integration Suite man mano che termina la manutenzione di PI/PO. Il licensing diventa una questione di crescita dei FUE. La dismissione diventa più urgente perché far girare in parallelo i sistemi legacy aggiunge costi a un abbonamento pluriennale.