SAP Clean Core: cos'è, livelli da A a D e governance

SAP Clean Core significa mantenere il suo sistema S/4HANA il più vicino possibile allo standard SAP, per quanto il suo business lo consenta. Tutto ciò che aggiunge viene costruito tramite interfacce che SAP ha rilasciato e si è impegnata a mantenere stabili, così gli upgrade non lo rompono.

La risposta breve: il Clean Core è una disciplina su come estendere e governare SAP. La logica custom va on-stack con ABAP Cloud o side-by-side su SAP BTP, e SAP classifica ogni estensione dal livello A (il più pulito) al livello D (modifiche da eliminare). Il vantaggio sono upgrade più rapidi: ho visto aziende ridurre così del 40% i tempi dei loro upgrade.

Se il suo sistema è pieno di modifiche agli oggetti standard di SAP, ogni release diventa un progetto di regressione. Se la sua logica custom sta dietro interfacce rilasciate, gli upgrade diventano ordinaria manutenzione.

Ho visto aziende ridurre del 40% i tempi degli upgrade applicando i principi del Clean Core. Ci sono riuscite riducendo al minimo le personalizzazioni e governando quelle che hanno mantenuto.

Nel 2024 un'azienda europea di beni di consumo ha sostituito la sua logica di prezzo legacy con un'app Fiori modulare costruita fuori dal core, su SAP BTP. Questo ha eliminato del tutto i test di regressione per quella logica.

Un ERP Clean Core si può comunque personalizzare. La personalizzazione deve usare interfacce che SAP ha rilasciato e si è impegnata a mantenere stabili. SAP offre due modi per farlo:

• On-stack, con ABAP Cloud. Le estensioni girano dentro S/4HANA ma usano solo API e punti di estensione rilasciati.
• Side-by-side, su SAP BTP. Le estensioni girano come applicazioni separate e comunicano con S/4HANA tramite API o eventi.

SAP descrive il suo approccio come BTP-first, con una scelta caso per caso. Nella mia esperienza, conta meno dove gira il codice che sapere se il requisito ha davvero bisogno di codice.

Un core «sporco» è familiare a chiunque abbia gestito ECC: programmi standard modificati, tabelle Z scritte direttamente, interfacce che leggono gli oggetti interni di SAP, implicit enhancement che nessuno ha documentato. Niente di tutto questo era sbagliato quando è stato costruito. Semplicemente non era pensato per un sistema che si aggiorna ogni uno o due anni.

Tratto questo tema anche in un video sul mio canale YouTube (in inglese).

SAP organizza il Clean Core intorno a cinque principi guida. Ecco come SAP inquadra ciascuno, e che cosa guardo per primo:

Principio	Che cosa intende SAP	Che cosa controllo per primo
Processi	Restare il più vicino possibile al processo standard SAP	Quali varianti di processo esistono solo perché «abbiamo sempre fatto così»
Estensibilità	Estensioni disaccoppiate dal core tramite API rilasciate, con una governance su quale opzione usare	Quanto codice custom esiste, quanto ne viene usato e a quale livello si trova
Dati	Dati puliti e conformi, con un modello di governance consolidato	Dati anagrafici duplicati e incompleti, campi custom che nessuno sa spiegare
Integrazioni	Connessioni standardizzate e sicure, basate su tecnologie supportate	Interfacce punto a punto che leggono direttamente le tabelle
Operations	Governance, persone, processi e strumenti che tengono in piedi gli altri quattro	Chi approva un'estensione e che cosa impedisce la modifica successiva

La maggior parte dei team comincia e finisce con l'estensibilità, perché è la più facile da misurare. Nella mia esperienza, processi e dati causano più ritardi. Il codice custom di solito è il sintomo, e il processo che c'è dietro è la causa.

Ad agosto 2025 SAP ha sostituito il suo precedente modello di estensibilità a tre livelli con il concetto dei livelli Clean Core. Ogni estensione viene valutata in base a come è costruita, a quanto è disaccoppiata dal core e a quanto in sicurezza sopravvive a un upgrade. Se legge materiale SAP più vecchio che parla di tier, è questo che lo ha sostituito.

Livello ALivello BLivello CLivello D

Che cosa usaLivello ASolo interfacce pubbliche rilasciate e stabiliLivello BAnche le API classiche di SAPLivello COggetti interni di SAPLivello DModifiche, scritture su tabelle SAP, implicit enhancement

Rischio di upgradeLivello AIl più basso, coperto da contratti di stabilitàLivello BIn genere stabile agli upgradeLivello CDa verificare a ogni upgradeLivello DIl più alto

Che cosa decidereLivello ALa scelta predefinita per tutto ciò che è nuovoLivello BAccettare, registrando il motivoLivello CAccettare con un motivo, ricontrollare a ogni upgradeLivello DEliminare per primo, o portarlo a B o C

Fonte: Concetto dei livelli Clean Core di SAP, SAP News, agosto 2025

Il livello A usa solo interfacce pubbliche rilasciate con contratti di stabilità, costruite con SAP Build, ABAP Cloud o BTP. Il livello B aggiunge le API classiche di SAP. Il livello C tocca oggetti interni di SAP, e per questi SAP prevede un changelog che aiuti a pianificare gli upgrade.

Il livello D comprende modifiche, scritture su tabelle SAP, implicit enhancement e altre tecniche che SAP non raccomanda. È più utile del vecchio dibattito «pulito o non pulito», perché le permette di fissare un obiettivo per ogni oggetto. Portare i suoi oggetti di livello D a B o C prima di un upgrade è già una riduzione concreta del rischio.

ABAP Cloud è il modello di sviluppo ABAP di SAP pensato per il cloud. Gli sviluppatori usano la versione di linguaggio «ABAP for Cloud Development» e possono costruire solo su oggetti rilasciati, API pubbliche e punti di estensione. È nato nell'ambiente ABAP di SAP BTP e oggi è disponibile in tutte le edizioni di S/4HANA (SAP ABAP Cloud FAQ).

S/4HANA Cloud le offre tre strade di estensione. L'estensibilità per key user copre semplici modifiche a campi, logica e interfaccia senza toccare il codice SAP. L'estensibilità per sviluppatori con ABAP Cloud gestisce la logica strettamente accoppiata, e le estensioni side-by-side su SAP BTP gestiscono tutto ciò che deve restare disaccoppiato.

L'edizione decide quanta scelta ha:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition e on-premise
Sviluppo ABAP	Solo ABAP Cloud, obbligatorio per i nuovi clienti dalla release 2208	ABAP Cloud raccomandato dal 2022; ABAP classico ancora consentito
Modifiche al codice SAP	Non possibili	Possibili, ma sono di livello D
Estensioni key user e side-by-side su BTP	Disponibili	Disponibili
Chi impone il Clean Core	Il sistema	La sua governance

La mia regola per i clienti Private Edition: per tutto ciò che è nuovo, la tratti come se fosse la Public Edition. L'ABAP classico è consentito, ma ogni oggetto classico che aggiunge oggi è una decisione che qualcuno dovrà difendere al prossimo upgrade.

Le decisioni sul Clean Core dovrebbero spettare a una design authority composta da business e IT. L'IT da sola approverà tutto ciò che è tecnicamente possibile. Il business da solo chiederà di riavere il suo vecchio processo.

Ecco come la imposterei:

1. Nomini i membri. I process owner di business per ogni area principale, più il solution architect e il lead developer. I process owner decidono se un requisito è reale, e l'IT decide come viene costruito.
2. Concordi l'ordine di preferenza prima che inizi lo sviluppo. Prima il processo standard, poi l'estensibilità per key user, poi il livello A su ABAP Cloud o BTP. Il livello B o C richiede una motivazione scritta, e il livello D un piano di uscita.
3. Ogni richiesta di estensione deve avere un owner e una motivazione di business. Niente owner, niente sviluppo. La decisione e il livello accettato finiscono in un unico registro.
4. Metta un controllo tecnico davanti ai trasporti. Esegua in modo pianificato i controlli Clean Core dell'ABAP test cockpit e fermi il nuovo codice di livello D prima che arrivi in produzione.
5. Riveda il registro prima di ogni upgrade. Dismetta ciò che nessuno usa più e porti a un livello superiore tutto ciò che ora può raggiungerlo.

A quel tavolo la domanda una volta era «perché questo non può stare su BTP?». Oggi chiederei «perché questo non può essere di livello A?». Se non può, la domanda successiva è quale livello sta accettando e perché.

L'errore più grande sul Clean Core che vedo è cercare di far funzionare SAP come Oracle. Adotti i processi standard di SAP invece di ricostruire in codice custom la logica di un altro sistema. Se sta ancora scegliendo tra i due, li confronto in SAP vs Oracle.

Il Clean Core è un problema di change management prima ancora che tecnico. Ogni oggetto custom esiste perché qualcuno lo ha chiesto. Eliminarlo significa convincere quella persona che il processo standard è sufficiente.

Quella conversazione va meglio quando il business vede funzionare il nuovo processo, non una slide che lo descrive. Va meglio anche quando mette alla prova l'affermazione che un processo sia unico, perché spesso non lo è (veda i passi 4 e 5 più sotto).

Le competenze contano quanto gli strumenti. Un team ABAP che non ha mai lavorato con ABAP Cloud o BTP rallenterà il programma mentre impara. Un'azienda manifatturiera con cui ho lavorato ha svolto un programma interno su BTP di tre mesi prima dell'avvio del suo progetto S/4HANA, e lo ha ripagato con meno sorprese durante lo sviluppo.

La conformità al Clean Core indica quanta parte del suo sistema rispetta i criteri di SAP sui cinque principi. Non può gestirla senza numeri, e SAP le offre tre posti dove ottenerli.

1. L'ABAP test cockpit. Lo strumento SAP per i controlli a livello di codice. Mostra quali oggetti custom usano oggetti non rilasciati, modifiche o accesso diretto alle tabelle.
2. Il SAP Readiness Check. È incluso nel suo contratto di manutenzione e mostra che cosa toccherà un passaggio a S/4HANA prima che lei si impegni.
3. Il RISE with SAP Methodology dashboard, noto anche come clean core dashboard. Gira in SAP Cloud ALM. La sua vista di sistema controlla la sua versione di S/4HANA, conferma che gli strumenti di raccolta dati sono attivi e rivede le estensioni prima di un upgrade, mentre la vista operations segue i KPI operativi.

I numeri che metterei davanti alla design authority ogni mese sono semplici. Quanti oggetti custom ci sono a ogni livello, e il livello D sta calando? Quante eccezioni sono aperte, e ognuna ha un owner?

Se mi chiedesse di valutare il suo sistema il mese prossimo, questo è l'ordine che seguirei.

1. Scopra che cosa viene usato. Esegua il SAP Readiness Check e raccolga i dati d'uso del suo codice custom. In un programma, l'analisi con smartShift ci ha portato da 18.000 oggetti custom a 3.200, perché quasi tutto il resto semplicemente non veniva usato.
2. Classifichi ciò che resta nei livelli da A a D. Usi l'ABAP test cockpit per il codice. Se è su RISE, da lì in poi lo segue il clean core dashboard.
3. Decida oggetto per oggetto. Dismetterlo, spostarlo su un'interfaccia rilasciata, ricostruirlo su BTP o tenerlo con una motivazione documentata. Cominci dal codice che gira ogni giorno, perché un report usato due volte l'anno da un team regionale può aspettare.
4. Porti il business nella stanza. Un responsabile finance con cui ho lavorato ha capito la sua nuova app Fiori solo dopo una dimostrazione di 45 minuti. Quella sessione ha risparmiato due settimane di botta e risposta in UAT.
5. Metta in discussione il «il nostro processo è diverso». In un workshop con il team vendite di un'azienda industriale europea nel 2023, il processo «unico» si è rivelato per l'80% amministrazione legacy ridondante. Lo standard SAP ha migliorato l'esperienza dei loro clienti appena sono spariti i workaround.
6. Inizi presto il lavoro sui dati. Un cliente retail del GCC con cui ho lavorato nel 2024 aveva oltre 15.000 campi custom da esaminare. Nella mia esperienza la migrazione dei dati assorbe dal 30 al 40% dell'impegno di implementazione, e la mia guida ai costi di implementazione SAP mostra dove questo finisce nel budget.
7. Definisca la governance prima del go-live. Istituisca la design authority descritta sopra e ne faccia l'unica strada per una nuova estensione.

Tre domande emergono in quasi ogni conversazione che ho su questo tema.

Il Clean Core è obbligatorio con RISE with SAP?

Non come regola generale. Nella Public Edition lo impone il sistema, mentre nella Private Edition e on-premise può ancora modificare il core.

Lì il Clean Core è una scelta di governance che SAP monitora tramite il RISE methodology dashboard. Se un system integrator le dice che è un obbligo contrattuale, gli chieda di mostrarle la clausola.

Quanto tempo ho ancora con ECC?

Per SAP ERP 6.0 con gli enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027. La manutenzione estesa opzionale arriva al 31 dicembre 2030, a un costo aggiuntivo.

Dopo, la transition option SAP ERP, private edition copre dal 2031 al 2033. Vale solo per i sistemi di grandi dimensioni già passati a SAP ERP, private edition su SAP HANA prima della fine del 2030.

Consideri il 2033 una via d'eccezione, non una data su cui pianificare. La mia guida alla migrazione da ECC a S/4HANA tratta le scelte di percorso.

Il Clean Core conta per l'AI?

Sì. Restare sullo standard SAP aiuta l'AI e Joule a funzionare meglio, e i processi pesantemente modificati sono proprio quelli dove è più difficile adottarli.

SAP costruisce le sue funzionalità di AI, Joule compreso, sui propri processi standard e sul proprio modello dati. Joule for developers genera codice ABAP Cloud basato su API rilasciate. Spiego come cloud, AI e Clean Core si incastrano in modernizzazione dell'ERP.

I team che saltano il Clean Core non evitano il lavoro. Lo rimandano, e torna sotto forma di upgrade bloccati, maratone di test di regressione e codice custom che nessuno capisce.

Prima di firmare un contratto S/4HANA o RISE, chieda al suo system integrator di classificare il suo codice custom attuale nei livelli da A a D. Se non è in grado di produrla, questo le dice qualcosa sulla stima. Prenoti una call e analizziamo la sua situazione.

Che cos'è il Clean Core in SAP?

Clean Core significa mantenere S/4HANA vicino allo standard SAP e costruire le estensioni solo tramite interfacce che SAP ha rilasciato e si è impegnata a mantenere stabili. Le estensioni girano on-stack con ABAP Cloud oppure side-by-side su SAP BTP. L'obiettivo è che gli upgrade non rompano la sua logica custom.

Quali sono i cinque principi di SAP Clean Core?

I cinque principi guida del Clean Core secondo SAP sono processi, estensibilità, dati, integrazioni e operations. I processi restano vicini allo standard, le estensioni usano API rilasciate e i dati vengono mantenuti puliti con un modello di governance. Le integrazioni usano tecnologie supportate, e le operations comprendono la governance, le persone e gli strumenti che tengono in piedi gli altri quattro.

Che cosa sono i livelli A, B, C e D di SAP Clean Core?

Da agosto 2025 SAP classifica le estensioni in quattro livelli. Il livello A usa solo interfacce pubbliche rilasciate e stabili, il livello B usa anche le API SAP classiche e il livello C accede a oggetti interni di SAP. Il livello D comprende modifiche, scritture su tabelle SAP e implicit enhancement, e comporta il rischio di upgrade più alto.

Il Clean Core è obbligatorio per RISE with SAP?

Non come regola generale. S/4HANA Cloud Public Edition consente solo ABAP Cloud e interfacce rilasciate, quindi impone il Clean Core a livello tecnico. Nella Private Edition può ancora modificare il core, per cui il Clean Core è una decisione di governance che SAP monitora tramite il RISE with SAP Methodology dashboard.

Che cos'è ABAP Cloud?

ABAP Cloud è il modello di sviluppo ABAP di SAP pensato per il cloud. Consente solo oggetti rilasciati, API pubbliche e punti di estensione, e questo mantiene il codice custom stabile agli upgrade. È obbligatorio in S/4HANA Cloud Public Edition per i nuovi clienti dalla release 2208 e raccomandato nella Private Edition e on-premise dal 2022.

Come si misura il Clean Core?

Usi l'ABAP test cockpit per i controlli a livello di codice e classifichi gli oggetti custom nei livelli da A a D. I clienti RISE possono monitorare l'adozione nel RISE with SAP Methodology dashboard, chiamato anche clean core dashboard, in SAP Cloud ALM. Io seguo il numero di oggetti a ogni livello, l'andamento del livello D e il numero di eccezioni aperte con un owner.

Chi dovrebbe avere la titolarità della governance SAP Clean Core?

Una design authority composta da business e IT dovrebbe avere la titolarità di ogni decisione Clean Core. I process owner di business decidono se un requisito è reale, e l'IT decide come viene costruito e a quale livello. Ogni eccezione viene registrata con un owner e rivista prima di ogni upgrade.

Quando finisce il supporto di SAP ECC?

Per SAP ERP 6.0 con gli enhancement package da 6 a 8, la manutenzione standard termina il 31 dicembre 2027, con manutenzione estesa opzionale fino al 31 dicembre 2030 a un costo aggiuntivo. La transition option SAP ERP, private edition arriva al 2033 solo per i sistemi di grandi dimensioni idonei passati a SAP ERP, private edition su SAP HANA prima della fine del 2030.