Modernizzazione dell'ERP nel 2026: cloud, AI e Clean Core

Modernizzare l'ERP nel 2026 significa prendere tre decisioni, in quest'ordine: che cosa l'ERP deve smettere di fare, quanto pulito si vuole mantenere il suo core e se i dati sono abbastanza buoni da rendere utile l'AI. Per i clienti SAP dietro a tutte e tre c'è una data certa: la manutenzione mainstream di ECC termina il 31 dicembre 2027, con manutenzione estesa a pagamento fino alla fine del 2030.

Questo articolo è per CIO, CFO ed enterprise architect che hanno finito l'analisi e ora devono eseguire. Tratta le forze che spingono ad agire, l'architettura con backbone e satelliti, il Clean Core, il vuoto di governance, la prontezza all'AI e una tabella dei rischi per i prossimi 18 mesi.

Nel 2024 la maggior parte dei dirigenti guadagnava ancora tempo: studiava le tempistiche di ECC, discuteva tra ibrido e migrazione completa, faceva prove in sandbox senza impegnarsi. Quella finestra si è chiusa. Il debito tecnico nei panorami ECC e Oracle E-Business Suite non è più teorico. Si manifesta nei test di regressione falliti dopo gli aggiornamenti, nei rilievi di audit su custom code di cui nessuno è responsabile e nei dati che impiegano 12 ore per passare dai sistemi di pianificazione a quelli di esecuzione.

La scadenza. Dopo il 2027 i clienti ECC possono acquistare la manutenzione estesa fino alla fine del 2030, a una tariffa più alta. Oltre, SAP offre un'opzione di transizione verso la private edition dell'ERP per il periodo 2031-2033, ma solo tramite RISE, e SAP precisa che è un'offerta di transizione a pagamento, non un'estensione della manutenzione. Intanto, una ricerca Gartner riportata da The Register ha rilevato che alla fine del 2024 solo il 39% circa dei circa 35.000 clienti ECC di SAP aveva acquistato o sottoscritto licenze S/4HANA. Avere la licenza non significa aver migrato. Il mercato dei partner sarà in tensione.

Il modello di budget. L'ERP in cloud sposta la spesa dalle licenze in capex alle sottoscrizioni. Sembra più lineare. In pratica i CFO trovano i costi del cloud meno prevedibili: con RISE with SAP e SAP GROW, la crescita dei Full User Equivalent (FUE), i servizi aggiuntivi e i costi di integrazione aggiungono voci che non erano nel business case iniziale.

Frammentazione in finanza e supply chain. I team finanziari usano l'AI su contabilità fornitori e clienti mentre i processi di audit usano ancora template pensati per un'altra epoca. Le supply chain sono modernizzate solo in parte: SAP IBP per la pianificazione, un warehouse management più vecchio per l'esecuzione, Ariba per gli acquisti ma entrate merci manuali. Il collo di bottiglia non è la tecnologia. Sono le giunzioni tra i sistemi.

L'ERP è un livello, non l'intero stack. In molte aziende ServiceNow gestisce l'orchestrazione dei processi, Salesforce i flussi con i clienti, Workday o SuccessFactors il ciclo di vita delle risorse umane. L'ERP è diventato il backbone finanziario, non l'hub di processo tuttofare che veniva venduto negli anni Novanta.

Il modello con cui lavora oggi la maggior parte degli enterprise architect è un backbone finanziario (SAP S/4HANA o Oracle Fusion) circondato da piattaforme specialistiche.

Livello	Che cosa ci sta	Che cosa non ci sta
Backbone finanziario	Contabilità generale, controlling, acquisti, magazzino, esecuzione della produzione, chiusura statutaria	Approvazioni di workflow, CRM, gestione della forza lavoro, analytics
Workflow	ServiceNow per i processi IT e operativi, le approvazioni, il change management	Registrazioni transazionali
Relazione con i clienti	Salesforce o SAP Sales and Service Cloud	Elaborazione finanziaria
Forza lavoro	Workday o SAP SuccessFactors	Transazioni operative
Analytics	SAP Business Data Cloud, SAP Analytics Cloud, Power BI, Snowflake	Il sistema di registrazione (system of record)

La separazione è voluta. Riportare tutto dentro SAP aggiunge attrito, rallenta gli aggiornamenti e confonde le responsabilità. Ammassare CRM, workflow, analytics ed EHS in un unico sistema è ciò che ha reso così dolorosi i programmi precedenti.

La domanda da porsi: di che cosa l'ERP non deve più essere responsabile? Se la salta, ricostruisce lo stesso monolite su una licenza più recente. Il mio articolo sulla modernizzazione dell'ERP con SAP e ServiceNow analizza una versione di questa divisione.

Nell'agosto 2025 SAP ha sostituito il modello di estensibilità a tre livelli con quattro livelli Clean Core. Il livello A usa solo API rilasciate e stabili, side by side su SAP BTP o in-system con ABAP Cloud. Il livello B usa API e tecnologie classiche che SAP considera ancora pulite. Il livello C accede a oggetti interni e richiede misure speciali. Il livello D non è pulito.

La public edition (SAP Cloud ERP, venduta come SAP GROW) ammette solo il livello A, quindi è la piattaforma a imporre il Clean Core e ad assorbire due release importanti all'anno. La private edition (SAP Cloud ERP Private, in RISE) e l'on-premise ammettono ancora le estensioni classiche, quindi lì il Clean Core dipende dalla governance. In ogni caso, un sistema molto personalizzato trasforma ogni upgrade in un progetto e ogni test di regressione in una crisi.

Che cosa le chiede il Clean Core:

1. Togliere dal core il custom code inutilizzato. Ogni programma custom che si tiene è qualcosa da testare a ogni upgrade.
2. Costruire le nuove estensioni al livello A, dove possibile: su SAP BTP, con SAP Build o in-system con ABAP Cloud.
3. Usare i processi standard ovunque SAP li fornisca e personalizzare solo dove lo richiedono le norme o una reale differenza competitiva.

La resistenza è culturale, non tecnica. I responsabili di business che per 15 anni si sono affidati al custom code si aspettano ancora che venga «semplicemente reimplementato». Quell'aspettativa appartiene al 2012.

Un tipico panorama ECC contiene da 1.500 a 3.000 oggetti custom, in base alle valutazioni che ho condotto nel manifatturiero e nei servizi, e solo circa un quarto mostra un uso attivo da parte del business. Il resto è zavorra storica che gonfia i costi di migrazione e crea esposizione in sede di audit.

La mossa pratica: eseguire subito una scansione degli utilizzi. Dismettere ciò che è inattivo. Pubblicare un elenco dei tagli prima che inizi il disegno. I team che pianificano il Clean Core dalla prima settimana hanno esperienze di upgrade molto migliori di quelli che lo trattano come un vincolo da aggirare. Il mio articolo sulla strategia Clean Core entra nel merito del metodo.

Con l'ERP come uno dei tanti livelli, le questioni di responsabilità diventano critiche. Chi è responsabile di:

1. L'API tra Salesforce e l'ERP?
2. Un workflow che attraversa SAP e ServiceNow?
3. Priorità di modifica in conflitto, quando entrambi i sistemi richiedono aggiornamenti nello stesso momento?

Ho visto questo problema ritardare i go-live di mesi. I team non si accorgono di essere bloccati finché i test di integrazione non rivelano la sovrapposizione.

In un caso, cinque sistemi toccavano lo stesso record anagrafico fornitore. Cinque. Nessuno aveva un documento di responsabilità sui dati anagrafici e nessuno aveva definito chi potesse modificare che cosa, in quale sistema. Non è un fallimento della tecnologia. È un fallimento di governance che la tecnologia ha messo a nudo.

Il valore dell'AI nell'ERP è reale, ma dipende dalla qualità dei dati e da un'architettura pulita. Joule ora copre S/4HANA, SuccessFactors, Ariba e altri prodotti SAP, e gli agenti di SAP lavorano sotto gli assistenti Joule. I casi d'uso agentici su SAP BTP sono in produzione, non slide. Dipendono tutti da dati puliti, coerenti e strutturati.

Se i suoi dati sono duplicati, codificati in modo incoerente o conservati in tabelle custom che S/4HANA non riconosce, l'AI non ha nulla di affidabile su cui lavorare. I team finanziari che usano l'AI sulla contabilità fornitori lo scoprono in fretta, quando le fatture vengono abbinate al fornitore sbagliato perché l'anagrafica fornitori non è mai stata bonificata.

La sequenza che funziona: prima il Clean Core, poi la data governance, poi l'analytics, infine l'AI. Saltare dei passaggi non accelera nulla. Sposta il problema più avanti.

1. 01Fissare il confineDecidere che cosa l'ERP deve smettere di fare
2. 02Pulire il coreDismettere il codice inutilizzato, costruire il nuovo al livello A
3. 03Governare i datiUn responsabile per ogni oggetto dati
4. 04Costruire l'analyticsSAP Business Data Cloud, SAC o Power BI su dati governati
5. 05Aggiungere l'AIJoule e agenti su una base affidabile

AI con qualcosa di affidabile su cui lavorare

Rischio	Segnale	Risposta pratica
Pressione della scadenza ECC	La manutenzione mainstream termina a dicembre 2027; la maggior parte dei clienti ECC non aveva acquistato licenze S/4HANA entro la fine del 2024	Bloccare ora i piani di risorse dei partner; le tariffe giornaliere senior negli Stati Uniti sono già tra $1.800 e $3.500
Debito di custom code	Da 1.500 a 3.000 oggetti custom, circa un quarto in uso attivo	Eseguire scansioni degli utilizzi, pubblicare un elenco dei tagli, avviare sprint di dismissione
Impatto delle release	Le release coincidono con la chiusura finanziaria e con i picchi della supply chain	Fissare le finestre di rilascio lontano dalla chiusura; automatizzare i test di regressione
Rischio nella migrazione dei dati	L'armonizzazione tardiva produce difetti che i team scambiano per bug	Dimensionamento anticipato; controlli su dati bancari, fiscali e di compliance prima del design freeze
Lacune di responsabilità sull'integrazione	Cinque o più sistemi che toccano gli stessi dati anagrafici condivisi	Pubblicare una matrice di autorità; un responsabile per ogni oggetto dati
Due strumenti di lifecycle	I panorami ibridi usano in parallelo Solution Manager e SAP Cloud ALM	Cloud ALM come predefinito per i programmi cloud; la manutenzione mainstream di Solution Manager 7.2 termina a fine 2027

Per la versione di questi rischi a livello di delivery, veda i dieci errori di modernizzazione ERP da evitare e, per i percorsi di migrazione veri e propri, la guida alla migrazione da ECC a S/4HANA.

Che cos'è il Clean Core in SAP S/4HANA?

Mantenere S/4HANA il più vicino possibile allo standard e collocare le estensioni dove gli upgrade non possono romperle. Da agosto 2025 SAP classifica le estensioni dal livello A (solo API rilasciate, su SAP BTP o in-system con ABAP Cloud) al livello D (non pulito). La ragione di business è la protezione degli upgrade: un sistema pulito assorbe le release in pochi giorni, uno molto personalizzato ne fa un progetto ogni volta.

Che cos'è l'architettura ERP con backbone e satelliti?

L'ERP (SAP S/4HANA o Oracle Fusion) gestisce ciò per cui è costruito: registrazioni finanziarie, magazzino, acquisti, transazioni di produzione e reporting statutorio. Il resto lo gestiscono piattaforme specialistiche: ServiceNow per i workflow, Salesforce per la relazione con i clienti, Workday o SuccessFactors per le risorse umane e piattaforme di analytics per gli insight. Costringere tutto questo dentro l'ERP crea un monolite che si aggiorna lentamente e richiede molta personalizzazione.

Come devono affrontare le aziende la scadenza ECC del 2027?

Si parta da SAP Readiness Check. Fa emergere i volumi di custom code, le dipendenze degli add-on e il dimensionamento dei dati, i tre fattori che decidono se andare in brownfield, greenfield o selective. Le migrazioni enterprise complesse durano di solito da 18 a 24 mesi dalla valutazione al go-live, quindi se non ha ancora scelto un approccio e avviato le conversazioni con i partner, un go-live nel 2027 è già stretto. La manutenzione estesa fino al 2030 costa di più e compra tempo, non innovazione.

Quando l'AI è utile nella modernizzazione dell'ERP e quando no?

Quando i dati sono puliti, coerenti e strutturati e il processo ha regole chiare: l'automazione della contabilità fornitori, le previsioni della domanda e il rilevamento delle anomalie nelle transazioni finanziarie sono casi collaudati. L'AI non è una scorciatoia per aggirare dati scadenti o lacune di governance. Le decisioni prese su input sbagliati sono più difficili da individuare degli errori manuali. Prima vengono Clean Core, data governance e processi stabili.

Quali sono i maggiori errori di modernizzazione ERP?

Trattarla come un progetto tecnologico, così il dibattito sul Clean Core è perso prima che i responsabili di business entrino nella stanza. Avviare la data governance dopo il disegno, quando le decisioni della prima settimana avrebbero fatto risparmiare mesi di test. Non definire che cosa l'ERP deve smettere di fare, così il perimetro del core cresce per inerzia, ed è così che è stato costruito l'ultimo monolite.

Quanto costa la modernizzazione dell'ERP?

Una conversione brownfield da ECC a S/4HANA per un'azienda mid-market costa in genere da $2M a $8M di costi di implementazione, più la sottoscrizione ricorrente. I programmi enterprise con perimetro globale, forte personalizzazione e molte entità possono costare da $20M a oltre $100M. Includa nel modello integrazione, test e supporto operativo oltre alle licenze e, con RISE e SAP GROW, simuli la crescita dei FUE su tutta la durata del contratto.