Strategia SAP clean core: che cosa significa e come applicarla

Il clean core decide se un upgrade di S/4HANA richiede sei settimane o sei mesi. Se il suo sistema è pieno di modifiche agli oggetti standard di SAP, ogni release diventa un progetto di regressione. Se la 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 prima dell'avvio del programma S/4HANA. Un'azienda di beni di consumo ha sostituito una vecchia logica di pricing con un'app Fiori modulare costruita fuori dal core, e da allora i suoi upgrade hanno smesso di rompere quella logica.

Molto è cambiato da quando ho scritto questo articolo, nell'aprile 2025. SAP descrive ora il clean core con cinque principi guida e, da agosto 2025, classifica ogni estensione in uno di quattro livelli. Anche le scadenze di ECC sono più chiare. Questa versione ne tiene conto.

Clean core significa mantenere il sistema S/4HANA il più vicino possibile allo standard SAP, per quanto il suo business lo consenta, e costruire tutto ciò che è in più in un modo che sopravviva agli upgrade.

Si può ancora personalizzare. La personalizzazione deve usare interfacce che SAP ha rilasciato e che 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 ed extension point rilasciati.
• Side-by-side, su SAP BTP. Le estensioni girano come applicazioni separate e dialogano con S/4HANA tramite API o eventi.

La linea guida di SAP è scegliere caso per caso, partendo da BTP. Nella mia esperienza, dove gira il codice conta meno del chiedersi se il requisito abbia davvero bisogno di codice.

Un core sporco lo riconosce subito chi ha gestito ECC: programmi standard modificati, Z-table scritte direttamente, interfacce che leggono le parti interne 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.

SAP organizza il clean core attorno a cinque principi guida. La versione precedente di questo articolo elencava titoli diversi. Questi sono quelli che usa SAP, con ciò che guardo per primo in ciascuno:

Principio	Cosa intende SAP	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 governance su quale opzione si usa	Quanto codice custom esiste, quanto ne viene usato e a quale livello si colloca
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, costruite su tecnologie supportate	Interfacce punto a punto che leggono direttamente le tabelle
Operations	Governance, persone, processi e strumenti che mantengono in vigore gli altri quattro	Chi approva un'estensione e che cosa impedisce la prossima modifica

La maggior parte dei team parte 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. La causa è il processo che c'è dietro.

Ad agosto 2025 SAP ha sostituito il precedente modello di estensibilità a tre livelli con il concetto di livelli clean core. Ogni estensione viene valutata in base a come è costruita, a quanto è disaccoppiata dal core e a quanto facilmente può essere aggiornata.

Livello	Descrizione di SAP	Cosa significa per il suo upgrade
A	Estendere con SAP Build. Solo interfacce pubbliche rilasciate e stabili, on-stack con ABAP Cloud o side-by-side su BTP	Rischio più basso. SAP garantisce queste interfacce con contratti di stabilità
B	Usa anche le API e le tecnologie classiche di SAP	In genere stabile agli upgrade, ma fuori dal modello di sviluppo cloud
C	Accede a oggetti interni di SAP	Parzialmente conforme. Ogni upgrade richiede una verifica; SAP prevede un changelog per gli oggetti interni
D	Non raccomandato: modifiche, scritture su tabelle SAP, implicit enhancement, oggetti esplicitamente non raccomandati	Il debito tecnico da eliminare per primo

Questo è più utile del vecchio dibattito «clean o non clean». Permette di fissare un obiettivo per ogni oggetto. Non tutto deve arrivare al livello A. Portare gli oggetti di livello D a B o C prima di un upgrade è già una vera riduzione del rischio.

Livello ALivello BLivello CLivello D

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 negli upgradeLivello AIl più basso, garantito da contratti di stabilitàLivello BIn genere stabile agli upgradeLivello CDa verificare a ogni upgradeLivello DIl più alto

Cosa decidereLivello AIl default per qualsiasi novitàLivello BAccettare, registrando il motivoLivello CAccettare con un motivo, ricontrollare a ogni upgradeLivello DEliminare per primo, o portare a B o C

Fonte: Concetto di livelli clean core di SAP, SAP News, agosto 2025

Se mi chiedesse di valutare il suo sistema il mese prossimo, seguirei quest'ordine.

1. Scopra che cosa viene usato. Esegua lo SAP Readiness Check, incluso nel suo contratto di manutenzione, e raccolga i dati di utilizzo del suo codice custom. In un programma, l'analisi con smartShift ci ha portati da 18.000 oggetti custom a 3.200. La maggior parte degli altri oggetti, semplicemente, non veniva usata.
2. Classifichi ciò che resta nei livelli da A a D. L'ABAP test cockpit è lo strumento SAP per i controlli a livello di codice. Con RISE, la dashboard RISE with SAP Methodology riporta l'adozione del clean core.
3. Decida oggetto per oggetto. Lo dismetta, lo porti su un'interfaccia rilasciata, lo ricostruisca su BTP oppure lo mantenga con una motivazione documentata. Parta dal codice che gira ogni giorno. 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 fatto risparmiare due settimane di andirivieni in UAT.
5. Metta in discussione il «il nostro processo è diverso». In un workshop con un team vendite, il processo «unico» si è rivelato per l'80% amministrazione legacy ridondante. Lo standard SAP ha migliorato la loro esperienza con i clienti una volta eliminati i workaround.
6. Avvii presto il lavoro sui dati. Un cliente retail aveva più di 15.000 campi custom da passare in rassegna. Nella mia esperienza la migrazione dei dati assorbe il 30-40% dell'impegno di implementazione ed è la parte che la maggior parte dei piani sottostima. Spiego perché in perché la migrazione dei dati SAP fallisce.
7. Definisca la governance prima del go-live. Una design authority dovrebbe rivedere ogni nuova estensione. La domanda predefinita era «perché non può stare su BTP?». Oggi chiederei «perché non può essere di livello A e, se non può, quale livello stiamo accettando e perché?»

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 progetto S/4HANA, e ha pagato con meno sorprese durante la fase di build.

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

Il clean core è obbligatorio con RISE with SAP? Non come regola generale. In S/4HANA Cloud Public Edition si può estendere solo tramite interfacce rilasciate, quindi è il sistema a imporlo. In Private Edition e on-premise si può ancora modificare il core. Lì il clean core è una scelta di governance, e SAP la monitora tramite la dashboard della metodologia RISE. Se un system integrator le dice che è contrattuale, gli chieda di mostrarle la clausola.

Quanto tempo ho su ECC? Per SAP ERP 6.0 con 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, e SAP chiede ai clienti di ordinarla entro il terzo trimestre 2027. Gli enhancement package precedenti sono usciti dalla manutenzione standard a fine 2025. Dopo il 2030, la transition option di SAP ERP, private edition copre il periodo 2031-2033. Si applica solo ai grandi sistemi già migrati a SAP ERP, private edition su SAP HANA entro la fine del 2030, e solo con il max success plan di SAP. Consideri il 2033 una via d'eccezione, non una data di pianificazione. La mia guida alla migrazione da ECC a S/4HANA tratta le scelte di percorso.

Il clean core conta per l'AI? SAP costruisce le sue funzionalità di AI, Joule incluso, sopra i propri processi standard e il proprio modello dati. Joule for developers genera codice ABAP Cloud basato su API rilasciate. La mia posizione di lavoro è semplice: quanto più i suoi processi e i suoi dati sono vicini allo standard, tanto meno adattamento serve prima che quelle funzionalità le siano utili. I processi fortemente modificati sono quelli in cui le funzionalità di AI sono più difficili da adottare.

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.

Se sta per firmare un contratto S/4HANA o RISE, chieda al suo system integrator una classificazione da A a D del suo attuale codice custom prima di concordare il perimetro. Se non è in grado di produrla, dice qualcosa sulla stima. Può mettere alla prova le sue opzioni di migrazione con la mia valutazione della migrazione da ECC a S/4HANA, oppure prenoti una call e guardiamo insieme la sua situazione.

Che cos'è il clean core di 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 le cinque dimensioni del clean core di SAP?

SAP le chiama i cinque principi guida del clean core: processi, estensibilità, dati, integrazioni e operations. I processi restano vicini allo standard. Le estensioni usano API rilasciate. I dati sono mantenuti puliti sotto un modello di governance. Le integrazioni usano tecnologie standardizzate e supportate. Le operations comprendono la governance, le persone e gli strumenti che mantengono in vigore gli altri quattro.

Quali sono i livelli clean core SAP A, B, C e D?

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 classiche di SAP. Il livello C accede a oggetti interni di SAP e richiede una verifica a ogni upgrade. Il livello D comprende modifiche, scritture su tabelle SAP, implicit enhancement e altre tecniche non raccomandate, e rappresenta il rischio più alto.

Il clean core è obbligatorio con RISE with SAP?

Non come regola generale. S/4HANA Cloud Public Edition consente estensioni solo tramite interfacce rilasciate, quindi impone tecnicamente il clean core. In Private Edition si può ancora modificare il core, quindi il clean core è una decisione di governance. SAP riporta l'adozione del clean core tramite la dashboard RISE with SAP Methodology.

Quando termina il supporto di SAP ECC?

Per SAP ERP 6.0 con 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. Gli enhancement package precedenti sono usciti dalla manutenzione standard a fine 2025. La transition option di SAP ERP, private edition, arriva al 2033 solo per i grandi sistemi idonei, migrati a SAP ERP, private edition su SAP HANA entro la fine del 2030.

Come valuto la prontezza al clean core del mio sistema SAP?

Parta dallo SAP Readiness Check e dai dati di utilizzo del suo codice custom. Classifichi ciò che è ancora in uso nei livelli da A a D, usando l'ABAP test cockpit per i controlli a livello di codice. Poi decida oggetto per oggetto se dismetterlo, portarlo su un'interfaccia rilasciata, ricostruirlo su SAP BTP o mantenerlo con una motivazione documentata. Riveda nello stesso momento processi e dati, perché di solito spiegano perché quel codice esiste.

Che ruolo ha SAP BTP in una strategia clean core?

SAP BTP è il luogo in cui girano le estensioni side-by-side. Le applicazioni su BTP si collegano a S/4HANA tramite API ed eventi, così il core resta intatto. SAP raccomanda un approccio BTP-first, con estensioni ABAP Cloud on-stack quando la logica deve stare vicina ai dati o alla transazione.