Gestione degli stakeholder in SAP: fermare i conflitti prima che inizino

La gestione degli stakeholder in SAP decide se un programma finisce in tempo o passa l'ultimo trimestre a litigare. Si riduce a quattro abitudini. Mappare chi conta e che cosa sta a cuore a ciascun gruppo. Mettere per iscritto chi ha l'autorità di decidere che cosa. Tenere una cadenza di comunicazione in linea con la fase di SAP Activate. Registrare ogni decisione importante insieme alle alternative. Questa guida è per direttori di programma, PMO e executive sponsor di programmi S/4HANA. Usi la tabella dei ruoli e la cadenza fase per fase qui sotto per costruire il piano di coinvolgimento prima del primo workshop.

Una volta ho lavorato a un rollout SAP in cui l'IT voleva controlli di sistema rigidi e la Finance aveva bisogno di più flessibilità. Quando siamo arrivati noi, i due team avevano smesso di parlarsi. La Finance era frustrata. L'IT era sulla difensiva. La direzione voleva sapere perché nessuno comunicasse.

Abbiamo costruito una mappa dei ruoli, organizzato incontri di allineamento regolari e creato un'unica fonte di verità per le decisioni. Se questo lavoro di base fosse stato fatto all'inizio, avremmo risparmiato mesi di discussioni.

Lo schema vale ben oltre quel programma. La tecnologia raramente fallisce da sola. I programmi falliscono quando le decisioni non vengono prese e le aspettative non sono mai state fissate. Falliscono quando la comunicazione dipende dai rapporti personali invece che da una cadenza, e quando i conflitti che dovevano restare a livello operativo arrivano alla direzione con settimane di ritardo.

Non tutti in un programma SAP hanno le stesse preoccupazioni o la stessa influenza. Se li si tratta come un unico pubblico, si inviano aggiornamenti irrilevanti e si perdono i rischi reali.

Ruolo	Che cosa gli sta a cuore	Come coinvolgerli
Executive sponsor (CEO, COO, group CFO)	Ritorno, rischio di business, credibilità del programma	Diretto, regolare, breve
Steering committee (CIO, CFO, responsabili delle business unit)	Tempi, budget, perimetro	Revisioni strutturate dello steering, con decisioni
Vertici della Finance (CFO, controller)	Riconoscimento dei ricavi, integrità del reporting, controlli	Coinvolgimento precoce nella progettazione; approvazione del perimetro FI/CO
Responsabili di operations e di business	Continuità dei processi, formazione, usabilità	Workshop di progettazione; responsabilità dei test di accettazione utente (UAT)
Vertici IT (CIO, responsabile dell'architettura)	Architettura, sicurezza, integrazione, supporto	Approvazione della progettazione tecnica
Process owner	Accuratezza dei processi, eccezioni, casi limite	Guidano i workshop di progettazione; approvano la configurazione
Utenti finali	Curva di apprendimento, lavoro quotidiano, cambi di mansione	Formazione e change management
System integrator (SI)	Perimetro di delivery, richieste di modifica, risorse	Governance formale e documenti di perimetro
HR e change management	Impatto sulle persone, cambi di ruolo, comunicazione	Un workstream parallelo alla delivery

La matrice potere-interesse indica dove concentrare gli sforzi. CIO, CFO e sponsor stanno in alto su entrambi gli assi: approvano le modifiche, rinviano il go-live e assegnano le persone, e se si disimpegnano il programma perde la sua copertura. I process owner, i controller e gli architetti hanno un interesse elevato e meno potere formale, ma la loro conoscenza di come funziona davvero il business li rende essenziali nella progettazione. I membri del consiglio di amministrazione e i dirigenti esterni al programma hanno bisogno di briefing sulle milestone, non di aggiornamenti settimanali. Gli utenti finali hanno poca influenza e la massima esposizione: la loro adesione al go-live decide se il sistema funziona nella pratica.

Influenza sul risultatoAltoMedioBasso

• Consiglio di amministrazione, dirigenti esterni

• Sponsor, CFO, CIO

• Process owner
• Controller, architetti

• Utenti finali

BassoMedioAltoQuanto il programma li riguarda

Il coinvolgimento più efficace avviene prima che qualcuno abbia un reclamo. Al kick-off si fissano tre cose.

Poteri decisionali

Chi può approvare una modifica di perimetro? Chi firma l'UAT? Chi può portare uno slittamento del go-live allo steering committee? Lo si scrive, lo si fa firmare e lo si inserisce nel project charter. Quando una decisione viene contestata a metà progetto, è a quel documento che si fa riferimento.

Senza di esso, le decisioni contestate vanno a chi urla più forte o ha l'orecchio dello sponsor. Nessuna delle due è governance, ed entrambe generano risentimento. La mia guida alla redazione di un project charter SAP spiega che cosa deve contenere la sezione sui poteri decisionali.

Cadenza di comunicazione

Al kick-off si decide con quale frequenza il programma comunica, attraverso quale canale e con quali contenuti. Steering ogni due settimane. Responsabili dei workstream ogni settimana. Utenti finali alle milestone, con richiami alla formazione. Se le persone sentono il programma solo quando qualcosa non va, penseranno che sia sempre in difficoltà.

Baseline del perimetro

Si scrive che cosa è nel perimetro e che cosa ne è esplicitamente fuori. Le esclusioni contano quanto le inclusioni, perché ogni confine non definito è un conflitto futuro. Si pensi a un responsabile finance che dà per scontato che la gestione delle note spese sia nel perimetro e scopre in Realize che non lo è. Quella persona sarà difficile per il resto del programma, non perché lo sia per natura, ma perché il programma ha infranto una promessa implicita.

Le esigenze di coinvolgimento cambiano man mano che il programma attraversa le fasi di SAP Activate. Ciò che funziona in Explore non funziona in Deploy. Lo si usi come ossatura del piano di coinvolgimento:

Fase	Focus del coinvolgimento	Cadenza	Chi guida
Discover e Prepare	Mappa dei ruoli, struttura di governance, briefing per lo sponsor, prime sessioni di allineamento con Finance, Operations e IT	Briefing allo sponsor all'avvio; steering costituito	Direttore del programma
Explore	Workshop di fit-to-standard con responsabili di business e process owner; decisioni di fit-gap riviste prima dell'approvazione	Sessioni di lavoro settimanali; steering alla chiusura della fase	Solution architect e process owner
Realize	Preparazione dell'UAT; tutela del tempo dei responsabili di business per i test; stato di difetti e migrazione dei dati	Steering ogni due settimane; responsabili dei workstream ogni settimana	Responsabile del programma
Deploy	Prontezza al cutover, criteri di go/no-go concordati prima dell'inizio del cutover	Stand-up giornalieri sul cutover; briefing esecutivo sul go/no-go	Responsabile delle operations di business, con il supporto di IT e SI
Run	Comunicazione in hypercare, canali per le segnalazioni, revisioni di stabilizzazione	Ogni giorno per due settimane, poi ogni settimana; revisioni a 30, 60 e 90 giorni	Responsabile del supporto e process owner

Due fasi causano la maggior parte dei problemi. In Explore, se in sala non ci sono le persone giuste, le decisioni vengono riaperte in Realize, a configurazione già avviata. In Realize, i responsabili dell'UAT non disponibili o non preparati sono uno schema frequente. Lo si risolve nel piano durante Explore, non due settimane prima dell'inizio dei test.

Il modello tradizionale prevedeva tre parti: il cliente, il SI e gli sponsor. Con RISE with SAP, SAP entra come partecipante alla delivery. Gestisce l'infrastruttura e le operazioni tecniche, e il suo team di customer success monitora adozione e valore. Ne derivano tre cambiamenti di governance.

1. Un forum di revisione delle estensioni. Ogni gap richiede una decisione: configurarlo, estenderlo tramite API rilasciate (on-stack con ABAP Cloud o side-by-side su SAP BTP) o respingerlo. In S/4HANA Cloud Public Edition la modifica del core non è possibile. In Private Edition lo è, ma ogni modifica aggiunge lavoro negli upgrade. Un piccolo forum sotto lo steering, con un architetto autorizzato a decidere, evita che ogni discussione sulle personalizzazioni finisca allo steering. Senza di esso, il debito tecnico emerge al primo upgrade importante.
2. Una cadenza di customer success con SAP. Il team di SAP interviene su adozione, uso di BTP e roadmap. Procede in parallelo con la governance dell'implementazione e continua dopo il go-live. La si integri nella governance invece di gestirla a parte.
3. Un percorso di escalation verso SAP. Quando qualcosa si guasta a livello di piattaforma, il CIO deve sapere chi chiamare in SAP, non solo presso il partner. Si confermino i contatti e i livelli di servizio prima di firmare.

I programmi GROW with SAP su Public Edition richiedono gli stessi tre elementi in versione più leggera: meno decisioni sulle estensioni perché c'è meno spazio per estendere, una cadenza di customer success più standardizzata e un'escalation che di solito passa prima dal partner. I programmi on-premise mantengono il modello tradizionale, con SAP come fornitore anziché come partecipante.

Gli strumenti di AI aiutano con le pratiche burocratiche del coinvolgimento, non con le relazioni.

I riepiloghi delle riunioni sono il vantaggio più chiaro. Microsoft Copilot trasforma una riunione dello steering registrata in una bozza di verbale che richiede una breve revisione invece di una lunga stesura. Le decisioni che cattura sono di solito corrette, perché lavora sulla trascrizione e non sulla memoria.

I registri delle decisioni vengono secondi. Le funzioni di AI di Confluence, ora sotto il marchio Rovo di Atlassian, possono trasformare gli appunti delle riunioni in voci strutturate del registro delle decisioni, una volta costruito un modello.

La stesura dei requisiti aiuta in Explore. SAP Cloud ALM può redigere requisiti a partire dalle trascrizioni dei workshop di fit-to-standard. Serve comunque una persona che convalidi ogni riga.

L'analisi del sentiment è per lo più teatro nei programmi con meno di 100 persone. Il segnale è debole, i falsi positivi sono frequenti e farsi vedere mentre si monitora il sentiment ha un costo politico reale. Nei programmi molto grandi può individuare per tempo i gruppi che si disimpegnano. Per la maggior parte dei programmi, conviene spendere altrove il budget per l'AI.

La resistenza a SAP ha quasi sempre una base razionale. Chi si oppone di solito sta proteggendo qualcosa: un workaround che copre una lacuna del vecchio sistema, un controllo manuale che il processo standard non mostra, o la preoccupazione per la capacità del proprio team di assorbire il cambiamento. Prima di reagire si trovi quella base. Si affronti la preoccupazione di fondo e di solito la resistenza svanisce senza uno scontro.

«Ci serve questa personalizzazione»

Di solito difende un processo che oggi funziona e che la persona non crede che lo SAP standard sia in grado di gestire. Si ripercorre il processo standard chiedendo esattamente dove fallisce. Spesso la preoccupazione riguarda un caso limite che la configurazione può gestire. A volte è legittima. Lo si scopre solo avendo la conversazione, e con il clean core la posta in gioco è più alta, perché la risposta decide se si costruisce e si mantiene un'estensione.

«Non siamo pronti per il go-live»

Lo si prenda sul serio. Quando un responsabile di business dice di non essere pronto, di solito ha un motivo: qualità dei dati, formazione incompleta, un processo non testato. Si individui la preoccupazione specifica. Se è fondata, deve far slittare il go-live. Se è ansia e non evidenza, la si affronti con una preparazione mirata, non con una nuova data.

La versione più comune: l'UAT ha fatto emergere problemi che non sono stati risolti. Andare avanti sposta il problema dall'UAT alla produzione. Uno slittamento di due settimane costa di solito molto meno di un periodo di hypercare passato su problemi noti prima del go-live.

«Nessuno ci ha detto di questa modifica»

Questo è un fallimento di comunicazione. La persona era nella lista di distribuzione ma non nella sessione di progettazione, oppure la modifica stava in un documento che non ha mai letto. Non si discuta su chi abbia comunicato che cosa. Ci si scusi, si ripercorra la modifica insieme alla persona, la si aggiunga alle future revisioni di progettazione nella sua area e si corregga la lacuna nel piano di coinvolgimento.

Quando un conflitto supera il livello operativo, contano tre cose.

Tenerlo dentro la governance. Una disputa tra Finance e IT sugli accessi al sistema appartiene allo steering, non va risolta informalmente da chi è più insistente. La risoluzione informale dei conflitti strutturali genera risentimento e decisioni riaperte.

Inquadrarlo in termini di business. Finance e IT che litigano sul controllo degli accessi è politica. Finance e IT che presentano il rischio di sicurezza a fronte del costo operativo è una decisione di business, e lo steering può prenderla. Tradurre l'una nell'altra è compito del responsabile del programma, o del responsabile del SI, a seconda del contratto.

Registrare ogni decisione importante. Che cosa è stato deciso, da chi, quando e quali alternative sono state valutate. Tra sei mesi qualcuno dirà «non avevamo mai concordato questo». Quando lo steering chiede perché è stata scelta una configurazione, o un nuovo arrivato mette in dubbio una decisione passata, serve il registro, non una ricostruzione a memoria. Un registro delle decisioni condiviso, aggiornato ogni settimana e rivisto allo steering, costa quasi nulla e fa risparmiare moltissimo.

Se la casella di posta del responsabile del programma è piena di escalation urgenti, il piano non funziona. I programmi sani si reggono su decisioni strutturate, non su emergenze quotidiane.

Segnali positivi: le riunioni dello steering producono decisioni anziché rinvii; i responsabili di business partecipano ai workshop e all'UAT senza doverli rincorrere; le modifiche di perimetro arrivano attraverso il processo di change; i problemi post go-live passano da canali definiti; il registro delle decisioni è aggiornato e citato allo steering.

Segnali di allarme: le persone contattano il responsabile del programma fuori dalla struttura di governance; i responsabili di business approvano i deliverable senza leggerli e poi li contestano; lo sponsor sparisce tra una riunione dello steering e l'altra; chi ha saltato la progettazione contesta il change freeze; lo stesso conflitto compare in tre riunioni dello steering di fila.

Quando compaiono segnali di allarme, non si spinga più forte sul piano esistente. Si individui quale elemento sta cedendo (cadenza, autorità, comunicazione o documentazione) e si corregga quello. Più email e più riunioni peggiorano la situazione. Per lo steering committee in sé, vedere la mia guida alla creazione di uno steering committee SAP efficace e, per il lato umano del go-live, i miei appunti sul change management in SAP.

Che cos'è la gestione degli stakeholder in un'implementazione SAP?

È il lavoro strutturato di individuare chi ha influenza o interesse nel programma, comprenderne le preoccupazioni, impostare comunicazione e processo decisionale e mantenerli coinvolti dal kick-off all'hypercare.

SAP tocca contemporaneamente Finance, HR, Procurement, Operations e IT, e ciascuno ha priorità e influenza diverse. Gestirli come un unico pubblico produce aggiornamenti generici e non coglie le preoccupazioni che alimentano la resistenza. SAP Activate integra questo aspetto in ogni fase: i workshop in Explore, la responsabilità dell'UAT in Realize e le revisioni di prontezza in Deploy dipendono tutti da partecipanti di business preparati.

Come si costruisce una mappa dei ruoli per un progetto SAP?

Si colloca ogni persona o gruppo su due assi: influenza sul risultato e quanto il programma li riguarda. Sponsor, CFO e CIO sono alti su entrambi e richiedono un contatto diretto e regolare. Controller, process owner e architetti hanno un interesse elevato e devono essere coinvolti nella progettazione. I dirigenti esterni al programma hanno bisogno di briefing sulle milestone. Gli utenti finali hanno bisogno di una comunicazione mirata su che cosa cambia per loro, quando si svolge la formazione e dove trovare aiuto.

Si tenga la mappa aggiornata. Le persone cambiano ruolo, l'influenza si sposta man mano che il programma diventa visibile e nuovi partecipanti entrano con l'ampliarsi del perimetro.

Che cosa deve contenere un piano di coinvolgimento SAP?

Un registro dei ruoli (nome, funzione, influenza, interesse, principali preoccupazioni), un piano di comunicazione (canale, frequenza e contenuto per gruppo), i poteri decisionali per le modifiche di perimetro, le decisioni di progettazione e la prontezza al go-live, le attività per ogni fase di Activate, un percorso di escalation per le decisioni contestate e un modo per sollevare formalmente le preoccupazioni.

Lo si aggiorni a ogni passaggio di fase. Lo si documenti abbastanza bene da permettere al team di gestirlo senza che il responsabile del programma segua personalmente ogni interazione, perché questo non regge oltre trenta partecipanti nominati.

Come si gestisce la resistenza a SAP da parte dei responsabili di business?

Prima si cerca la fonte. Le più comuni sono la preoccupazione che il nuovo processo trascuri un caso limite importante, il timore di perdere produttività e la sensazione di essere esclusi dalle decisioni. Le preoccupazioni sui processi vanno in una sessione di progettazione. I timori sulla produttività richiedono formazione realistica e un supporto chiaro in hypercare. L'esclusione è un fallimento di comunicazione da correggere, non da discutere.

La resistenza senza base razionale è più difficile. La leva di solito è lo sponsor, che deve chiarire che il programma ha l'impegno della direzione. Andare avanti senza affrontare la resistenza è l'opzione peggiore: le preoccupazioni ricompaiono nell'UAT.

Come si gestiscono i conflitti tra Finance e IT in un programma SAP?

La maggior parte si riduce a una di tre tensioni: accesso contro segregazione dei compiti, flessibilità di reporting contro data governance, ritmo di integrazione contro revisione di sicurezza.

Si nomini la tensione con precisione. «La Finance vuole che i controller abbiano accesso in lettura agli ordini di produzione per il reporting, e l'IT ritiene che questo violi la segregazione dei compiti» si può risolvere; «la Finance vuole flessibilità» no. Lo si porta allo steering con le opzioni e i relativi rischi. Poi si registrano la decisione e le alternative, perché queste dispute tornano quando le persone cambiano. Se lo steering non riesce a risolverla, passa allo sponsor. È la governance che funziona come previsto.

Come cambia la gestione degli stakeholder con RISE with SAP?

SAP diventa un partecipante e non più soltanto un fornitore. Servono un forum di revisione delle estensioni che decida come gestire ogni gap in ottica clean core, un posto nella governance per la cadenza di customer success di SAP e un percorso di escalation documentato verso SAP per i problemi di piattaforma, che non dipenda dal partner. Si confermino i contatti di escalation e i livelli di servizio prima della firma.