Per anni, in molti progetti ERP, “custom” è stato sinonimo di flessibilità: se un processo non rientra nello standard, si adatta il sistema. È una percezione comprensibile, ma oggi — con SAP S/4HANA Cloud Public Edition — diventa una lettura incompleta. Nel Public Cloud, la domanda non è “quanto possiamo customizzare”, ma come manteniamo il sistema governabile e aggiornabile nel tempo.
Il problema emerge nel day‑2, non al go‑live. Se il sistema dipende da personalizzazioni sul core, ogni evoluzione si trasforma in un tema di compatibilità, test e manutenzione; spesso l’AMS finisce per “assorbire” scelte che non sono state definite a livello di processo. È qui che la gestione diventa reattiva: più eccezioni, più effort, più rischio di instabilità.
Questa dinamica è particolarmente critica nel Public Cloud, dove il modello è basato su processi standard e aggiornamenti continui: le deviazioni dallo standard aumentano il carico di manutenzione e rendono più complessa l’adozione delle release.
SAP colloca il fit-to-standard al centro della metodologia SAP Activate, in particolare nella fase Explore: i workshop servono a guidare le persone esperte di processo attraverso i flussi standard, validare lo scope e raccogliere le informazioni necessarie alla configurazione. Il principio è “adottare i processi standard il più possibile”, riducendo complessità e mantenendo la soluzione pronta alle release future.
In termini molto concreti: nel Public Cloud il progetto non parte dal “requisito” e poi costruisce la soluzione, ma parte dallo standard SAP e verifica cosa è davvero necessario differenziare. Questo ribalta il modello decisionale e sposta il focus su governance e priorità, non su sviluppo.
SAP non dice “zero estensioni”. Dice: estensioni governate e disaccoppiate dal core, in modo che non si rompano con gli upgrade e che gli upgrade non rompano le estensioni. È il senso della logica clean core: decoupling, contratti stabili (API rilasciate), e scelte di estensione motivate da reale valore di business.
Un punto spesso sottovalutato è che anche cambiamenti “piccoli” possono diventare un freno alle release: nei contenuti SAP sul fit-to-standard viene esplicitato che perfino un singolo campo custom richiede verifiche rispetto a deprecazioni ad ogni release.
E, quando un gap richiede un’estensione, la logica indicata è: farla in modo clean core compliant, con governance chiara e valore tangibile.
Governance IT. Fit-to-standard rende esplicita una decisione che prima era spesso implicita: cosa è “standard”, cosa è “differenziante” e cosa è “innovazione”. SAP raccomanda una governance che mantenga il core vicino allo standard e che valuti ogni deviazione in base al valore e all’impatto.
Costi. Il costo non è il “custom” in sé, ma la sua coda: test, manutenzione, remediation, gestione dell’upgrade. Ridurre personalizzazioni non significa rinunciare al business, ma ridurre il debito tecnico e riallocare risorse su ciò che differenzia davvero.
Affidabilità. Il Public Cloud è pensato per ricevere innovazione continua. Se la soluzione è costruita vicino allo standard e le estensioni sono disaccoppiate, l’affidabilità cresce perché il sistema resta aggiornabile senza shock ad ogni release.
Fit-to-standard vs custom non è una disputa “metodologica”. È una scelta su come l’azienda vuole governare l’ERP nei prossimi anni: come si prendono decisioni, come si gestiscono le eccezioni, come si protegge la capacità di adottare innovazione.
Definizione utile: Fit-to-standard è l’approccio SAP Activate che valida i processi standard come base della soluzione e limita le deviazioni ai soli requisiti realmente differenzianti, governando estensioni e integrazioni per preservare upgradeability.
Se l’organizzazione vuole davvero il Public Cloud, la domanda non è “quanto custom possiamo fare”.
È: abbiamo un modello di governance che ci permette di restare standard dove conviene e differenziare dove serve, senza perdere aggiornabilità?