Il metodo ADKAR, sviluppato da Prosci, struttura il cambiamento attorno a cinque tappe individuali: Awareness, Desire, Knowledge, Ability, Reinforcement. La sua adozione oggi supera il perimetro delle società di consulenza. Grandi gruppi come Atos lo integrano nei loro percorsi di certificazione interni, al pari di SAFe o ITIL, rendendolo un riferimento di competenze atteso per le posizioni legate alla trasformazione digitale.
ADKAR in un contesto di iper-cambiamento: uscire dal sequenziale
Il modello ADKAR è stato concepito come una progressione lineare. In un ambiente di rilascio continuo, di agilità su larga scala o di implementazione di strumenti IA, questa sequenzialità non regge più. I collaboratori attraversano più cicli ADKAR in parallelo, a stadi diversi a seconda dei progetti.
Vedi anche : Tutto quello che c'è da sapere sulla locazione di box di stoccaggio a Pessac, vicino a Bordeaux
Osserviamo sul campo che le cinque fasi si sovrappongono non appena il ritmo di trasformazione accelera. Un dipendente può essere nella fase Ability su un’implementazione ERP mentre inizia appena l’Awareness su una revisione dei processi legata all’IA. Trattare questi cicli come indipendenti significa ignorare il carico cognitivo accumulato.
Affinché il modello rimanga operativo, deve essere gestito come un backlog di transizioni individuali piuttosto che come un tunnel unico. Ogni collaboratore ha un portafoglio di cambiamenti attivi, e il ruolo del change manager consiste nel dare priorità ai traguardi ADKAR in base all’impatto sul business, non in ordine alfabetico del modello. Come dettaglia la metodologia ADKAR spiegata su Campus Recrutement, la comprensione approfondita di ogni fase rimane la base, anche quando l’esecuzione smette di essere lineare.
Da scoprire anche : Tutto quello che c'è da sapere sul compagno di Yoann Usai nel 2026 e sulla loro vita di coppia
Diagnosticare il punto di blocco ADKAR in un progetto di trasformazione
Il valore operativo di ADKAR risiede meno nella descrizione delle cinque fasi che nella sua capacità di localizzare precisamente dove un individuo o un team si ferma. Troppi progetti falliscono perché i team di progetto investono massicciamente nella formazione (Knowledge) mentre il vero blocco si trova a monte, sul Desire.
Una diagnosi ADKAR affidabile si basa su colloqui individuali brevi e mirati, non su indagini di soddisfazione generiche. Per ogni traguardo, la domanda è binaria: l’individuo ha superato questa soglia, sì o no? Il primo “no” nella sequenza identifica il punto di intervento prioritario.
Concretamente, su un programma ERP di grande portata (SAP, Oracle), Prosci propone ora percorsi di formazione dedicati a ciascun ruolo: sponsor, project manager, manager di prossimità. Questa granularità consente di industrializzare la diagnosi e di assegnare le risorse di supporto dove il blocco è reale.
- Se il blocco è su Awareness, il problema è un deficit di comunicazione sponsorizzata dalla direzione, non una mancanza di materiali formativi.
- Se il blocco è su Desire, nessuna formazione tecnica compenserà l’assenza di risposta alla domanda “cosa ci guadagno personalmente”.
- Se il blocco è su Ability, il collaboratore comprende e vuole cambiare, ma l’ambiente di lavoro (strumenti, processi, carico) non gli consente di praticare.
ADKAR come mattoncino di orchestrazione in un portafoglio di progetti
ADKAR non è più solo una griglia HR o di comunicazione. Le piattaforme di gestione dei progetti come Asana lo presentano ora come un modello di orchestrazione dell’adozione, complementare ai framework di delivery Agile o PMI.
Questa evoluzione d’uso cambia la postura del change manager. Non produce più un “piano di gestione del cambiamento” in parallelo al progetto. Integra i traguardi ADKAR direttamente nel backlog del team di progetto, con criteri di accettazione legati all’adozione reale da parte degli utenti finali.
Su un programma di trasformazione con più cantieri simultanei, raccomandiamo di mappare le popolazioni impattate per cantiere, poi di incrociare questa mappatura con lo stato ADKAR di ciascun gruppo. Il risultato è un cruscotto di adozione che completa gli indicatori classici di avanzamento del progetto (budget, tempi, ambito).
Integrare ADKAR nei rituali agili
In un contesto SAFe o Scrum su larga scala, il Program Increment Planning offre un punto di ancoraggio naturale. Ogni PI Planning può includere un obiettivo di adozione formulato in termini ADKAR: ad esempio, “raggiungere la soglia Knowledge per i 40 utenti chiave del modulo finance prima del prossimo PI”.
Le retrospettive di team diventano anche uno strumento di Reinforcement. Strutturando una parte della retrospettiva attorno alla domanda “quali nuove pratiche abbiamo effettivamente adottato in questo sprint”, si ancorano l’ultimo traguardo ADKAR in un rituale già esistente, senza aggiungere ulteriori riunioni.
Limiti di ADKAR e decisioni da conoscere
Il modello postula che il cambiamento sia auspicabile. Non fornisce alcun quadro per decidere se un cambiamento meriti di essere attuato. ADKAR accompagna l’adozione, non valida la pertinenza strategica del progetto. Questa distinzione è spesso sfocata nelle organizzazioni che confondono “le persone resistono” e “il progetto è mal calibrato”.
Un altro limite: il modello tratta l’individuo come unità di analisi, il che è la sua forza ma anche il suo punto cieco. Le dinamiche collettive (effetto di gruppo, cultura di team, giochi politici tra direzioni) non sono modellizzate. Un collaboratore può aver superato le cinque fasi individualmente e regredire sotto la pressione di un collettivo ostile al cambiamento.
- ADKAR funziona meglio quando è accoppiato a un modello organizzativo (Kotter per il sponsorship, Lewin per la dinamica di gruppo).
- Su trasformazioni IA, il traguardo Knowledge richiede aggiornamenti continui poiché gli strumenti evolvono tra due cicli di formazione.
- Il Reinforcement è il traguardo più trascurato in pratica, mentre è quello che determina se il cambiamento sopravvive oltre il go-live.
L’efficacia di ADKAR dipende meno dal modello stesso che dalla rigore con cui la diagnosi individuale è condotta e mantenuta nel tempo. Un tableau ADKAR aggiornato una volta all’inizio del progetto e poi dimenticato non produce alcun risultato. Il cambiamento si gestisce in continuazione, oppure non si gestisce affatto.