Extension su BTP - estendere i processi non coperti dallo standard mantenendo il core pulito

Nelle organizzazioni che utilizzano SAP, prima o poi emerge sempre lo stesso tema: lo standard non copre tutto.
Ci sono parti di processo che riflettono specificità operative, vincoli di settore che non rientrano nel modello standard dell’ERP.

Il problema non è se estendere, ma come farlo senza compromettere stabilità, aggiornabilità e governance del sistema SAP.
È su questo punto che SAP ha chiarito negli ultimi anni la propria posizione, introducendo il concetto di Clean Core ed evolvendo il modello di estendibilità su SAP BTP. 

Come il problema si manifesta operativamente  

Dal punto di vista operativo, le estensioni nascono quasi sempre da esigenze legittime:

• un passaggio di processo non previsto dallo standard
• una logica decisionale specifica
• specificità del settore industriale
• custom ABAP nel core (on premises / private cloud)
• impossibilità di copire l’esigenza (public cloud)
• logiche replicate in più sistemi
• frammentazione del flusso di lavoro
• gestione manuale

In assenza di una strategia chiara, queste esigenze vengono spesso risolte in modo reattivo:

Nel breve periodo la soluzione funziona.
Nel medio termine, però, emergono gli effetti noti: aumento del debito tecnico, processi non del tutto integrati, upgrade complessi, costi AMS crescenti.

SAP descrive proprio questo scenario come il motivo per cui la personalizzazione “nel core” non è più sostenibile in contesti S/4HANA private cloud e impossibile sulle versioni public cloud.

Il punto di vista SAP: estendere sì, ma fuori dal core  

La strategia SAP non è “no custom”, ma custom dove ha senso.
Il principio chiave del Clean Core è separare ciò che deve rimanere standard da ciò che può essere esteso, mantenendo il core pulito e aggiornabile.

In questo modello:

• lo standard ERP gestisce i processi core
• le estensioni coprono le specificità
• l’integrazione avviene tramite API ed eventi rilasciati

SAP BTP diventa quindi il livello naturale per costruire estensioni side‑by‑side, integrate ma disaccoppiate dal core, unica strada di estensione per chi adotta un sistema S/4HANA public cloud.

Approccio reattivo vs approccio strutturato   

Estensioni reattive

Tipicamente si osservano quando:

• ogni esigenza viene risolta “dove capita”
• non esiste una distinzione chiara tra standard ed estensione
• le decisioni sono guidate dall’urgenza
• core sempre più complesso
• difficoltà negli upgrade
• dipendenza da singole competenze
• AMS orientato alla gestione di eccezioni
• valutare se la richiesta è davvero fuori standard
• decidere dove estendere (in‑app vs side‑by‑side)
• utilizzare SAP BTP come piattaforma di estensione e integrazione

Conseguenze:

Estensioni strutturate (Clean Core)

SAP propone un approccio opposto:

Questo consente di aggiungere un pezzo di processo mantenendo continuità con lo standard e con il resto dell’ecosistema.

Errori tipici nelle organizzazioni IT  

Dall’osservazione di ambienti complessi emergono errori ricorrenti:

• estendere il core per comodità o abitudine
• non distinguere tra configurazione e sviluppo
• usare BTP come “nuovo posto dove fare custom” senza governance e back to standard
• replicare logiche di processo in più sistemi
• non prevedere il ciclo di vita dell’estensione

Questi errori non violano solo le best practice SAP, ma ridimensionano nel tempo il valore dell’investimento S4/HANA.

I benefici di un’estensione allineata alle indicazioni SAP  

Un approccio strutturato all’estensione su SAP BTP porta benefici concreti per il CIO:

• core ERP più stabile e aggiornabile
• riduzione del debito tecnico
• integrazioni più governabili
• estensioni riutilizzabili e scalabili
• AMS meno reattivo e più prevedibile

SAP sottolinea come il modello side‑by‑side sia oggi il più adatto a supportare evoluzioni future, AI e automazione, senza compromettere l’ERP.

Un criterio di valutazione per il CIO    

La domanda chiave non è “serve un’estensione?” ma: questa logica deve vivere nel core o può essere orchestrata all’esterno?

Se la risposta è la seconda, SAP BTP offre:

• servizi di sviluppo (pro‑code e low‑code)
• integrazione standardizzata
• sicurezza e governance centralizzate

In questo modo, il processo rimane end‑to‑end, ma il core resta pulito.

Una scelta architetturale, non tattica  

L’estensione su SAP BTP non è una scorciatoia, ma una scelta architetturale.
È il passaggio da una personalizzazione reattiva a una gestione consapevole delle differenze di processo.

Ed è qui che il CIO può fare la vera differenza:
non decidendo se estendere, ma con quale modello farlo.