Private Cloud non significa “continuare come prima”. Anche lì, la direzione SAP resta clean core, semplificazione e governo della complessità.

Quando un’azienda valuta SAP S/4HANA Cloud Public Edition o SAP S/4HANA Cloud Private Edition, la discussione parte quasi sempre da qui: quante personalizzazioni abbiamo oggi? È una domanda comprensibile, ma rischia di spostare l’attenzione sul punto sbagliato. Nel materiale SAP più recente, il Public Cloud è descritto come una soluzione “ready-to-run” che privilegia standardizzazione e deployment speed, mentre il Private Cloud viene presentato come “tailored-to-fit”, quindi più flessibile e più personalizzabile. La differenza, però, non si esaurisce nel tema custom: riguarda soprattutto come il sistema verrà governato nel tempo.

Il punto, quindi, non è chiedersi quanto del passato si possa “portare dentro” il nuovo ERP, ma quale modello operativo l’azienda è davvero in grado di sostenere. Public e Private non sono scelte infrastrutturali. Sono scelte di modello operativo: il deployment model influenza governance, estensioni, velocità di evoluzione e qualità del supporto.

Come SAP inquadra la scelta

Le indicazioni SAP danno una prima direzione chiara. In un blog ufficiale del 2026, il Public Cloud viene indicato come destinazione preferibile quando possibile, perché offre Accesso più rapido all'innovazione, un modello operativo cloud più semplice e un TCO ridotto. Lo stesso contenuto, però, evidenzia anche i limiti da valutare: il Public Cloud richiede una new implementation, ha un perimetro funzionale che va verificato e implica accettare che alcune personalizzazioni e parte dei dati non possano essere semplicemente traslati così come sono. Il Private Cloud, invece, consente anche system conversion e selective data transition, quindi può essere più adatto dove il ridisegno completo non è sostenibile o dove alcuni vincoli di processo restano indispensabili.

Questo significa che la vera domanda non è “quanti custom abbiamo”, ma:

• quanto siamo standardizzabili;
• quanto vogliamo evolvere velocemente;
• quanto siamo governabili.
  
  Dove il problema si manifesta davvero nei sistemi

Operativamente, il problema emerge quando si usa il volume di custom storico come criterio principale di scelta. È un errore frequente: si assume che molto custom significhi automaticamente Private Cloud. In realtà, il custom non misura da solo la complessità reale. Non dice se quei processi sono ancora differenzianti, se sono documentati, se hanno ownership chiara, se sono sostenibili con il lifecycle cloud, o se stanno semplicemente assorbendo eccezioni accumulate negli anni. Questa distinzione è importante perché, dal punto di vista SAP, il Public Cloud mantiene il core standard e sposta la differenziazione su forme di estensibilità progettate per essere upgrade-proof.

Il SAP Help Portal lo formula in modo molto diretto: l’extensibility concept di SAP S/4HANA Cloud Public Edition abilita “lifecycle-stable software products”. In pratica, gli aggiornamenti SAP non devono dipendere dalle estensioni di clienti o partner; ciò che non può stare nel core viene gestito tramite side-by-side extensibility su SAP BTP, mentre nel core restano le estensioni a basso impatto (key user) o quelle più strettamente integrate e governate (developer extensibility). Questo cambia il problema: non è più “quanti sviluppi devo conservare?”, ma dove deve vivere la differenziazione per non compromettere aggiornabilità e stabilità.

Errori tipici nelle organizzazioni IT

Il primo errore è partire dal legacy invece che dal modello operativo futuro. Se si usa l’esistente come vincolo assoluto, il Private sembra sempre la scelta più sicura. Ma SAP stessa, nelle linee guida sulle extension patterns, invita a valutare ogni use case e a scegliere la tecnologia più adatta in base a prossimità al core, consistenza transazionale, necessità di dati, integrazione ed eventi — non per inerzia storica.

Il secondo errore è confondere flessibilità con modifica del core. SAP non dice che nel Public Cloud non si possa differenziare. Dice che la differenziazione va realizzata con strumenti coerenti con il lifecycle della piattaforma, proprio per mantenere il sistema stabile agli upgrade. Alcune estensioni restano nel core, altre devono vivere fuori dal core. La vera architettura nasce da questa distinzione, non dal numero di oggetti custom ereditati.

Il terzo errore è valutare Public vs Private solo in ottica progettuale. Il tema decisivo, soprattutto in ambienti complessi con AMS o running, è il day-2: test, ruoli, supporto, estensioni, cambiamenti e priorità. Se questa parte non è stata pensata prima, la complessità riemerge comunque — solo in un altro punto del sistema.

Benefici di un approccio allineato a SAP

Un approccio coerente con le indicazioni SAP porta benefici molto concreti. Il primo è la riduzione del debito operativo e tecnico: meno dipendenza da logiche stratificate nel core, più chiarezza su cosa è standard e cosa è davvero differenziante. Il secondo è la maggiore affidabilità del sistema, perché le estensioni vengono progettate in modo upgrade-stable e con responsabilità più chiare su sicurezza, dati e lifecycle. Il terzo è una migliore leggibilità dei costi, perché la manutenzione non cresce in modo opaco tra ticket ricorrenti, workaround e sviluppi non classificati.

Il ruolo della consulenza: non spingere un modello, ma chiarire la scelta

Qui il valore di una società di consulenza non dovrebbe stare nel “dire Public” o “dire Private”. Dovrebbe stare nel rendere la scelta più solida. In concreto, vuol dire aiutare l’azienda a distinguere tra processi davvero differenzianti e complessità solo sedimentata, capire quali estensioni vadano nel core e quali fuori, e impostare un modello che tenga insieme progetto, evoluzione e supporto senza scaricare tutto sull’AMS. In altre parole: non vendere una piattaforma, ma ridurre l’ambiguità decisionale. Questa è la parte che fa davvero la differenza nei contesti complessi.

In conclusione

La scelta tra SAP Public Cloud e SAP Private Cloud non dipende prima di tutto dal numero di custom esistenti, ma dalla capacità dell’azienda di standardizzare ciò che non differenzia e governare nel tempo ciò che deve restare distintivo.