Le migliori strategie di implementazione SAP per evitare errori costosi

La migliore strategia di implementazione SAP è quella che si adatta alla sua azienda e che il suo team riesce a sostenere. Si riduce a tre decisioni. Quale modello di deployment: S/4HANA Cloud Public Edition (di solito tramite GROW with SAP), Private Edition (di solito tramite RISE with SAP) oppure on-premise. Quale percorso di migrazione: greenfield, brownfield o bluefield. E quale modello di rollout: Big Bang, a fasi o ibrido. Questa guida è per CIO, direttori di programma e sponsor che scelgono un approccio per S/4HANA. Risponda alle cinque domande qui sotto, prenda per prima la decisione sul deployment, poi usi la tabella di confronto e l'albero decisionale per definire le altre due.

Nei 21 programmi a cui ho lavorato gli schemi sono coerenti. La scelta della strategia conta, ma è la metà più piccola della decisione. La metà più grande è se il team riesce a mantenere la disciplina per 14 mesi di esecuzione, dopo che il foglio di calcolo con le opzioni è stato archiviato.

L'obiettivo non è l'opzione più rapida o più economica. È l'approccio che si adatta al business: struttura, cultura, ritmo, profilo normativo e obiettivi di lungo periodo.

Cinque domande a cui rispondere per prime

1. Quanto è complessa la sua struttura: entità singola, multi-entità, multi-paese?
2. I suoi team hanno bisogno di tempo per adattarsi o sono pronti al cambiamento adesso?
3. Parte da più sistemi legacy, da un unico ERP o da una pagina bianca?
4. Dispone di competenze SAP interne o dipenderà dai partner?
5. Quanta interruzione dell'operatività può tollerare al go-live?

Non esiste una risposta universale. La strategia deve rispecchiare la sua realtà, non la storia di successo di qualcun altro.

Che cosa è cambiato tra il 2023 e il 2026

RISE e GROW sono diventati i modi standard di acquistare S/4HANA nel cloud. RISE with SAP riunisce in un'unica sottoscrizione il software (di solito Private Edition), l'infrastruttura e le operazioni tecniche gestite da SAP e i crediti BTP. GROW with SAP confeziona la Public Edition per le medie aziende con processi standard. Il modello tradizionale, licenza e poi implementazione, esiste ancora per l'on-premise, ma la maggior parte delle nuove conversazioni parte da RISE o da GROW.

Il Clean Core è passato da consiglio ad architettura. Sulla Public Edition non si può modificare il core: le estensioni usano API rilasciate, on-stack con ABAP Cloud oppure side-by-side su SAP BTP. Su Private Edition e on-premise si può ancora, ma le linee guida di SAP considerano la modifica l'ultima risorsa, perché ognuna aggiunge lavoro per gli aggiornamenti. I partner senza esperienza di Clean Core creano debito tecnico dalla prima settimana.

L'AI è arrivata negli strumenti di delivery. SAP Joule for Consultants (disponibile in generale da maggio 2025) risponde alle domande di configurazione a partire dai contenuti di SAP. SAP Cloud ALM può redigere i requisiti dalle trascrizioni dei workshop di fit-to-standard. SAP Build Code (disponibile in generale da marzo 2024) usa Joule per generare estensioni Java e JavaScript, e Joule for developers ha aggiunto la generazione e la spiegazione di codice ABAP dalla fine del 2024. Niente di tutto questo cambia la scelta strategica. Cambia costi e tempi all'interno di qualunque scelta si faccia.

Dove le strategie riescono o falliscono

L'esecuzione conta più della scelta. Quattro schemi di fallimento compaiono qualunque approccio sia stato scelto.

1. Il coinvolgimento dei vertici che sparisce. In un'implementazione S/4HANA per una banca, il CEO partecipava a ogni riunione importante, faceva buone domande e sosteneva il team. Il progetto è finito in tempo e ha speso meno del previsto. I dirigenti di una catena di negozi, invece, hanno delegato tutto dopo il kick-off. Il progetto si è fermato per mesi perché nessuno riusciva a prendere decisioni.
2. La migrazione dei dati trattata come un compito dell'IT. Un cliente insisteva che i suoi dati anagrafici dei prodotti fossero «abbastanza puliti». Il primo giorno il suo magazzino ha ricevuto ordini per prodotti fuori produzione da tre anni. La bonifica ha richiesto settimane e gli è costata un cliente importante. La migrazione dei dati richiede una titolarità di business.
3. Formazione saltata o frettolosa. Ho visitato un ufficio due settimane dopo il lancio di SAP. Il team di contabilità aveva post-it su tutti i monitor con promemoria per le attività di base; aveva avuto un solo giorno di formazione. Il loro responsabile mi ha detto: «Stiamo solo cercando di sopravvivere». Quell'azienda ha speso 200.000 dollari in più di assistenza nel primo anno.
4. Persone che aggirano il sistema. Ho lavorato con uno stabilimento convinto che bastasse la formazione. Gli operai non si fidavano del nuovo sistema e sono tornati ai fogli di calcolo. Correggere la situazione dopo il go-live è stato costoso. Il change management è comunicazione, coinvolgimento e sostenitori all'interno del business, con la formazione come una sola delle componenti.

I due principali modelli di rollout

Big Bang

• Tutto operativo con un unico cutover
• Il percorso più rapido verso processi standardizzati
• Costo iniziale più basso, rischio più alto il primo giorno
• Richiede prove di cutover rigorose e dati puliti

A fasi

• Go-live a ondate per modulo, area geografica o funzione
• Più spazio per correggere la rotta tra un'ondata e l'altra
• Costo di supporto più lungo, più integrazioni da mantenere
• Richiede disciplina e governance costanti

Big Bang

Una volta ho partecipato al go-live SAP di un'azienda manifatturiera in cui tutto è passato in un solo fine settimana. Finanza, acquisti, vendite e produzione sono partiti il lunedì mattina. È stato intenso, ma la chiarezza era potente. Tutti si sono mossi insieme, senza dubbi su quale sistema o quali dati usare.

Ciò che ha fatto funzionare le cose: il team ha provato il cutover più volte, ha ripulito i dati con settimane di anticipo e ha formato gli utenti su casi di test reali. Il lato positivo sono un allineamento più rapido e ritorni più veloci. Il lato negativo è l'assenza di margine d'errore. Quando un problema di prezzi ha colpito gli ordini di vendita il primo giorno, ha colpito tutte le regioni.

Funziona quando: i processi sono standardizzati, i team sono preparati e la leadership tiene ferma la linea sul perimetro.

A fasi

Su un altro progetto, con una catena retail, abbiamo scelto le fasi: prima finanza, HR e acquisti, poi logistica e punto vendita. Ci è voluto più di un anno, ma ha dato ai team il tempo di respirare. Il team HR ha passato il primo mese a mettere a punto i flussi di lavoro prima di formare tutti gli altri. In un Big Bang non sarebbe stato possibile.

Il compromesso è un periodo di supporto più lungo, e i dati che passano tra sistemi già operativi e non ancora operativi richiedono un'attenzione in più.

Funziona quando: l'organizzazione è grande o distribuita, i processi variano da regione a regione o la leadership vuole avere spazio per correggere la rotta.

Ibrido

A volte la risposta è entrambi.

Un distributore di elettronica di consumo nel Regno Unito con cui ho lavorato aveva bisogno di avere finanza e acquisti operativi in fretta. Il suo magazzino non era pronto, per via di troppe dipendenze. Così sono partite per prime finanza e acquisti, e logistica e magazzino sono seguite. Big Bang in un'area, a fasi in un'altra.

L'ibrido aggiunge lavoro di coordinamento. Se gli acquisti sono in SAP e le vendite no, la sincronizzazione dei dati tra i due richiede una progettazione attenta, e la governance deve restare rigorosa per tutto il tempo.

Funziona quando: le business unit procedono a velocità diverse, alcuni reparti devono muoversi più in fretta oppure i picchi stagionali escludono certe date di go-live.

Ecco come si confrontano i tre modelli:

Criterio	Big Bang	A fasi	Ibrido
Tempistica	La più breve: tutto in una volta	Più lunga: distribuita su più ondate	Intermedia: alcune aree veloci, altre più lente
Interruzione del business	Alta se il go-live ha problemi	Più bassa: il cambiamento è graduale	Alta per la prima ondata, più bassa dopo
Rischio	I problemi colpiscono tutta l'azienda	I problemi restano dentro una fase	Concentrato nelle parti Big Bang
Costo	Più basso all'inizio, errori costosi	Totale più alto, meno emergenze	Una via di mezzo; il coordinamento è la variabile imprevedibile
Migrazione dei dati	Un'unica finestra; deve essere completa	Caricamenti suddivisi, meno dati per fase	Le interfacce tra sistemi già operativi e non ancora operativi sono la parte difficile
Adozione da parte degli utenti	Difficile: cambiamento da un giorno all'altro	Più facile: esposizione graduale	La prima ondata fa da apripista; le successive imparano da essa
Più adatto a	Organizzazioni più piccole, processi standard, alta prontezza	Grandi aziende distribuite con processi diversi	Organizzazioni multi-unit in cui alcune unità sono pronte e altre no

Decide

Quale percorso di migrazione fa al caso suo?

Il legacy è frammentato e vuole ridisegnare i processi

→Greenfield

I processi sono solidi, ECC è stabile, lo storico deve restare

→Brownfield

Più entità, vuole un riuso parziale e dati selettivi

→Bluefield

Greenfield: partire da zero

L'ho visto su un progetto per un'azienda retail cresciuta in fretta con le acquisizioni, i cui sistemi erano frammentati. Siamo partiti da zero e abbiamo progettato processi unificati su S/4HANA. I team abituati ai propri modi di lavorare all'inizio hanno opposto resistenza. Il risultato è stato più coerenza tra le regioni, un reporting più pulito e sistemi che dialogavano tra loro.

Da usare quando: i sistemi legacy sono troppo frammentati o personalizzati per essere migrati in modo pulito e il business vuole ripensare il proprio modo di lavorare anziché digitalizzare vecchie abitudini.

Brownfield: convertire e aggiornare

In uno dei miei primi progetti, con un'azienda manifatturiera, il brownfield è stata la scelta giusta. Il cliente aveva personalizzato pesantemente il proprio sistema ECC e ricominciare da capo sembrava troppo rischioso. Ci siamo concentrati sulla conversione tecnica a S/4HANA. Gli utenti si sono abituati più in fretta e siamo andati in produzione prima, ma ci siamo portati dietro flussi di lavoro macchinosi che avrebbero dovuto essere ridisegnati.

Da usare quando: i processi esistenti sono solidi e documentati, lo storico transazionale conta per audit o compliance, budget o tempo sono limitati e l'organizzazione non si sta ristrutturando.

Bluefield: transizione selettiva

Il bluefield (transizione selettiva dei dati) sposta specifici company code, business unit o intervalli di date anziché tutto. Si adatta alle aziende plasmate da fusioni o scorpori, o ai sistemi che si portano dietro anni di dati di cui nessuno ha bisogno. Si ottiene la libertà di processo del greenfield con la continuità del brownfield per le parti che si sceglie di conservare. La mia guida alla migrazione da ECC a S/4HANA approfondisce i tre percorsi e le relative tempistiche.

Nel 2018 il modello di rollout e il percorso di migrazione erano l'intera strategia. Nel 2026 c'è una terza decisione, che limita le altre due: quale edizione di S/4HANA si usa e come la si acquista.

1. 03Modello di rolloutBig Bang, a fasi o ibrido, determinato da quanta interruzione si riesce ad assorbire
2. 02Percorso di migrazioneGreenfield, brownfield o bluefield, entro i limiti di ciò che l'edizione supporta
3. 01Modello di deploymentPublic Edition, Private Edition o on-premise. Si decide per primo

S/4HANA Cloud Public Edition (di solito acquistata tramite GROW with SAP e commercializzata da SAP come SAP Cloud ERP). SaaS multi-tenant, processi standard di SAP, aggiornamenti ogni sei mesi, nessuna modifica del core. Solo greenfield. Il time to value più rapido, la minore flessibilità. Ideale per le medie aziende disposte ad adottare lo standard SAP. Se i suoi processi richiedono scostamenti significativi, è la risposta sbagliata.

S/4HANA Cloud Private Edition (di solito acquistata tramite RISE with SAP). Single-tenant, infrastruttura gestita da SAP, una nuova release ogni due anni con sette anni di manutenzione ordinaria e più margine per configurare ed estendere. Supporta brownfield, greenfield e transizioni selettive. La scelta predefinita per la maggior parte dei grandi programmi enterprise.

S/4HANA on-premise. L'infrastruttura la gestiscono lei o il suo hyperscaler. Massima estensibilità e controllo, cadenza di aggiornamento più lenta. Il Clean Core è raccomandato ma non imposto. Adatta a requisiti rigorosi di residenza dei dati e a organizzazioni con solidi team Basis interni. Le nuove funzionalità di SAP arrivano sempre più spesso prima nelle edizioni cloud.

Modello di rollout e percorso di migrazione si collocano poi dentro l'edizione scelta. Un progetto su Public Edition è greenfield per definizione. Un programma su Private Edition che converte un sistema ECC molto personalizzato è di solito brownfield o bluefield, e su larga scala di solito a fasi. Per l'aspetto commerciale di RISE e GROW, consulti le mie pagine su GROW with SAP e RISE with SAP.

Era un giovedì mattina, a metà di un workshop di progettazione. Il responsabile IT aveva appena finito di mostrare il processo order-to-cash standard di SAP. Qualcuno delle vendite ha detto: «Sì, ma noi non lavoriamo così». Nella sala è calato il silenzio. Quel momento si verifica in quasi ogni progetto.

Fit-to-standard

Restare sullo standard SAP riduce i tempi di implementazione e la manutenzione a lungo termine. Gli aggiornamenti non possono rompere una logica custom che non esiste. In un progetto retail a cui ho lavorato, il fit-to-standard ha aiutato il cliente ad andare in produzione in meno di sei mesi: meno parti in movimento, meno andirivieni, un sistema più pulito per gli aggiornamenti futuri.

Regola pratica: personalizzare solo quando lo impone una normativa o quando il processo dà un vero vantaggio competitivo. Mai perché «abbiamo sempre fatto così».

Clean Core nella pratica

Chieda a ogni partner esempi di estensioni che ha realizzato su API rilasciate o su SAP BTP. Se la risposta è vaga, la consideri un campanello d'allarme. I partner che portano abitudini on-premise in un programma cloud accumulano debito tecnico fin dal primo sprint.

Quando il codice è inevitabile

Un po' di sviluppo custom è necessario. Strumenti di AI come SAP Build Code e Joule for developers abbassano il costo di scriverlo. Non abbassano il costo di mantenerlo.

Una logica custom che nessuno ha documentato diventa una logica che nessuno vuole toccare, e questo ritarda ogni modifica successiva. Nessuno strumento di AI risolve il problema. La disciplina nella documentazione sì. Se deve personalizzare, documenti fin dall'inizio, costruisca su API rilasciate o su BTP e la tenga isolata dal core. Una personalizzazione pulita ha un costo reale che si può recuperare. Una personalizzazione sporca ha un costo che si continua a pagare.

Sono le fasce di costo totale dei programmi che vedo sul mercato statunitense per S/4HANA nel 2026. Variano in base a perimetro, complessità, settore, partner ed edizione. Le usi come riferimenti per la pianificazione del budget, non come preventivi.

Strategia e perimetro	Costo totale tipico del programma
Mid-market brownfield, a fasi	da 5 a 15 milioni di dollari
Mid-market greenfield, Big Bang	da 8 a 20 milioni di dollari
Mid-market GROW with SAP (sottoscrizione e delivery)	da 2 a 6 milioni di dollari
Enterprise brownfield, a fasi	da 25 a 80 milioni di dollari
Enterprise greenfield, Big Bang	da 35 a 120 milioni di dollari
Enterprise RISE with SAP (sottoscrizione e delivery)	da 20 a 80 milioni di dollari
Globale multi-regione, qualsiasi combinazione	da 100 a oltre 300 milioni di dollari

Il modello di deployment è la variabile di costo più spesso sottostimata. Le sottoscrizioni RISE e GROW non costano meno delle licenze on-premise una volta sommato l'impegno pluriennale. Il loro valore sta nella responsabilità dell'infrastruttura che passa ad altri, nel time to value più rapido e nei costi di sottoscrizione prevedibili. Il motivo per scegliere RISE o GROW raramente è il costo totale. È il modello operativo.

Che cos'è una strategia di implementazione SAP?

È l'approccio con cui un'azienda introduce SAP: perimetro, metodo, modello di deployment, percorso di migrazione, modello di rollout e tempistica. Le scelte principali nel 2026 sono il modello di deployment (Public Edition, Private Edition o on-premise), il percorso di migrazione (greenfield, brownfield o bluefield) e il modello di rollout (Big Bang, a fasi o ibrido).

Conta se la combinazione si adatta alla prontezza dell'organizzazione, alla complessità dei processi, al profilo normativo e alla tolleranza verso le interruzioni.

Quando funziona un'implementazione Big Bang?

Quando i processi sono già standardizzati, gli utenti sono ben formati, i dati sono stati ripuliti prima della migrazione e la leadership tiene fermo il perimetro. Se manca anche uno solo di questi elementi, in particolare dati puliti e prontezza degli utenti, è un azzardo.

I problemi al go-live colpiscono tutto in una volta. Con la preparazione sono gestibili. Senza, è una crisi.

Qual è la differenza tra implementazione SAP greenfield e brownfield?

Il greenfield parte con un sistema nuovo, senza configurazioni legacy portate dietro. I processi si progettano da zero attorno allo standard SAP. Il brownfield converte il sistema esistente, conservando storico transazionale e configurazione.

Il greenfield costa di più all'inizio e produce un sistema più pulito e più pronto per il futuro. Il brownfield è più rapido e meno dirompente, ma si porta dietro soluzioni di ripiego e codice custom. Il bluefield è la via di mezzo: migrazione selettiva delle entità e dei dati che si sceglie.

Qual è la differenza tra RISE with SAP e GROW with SAP?

RISE with SAP è l'offerta in sottoscrizione di SAP per le grandi aziende, di solito basata su S/4HANA Cloud Private Edition, con infrastruttura e operazioni tecniche gestite da SAP in un unico contratto. Sul mercato statunitense vedo in genere programmi complessivi da 20 a 80 milioni di dollari, delivery inclusa.

GROW with SAP è pensato per le medie aziende e gira su S/4HANA Cloud Public Edition con i processi standard di SAP. In genere vedo da 2 a 6 milioni di dollari, delivery inclusa.

La scelta tra i due dipende dalle dimensioni dell'azienda e da quanto i suoi processi devono discostarsi dallo standard SAP.

Che cos'è il fit-to-standard in SAP e perché oggi conta di più?

Fit-to-standard significa adattare i propri processi alle funzionalità standard di SAP invece di personalizzare SAP sul modo in cui si lavora oggi. Accorcia l'implementazione, riduce la manutenzione e rende gli aggiornamenti più puliti.

Oggi conta di più a causa del Clean Core. Sulla Public Edition la modifica del core non è affatto possibile. Su Private Edition e on-premise ogni modifica aggiunge lavoro per gli aggiornamenti. La domanda da porsi è se esista un vero motivo di business per cui lo standard SAP non può rispondere e, in tal caso, se il partner è in grado di costruire l'estensione su API rilasciate o su SAP BTP.

Quali sono le fasi della metodologia SAP Activate?

SAP Activate ha sei fasi. Discover (esplorare l'offerta di SAP e il business case), poi quattro fasi di delivery fondamentali: Prepare (pianificare, definire la governance, costituire il team), Explore (workshop di fit-to-standard e backlog), Realize (configurare, estendere, testare a sprint) e Deploy (cutover, go-live e hypercare). Run copre le operations dopo il go-live.

Realize è la fase in cui la maggior parte dei progetti perde tempo, soprattutto quando i problemi di qualità dei dati emergono nei test o il perimetro delle personalizzazioni cresce. Una baseline di perimetro rigorosa lungo tutta la fase Realize distingue i progetti che vanno in produzione in tempo da quelli che vanno alla deriva.

Perché le implementazioni SAP falliscono?

Quattro cause spiegano la maggior parte dei fallimenti: il coinvolgimento dei vertici che sparisce dopo il kick-off, la migrazione dei dati trattata come un compito dell'IT, un change management limitato ai manuali di formazione e partner senza esperienza di Clean Core che creano debito tecnico destinato a emergere al primo aggiornamento.

La tecnologia raramente fallisce. I programmi falliscono quando le decisioni non vengono prese, quando dati sporchi arrivano nel nuovo sistema, quando gli utenti trovano scorciatoie o quando le personalizzazioni devono essere rifatte. La strategia conta. La disciplina di esecuzione conta di più.