Come creare uno steering committee efficace per un progetto SAP

Uno steering committee di progetto SAP è il piccolo gruppo di dirigenti che prende le decisioni che il team di progetto non può prendere: budget, modifiche di perimetro, conflitti tra reparti e il go/no-go finale. Funziona quando i membri hanno un'autorità reale, si riuniscono abbastanza spesso da decidere in riunione e giudicano la prontezza sulle evidenze, non sul calendario. Questa guida è per sponsor e direttori di programma che stanno costituendo un comitato o stanno riparandone uno diventato un pubblico per i report di stato. Copre che cosa il comitato deve decidere, i membri per dimensione del progetto, come devono funzionare le decisioni, una checklist go/no-go e che cosa cambiano RISE with SAP e gli strumenti di AI.

Non ho mai visto un progetto SAP riuscire con uno steering committee debole. Il comitato è il luogo in cui si prendono le decisioni difficili. O si prendono in tempo reale, o si accumulano finché esplodono al cutover.

In un rollout SAP, il comitato si riuniva una volta al mese. Il team di progetto aveva segnalato workflow di approvazione che non funzionavano, test incompleti e formazione mancante. La leadership disse che lo avrebbe «esaminato». Non l'ha mai fatto. Il progetto è andato in produzione e la finanza ha passato i sei mesi successivi a ripulire.

In un'altra azienda, il comitato si riuniva ogni settimana e prendeva decisioni vere. Quando i test hanno rivelato delle lacune, ha riassegnato le risorse. Quando un processo non funzionava, lo ha corretto. Quel progetto è andato in produzione senza intoppi.

Un comitato guidava. L'altro stava seduto alle riunioni.

Se il comitato riceve solo report di stato, sta già fallendo. La tabella mostra la differenza nella pratica.

Funzione	Come appare quando funziona	Come appare quando è debole
Decisioni importanti	Esamina il caso e decide subito	«Ne parliamo offline»; il problema torna il mese dopo
Ostacoli	L'HR ritarda i test? Il presidente chiama direttamente il responsabile di reparto	Prende atto del problema e lo registra
Perimetro	Valuta ogni change request rispetto al piano	Timbra ciò che viene escalato con più insistenza
Rischio	Vede un fornitore in difficoltà e prepara un'alternativa prima che arrivino i ritardi	Aspetta di vedere se si risolve da solo
Budget	Approva 2 milioni di dollari in più per estendere di tre mesi perché l'interruzione costerebbe di più	Rimanda al mese successivo
Go/no-go	Rinvia il go-live di sei settimane perché i test non sono completi, e tiene il punto	Approva il go-live perché la data è sul calendario

L'ultima riga è la più importante. Ho visto comitati rinviare dei go-live anche quando i team volevano lanciarsi. Il comitato di un cliente farmaceutico ha rinviato il go-live di sei settimane perché i test non erano completi. Una scelta difficile, ma gli ha evitato un disastro.

Con troppi membri il comitato non riesce a decidere. Con troppo pochi mancano voci critiche.

Dimensione del progetto	Budget e perimetro	Membri	Chi deve esserci
Piccolo	Meno di 0,5 milioni di dollari, un reparto, meno di 6 mesi	Da 3 a 5	Responsabile di reparto, IT lead, rappresentante della finanza
Media impresa	Da 0,5 a 5 milioni di dollari, più reparti, da 6 a 18 mesi	Da 5 a 8	Responsabili di business dei reparti coinvolti, vertici IT, finanza
Grande impresa	Oltre 5 milioni di dollari, a livello aziendale, 18 mesi o più	Da 8 a 12	C-level di finanza, HR, operations e IT; programme manager; change lead

La regola che applico: includere persone con una reale autorità decisionale. Ho visto comitati fallire perché titoli di alto livello non potevano approvare nulla senza consultare qualcun altro. Se il CFO non può partecipare, mandi qualcuno con un mandato vero a decidere, non a riferire.

Il presidente dovrebbe essere lo sponsor del progetto, di solito un dirigente C-level in grado di chiamare a rispondere gli altri dirigenti. Un middle manager alla presidenza non può sovrastare un CFO, e quell'autorità conta quando emergono conflitti di perimetro o di budget.

Sulle evidenze. Ho lavorato con un cliente manifatturiero il cui team IT sosteneva che una modifica di processo avrebbe aggiunto tre mesi. Il business insisteva che fosse «semplice». Il comitato si è rifiutato di decidere finché non ha visto stime di effort, analisi delle dipendenze e pianificazione della capacità. L'IT aveva ragione. Il comitato ha deciso bene perché ha preteso evidenze invece di schierarsi con la voce più forte.

In fretta. Ho visto un cliente il cui comitato si riuniva ogni due settimane ma chiudeva sempre con «ne discutiamo offline». I problemi si sono accumulati finché il progetto aveva sei mesi di ritardo. Il comitato di un altro cliente prendeva decisioni in riunione e il suo progetto è finito in anticipo e sotto budget. I comitati lenti producono progetti in ritardo.

Con autorità esplicita. I comitati efficaci possono sovrastare i responsabili di reparto, approvare budget non pianificato e respingere aggiunte di perimetro a lavori in corso. Se questi poteri non sono scritti e compresi, il comitato diventa consultivo, e i comitati consultivi non portano a termine i progetti SAP.

Sul perimetro, in modo selettivo. Presso uno dei miei clienti, un reparto ha chiesto all'improvviso 20 report in più. Il comitato ha chiesto se ciascuno servisse subito e se avrebbe compromesso la timeline. Ne ha approvati cinque critici e ha rimandato il resto a dopo il go-live. Quella decisione ha probabilmente salvato la data di go-live.

Tenga le riunioni tra 60 e 90 minuti. I rischi principali, le decisioni specifiche richieste e le azioni con responsabili e date. Niente aggiornamenti tecnici che si possono leggere prima. Se lo stesso tema compare per tre riunioni di fila senza risoluzione, ha un problema di governance, non di complessità.

Usi i dati, non le presentazioni. Ho lavorato con un cliente del settore energia che aveva costruito una dashboard con esecuzione dei test, risoluzione dei difetti, completamento della formazione e consumo del budget. Le riunioni hanno smesso di servire a capire a che punto si fosse e sono diventate riunioni per risolvere problemi.

Faccia vedere il sistema al comitato. Il comitato di un cliente farmaceutico ha svolto uno scenario «una giornata tipo». Si è accorto che il disegno approvato avrebbe costretto il personale a usare cinque schermate diverse per un processo comune. Ha ordinato subito una riprogettazione.

Metta in conto la politica. Il fallimento più comune non è l'incompetenza. Sono i reparti che difendono il proprio territorio e i team che rimandano i test per il lavoro di fine anno. In un progetto, l'HR continuava a rimandare i test sulle paghe perché era occupata con le attività di fine anno. Il comitato ha riprioritizzato il lavoro e assegnato tester di riserva, e il progetto è rimasto in linea invece di scivolare per mesi.

Usi verifiche indipendenti ai gate principali. Un cliente manifatturiero ha fatto valutare la propria prontezza da revisori esterni prima di approvare il go-live. La revisione ha trovato diversi problemi gravi che il team di progetto aveva trascurato o minimizzato. La mia guida ai quality gate SAP mostra come strutturare quei checkpoint.

La pressione del calendario è la base sbagliata per approvare un go-live. Prima del voto, il comitato dovrebbe vedere le evidenze su ciascuno di questi punti:

1. Test di integrazione e di accettazione utente completati, senza difetti critici aperti
2. Ultima migrazione dati di prova riconciliata e firmata dalla finanza
3. Prova del cutover completata entro la finestra pianificata
4. Key user formati, con supporto sul campo e job aid pronti
5. Prontezza del business confermata per iscritto da ciascun process owner
6. Piano di rollback testato e concordato
7. Team di hypercare, percorso di escalation e supporto al primo closing in atto

Se anche una sola voce è rossa, un comitato forte dice no. Un ritardo di sei settimane si recupera. Un go-live fallito che interrompe le operazioni o la chiusura finanziaria può richiedere mesi per stabilizzarsi. Ho ripulito troppi go-live approvati perché la data sembrava immovibile. Alimenti l'agenda del comitato con un registro dei rischi vivo, così questi punti emergono per tempo.

RISE porta SAP dentro il modello di governance. Su RISE with SAP, SAP gestisce l'infrastruttura e le operazioni tecniche. Il documento di SAP su ruoli e responsabilità di RISE prevede che i clienti lavorino con un SAP Cloud Architect Advisor, un Client Delivery Manager o il centro clienti del private cloud di SAP. Per i problemi di piattaforma, come prestazioni, disponibilità o livelli di servizio, il comitato ha bisogno di un canale verso questi referenti che non passi dal partner di implementazione. Li inviti per i punti all'ordine del giorno che li riguardano, non come membri permanenti.

Un forum sul clean core va sotto il comitato. Nei programmi RISE, istituisca una design authority che approva o respinge le richieste di personalizzazione sulla base dei principi di clean core. Escala al comitato solo quando una richiesta critica per il business viene bloccata. Senza questo livello, ogni personalizzazione diventa uno scontro in comitato. On-premise vale ancora il modello tradizionale e SAP è un fornitore, non un partecipante.

1. Steering committeePresieduto dallo sponsor. Budget, perimetro, conflitti, go/no-go
   Referenti di delivery SAPInvitati per i temi di piattaforma, senza passare dal partner

• Programme management officeEsecuzione quotidiana, registro dei rischi, coordinamento
• Design authority sul clean coreDecide sulle personalizzazioni, escala solo le richieste critiche bloccate

L'AI fa risparmiare tempo sulla documentazione. Microsoft 365 Copilot redige i verbali dalla riunione registrata. Il lavoro diventa rivedere una bozza invece di scrivere da zero, e le decisioni arrivano dalla trascrizione. Rovo di Atlassian può trasformare gli appunti delle riunioni in voci strutturate del registro delle decisioni, una volta costruito il template. Gli assistenti basati su Joule in SAP Cloud ALM possono redigere una prima valutazione d'impatto per una richiesta di perimetro, così il comitato può decidere in riunione invece di rimandare.

Per ora lasci perdere la sentiment analysis. Alcuni fornitori propongono l'analisi del sentiment delle comunicazioni di programma come input per il comitato. Nella maggior parte dei programmi è scena: il segnale è debole, i falsi positivi sono frequenti e farsi vedere a monitorare il sentiment ha un costo politico. Solo nei programmi molto grandi può segnalare per tempo gruppi che si stanno disimpegnando. Per la maggior parte dei comitati non è dove spendere il budget AI.

Qual è il ruolo di uno steering committee in un progetto SAP?

Prende le decisioni che il team di progetto non può prendere: approvazioni di budget, modifiche di perimetro, escalation delle risorse e il go/no-go finale. Risolve i conflitti tra reparti e chiede ai responsabili di reparto di rispettare gli impegni su test e formazione. Se riceve solo aggiornamenti di stato, non fa il proprio lavoro. Il valore sta nelle decisioni prese, non nelle riunioni a cui si partecipa.

Quante persone devono far parte di uno steering committee SAP?

Da tre a cinque per un progetto piccolo di un solo reparto; da cinque a otto per la media impresa; da otto a dodici per un programma enterprise. Il fallimento più comune è avere troppe persone: un comitato di 20 diventa un pubblico per le presentazioni. Ogni membro deve avere una reale autorità decisionale su qualcosa. Su RISE, si coinvolgano i referenti di delivery di SAP per i temi di piattaforma e non come membri permanenti.

Come cambia lo steering committee con RISE with SAP?

SAP diventa un partecipante alla delivery per infrastruttura e operazioni tecniche, quindi il comitato ha bisogno di un canale diretto con i referenti assegnati da SAP, che non passi dal partner di implementazione. Serve anche una design authority sul clean core sotto di esso, per gestire le richieste di personalizzazione, con escalation solo delle richieste critiche per il business che vengono bloccate. On-premise, SAP resta un fornitore.

Che differenza c'è tra uno steering committee e un PMO?

Il project management office gestisce l'esecuzione quotidiana: attività, registri dei rischi e coordinamento tra i workstream. Lo steering committee prende le decisioni che il PMO non può prendere: spostamenti di budget, modifiche di perimetro e go/no-go. Nelle organizzazioni più grandi, un comitato a livello di portafoglio sta sopra più progetti e alloca le risorse tra di essi.

Che cosa deve esserci nell'agenda di uno steering committee?

Decisioni, non aggiornamenti. Si parta dai tre-cinque rischi principali, poi dalle decisioni specifiche che richiedono approvazione, poi dai problemi tra reparti da risolvere, poi dalle azioni dell'ultima riunione con responsabili e date. Se un punto compare tre volte senza risoluzione, si metta in discussione il modo in cui viene gestito, invece di discuterlo di nuovo.

Quando lo steering committee dovrebbe rinviare il go-live?

Quando i test non sono completi, i key user non sono formati, la migrazione dei dati non è riconciliata, un'integrazione critica è instabile o il piano di rollback non è stato testato. Un rinvio costa quasi sempre meno della pulizia dopo il go-live. Un ritardo di sei settimane si recupera; un go-live fallito che interrompe la supply chain o la chiusura finanziaria può richiedere mesi per stabilizzarsi.