Quality gate SAP: come impostarli e dove falliscono

Un quality gate è un punto di controllo formale tra le fasi di progetto. Prima di andare avanti, il team deve dimostrare che i criteri concordati sono soddisfatti. Se lo sono, si procede. Se non lo sono, si sistemano prima i problemi. In un programma SAP i gate si collocano alle transizioni tra le fasi di SAP Activate, ciascuno con un owner nominato che ha l'autorità di dire «non siamo pronti».

Una grande azienda di beni di consumo di Singapore stava avviando SAP a livello globale. Il team aveva bruciato le tappe sui test per rispettare le scadenze. Ho visto il disastro svolgersi sotto i miei occhi. I test utente erano stati appena abbozzati, ma i dirigenti hanno spinto comunque per il lancio. Nel giro di pochi giorni sono emersi i problemi: configurazioni mancanti, workflow interrotti, dati completamente sbagliati. Le settimane di caos dopo il lancio erano dovute a problemi che si vedevano già prima del go-live. Nessuno si è fermato a controllare.

Io i quality gate review non li salto mai. Niente scorciatoie, niente timbri di approvazione. All'inizio richiede più tempo, ma fa risparmiare mesi di rimedi dopo.

Un gate è un punto decisionale con uno standard scritto, un'approvazione documentata e la reale autorità di rimandare il progetto. Non è una revisione dell'avanzamento né un aggiornamento di stato per lo steering committee.

Senza quell'autorità, le revisioni diventano timbri di approvazione. E i gate ridotti a timbro sono peggio di nessun gate, perché danno una falsa sicurezza. Un cliente del retail faceva «revisioni» che erano in sostanza timbri. Dopo sei mesi era irrimediabilmente in ritardo, perché nessuno aveva affrontato i problemi che quelle revisioni avrebbero dovuto intercettare.

SAP Activate ha sei fasi: Discover, Prepare, Explore, Realize, Deploy e Run. Ogni transizione è un gate naturale. Ecco cosa mi aspetto che ciascun gate verifichi.

Gate di fase	Focus sulla qualità	Evidenze da vedere	Si passa quando
Discover	Business case, allineamento del vertice	Business case, roadmap di alto livello	Business case firmato, sponsor impegnato
Prepare	Governance, team, rischi	Charter, modello di governance, registro dei rischi	Charter approvato, owner dei rischi nominati, team inserito
Explore	Fit-to-standard, design, approccio all'integrazione	Decisioni fit-gap, disegni di processo, architettura di integrazione	Process owner hanno approvato; ogni gap ha una decisione
Realize	Configurazione, test di integrazione	Report di esecuzione dei test, registro dei difetti	Soglie di test raggiunte, difetti critici chiusi
Deploy	Dati, formazione, prontezza del cutover	Riconciliazione della migrazione, registri della formazione, piano di cutover	Prova generale completata, piano di rollback concordato
Run	Stabilizzazione e passaggio di consegne	Registro degli incidenti, report sulle prestazioni	Incidenti entro i limiti concordati, passaggio al supporto firmato

Nella pratica, Explore, Realize e Deploy sono le fasi più rischiose. Un problema che supera uno di questi tre gate costa di più quando emerge dopo il go-live.

1. 01DiscoverBusiness case firmato, sponsor impegnato
2. 02PrepareCharter approvato, owner dei rischi nominati
3. 03ExploreOgni gap ha una decisione
4. 04RealizeSoglie di test raggiunte, difetti critici chiusi
5. 05DeployProva generale completata, rollback concordato
6. 06RunIncidenti entro i limiti, passaggio di consegne firmato

Ogni gate è firmato da un solo owner con l'autorità di dire non siamo pronti

Scriva i criteri di ingresso e di uscita di ogni gate nel project charter prima che inizi la configurazione. I criteri scritti sotto la pressione delle scadenze descrivono ciò che il team è in grado di mostrare in quel momento, non ciò di cui il progetto ha bisogno. Un cliente ha provato ad accorpare le fasi per «risparmiare tempo». Ha finito per rifare settimane di lavoro.

Criteri che danno una risposta sì o no

«Test completati» non è un criterio. Scatena discussioni. Ho lavorato con un cliente del retail il cui gate diceva semplicemente «UAT completato». Metà del team lo leggeva come tutti i test eseguiti; l'altra metà come tutti i difetti corretti.

«Il 95% dei casi di test eseguiti, tutti i difetti di priorità 1 risolti, nessun difetto di priorità 2 aperto da più di cinque giorni» è un criterio. Produce una risposta.

I gate di un cliente manifatturiero fallivano perché i criteri erano troppo vaghi. Nessuno sapeva se li avesse davvero superati. Quando i criteri sono diventati soglie misurabili, le discussioni sui passaggi di fase sono finite.

Un solo owner con l'autorità di rimandare

Ogni gate ha bisogno di un owner nominato che possa rimandare il progetto. Una persona, non un comitato. Ho visto un progetto schiantarsi perché nessuno aveva il potere di rimandare la fase successiva, anche se il team non era pronto.

Il contrario funziona. Un cliente del retail ha nominato un direttore senior come owner del gate. Quando diceva «non siamo pronti», tutti ascoltavano. Metta quell'autorità nel charter.

Il sostegno del vertice prima che arrivi la pressione

Ai dirigenti i quality gate piacciono finché un gate non mette a rischio una scadenza. Un CIO ha scavalcato un gate non superato per rispettare un obiettivo trimestrale. I problemi che ne sono seguiti sono costati il doppio di quanto sarebbe costato il ritardo. Ho visto questo schema ripetersi molte volte, perciò oggi chiedo l'approvazione del vertice sul framework dei gate prima dell'avvio del progetto.

Evidenze dal sistema di riferimento

Le decisioni sui gate richiedono evidenze: report di esecuzione dei test, registri dei difetti, approvazioni dei processi, riconciliazioni della migrazione. Le prelevi dallo strumento, non da ciò che le persone dicono di aver fatto. Un mio cliente ha scoperto, dai report di Solution Manager, che il 40% dei casi di test «completati» non era mai stato eseguito. Se n'è accorto prima del gate, non dopo.

1. Associ i gate alle transizioni di fase. Per SAP Activate, almeno dopo Prepare, Explore, Realize e Deploy. Un cliente del settore energia ha creato checkpoint casuali nel mezzo e si è ritrovato nel caos.
2. Definisca i criteri di ingresso e di uscita prima che inizi la configurazione. Concordi copertura dei test, soglie dei difetti e i process owner che devono firmare. Li inserisca nel charter e ottenga la firma dello sponsor.
3. Pianifichi i gate con un margine. Metta ogni gate in calendario come attività, non solo come milestone. Un mio cliente del retail riservava una settimana intera prima di ogni gate solo per rimettere ordine.
4. Scelga revisori in grado di decidere. I responsabili di business approvano i processi. I responsabili tecnici approvano configurazione e integrazione. I consulenti non firmano mai al posto del business.
5. Tenga le evidenze in un unico posto. Sei mesi dopo, un auditor chiederà chi ha approvato la migrazione dei dati. La risposta dovrebbe richiedere pochi minuti.
6. Renda i risultati visibili. Un cliente ha appeso il dashboard dei gate alla parete della sala di progetto. Era impossibile ignorarlo.

Esempi di criteri di uscita per i due gate che contano di più

Gate Realize:

1. Esecuzione dei test pari o superiore alla soglia concordata, con i risultati archiviati nello strumento di test.
2. Nessun difetto di priorità 1 aperto; difetti di priorità 2 entro il limite di anzianità concordato.
3. Ogni processo critico approvato dal process owner nominato.
4. Test di integrazione eseguiti su catene di processo complete, con risultati documentati.
5. Ogni sviluppo custom approvato in base alle regole di clean core del programma.

Gate Deploy:

1. Prova generale della migrazione dei dati completata e riconciliazione firmata dal responsabile dei dati.
2. Completamento della formazione per ruolo pari o superiore alla soglia concordata.
3. Piano di cutover provato, con tempistiche e punti decisionali go/no-go.
4. Piano di rollback documentato e testato.
5. Team di hypercare nominato, con percorsi di escalation e definizioni di severità concordati.

Se il gate Deploy mostra eccezioni di riconciliazione non risolte o utenti non formati e il business vuole comunque procedere, ne faccia una decisione documentata, con un firmatario nominato. Non un esito per inerzia perché nessuno voleva dire no.

Due cose hanno cambiato il modo in cui progetto i gate nei programmi attuali.

Il clean core è ormai un criterio di gate. SAP classifica le estensioni dal livello A (solo interfacce rilasciate) al livello D (modifiche e scritture dirette sulle tabelle). Al gate Explore, ogni gap deve avere una decisione: configurarlo, svilupparlo come estensione basata su API rilasciate oppure respingerlo. Al gate Realize, verifichi che non si siano insinuati nuovi oggetti di livello D. La Public Edition lo impone a livello tecnico. La Private Edition e l'on-premise no, quindi a farlo rispettare è il gate.

SAP Cloud ALM è lo strumento di default. È incluso nelle sottoscrizioni cloud SAP con Enterprise Support, cloud edition, e in SAP Enterprise Support per i clienti on-premise (SAP Support). Copre fit-to-standard, assegnazione dei task, orchestrazione dei test e tracciabilità. La mainstream maintenance di SAP Solution Manager 7.2 termina a fine 2027 e SAP raccomanda di passare a Cloud ALM prima di quella data (SAP Support). Se è a metà programma su Solution Manager, chiuda lì. Pianifichi i nuovi programmi attorno a Cloud ALM.

Strumenti per gestire i gate

Lo strumento conta meno della disciplina. Un cliente del retail ha costruito su SharePoint un processo di gate pulito, che ha funzionato benissimo per un'implementazione di medie dimensioni. Ho visto anche gate fallire su una configurazione completa di Solution Manager, perché il team teneva fogli di calcolo paralleli.

Strumento	Ruolo nella gestione dei gate	Ideale per
SAP Cloud ALM	Fit-to-standard, task, test, tracciabilità	Nuovi programmi S/4HANA, cloud o on-premise
SAP Solution Manager 7.2	Monitoraggio del progetto, gestione di test e difetti	Programmi che lo usano già
Jira e Confluence	Task, difetti, criteri ed evidenze dei gate	Team che usano già gli strumenti Atlassian
Tricentis Tosca	Automazione dei test e reporting sulla copertura	Programmi con forte automazione dei test
ServiceNow	Workflow di approvazione e audit trail	Aziende che usano già ServiceNow

Qualunque strumento scelga, deve essere l'unica fonte di verità. Un foglio di calcolo parallelo mostra sempre la versione che il team vuole mostrare. Il mio confronto tra strumenti SAP per test e validazione approfondisce il lato dei test.

Saltati sotto la pressione delle scadenze. Quando i progetti slittano, i gate sono la prima cosa che viene tagliata. In un progetto le revisioni sono diventate timbri di approvazione e il go-live è stato un incubo: i sistemi sono andati in crash, gli ordini si sono bloccati e hanno dovuto fare un rollback completo. Le tre settimane «risparmiate» sono costate tre mesi di recupero.

Criteri vaghi. Ne ho già parlato. Se un criterio ha bisogno di interpretazione, è solo uno spunto per discutere.

Revisori senza tempo. Quando i revisori chiave sono divisi su più progetti, le revisioni si riducono a spuntare caselle. La revisione del gate Realize in un programma di medie dimensioni dovrebbe durare almeno mezza giornata, con le evidenze lette in anticipo.

Cultura. I team abituati a correre verso le milestone cercano il modo di aggirare i gate. Le cose cambiano quando un dirigente dice al kickoff che i gate sono obbligatori e poi lo dimostra, rifiutandosi di scavalcare il primo che provoca un ritardo.

Tre numeri che mostrano se i gate funzionano

Li monitori per capire se i gate stanno proteggendo il progetto o se ne hanno solo l'aspetto.

1. Defect leakage: la quota di difetti trovati dopo un gate che il gate avrebbe dovuto intercettare.
2. Tasso di superamento al primo tentativo: se ogni gate passa al primo colpo, probabilmente i criteri non hanno denti.
3. Incidenti al go-live: gli incidenti ad alta priorità nei primi 30 giorni sono un verdetto diretto sul gate Deploy.

I gate vanno nel charter fin dal primo giorno. La mia guida al project charter mostra dove inserirli, e la guida allo steering committee spiega chi dovrebbe avere l'autorità di farli rispettare.

Che cos'è un quality gate nei progetti SAP?

Un punto di controllo formale tra le fasi di progetto. Il team deve dimostrare che criteri specifici e misurabili sono soddisfatti prima di andare avanti. Ogni gate ha un owner nominato con l'autorità di rimandare il progetto. In SAP Activate i gate si collocano alle transizioni di fase, soprattutto dopo Explore, Realize e Deploy.

Quali sono i quality gate in SAP Activate?

SAP Activate ha sei fasi (Discover, Prepare, Explore, Realize, Deploy e Run) e ogni transizione è un gate. Discover verifica il business case. Prepare verifica la governance e il charter. Explore verifica l'approvazione del design e le decisioni sui gap. Realize verifica i risultati dei test e i difetti. Deploy verifica dati, formazione e prontezza del cutover. Run verifica la stabilizzazione e il passaggio di consegne.

Cosa dovrebbero includere i criteri dei quality gate SAP?

Criteri che danno una risposta sì o no. Per Realize: soglie di esecuzione dei test, difetti aperti per priorità, approvazioni dei process owner e risultati dei test di integrazione. Per Deploy: riconciliazione della migrazione, completamento della formazione per ruolo, un piano di cutover provato, un piano di rollback testato e un team di hypercare con le persone assegnate. Ogni criterio ha bisogno di un owner che produca le evidenze.

Perché i quality gate falliscono nelle implementazioni SAP?

Vengono saltati sotto la pressione delle scadenze, i criteri sono vaghi, i revisori non hanno il tempo di prepararsi oppure un dirigente scavalca un gate non superato. La causa di fondo è trattare i gate come un peso burocratico anziché come una protezione.

Quale strumento dovrei usare per gestire i quality gate SAP?

Per i nuovi programmi, SAP Cloud ALM. È incluso nelle sottoscrizioni cloud SAP e in Enterprise Support e supporta fit-to-standard, test e tracciabilità. SAP Solution Manager 7.2 esce dalla mainstream maintenance a fine 2027. Jira, Tricentis Tosca e ServiceNow funzionano bene dove l'azienda li usa già. La regola è una sola fonte di verità.

Come si valuta la prontezza al go-live al quality gate finale?

Verifichi cinque cose con le evidenze: migrazione dei dati provata e riconciliata, formazione completata per ogni ruolo, piano di cutover provato con punti go/no-go, piano di rollback testato e hypercare con il personale assegnato e percorsi di escalation. Se uno di questi punti non regge e il business vuole comunque procedere, lo registri come decisione di business firmata.