Fit-to-standard vs custom: perché cambia tutto
(soprattutto nel Public Cloud)
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 strutturale: quando il custom diventa
governance implicita
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.
Come SAP inquadra il tema: Fit-to-Standard come
“cloud mindset”
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.
Custom sì, ma “clean”: estendere senza
contaminare il core
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.
Impatto su governance IT, costi e affidabilità
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.
La scelta è di modello operativo
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à?
