Piano di change management: risolvere la resistenza prima che inizi

Un piano di change management per un programma ERP stabilisce come le persone passeranno dal modo in cui lavorano oggi a quello che il nuovo sistema richiede, e chi è responsabile di accompagnarle. Parte alla mobilitazione, non alla formazione. Ha sette parti, ciascuna con un responsabile indicato per nome, ed è collegato al project charter, ai workshop di progettazione e ai quality gate invece di essere gestito come un filone a parte.

La maggior parte delle resistenze non nasce dal nulla. Si accumula lentamente, molto prima del kickoff. Si sente nei commenti di traverso delle prime riunioni. Si nota quando i referenti di business chiave diventano silenziosi. Quando viene redatto un piano di cambiamento formale, gran parte del danno è già fatto.

Di solito comincia in pochi punti prevedibili:

1. I key user esclusi dalle prime fasi di progettazione.
2. I responsabili di reparto sorpresi da impatti di cui nessuno aveva parlato con loro.
3. Una comunicazione vaga che invita a rimettere tutto in discussione.
4. Progetti falliti in passato che hanno lasciato una sfiducia silenziosa.

Sono problemi strutturali, non solo problemi di comunicazione. Se lo steering committee è passivo, ci saranno attriti. Se il project charter non dice nulla sull'adozione, ha già perso una leva.

1. 01MobilitazioneMappare l'influenza e raccogliere la storia informale
2. 02ProgettazioneConcordare i KPI di adozione, i power user come coautori
3. 03TestGli utenti di business testano i propri processi
4. 04FormazionePer ruolo, su dati reali, in orari in cui le persone possono partecipare
5. 05Gate di go-liveSoglie di adozione, non solo approvazione funzionale
6. 06Primi 90 giorniMonitorare accessi, errori, ticket e workaround

Workaround intercettati prima che diventino abitudini

Un piano di cambiamento non è un calendario delle comunicazioni. Questi sono i sette componenti e chi dovrebbe occuparsi di ciascuno.

Componente	Scopo	Responsabile
Mappatura dei ruoli e dell'influenza	Tutte le persone coinvolte, con la loro influenza e non solo il loro titolo	Change lead
Valutazione dell'impatto del cambiamento	Come cambiano ruoli, processi e strumenti di ciascun gruppo	Process owner con il team di change
Piano di comunicazione	Destinatari, messaggi, canali e tempistiche, con cicli di feedback	Responsabile della comunicazione
Formazione e abilitazione	Percorso formativo per ruolo, pratica, verifiche di preparazione	Training manager
Coinvolgimento della leadership	Leader allineati, informati e visibilmente a sostegno del cambiamento	Executive sponsor con il change lead
KPI di adozione	Misure comportamentali concordate in fase di progettazione e monitorate oltre il go-live	Change lead
Monitoraggio della resistenza	Segnali di allerta precoci associati ai team	Tutti i responsabili dei workstream

Nella maggior parte dei piani di cambiamento, comunicazione significa newsletter, e-mail e town hall. Non è questo che muove le persone.

Ricordo un rollout in cui abbiamo comunicato tutto in tempo, ma nessuno sapeva spiegare perché il processo stesse cambiando. Avevamo volume, ma nessuna chiarezza.

Adattare il messaggio al pubblico. I senior manager vogliono prima di tutto l'impatto sul business. Gli utenti finali hanno bisogno di sentirlo dal proprio responsabile, non da un responsabile di programma che non hanno mai incontrato. I responsabili funzionali rispondono meglio quando hanno in mano una parte del messaggio.

Prevedere il feedback. Una comunicazione solo in uscita è metà di un piano. Ho lavorato con un team in cui le call settimanali di Q&A hanno avuto più effetto di qualsiasi e-mail. Colleghi ciò che sente al registro dei rischi, così i punti deboli emergono prima di venire a galla in pubblico.

Scegliere il momento giusto. Troppo presto crea confusione. Troppo tardi sembra una forzatura. In un rollout gli utenti pensavano che il loro lavoro stesse per essere sostituito. Nessuno lo aveva detto. Ma il silenzio ha riempito i vuoti. Affronti la paura in modo diretto e presto, prima che lo faccia qualcun altro al Suo posto.

Non riutilizzi la mappa delle persone dell'ultimo progetto. L'influenza cambia da un programma all'altro. Costruisca la mappa da zero e la aggiorni ogni mese.

Per ogni persona tenga traccia di tre cose: quanto il cambiamento la riguarda, dove si colloca oggi (favorevole, neutrale o resistente) e quanta influenza ha sugli altri. Un middle manager resistente con un team che lo segue conta più di un singolo utente resistente.

Raccolga anche la storia informale. I progetti falliti in passato plasmano i comportamenti in modi che i documenti di lessons learned non registrano mai. Poche ore passate ad ascoltare ciò che le persone ricordano Le dicono con che cosa ha davvero a che fare. La mia guida alla gestione degli stakeholder tratta la mappatura in modo più dettagliato.

La formazione è una parte del change management, non il suo insieme. Il fallimento tipico è una formazione che arriva troppo tardi, nel formato sbagliato, e si ferma prima che le persone siano sicure. Un corso di un giorno due settimane prima del go-live non è preparazione.

Che cosa funziona:

1. Contenuti per ruolo. Insegni a ogni gruppo ciò che serve per il proprio lavoro, non una visita guidata del sistema.
2. Pratica su dati reali. Usi i dati e le transazioni dell'azienda, non scenari dimostrativi.
3. Power user come formatori. Le persone imparano meglio da colleghi di cui si fidano. Tratti i power user come coautori della progettazione, non solo come tester.
4. Formazione al momento giusto. Un team finanziario con cui ho lavorato saltava le sessioni perché erano fissate in orari sbagliati. Spostarle ha risolto il problema.
5. Supporto dopo il go-live. La fiducia cala dopo il go-live, non prima. Affidi l'hypercare a persone che sappiano rispondere in fretta a domande reali.

Anche lo user acceptance testing (UAT) fa parte dell'adozione. Ricordo una sessione di UAT in cui un piccolo errore nella logica dei prezzi avrebbe causato una fatturazione errata. Lo ha individuato un team lead. Nessun altro se n'era accorto. Quella singola scoperta ha fatto risparmiare settimane di pulizia, ed è avvenuta perché un utente di business sentiva il sistema in parte come suo.

Inserisca le soglie di adozione nei quality gate. «Il sistema funziona» è un'approvazione funzionale. «Gli utenti sono pronti a lavorarci» è un'altra cosa, e la maggior parte dei programmi chiede solo la prima. La mia guida alle strategie di formazione SAP approfondisce il piano di formazione.

KPI di adozione da concordare prima del go-live

Li definisca durante la progettazione, così esiste una baseline di riferimento:

1. Tassi di accesso per gruppo di utenti nei primi 90 giorni.
2. Tassi di errore nelle transazioni chiave rispetto alla baseline del sistema legacy.
3. Ticket di supporto per volume e categoria.
4. Frequenza dei workaround: esportazioni in fogli di calcolo, registrazioni parallele, approvazioni manuali fuori dal sistema.
5. Fiducia dichiarata dai manager, rilevata con brevi pulse survey.

La finestra è stretta. Ho visto utenti tornare in silenzio ai fogli di calcolo nel giro di poche settimane, non perché il sistema fosse guasto ma perché nessuno li aveva aiutati ad affrontare il cambiamento. Pochi mesi dopo il go-live, i workaround diventano abitudini.

Strumenti di digital adoption

SAP ha completato l'acquisizione di WalkMe a settembre 2024, per un equity value di circa 1,5 miliardi di dollari. All'epoca SAP ha dichiarato che le capacità di AI di WalkMe avrebbero aggiunto a Joule un supporto sensibile al contesto nei vari flussi di lavoro. Significa che oggi SAP possiede due strumenti di adozione con punti di forza diversi:

• SAP Enable Now è adatto ai contenuti formativi strutturati: si registra un processo una sola volta e se ne ricavano documentazione, simulazioni e script di test.
• WalkMe è adatto alla guida dentro l'applicazione nel momento d'uso e può coprire applicazioni SAP e non SAP.

Li valuti insieme. Whatfix è la principale alternativa indipendente se vuole strumenti di adozione non legati a SAP. Nessuno di questi strumenti sostituisce un manager che spiega perché il cambiamento è importante.

Anche con una buona preparazione compaiono nuovi attriti. Controllarli in modo eccessivo di solito si ritorce contro. L'obiettivo è vederli presto.

I segnali d'allarme sono workshop saltati, silenzio nelle riunioni, feedback vago nei test e key user che costruiscono workaround non ufficiali. Associ ogni segnale al team da cui proviene, così può intervenire prima che arrivi allo steering committee.

Una pratica che funziona: ruotare i change lead per fase. Una sola persona che governa il cambiamento per un programma di due anni di solito si logora e perde prospettiva. Con il mutare della natura della resistenza, devono cambiare anche le persone che la affrontano.

Soprattutto, tenga il change management dentro la struttura del programma. I risultati comportamentali vanno nel project charter. I rischi legati alle persone, come il sovraccarico dei team e la sfiducia ereditata dal passato, vanno nel registro dei rischi accanto a quelli tecnici. Quando il change management confluisce in un generico aggiornamento della PMO, diventa una casella da spuntare.

Che cosa deve includere un piano di change management?

Sette parti: mappatura dell'influenza, una valutazione dell'impatto del cambiamento, un piano di comunicazione con cicli di feedback, formazione per ruolo, coinvolgimento della leadership, KPI di adozione e monitoraggio della resistenza. Ciascuna richiede un responsabile indicato per nome, e il piano va collegato al project charter, ai workshop di progettazione e ai quality gate.

Quali sono le 5 C del change management?

Ne esistono diverse versioni. Quella che uso io è: chiarezza (le persone sanno che cosa cambia per loro), coerenza (i leader dicono la stessa cosa), impegno (lo sponsor resta visibile), comunicazione (pertinente, tempestiva e bidirezionale) e capacità (formazione, supporto e tempo per adattarsi). Se ne manca anche una sola, le persone tornano alle vecchie abitudini.

Quali sono le 7 R del change management?

Provengono dall'IT service management e servono a valutare una richiesta di modifica prima di agire. Chi l'ha avanzata, il motivo, il ritorno atteso, i rischi, le risorse necessarie, chi ne è responsabile e il rapporto con le altre modifiche. Si applicano al controllo tecnico delle modifiche, non al lato umano di un programma.

Qual è la differenza tra change management organizzativo e tecnico?

Il change management organizzativo prepara le persone: comunicazione, formazione e supporto durante un cambiamento nel modo di lavorare. Il change management tecnico controlla quali modifiche entrano nel sistema SAP, attraverso transport, approvazioni, test e rollback. I programmi ERP di solito gestiscono bene il lato tecnico; i fallimenti dell'adozione nascono dal lato organizzativo. La mia guida agli strumenti di change management tecnico per SAP tratta il lato tecnico.

Devo usare WalkMe o SAP Enable Now?

Spesso entrambi. SAP Enable Now è più forte nella creazione di contenuti formativi strutturati prima del go-live. WalkMe è più forte nella guida dentro l'applicazione dopo il go-live, soprattutto quando gli utenti passano tra SAP e altre applicazioni. Poiché SAP possiede entrambi, li valuti insieme. Whatfix è la principale alternativa indipendente.

Quando deve iniziare il change management in un progetto ERP?

Alla mobilitazione, prima del primo workshop di progettazione. Le azioni iniziali che contano di più sono mappare l'influenza, raccogliere la storia informale dei progetti passati, inserire i risultati comportamentali nel project charter e fissare il ritmo di comunicazione dello sponsor.