Template di implementazione SAP: guida fase per fase

SAP Activate fornisce un template per quasi ogni deliverable di un programma S/4HANA. Li trova nello SAP Activate Roadmap Viewer e, nei programmi cloud, dentro SAP Cloud ALM. Trovarli è facile. Difficile è sapere quali prendere sul serio.

Questa guida è per program manager, responsabili PMO e sponsor che stanno avviando un'implementazione. Copre i template su cui insisto in ogni fase, mostra un layout funzionante per ciascuno e segnala dove i team tagliano gli angoli. Se ha una settimana prima del kickoff, faccia per primi il documento di scoping e la matrice degli stakeholder. Tutto ciò che viene dopo si appoggia su quei due.

Lo schema nei programmi ECC e S/4HANA a cui ho lavorato nel manifatturiero, nel retail e nei servizi finanziari è costante. I team che seguono i template individuano i problemi prima. I team che li trattano come carta facoltativa scoprono a metà progetto che ogni decisione mai messa per iscritto è diventata una disputa sul perimetro.

Questo è l'insieme che mi aspetto di vedere approvato, con il responsabile di ciascuno e il punto che deve superare.

Fase	Template	Responsabile	Approvato prima di
Prepare	Documento di scoping del progetto	Program manager (lo sponsor approva)	Avvio di Explore
Prepare	Business case	CFO o responsabile di business	Rilascio dei fondi
Prepare	Matrice degli stakeholder	Program manager	Prenotazione dei workshop di Explore
Explore	Foglio dei requisiti e del fit-gap	Solution architect con i process owner	Avvio di Realize
Realize	Registro delle configurazioni	Functional lead	Passaggio di ogni transport in QA
Realize	Registro degli sviluppi custom	Responsabile dello sviluppo	Avvio dello sviluppo di qualsiasi oggetto
Realize	Strategia di test	Test manager	Avvio del system integration test
Realize	Piano di migrazione dei dati	Responsabile della migrazione dei dati	Primo mock load
Deploy	Piano di cutover	Responsabile del cutover	Prova generale finale
Deploy	Valutazione di prontezza al go-live	Program director (lo sponsor firma)	Riunione di go/no-go
Run	Modello di supporto in hypercare	Responsabile della service delivery	Go-live
Run	Foglio di monitoraggio delle prestazioni	Responsabile Basis	Go-live

Activate ha sei fasi: Discover, Prepare, Explore, Realize, Deploy e Run. Combina i contenuti SAP Best Practices, la configurazione guidata e un approccio di delivery agile. Per la maggior parte dei clienti Discover avviene prima della firma del contratto, quindi i template qui sotto partono da Prepare.

1. 01DiscoverDi solito prima della firma del contratto
2. 02PrepareDocumento di scoping, business case, matrice degli stakeholder
3. 03ExploreFoglio dei requisiti e del fit-gap
4. 04RealizeRegistro delle configurazioni, registro degli sviluppi, strategia di test, piano di migrazione
5. 05DeployPiano di cutover, prontezza al go-live
6. 06RunModello di hypercare, monitoraggio delle prestazioni

Ogni template firmato prima del proprio gate

La sequenza delle fasi non è facoltativa. Ho lavorato con un retailer che ha provato a saltarne alcune parti e ha finito per rifare tre mesi di lavoro. Ogni quality gate esiste per un motivo.

Quando adatta i template, mantenga circa l'80% della struttura standard. Modifichi solo ciò che riflette il suo contesto: requisiti di settore, controlli normativi, specificità regionali. Riscrivere tutto vanifica lo scopo.

Cosa è cambiato negli strumenti nel 2026

La struttura di Activate è la stessa di prima. Gli strumenti che le girano intorno si sono mossi.

1. SAP Cloud ALM ospita i template nei programmi cloud. È il successore di Solution Manager proposto da SAP ed è incluso in SAP Enterprise Support e nelle sottoscrizioni cloud come RISE with SAP. Scoping, requisiti, piani di test e attività di cutover possono stare lì, con tracciabilità tra loro. Solution Manager 7.2 esce dalla manutenzione standard a fine 2027, con manutenzione estesa fino al 2030 per alcune funzioni, quindi gli scenari on-premise esistenti hanno qualche anno, non un decennio.
2. Joule è ora dentro gli strumenti della metodologia. SAP ha reso disponibile Joule nell'Activate Roadmap Viewer nel 2025 e in SAP Cloud ALM, quindi un team può chiedere indicazioni sulle attività o far redigere contenuti a partire dalla roadmap. Accelera la prima bozza. Non sostituisce la persona che firma il fit-gap.
3. Clean core è ora una regola di progettazione, con dei livelli. Nell'agosto 2025 SAP ha sostituito il suo modello di estensibilità a tre livelli con quattro livelli di clean core, da A a D. Il livello A usa solo API rilasciate, su SAP BTP oppure nel sistema con ABAP Cloud. Il livello D non è affatto clean. Il template di fit-gap ha bisogno di una colonna che indichi dove atterrerà ciascun gap.
4. La public edition restringe il fit-gap. SAP ora commercializza S/4HANA Cloud Public Edition come SAP Cloud ERP, venduto alle aziende di medie dimensioni come SAP GROW. Valgono le stesse sei fasi con artefatti più leggeri, e sono ammesse solo estensioni tramite API rilasciate, quindi la colonna «gap» ha meno risposte possibili.

I progetti che saltano questo lavoro preliminare lo pagano in Explore e Realize.

Template di scoping del progetto

Definisce che cosa il progetto comprende e che cosa no. Quando qualcuno prova ad aggiungere perimetro dopo tre mesi (e succederà), questo documento è il punto di riferimento. Il project charter SAP sta sopra di esso e contiene i dettagli di governance.

Sezione	Dettagli
Titolo, sponsor, PM	Implementazione di SAP S/4HANA Finance; CFO; PM senior indicato per nome
Contesto	Stato attuale e motivo del cambiamento
Obiettivi	Ridurre il ciclo di chiusura da 14 a 5 giorni; eliminare le riconciliazioni manuali
Nel perimetro	FI/CO, integrazione MM/SD, migrazione dei dati, UAT, go-live
Fuori dal perimetro	Moduli HR, migrazione dei report legacy, integrazioni di terze parti oltre l'ERP
Ipotesi	Sponsor esecutivo disponibile per lo SteerCo mensile; dati di test concordati entro la settimana 6
Vincoli	Data di go-live fissa; solo risorse interne per la configurazione
Deliverable	Sistema configurato, piani di test, piano di cutover, materiali di formazione
Tempistica	Prepare: settimane 1-4; Explore: settimane 5-10; Realize: settimane 11-26
Approvazione	Prima dell'avvio di Explore sono richieste le firme dello sponsor del progetto e del PMO

Template di business case

Percorre l'analisi costi-benefici in un formato che il team finanza sa leggere. Ho avuto clienti che hanno ottenuto l'approvazione del programma al primo invio con questa struttura, perché i numeri sono chiari e le ipotesi sono scritte.

Una regola a cui mi attengo: il system integrator che eseguirà il lavoro non dovrebbe scrivere questo documento. Il loro incentivo è partire. Il suo è finire. Il mio template di business case SAP approfondisce il modello dei benefici.

Sezione	Dettagli
Responsabile e sintesi	CFO o program director; perché adesso, cosa cambia, cosa resta uguale
Definizione del problema	Problemi operativi specifici (durata del ciclo di chiusura, workaround manuali, età del sistema)
Approccio proposto	Greenfield / brownfield / selective, con sintesi del perimetro
Benefici	Quantificati: giorni risparmiati nel ciclo di chiusura, risparmio di FTE, riduzione del tasso di errore, riduzione del rischio di audit
Costi e finanziamento	Implementazione, licenza o sottoscrizione, tempo delle risorse interne, riserva per imprevisti; fonte del budget
Rischi	I primi tre, con probabilità e impatto
Raccomandazione	Procedere / procedere con condizioni / rinviare, con motivazione

Matrice di identificazione degli stakeholder

Mappa tutte le persone toccate dall'implementazione e il loro livello di influenza. Le dice a colpo d'occhio chi ha bisogno di aggiornamenti settimanali e a chi basta un avviso prima del go-live.

Stakeholder	Ruolo	Interesse	Influenza	Coinvolgimento
CFO di gruppo	Sponsor esecutivo	ROI del programma, miglioramento della chiusura contabile	Alta	SteerCo mensile, aggiornamento scritto settimanale
Direttore IT	Responsabile tecnico	Stabilità del sistema, integrazione, sicurezza	Alta	Program board settimanale, quotidiano durante Realize
Direttore finanziario	Process owner chiave	Design FI/CO, processo di chiusura	Alta	Workshop in Explore, firma dell'UAT
Direttori di stabilimento	Utenti impattati	Cambiamenti ai processi MM/PP	Media	Comunicazioni mensili sul cambiamento, partecipazione all'UAT
Utenti finali (AP/AR)	Operatori	Cambiamenti a livello di transazione	Bassa	Formazione, supporto in hypercare
Internal Audit	Governance	Tracciabilità, controlli, compliance	Media	Revisione degli artefatti ai quality gate

Usi la stessa matrice per pianificare i workshop di Prepare che raccolgono i requisiti di alto livello per reparto. Numeri quei requisiti nel formato che userà in Explore (REQ-001 e così via), così nulla viene rinumerato più tardi e la tracciabilità fino alla richiesta originale resta intatta.

Explore è il momento in cui l'implementazione prende forma. Questi template rivelano il divario tra ciò che SAP fa di serie e ciò di cui il business ha bisogno.

Template di mappatura dei requisiti e fit-gap

La mappatura dei requisiti cattura le esigenze di business per reparto e riconduce ciascuna a un componente di sistema e a un test case. Ho visto aziende saltarla e ritrovarsi con sistemi che nessuno usa, perché la realizzazione si basava su ciò che i consulenti avevano dato per scontato invece che su ciò che il business aveva detto.

L'analisi fit-gap mostra poi dove lo standard SAP soddisfa ogni esigenza e dove no. Per la maggior parte dei miei clienti è una vera rivelazione. Mi piace osservare il momento in cui un team capisce di poter usare la funzionalità standard invece di costoso codice custom.

Tengo entrambe in un unico foglio, con una colonna per il percorso di risoluzione. Su S/4HANA ogni gap richiede una risposta esplicita: configurazione standard, key user extension, developer extension nel sistema, oppure estensione side-by-side su SAP BTP. Le modifiche classiche al codice SAP sono la risposta più costosa e dovrebbero richiedere un approvatore nominato.

Req ID	Requisito	Componente SAP	Fit / Gap	Percorso di risoluzione	Rif. test
REQ-001	Scritture di chiusura mensile automatizzate	FI-GL, chiusura di periodo	Fit	Configurare i template di documento ricorrenti	TC-001
REQ-002	Approvazione degli ordini di acquisto tramite Fiori	Acquisti MM, app di approvazione Fiori	Gap (assente in ECC)	App standard S/4HANA e configurazione del workflow	TC-003
REQ-003	Automazione della fatturazione intercompany	Fatturazione SD, integrazione FI	Gap	Configurazione della fatturazione intercompany	TC-010
REQ-004	Monitoraggio dei job batch	App Application Jobs	Fit	App standard	TC-015
REQ-005	Portale self-service per i fornitori	SAP Ariba o portale fornitori	Gap	Integrazione Ariba	TC-020
REQ-006	Archiviazione dei dati conforme al GDPR	ILM, archiviazione dei dati	Gap	Configurazione della policy ILM	TC-025
REQ-007	Reporting in tempo reale sui centri di costo	CO, embedded analytics o SAC	Gap	Embedded analytics o connessione live a SAC	TC-030
REQ-008	Supportare 500 utenti simultanei	Dimensionamento HANA	Gap (300 testati)	Revisione del dimensionamento e potenziamento dell'infrastruttura	TC-035

Questa è la fase di realizzazione. Questi template sono la traccia di audit di ogni decisione di configurazione, di ogni sviluppo e di ogni risultato di test.

Template di tracciamento delle configurazioni

Registra ogni modifica al sistema: chi l'ha fatta, perché e in quale transport è finita. Quando qualcosa si rompe più avanti, risale al problema in pochi minuti invece che in giorni.

1. ID di configurazione e modulo: [ad es. MM-CONF-001, MM]
2. Percorso IMG e oggetto di configurazione: [ad es. tabella T161, tipi di documento dell'ordine di acquisto]
3. Scopo e processo di business interessato
4. Configurato da e data
5. Numero della richiesta di transport: [ad es. DEVK900123]
6. Valori chiave: prima e dopo
7. Test case collegati
8. Stato di validazione e approvazione

Registro degli sviluppi custom

Ogni oggetto custom riceve una riga prima che qualcuno scriva codice. Uno dei miei clienti ha ridotto del 30% il codice custom perché il registro mostrava dove lo standard SAP avrebbe funzionato benissimo.

Dev ID	Oggetto	Descrizione	Sviluppatore	Effort (ore)	Stato	Tipo di estensione
CD-001	Tile Fiori: panoramica dei centri di costo	Tile di reporting CO in tempo reale per la finanza	Sviluppatore Fiori	12	Completato	Developer extension
CD-002	Report di fatturazione intercompany	Report per la riconciliazione IC	Sviluppatore ABAP	20	In corso	Developer extension
CD-004	App stato dei pagamenti ai fornitori	App Fiori per le richieste sui pagamenti AP	Sviluppatore BTP	10	In attesa di QA	Side-by-side su BTP
CD-005	Notifica di entrata merci	Invio di un'email alla registrazione di un'entrata merci	Sviluppatore di integrazioni	24	Pianificato	Basata su eventi, su BTP

Template della strategia di test

Mette tutti i piani di test in un unico posto: chi testa cosa, quando, in quale ambiente e con quale standard.

Sezione	Dettagli
Perimetro	Test funzionali, di integrazione, di regressione, di prestazioni e UAT sui moduli nel perimetro (i penetration test spettano a InfoSec)
Ambienti	DEV, QA, UAT (pre-produzione), staging per la validazione finale
Strumenti	Gestione dei test in SAP Cloud ALM o Jira/Xray; automazione con Tricentis Tosca o simili; prestazioni con JMeter o LoadRunner
Ciclo di vita dei difetti	Nuovo, In lavorazione, Risolto, Verificato, Chiuso; gravità e priorità definite al triage
Criteri di uscita	Tutti i difetti critici chiusi; firma dell'UAT ricevuta; tasso di superamento dei test di regressione di almeno il 95%; benchmark di prestazioni raggiunti

Template di pianificazione della migrazione dei dati

La migrazione dei dati è il flusso di lavoro che più probabilmente le farà male. Questo template la scompone in passaggi che fanno emergere i problemi di qualità dei dati prima del cutover e non durante. L'articolo sugli schemi di fallimento della migrazione dei dati spiega cosa va storto quando la si salta.

Sezione	Dettagli
Perimetro	Dati anagrafici dei clienti, dati anagrafici dei fornitori, partite aperte, dati anagrafici dei materiali, saldi di magazzino, gerarchie dei centri di costo
Sistemi di origine	ECC 6.0 EHP 7 (principale); sistema HR legacy (assegnazioni dei dipendenti ai centri di costo)
Sistema di destinazione	S/4HANA (release corrente)
Mappatura e regole	Clienti e fornitori verso Business Partner; centri di costo verso la nuova gerarchia; rimozione delle coordinate bancarie non valide; unione dei duplicati
Strumenti di migrazione	SAP S/4HANA Migration Cockpit (principale); Migration Object Modeler per gli oggetti custom; script per il pre-processing
Strategia di caricamento	Mock load su QA; migrazione delta e riconciliazione; cutover in produzione
Approccio di validazione	Conteggio dei record da origine a destinazione; campionamento casuale del 10%; report di riconciliazione dei saldi
Piano di rollback	Backup pre-cutover; sistema legacy in standby per 48 ore

La fase Deploy è il momento in cui si va live. Questi template trasformano un weekend caotico in un evento gestito.

Template di pianificazione del cutover

Mappa la finestra di blackout ora per ora. Ogni attività, ogni responsabile, ogni orario di inizio. Il suo team non dovrebbe mai trovarsi fermo alle 2 di notte a chiedersi cosa fare dopo.

Concordi quattro cose prima di scrivere l'elenco delle attività: la finestra (per esempio da venerdì alle 22:00 a sabato alle 06:00), il trigger di rollback, la rapidità con cui il sistema legacy può essere riattivato e gli smoke test che dimostrano che il nuovo sistema funziona. Poi la sequenza delle attività:

Passo	Descrizione	Responsabile	Orario di inizio	Stato
1	Congelamento del sistema ECC (nessuna registrazione)	Basis	22:00	In sospeso
2	Estrazione finale dei dati e riconciliazione	Responsabile della migrazione dei dati	22:30	In sospeso
3	Esecuzione del caricamento di migrazione in produzione	DBA	23:00	In sospeso
4	Import dei transport rimanenti in produzione	Basis	00:30	In sospeso
5	Switch di DNS e load balancer verso S/4HANA	Rete	01:30	In sospeso
6	Smoke test: registrazione FI, entrata merci, ordine di vendita	QA lead	02:00	In sospeso
7	Conferma del business e decisione di go/no-go	Program director	03:00	In sospeso
8	Apertura del sistema agli utenti di business	Basis	06:00	In sospeso

Valutazione di prontezza al go-live

Decide se è davvero pronto a passare. Ho avuto clienti che hanno rimandato il go-live in base a questa valutazione, e me ne sono stati grati più tardi.

Area	Verifiche (ciascuna con risposta sì o no, con evidenza)
Funzionale	Processi chiave testati; scenari cross-modulo completati; difetti P1/P2 aperti elencati; i key user confermano la prontezza
Dati	Caricamenti dei dati anagrafici completati; dati transazionali validati; report di riconciliazione approvati; congelamento del legacy confermato
Tecnica	Piano di cutover approvato; transport in produzione; job batch schedulati; monitoraggio configurato
Persone	% di copertura della formazione; ruoli di accesso validati; team di hypercare con organico completo; piano di supporto comunicato
Decisione	Rischi critici e mitigazioni elencati; Go / No-go / Condizionato; approvato con nome, ruolo e data

Dopo il go-live il lavoro cambia forma. Questi template accompagnano il sistema e il team attraverso l'hypercare fino alla fase di regime.

Template di supporto post-implementazione

Organizza il modo in cui gestisce i problemi dopo il lancio. Senza, ogni problema diventa un P1.

Sezione	Dettagli
Finestra di hypercare	Settimane 1-4 dopo il go-live: copertura 24/7
Canali di supporto	Coda di incident ServiceNow (principale); canale chat dedicato; phone bridge per i problemi P1
Livelli di supporto	1: service desk (password, navigazione, problemi noti); 2: consulenti funzionali (domande sui processi, piccole configurazioni); 3: Basis e sviluppo (errori di sistema, prestazioni, interfacce)
SLA (risposta / risoluzione)	Critico 15 min / 2 h; Alto 30 min / 4 h; Medio 4 h / 1 giorno; Basso 1 giorno / 3 giorni
Monitoraggio	SAP Cloud ALM o Solution Manager; revisione quotidiana dei log di errore
Criteri di uscita	Nessun problema P1/P2 aperto; tutti gli incident documentati; firma finale di consegna

Template di monitoraggio delle prestazioni

Le permette di osservare giorno per giorno lo stato di salute del sistema e di individuare i rallentamenti prima che gli utenti si lamentino. Di recente ho aiutato un'azienda a intercettare in questo modo un problema del database che avrebbe mandato in crash il sistema durante la chiusura mensile.

Metrica	Obiettivo	Strumento	Soglia di allarme	Responsabile
Tempo di risposta dialog (95° percentile)	Meno di 1 secondo	ST03 / SAP Cloud ALM	2 secondi	Team Basis
Completamento dei job in background	100% secondo la schedulazione	SM37 / Application Jobs	Qualsiasi job fallito	Responsabile operations
Tempo delle query sul database	Meno di 200 ms	SAP HANA cockpit	500 ms	DBA
Disponibilità del sistema	Oltre il 99,5%	SAP Cloud ALM	Meno del 99%	Infrastruttura
Tasso di errore delle interfacce	Meno dell'1%	Monitoraggio di SAP Integration Suite	2%	Responsabile middleware
Tasso di successo dei login	Oltre il 98%	Log di audit di sicurezza	Meno del 95%	Responsabile sicurezza
Durata del job di chiusura mensile	Entro la finestra concordata	Job scheduler	Oltre il 30% sopra la baseline	Finance operations

I quality gate impediscono che un problema di una fase diventi una costosa rilavorazione nella successiva. La mia guida ai quality gate SAP spiega come impostarli. Ecco perché contano.

L'approvazione esecutiva prima del go-live non dovrebbe essere un timbro di rito. In un progetto su cui ho lavorato, il CEO ha individuato durante la revisione del go-live un grosso problema che avrebbe sconvolto il lavoro del team finanza.

Definisca criteri di superamento o fallimento a ogni gate. «Il 95% dei test di regressione deve passare.» «Tutti gli scenari di integrazione FI sono verdi.» Criteri così le danno una base difendibile per tenere la posizione quando il business vuole lanciare a una certa data indipendentemente dalla qualità.

In uno dei miei progetti, il quality gate ci ha fermati quando era passato solo il 75% dei test di integrazione. Abbiamo corretto i problemi prima di andare avanti di fretta. Questo ha fatto risparmiare al cliente circa 100.000 € in correzioni d'emergenza dopo il lancio.

Un gate che lo sponsor può scavalcare con una telefonata non è un gate. Metta per iscritto chi può derogarvi prima che serva.

Che cos'è la metodologia SAP Activate?

SAP Activate è la metodologia di implementazione di SAP per S/4HANA e per gli altri prodotti cloud. Si articola in sei fasi (Discover, Prepare, Explore, Realize, Deploy, Run) e combina i contenuti SAP Best Practices, la configurazione guidata e la delivery agile.

Gli elenchi di attività e i template dei deliverable per ogni scenario di deployment sono pubblicati nello SAP Activate Roadmap Viewer.

Quale fase di SAP Activate ha i template più importanti?

Prepare. Il documento di scoping, il business case e la matrice degli stakeholder pongono le basi di ogni decisione successiva, e sono quelli che i team saltano per arrivare prima alla configurazione. Quella scorciatoia è la causa più comune di dispute sul perimetro in Realize.

Explore viene al secondo posto. Le lacune nei documenti di fit-gap e di mappatura dei requisiti riaffiorano come difetti dell'UAT mesi dopo, quando correggerle costa molto più di quanto sarebbe costato alla settimana 3 di Explore.

Si possono personalizzare i template di SAP Activate?

Sì. Mantenga circa l'80% della struttura standard e modifichi solo ciò che è specifico del suo contesto: validazione farmaceutica, regole di procurement del settore pubblico, controlli SOX. Li aggiunga all'inizio di Prepare, non in Deploy.

Non personalizzi la struttura dei quality gate, la sequenza delle fasi né gli artefatti obbligatori (documento di scoping, business case, valutazione di prontezza al go-live).

I template di SAP Activate funzionano sia per greenfield sia per brownfield?

Sì. La differenza principale è in Explore. Una conversione brownfield porta avanti la configurazione esistente, quindi il fit-gap si concentra su ciò che deve cambiare, su quale codice custom lo standard S/4HANA può ora sostituire e su quale pulizia dei dati serve prima della conversione. Un programma greenfield parte da SAP Best Practices e conferma quali processi standard si adattano.

Anche il piano di cutover cambia. Una conversione di sistema brownfield segue una sequenza diversa da un go-live greenfield con migrazione completa dei dati.

Quanto deve essere dettagliato un piano di cutover?

Ora per ora come minimo, e più stretto di così per la finestra di blackout. Ogni attività ha bisogno di un orario di inizio, di un responsabile e di una dipendenza.

Concordi i criteri di rollback prima che il cutover inizi: quali condizioni fanno scattare il ritorno al sistema legacy, chi prende quella decisione e entro che ora. Le decisioni di rollback prese alle 4 di notte senza criteri concordati in anticipo sono il punto in cui iniziano i disastri dopo il go-live.