Il change management in un progetto ERP è l'insieme delle attività che portano le persone ad adottare davvero il nuovo sistema: coinvolgimento, comunicazione, formazione, sponsorship dei vertici e presidio dopo il go-live. Non è un corollario tecnico né un corso di una giornata. È la disciplina che decide se l'investimento produce valore o resta inutilizzato.

I dati di Prosci sono netti: i progetti con un'ottima gestione del cambiamento centrano gli obiettivi nel 93% dei casi, contro il 15% di quelli gestiti male. Sette volte la probabilità di riuscire. Il software, di nuovo, non è il punto debole. Le persone sì.

Perché l'adozione è il vero test di un progetto ERP?

Un sistema ERP può superare tutti i collaudi tecnici, gira, è veloce, i dati migrano, e fallire comunque. Il collaudo che conta non è tecnico: è comportamentale. Le persone lo usano come previsto, oppure no?

Troppo spesso la risposta è no. Continuano a tenere il loro Excel parallelo «perché è più veloce». Chiamano l'ufficio acquisti invece di guardare la giacenza a sistema. Registrano i movimenti a fine giornata in blocco, falsando i dati in tempo reale che giustificavano l'intero progetto. Il sistema funziona. L'azienda no.

Ecco perché il fallimento di un ERP è organizzativo, non tecnologico. McKinsey osserva da anni che circa il 70% dei programmi di cambiamento complessi non raggiunge gli obiettivi dichiarati; tra le cause cita prima lo scarso coinvolgimento delle persone e il sostegno inadeguato del management, non i bug. Rovesciato, lo stesso dato diventa promessa: nelle trasformazioni in cui il personale di prima linea sente di «possedere» il cambiamento, il tasso di successo sale al 70%. Quando insieme c'è anche l'iniziativa dal basso, supera il 79% (McKinsey, The science behind successful organizational transformations, 2021 ↗).

I numeri esistono. Non è un auspicio.

Resistenza al cambiamento: da dove nasce davvero?

C'è un equivoco da smontare subito. La resistenza non è pigrizia, né cattiva volontà. È la reazione razionale di chi sta per perdere qualcosa.

Quando introduci un ERP, chiedi a una persona di abbandonare un modo di lavorare che padroneggia, su cui è veloce, competente, sicura, per uno in cui sarà lenta, impacciata, dipendente da un manuale. Le chiedi di tornare temporaneamente incapace nel proprio mestiere. Per chi ha costruito parte della propria identità professionale su «io so come si fa qui», non è una questione di software: è una perdita di status e di controllo. La resistenza nasce lì.

Si aggrava quando il cambiamento arriva calato dall'alto, senza spiegazioni. I numeri lo confermano: secondo Gartner solo il 38% dei dipendenti si dichiara disposto a sostenere un cambiamento organizzativo, contro il 74% del 2016. La disponibilità al cambiamento è crollata. Chi avvia un progetto ERP oggi parte da una platea più stanca e più scettica di dieci anni fa.

La conseguenza pratica è una sola: la resistenza va prevista e lavorata prima, non gestita come un imprevisto al go-live. Chi capisce il perché del cambiamento, e che è stato coinvolto nel disegnarlo, resiste molto meno di chi trova il sistema acceso un lunedì mattina senza preavviso.

Qual è il ruolo dello sponsor executive?

La singola figura che determina l'esito dell'adozione non è il project manager né il capo IT. È lo sponsor: il dirigente che mette la faccia sul progetto. Prosci lo segnala come primo fattore di successo del cambiamento, davanti a tutto il resto.

Ma «sponsorship» e «visibilità» non sono la stessa cosa, ed è qui che si annida l'errore più comune. Il discorso di apertura al kick-off, l'e-mail entusiasta, la foto col team: visibilità. La sponsorship vera è un comportamento ripetuto e costoso per chi lo agisce.

• Usa il sistema per primo, o pretende i report dal sistema invece che dal vecchio Excel. Se il capo continua a chiedere i numeri «alla vecchia maniera», tutti capiscono che il nuovo sistema è facoltativo.
• Toglie ostacoli quando il progetto si scontra con le resistenze di reparto, invece di delegare il conflitto al project manager.
• Comunica più volte e di persona il perché del cambiamento.
• Tiene il punto quando arriva la pressione a «fare un'eccezione» per il reparto più influente. Le eccezioni sono la crepa da cui scola l'adozione di tutti gli altri.

Uno sponsor assente, o presente solo alla cerimonia, è uno dei modi più affidabili per affondare un progetto. Nessuna quantità di formazione lo compensa.

Il piano di adozione in 4 fasi (mappato sul modello ADKAR)

Il modello più usato per gestire il cambiamento individuale è l'ADKAR, sviluppato da Jeff Hiatt (Prosci) nel 1998. Cinque stadi che ogni persona attraversa: Awareness (consapevolezza), Desire (volontà), Knowledge (conoscenza), Ability (capacità), Reinforcement (rinforzo). La logica è che il cambiamento di un'azienda è la somma dei cambiamenti dei singoli: blocchi a uno stadio, e lì si ferma l'adozione di quella persona.

Tradotto in un progetto ERP, diventa un piano in quattro fasi.

1. Prima del progetto: consapevolezza e volontà (Awareness + Desire). Spiegare a tutti, non solo ai capi, perché si cambia e cosa c'è in gioco. Coinvolgere le persone chiave dei reparti nel disegno del nuovo processo: chi partecipa alla costruzione difende il risultato; chi lo subisce lo combatte. McKinsey rileva che il coinvolgimento già in fase di pianificazione è tra i fattori di successo più ricorrenti.
2. Durante la configurazione: trasferire conoscenza (Knowledge). Formazione mirata sui processi reali dell'azienda, non sul manuale generico del software. I key user di ogni reparto vanno individuati e preparati presto: diventeranno il primo punto di riferimento per i colleghi, scaricando il peso del supporto post go-live.
3. Al go-live: costruire capacità (Ability). Affiancamento sul campo nei giorni dell'avvio, supporto immediato, tolleranza per gli errori iniziali. Sapere una cosa e saperla fare sotto pressione sono due cose diverse. Questa fase serve a colmare quel salto.
4. Dopo il go-live: rinforzare (Reinforcement). Misurare l'adozione, celebrare i risultati, correggere ciò che non funziona, impedire che le persone scivolino verso le vecchie abitudini. È la fase più trascurata e quella che decide se il cambiamento regge nel tempo.

Le prime due fasi avvengono prima che il sistema sia in funzione. L'adozione si vince a monte.

Chi inizia a pensare al change management il giorno del go-live ha già perso le due fasi che contavano di più.

Come si misura l'adozione? I KPI che servono davvero

«Le persone lo stanno usando?» non è una domanda da affidare alle impressioni. Si misura. Senza misurarla, non sai se intervenire finché non è tardi. Alcuni indicatori concreti, leggibili direttamente dal sistema:

Un'avvertenza, perché qui si esagera spesso. Misurare non significa sorvegliare. I KPI di adozione servono a capire dove aiutare le persone, non a stilare classifiche punitive. Usati come bastone, peggiorano la resistenza invece di ridurla.

Quali errori evitare al go-live?

Il go-live concentra in pochi giorni tutti gli errori che si possono fare. I più frequenti, e i più evitabili.

• Trattare il go-live come la fine. È l'inizio. Il valore di un ERP si costruisce nei mesi successivi: i benchmark di settore collocano il ritorno sull'investimento intorno ai due anni e mezzo, non a due settimane. Smobilitare il team il giorno dopo l'avvio è l'errore numero uno.
• Formare due persone e sperare che insegnino alle altre. La formazione a cascata informale lascia buchi enormi. Ogni utente che dovrà usare il sistema va formato sul suo lavoro concreto.
• Andare in big bang senza rete. Tutto in produzione la stessa notte, nessun affiancamento, nessun piano B. Un avvio iterativo a blocchi riduce il rischio in modo misurabile.
• Concedere eccezioni «solo per ora». Il reparto che ottiene di continuare col vecchio sistema «in transizione» diventa il buco da cui esce l'adozione degli altri. Non esistono eccezioni temporanee: esistono precedenti.
• Confondere comunicazione con quantità. Più e-mail non vuol dire più adozione. L'eccesso genera change fatigue, stanchezza da cambiamento che oggi colpisce una quota crescente di lavoratori. Conta la chiarezza e la coerenza dei messaggi, non il volume.

Quando il change management non basta

Il miglior piano di adozione del mondo non salva un progetto partito male su altri fronti. Se gli obiettivi sono vaghi, le persone non sapranno verso cosa cambiare. Se i dati sono sporchi, perderanno fiducia nel sistema alla prima giacenza sbagliata e torneranno all'Excel, con piena ragione. Se il partner ha configurato un processo che non rispecchia come lavorano, l'adozione che chiedi è l'adozione di qualcosa che non funziona.

Il change management amplifica un progetto sano. Non resuscita un progetto malato.

Per questo va dentro al progetto dall'inizio, accanto agli obiettivi, ai dati e alla scelta del partner. Non si aggiunge alla fine come una vernice.

Domande frequenti

Cosa fare lunedì mattina