Come avviare nel modo giusto un progetto di implementazione SAP

Per avviare bene un'implementazione SAP, chiarisca cinque cose prima che qualcuno configuri una sola transazione. Scelga il modello di deployment. Firmi una charter con ambito e diritti decisionali. Nomini responsabili di business che partecipino ai workshop di design. Avvii presto il lavoro su dati e cutover. Costruisca un calendario con una contingenza reale. Se nel primo mese questi punti sono a posto, la maggior parte dei fallimenti costosi non si verifica mai.

Ho sempre pensato che, con un sistema configurato correttamente, un'implementazione SAP sarebbe filata liscia. Blueprint, build, test, go-live. Per anni questo è stato il mio modello mentale.

Implemento ERP, SAP compreso, da 25 anni, in Medio Oriente, nel Sud-Est asiatico e in Europa. Anche quando i team seguivano SAP Activate passo dopo passo, i progetti incontravano difficoltà. I problemi non erano quasi mai tecnici. Responsabilità deboli. Ipotesi che nessuno aveva verificato. Una pianificazione del cutover partita troppo tardi. Queste crepe all'inizio sembrano innocue. Una volta che si allargano, lo sforzo tardivo non può correggere ciò che una visibilità precoce avrebbe evitato.

Un'implementazione SAP è un programma di cambiamento aziendale con una componente software. I workstream sono design dei processi, configurazione, migrazione dei dati, integrazione, test, formazione e change management. Ognuno ha tempi, rischi e un responsabile propri.

I team che la trattano come un esercizio di configurazione sottofinanziano tutto ciò che configurazione non è. È la causa più costante dei go-live difficili che incontro.

Per un programma che parte oggi c'è un altro workstream da chiarire per primo: il modello di deployment. S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) oppure on-premise. Questa scelta determina come funziona ogni altro workstream.

SAP Activate è il metodo di delivery di SAP. Ha sei fasi, ciascuna con quality gate alla fine. Ecco a cosa serve ogni fase e l'aspetto che non lascerei mai scivolare.

Fase	Cosa succede	Cosa verifico che sia a posto
Discover	Business case, ambito di alto livello, modello di deployment	Costi e tempi realistici, non quelli ottimistici
Prepare	Governance, charter, team, registro dei rischi, ambienti	Decisori nominati con autorità reale
Explore	Workshop fit-to-standard, decisioni sui gap, approvazione del design	Responsabili di business in sala, non solo l'IT
Realize	Configurazione, sviluppo, integrazione, test di sistema	Pianificazione del cutover già avviata
Deploy	User acceptance test, caricamenti dati, formazione, cutover	Almeno una prova generale completa
Run	Go-live, hypercare, passaggio al supporto	Hypercare presidiato fino alla prima chiusura mensile

Il ritardo di calendario più comune nasce da un Explore lento. Comprime Realize, che a sua volta comprime Deploy. Lo user acceptance test (UAT) viene accorciato, la prova dei dati viene saltata e il go-live avviene comunque, perché la data era già stata annunciata. I primi 90 giorni dopo il go-live ne pagano il conto.

1. 01Explore in ritardoFit-to-standard e approvazione del design slittano
2. 02Realize compressoMeno tempo per sviluppo e test
3. 03Deploy compressoMeno tempo per UAT, caricamenti dati e formazione
4. 04Test tagliatiUAT accorciato, prova dei dati saltata
5. 05Go-live alla data annunciataPerché la data era stata annunciata

Il costo ricade sull'hypercare, nei primi 90 giorni

1. Approvazione del design senza il business

Explore produce un design. La sua qualità dipende dal fatto che i responsabili di processo che lo hanno firmato abbiano capito che cosa stavano firmando. Quando ai workshop partecipano solo l'IT e i consulenti, il design può essere tecnicamente corretto e risultare comunque irriconoscibile per chi lo userà. L'UAT diventa allora scoperta invece che validazione.

Un test semplice: tre mesi dopo l'approvazione, chieda a un responsabile di processo di illustrarle come funzionerà un ordine d'acquisto dopo il go-live. Se non ci riesce, l'approvazione non era reale.

2. Una governance che esiste solo sulla carta

Senza una governance applicata, l'ambito cresce in modo informale e le decisioni vengono rinviate. Una buona governance significa uno sponsor esecutivo nominato, un comitato direttivo con diritti decisionali definiti, un project manager in grado di far rispettare un phase gate e un processo di change control con un approvatore nominato.

Nella maggior parte dei miei progetti il CFO ha assunto il ruolo di promotore. Quando i reparti non riuscivano a mettersi d'accordo su un processo, era lei a prendere la decisione finale. Così si sono evitate le settimane di ritardo che si accumulano quando le questioni restano irrisolte. La mia guida ai comitati direttivi SAP spiega come impostarlo.

3. Pianificazione del cutover tardiva

Il cutover è la parte operativamente più complessa del programma. Un piano avviato poche settimane prima del go-live non verrà provato, perderà delle dipendenze e non avrà un vero punto di rollback.

Avvii la pianificazione del cutover in Realize. Documenti la sequenza, esegua almeno una prova generale completa e concordi in anticipo i criteri di rollback. Le decisioni di cutover prese sotto pressione, da persone sveglie da venti ore e senza criteri concordati prima, sono il punto in cui iniziano i disastri dopo il go-live.

4. Test di integrazione sacrificati

Onestamente, pensavo che i test fossero una voce su una checklist. Si configura il sistema, si eseguono alcuni casi di test, si va avanti. Poi ho visto un progetto crollare solo perché nessuno aveva verificato come le approvazioni d'acquisto influissero sulle registrazioni contabili. Quel momento ha cambiato il mio modo di vedere i test in SAP.

I test unitari dimostrano che una transazione funziona da sola. I guasti che fanno male dopo il go-live emergono quando un processo completo attraversa più moduli. Un'entrata merci bloccata dallo stato di un ordine d'acquisto. Un ciclo di fatturazione fermo per una determinazione dei conti mancante. Testi le catene complete, order-to-cash e procure-to-pay, e non le lasci scivolare nelle ultime settimane prima dell'UAT.

5. Migrazione dei dati sottovalutata

I dati di origine sono quasi sempre peggiori di quanto suggerisca la prima valutazione. Mappature di campi che sembrano semplici falliscono al caricamento. Il numero di record include dati inattivi. Le regole di pulizia richiedono decisioni di business, e quelle richiedono tempo.

Un'azienda manifatturiera ha scoperto migliaia di record cliente duplicati durante la migrazione e ha dovuto rinviare il go-live di tre settimane per correggerli. Pianifichi fin dall'inizio cicli di caricamento aggiuntivi. Il mio articolo sul perché la migrazione dei dati SAP fallisce entra nel dettaglio.

6. Change management trattato come facoltativo

Ho visto progetti in cui il sistema funzionava alla perfezione e gli utenti si aggrappavano comunque ai vecchi processi. Non perché fossero ostinati, ma perché nessuno li aveva accompagnati nel passaggio. Quando il change management viene tagliato, i workaround compaiono già nella prima settimana e diventano permanenti, e i ticket di supporto restano alti per mesi.

Le personalizzazioni pesanti rientrano nella stessa categoria. Ho lavorato con un cliente che aveva personalizzato oltre il 60% del sistema. In seguito ha faticato ad aggiornarlo e ha perso il supporto del vendor.

I fondamentali descritti sopra non sono cambiati. Oggi, all'avvio di un programma, vanno chiarite tre cose.

Il modello di deployment viene per primo. La Public Edition offre le opzioni di personalizzazione più limitate e il sistema lo gestisce SAP. La Private Edition con RISE offre più margine e SAP gestisce l'infrastruttura. L'on-premise offre il massimo controllo e la massima responsabilità. Lo decida in Discover. I programmi che lo rimandano passano Explore a discuterne.

Il Clean Core appartiene alla charter. La Public Edition consente estensioni solo tramite interfacce rilasciate, quindi impone il Clean Core a livello tecnico. La Private Edition e l'on-premise no, perciò diventa una decisione di governance. SAP oggi classifica le estensioni dal livello A (solo API rilasciate) al livello D (modifiche), come illustrato nel suo aggiornamento sul Clean Core di agosto 2025. Inserisca nella charter il livello obiettivo e il forum di approvazione, altrimenti i partner ricorreranno per default alle modifiche.

Gli strumenti di AI appartengono al metodo fin dal primo giorno. Joule è disponibile nello SAP Activate Roadmap Viewer. Joule for consultants risponde alle domande di configurazione e Joule for developers genera codice ABAP Cloud. Possono velocizzare le attività di stesura e di build. Non eliminano le decisioni di business, il lavoro sui dati né l'impegno sul cambiamento. Chieda al suo partner dove li usa e come questo si riflette nel piano.

L'approccio dovrebbe seguire la sua tolleranza al rischio, la complessità e la capacità di assorbire il cambiamento. Queste sono le opzioni più comuni.

Approccio	Cosa significa	Più adatto a
Big bang	Tutti i moduli e tutte le entità vanno in produzione insieme	Organizzazioni più piccole con ambito standard, disposte ad accettare un rischio di go-live più alto
Per fasi, per modulo	Prima la finanza, poi la supply chain, poi le risorse umane	Moduli con poche interdipendenze; permette al team di imparare tra una fase e l'altra
Per fasi, per paese o entità	Un template va in produzione in un'entità, poi viene esteso	Gruppi con un template globale
Conversione brownfield	ECC esistente convertito a S/4HANA	ECC maturo con processi stabili
Greenfield	Nuova implementazione S/4HANA	Legacy non SAP, oppure ECC con un forte debito tecnico
Transizione selettiva dei dati	Entità o dati scelti trasferiti in un sistema riprogettato	Fusioni, carve-out, riuso parziale

Ho visto piccoli rollout andare in produzione in meno di sei mesi. Ho visto anche progetti trascinarsi per due anni perché le decisioni non erano state prese in tempo. Se sta valutando una prima implementazione rispetto a un rollout da template, la mia guida a implementazione e rollout li mette a confronto.

La usi nel primo mese, prima che inizi la configurazione. Ogni voce ha un responsabile lato cliente.

1. Sponsor esecutivo: modello di deployment deciso e registrato, con le motivazioni.
2. Direttore del programma: charter firmata, con ambito, esclusioni esplicite, criteri di successo, diritti decisionali e change control. Gli accordi verbali sull'ambito evaporano. La mia guida alla project charter include un template.
3. Responsabili di business: un responsabile di processo nominato per ogni area, con il tempo davvero liberato per partecipare ai workshop.
4. Solution architect: obiettivo di Clean Core e forum di approvazione delle estensioni concordati.
5. Responsabile dei dati: profiling dei dati avviato in Prepare, non dopo l'approvazione del design.
6. Responsabile del cutover: nominato in Realize, con una data di prova già inserita nel piano.
7. Test manager: scenari di test sulle catene di processo complete elencati, comprese le approvazioni fino alle registrazioni contabili.
8. CFO: calendario confrontato con programmi comparabili, con contingenza per un Explore lento e cicli di dati aggiuntivi. Un piano che presume che tutto vada bene non è un piano.

Che cos'è un progetto di implementazione SAP?

È il programma che mette in funzione il software SAP per gestire le operazioni di un'azienda. Comprende design dei processi, configurazione, migrazione dei dati, integrazione, test, formazione e change management, di solito eseguiti con SAP Activate. L'impegno varia enormemente in base al numero di entità, paesi e moduli e allo stato dei dati esistenti.

Quali sono le fasi di un'implementazione SAP?

SAP Activate ha sei fasi: Discover, Prepare, Explore, Realize, Deploy e Run. Discover definisce il business case e l'ambito. Prepare imposta governance e team. Explore conduce i workshop fit-to-standard e conferma il design. Realize sviluppa e testa. Deploy comprende UAT, caricamenti dati, formazione e cutover. Run è il go-live e l'hypercare. Ogni fase termina con un quality gate.

Quanto dura un'implementazione SAP?

Dipende dall'ambito e dalla rapidità con cui si prendono le decisioni. Ho visto piccoli rollout andare in produzione in meno di sei mesi e progetti trascinarsi per due anni perché le decisioni non erano state prese in tempo. La causa più comune dei ritardi è una fase Explore lenta che comprime tutto ciò che viene dopo.

Quali sono i motivi più comuni per cui le implementazioni SAP falliscono?

Design approvato senza un reale coinvolgimento del business, governance non applicata, pianificazione del cutover tardiva, test di integrazione compressi, migrazione dei dati sottovalutata e change management tagliato. Tutti e sei di solito sono visibili presto e poco costosi da correggere in quel momento.

Che cosa deve contenere la project charter di un progetto SAP?

Obiettivi legati a risultati misurabili, ambito per modulo, entità, paese e integrazione, esclusioni esplicite, diritti decisionali con persone nominate, governance ed escalation, criteri di successo, change control, milestone principali e ipotesi chiave. Per un programma cloud, aggiunga il modello di deployment e l'approccio Clean Core. La faccia firmare dallo sponsor e dai responsabili di business prima che inizi la configurazione.

Che cos'è l'hypercare dopo il go-live di SAP?

L'hypercare è il periodo di supporto intensivo dopo il go-live, in genere da 30 a 90 giorni. Il team di progetto e il business lavorano fianco a fianco per risolvere i problemi e stabilizzare le operazioni. Lo mantenga presidiato per almeno un ciclo operativo completo, compresa la prima chiusura mensile, perché è allora che molti problemi emergono per la prima volta.