Quando si parla di SAP S/4HANA Cloud Public Edition, molte aziende concentrano l’attenzione sul go-live.
È comprensibile.
Il go-live è visibile. Ha una data. Ha un piano. Ha un impatto organizzativo immediato.
Ma nelle trasformazioni cloud il vero punto critico spesso arriva dopo: quando il sistema deve essere gestito, aggiornato, esteso e governato nel tempo.
Il problema, quindi, non è solo “andare live”.
È restare governabili dopo il go-live.
In molti ambienti SAP tradizionali, soprattutto cresciuti negli anni, i processi funzionano perché una parte significativa della complessità è stata assorbita dal sistema. Custom storici, eccezioni operative, workaround, integrazioni puntuali e interventi AMS hanno spesso permesso al business di continuare a lavorare anche in presenza di processi non completamente standardizzati.
Questo modello può reggere per molto tempo.
Ma nel cloud cambia il contesto.
SAP S/4HANA Cloud Public Edition è progettato intorno a un paradigma diverso: processi standard, release continue, estensibilità controllata e maggiore attenzione alla mantenibilità del core. SAP, nei propri contenuti su Clean Core ed extensibility, posiziona l’estensione come qualcosa da governare, preservando la stabilità e l’aggiornabilità del sistema.
Questo significa che il cloud non elimina automaticamente la complessità.
La rende più visibile.
Molti problemi non emergono durante il progetto perché il focus è arrivare al go-live.
Il punto è che il sistema, dopo il go-live, inizia davvero a vivere.
È lì che si vedono le domande rimaste aperte:
Se queste decisioni non sono state prese prima, finiscono spesso nel supporto.
E quando l’AMS diventa il luogo dove si risolvono scelte mai fatte a livello di processo, il sistema inizia a produrre complessità ricorrente: ticket ripetitivi, richieste di change continue, workaround, escalation e costi poco prevedibili.
Il problema non è l’AMS in sé.
Il problema è usare l’AMS come sostituto della governance.
SAP Activate spinge verso un’impostazione in cui lo standard viene validato prima di decidere le deviazioni. Questo approccio, noto come fit-to-standard, cambia la logica del progetto: non si parte più dal legacy per ricostruirlo nel cloud, ma dallo standard SAP per capire cosa è davvero necessario differenziare. SAP collega questo approccio anche all’utilizzo di processi preconfigurati e scope items, che descrivono processi end-to-end standard.
Questo non significa che ogni azienda debba diventare uguale alle altre.
Significa che la differenziazione deve essere consapevole.
Una cosa è estendere un processo perché rappresenta un reale vantaggio competitivo.
Un’altra è replicare nel cloud una deviazione nata anni prima per urgenza, abitudine o limite tecnico del sistema precedente.
Nel primo caso, l’estensione ha una logica.
Nel secondo, si trasferisce debito tecnico in un modello che richiede invece disciplina.
Nel cloud, ogni decisione non governata ha un impatto nel tempo.
Sul piano della governance IT, aumenta la difficoltà di capire chi possiede davvero il processo e chi decide le eccezioni.
Sul piano dei costi, crescono effort di supporto, test, manutenzione e gestione delle release.
Sul piano dell’affidabilità, aumenta il rischio che il sistema diventi fragile non per limiti della piattaforma, ma per eccesso di complessità non governata.
È qui che il concetto di Clean Core diventa concreto.
Clean Core non significa “non fare mai estensioni”.
Significa mantenere il core il più possibile stabile, documentato, aggiornabile e separare le logiche differenzianti quando serve. Le estensioni side-by-side su SAP BTP sono uno dei modelli indicati da SAP per costruire applicazioni disaccoppiate dal lifecycle del core, usando API ed eventi rilasciati quando disponibili.
Il go-live misura la capacità di completare un progetto.
Il day-2 misura la capacità di governare un modello operativo.
Per questo, nel cloud SAP, la domanda non è solo:
“siamo pronti al go-live?”
La domanda più importante è:
siamo pronti a gestire processi, eccezioni, estensioni e supporto senza ricreare nel cloud la complessità del legacy?
Perché il cloud non risolve da solo un modello operativo fragile.
Lo rende visibile.
E quando diventa visibile, non può più essere ignorato.