Il sistema è pronto.
I test sono conclusi.
Le utenze sono state configurate.
Le procedure aggiornate.
La formazione è stata programmata.
Arriva il giorno del go-live e il progetto entra ufficialmente in produzione.
Per molte organizzazioni questo momento rappresenta il traguardo.
Dal punto di vista tecnico è comprensibile.
Dal punto di vista dell’innovazione, molto meno.
Perché una tecnologia può essere perfettamente implementata e continuare a non cambiare quasi nulla.
Le persone possono utilizzare il nuovo sistema soltanto perché obbligate.
Possono continuare a mantenere file paralleli.
Possono trasferire informazioni fuori dalla piattaforma.
Possono ricreare attraverso email e fogli Excel il processo che il progetto avrebbe dovuto superare.
Possono imparare quali pulsanti premere senza comprendere realmente perché il modo di lavorare sia cambiato.
Il sistema è online.
L’innovazione, forse, non ancora.
L’adozione non viene dopo il progetto. È parte del progetto.
Implementare non significa adottare
Implementazione e adozione sono due risultati diversi.
L’implementazione risponde principalmente a domande tecniche:
- il sistema funziona?
- gli utenti possono accedere?
- le integrazioni sono operative?
- i dati sono disponibili?
- il workflow esegue correttamente le regole?
- i requisiti sono stati rispettati?
L’adozione pone domande differenti.
Le persone utilizzano davvero il nuovo strumento?
Lo utilizzano nel modo previsto?
Hanno abbandonato le modalità precedenti?
Comprendono cosa è cambiato e perché?
Il nuovo processo semplifica realmente il loro lavoro?
Le eccezioni possono essere gestite senza ricorrere continuamente a soluzioni parallele?
Sono domande meno facili da chiudere con un verbale di collaudo.
Ma sono quelle che determinano se una tecnologia entrerà davvero nell’organizzazione.
L’obbligo produce utilizzo, non necessariamente adozione
È possibile ottenere rapidamente un indicatore di utilizzo.
Basta rendere uno strumento obbligatorio.
Se una richiesta può essere presentata soltanto attraverso una piattaforma, le persone utilizzeranno quella piattaforma.
Ma il fatto che un sistema venga utilizzato non significa automaticamente che sia stato adottato.
La differenza emerge nei comportamenti che gli indicatori più semplici non mostrano.
Un utente inserisce i dati nel sistema ma continua a mantenerne una copia personale.
Un responsabile approva formalmente il workflow ma chiede comunque conferma via email.
Un documento viene archiviato correttamente, mentre la versione su cui si continua a lavorare resta in una cartella locale.
Una piattaforma contiene tutte le informazioni necessarie, ma le persone continuano a chiedere a un collega perché trovarle richiede troppo tempo.
Formalmente il processo è digitale.
Nella pratica, l’organizzazione continua a sostenere due sistemi: quello nuovo e quello precedente.
Ed è uno dei costi più difficili da vedere.
I processi paralleli sono un segnale
Quando compare un file Excel accanto a una nuova piattaforma, la reazione più immediata può essere:
gli utenti non vogliono cambiare.
A volte è vero.
Ma non dovrebbe essere la prima conclusione.
Un processo parallelo può essere il sintomo di qualcosa che il progetto non ha intercettato.
Forse manca un’informazione.
Forse il sistema non restituisce una vista necessaria.
Forse una determinata eccezione non è stata prevista.
Forse un’attività semplice richiede troppi passaggi.
Forse il vecchio file contiene una conoscenza operativa che non è stata trasferita nel nuovo processo.
Forse il problema non è resistenza al cambiamento.
È semplicemente che il nuovo sistema non risolve ancora completamente il problema.
Le scorciatoie create dagli utenti sono spesso informazioni sul progetto, prima ancora che comportamenti da correggere.
Questo non significa accettare indefinitamente processi paralleli.
Significa comprenderli prima di eliminarli.
L’adozione comincia molto prima del go-live
Uno degli errori più comuni consiste nel concentrare le attività di adozione nelle ultime settimane del progetto.
Il sistema è praticamente pronto.
A quel punto si preparano:
- comunicazioni;
- manuali;
- webinar;
- sessioni formative;
- FAQ;
- materiali di supporto.
Sono tutte attività utili.
Ma se l’adozione inizia qui, probabilmente inizia troppo tardi.
La prima attività di adoption dovrebbe avvenire quando il progetto sta ancora cercando di capire il problema.
Chi utilizza quotidianamente un processo conosce dettagli che raramente emergono interamente dalla documentazione.
Conosce le eccezioni.
Le attese.
Le informazioni che arrivano incomplete.
I passaggi che vengono formalmente eseguiti ma che nessuno considera realmente utili.
Le scorciatoie costruite negli anni.
I punti nei quali una procedura e il lavoro reale hanno iniziato a divergere.
Coinvolgere le persone in questa fase non è soltanto change management.
È analisi.
Coinvolgere non significa progettare per alzata di mano
Naturalmente coinvolgere gli utenti non significa trasformare ogni scelta progettuale in una votazione.
Un progetto ha obiettivi, vincoli, responsabilità e decisioni che devono rimanere chiare.
L’ascolto serve a comprendere il contesto.
Non necessariamente a replicare ogni preferenza.
Una persona può chiedere di mantenere una determinata funzionalità perché è abituata a utilizzarla.
Ma l’analisi potrebbe mostrare che quella funzione esiste soltanto per compensare un problema che il nuovo processo elimina alla radice.
In questo caso ascoltare non significa conservare.
Significa capire perché quella richiesta esista.
È una distinzione importante.
L’adozione non consiste nel costruire esattamente ciò che gli utenti chiedono.
Consiste nel costruire qualcosa che permetta loro di lavorare meglio e nel rendere comprensibile il cambiamento che ne deriva.
Spiegare il perché prima del come
La formazione tecnologica tende naturalmente a concentrarsi sul come.
Come accedere.
Come creare una richiesta.
Come compilare un campo.
Come caricare un documento.
Come approvare.
Come cercare.
È necessario.
Ma una trasformazione viene compresa molto meglio quando prima viene spiegato perché il processo sia cambiato.
Quale problema stiamo cercando di risolvere?
Cosa non funzionava nel modo precedente?
Quali passaggi sono stati eliminati?
Perché alcune informazioni vengono richieste in modo diverso?
Cosa accadrà alle vecchie modalità operative?
Quale vantaggio concreto dovrebbe emergere?
Una persona che comprende la logica del sistema riesce anche a interpretare meglio situazioni che non sono state spiegate durante la formazione.
Una persona che ha imparato soltanto una sequenza di clic dipende molto di più dal manuale.
Per questo la formazione più efficace non insegna soltanto l’interfaccia.
Insegna il nuovo processo.
La formazione non può correggere un cattivo design
Esiste poi un limite che vale la pena riconoscere.
Non tutto può essere risolto con più formazione.
Se un’operazione quotidiana richiede quindici passaggi inutili, una sessione formativa può spiegare quei quindici passaggi molto bene.
Restano comunque quindici.
Se le etichette non sono comprensibili, possiamo creare un manuale che le spieghi.
Ma forse sarebbe più efficace cambiarle.
Se un utente deve ricordare una regola complessa per scegliere correttamente tra cinque opzioni, possiamo inserirla nelle FAQ.
Oppure possiamo chiederci se il sistema possa applicare automaticamente quella regola.
Ogni volta che una formazione deve spiegare ripetutamente qualcosa di innaturale, vale la pena chiedersi se il problema sia davvero formativo.
L’adozione non deve quindi diventare il luogo nel quale vengono trasferite sulle persone le complessità che il progetto non ha risolto.
La tecnologia dovrebbe fare esattamente il contrario.
Gli utenti pilota non servono soltanto a trovare bug
Un gruppo pilota può essere uno degli strumenti più efficaci in un progetto di innovazione.
Ma il suo valore viene spesso limitato al testing.
Il pulsante funziona?
Il campo salva correttamente?
La notifica arriva?
Sono verifiche necessarie.
Ma gli utenti pilota possono dirci molto di più.
Capiscono immediatamente cosa devono fare?
Riescono a completare il processo senza essere guidati?
Quali termini interpretano in modo differente?
Quale passaggio rallenta l’attività?
Dove cercano una funzione che abbiamo posizionato altrove?
Quale informazione manca nel momento in cui devono prendere una decisione?
Queste osservazioni riguardano l’esperienza reale.
Un sistema può superare perfettamente tutti i test funzionali e risultare comunque difficile da utilizzare.
Per questo un buon pilota non verifica soltanto se la soluzione funziona.
Verifica se funziona per qualcuno.
I primi utenti influenzano tutti gli altri
L’adozione ha anche una componente sociale.
Quando una nuova tecnologia entra in un’organizzazione, le persone osservano ciò che succede agli altri.
Se i primi utilizzatori riescono a lavorare meglio, il nuovo sistema acquista credibilità.
Se incontrano difficoltà continue, quelle difficoltà diventano rapidamente parte del racconto organizzativo.
“Non funziona.”
“È complicato.”
“Prima era più semplice.”
“Serve il doppio del tempo.”
A volte queste affermazioni nascono da problemi reali.
Altre volte da episodi iniziali già corretti.
Ma una volta che una percezione si consolida, modificarla può essere molto più difficile che correggere il problema tecnico che l’ha originata.
Per questo le prime settimane contano particolarmente.
Il supporto deve essere rapido.
Il feedback deve essere raccolto.
I problemi visibili devono ricevere risposte visibili.
Le correzioni devono essere comunicate.
L’organizzazione deve poter vedere che il nuovo sistema continua a migliorare attraverso l’utilizzo reale.
Non tutti adottano allo stesso modo
Un’altra semplificazione consiste nel considerare gli utenti come un gruppo omogeneo.
Non lo sono.
Esistono persone curiose che sperimentano immediatamente.
Persone che attendono di capire se il nuovo sistema resterà davvero.
Persone che hanno bisogno di vedere un vantaggio concreto.
Persone che lavorano raramente sul processo e quindi dimenticano facilmente i passaggi.
Persone molto esperte del vecchio sistema che improvvisamente perdono una parte delle loro certezze operative.
Persone che conoscono poco il processo ma imparano rapidamente la nuova interfaccia.
La stessa strategia di adozione non funziona necessariamente per tutti.
Per alcune attività serve formazione.
Per altre una guida contestuale.
Per altre ancora un referente interno facilmente raggiungibile.
A volte è sufficiente rendere il sistema abbastanza intuitivo da non richiedere quasi nulla.
L’obiettivo non dovrebbe essere produrre più materiale.
Dovrebbe essere ridurre progressivamente il bisogno di supporto.
I champion funzionano quando sono credibili
In molti progetti vengono individuati key user, ambassador o champion.
È una buona idea.
Ma funziona soltanto se il ruolo non è puramente formale.
Un buon referente interno dovrebbe conoscere:
- il processo;
- le difficoltà degli utenti;
- le ragioni del cambiamento;
- i limiti dello strumento;
- i canali attraverso cui segnalare un problema.
E soprattutto deve essere percepito come una persona a cui è utile rivolgersi.
Non come l’estensione locale del progetto.
Il valore di questi ruoli sta nella prossimità.
Una domanda posta a un collega durante il lavoro spesso vale più di una pagina di manuale.
E quello stesso collega può riportare al progetto informazioni che difficilmente arriverebbero attraverso un ticket strutturato.
Misurare l’adozione è più difficile che contare gli accessi
Quante persone hanno effettuato il login?
È un dato utile.
Ma da solo dice pochissimo.
Una piattaforma potrebbe registrare il 100% degli accessi previsti e continuare a produrre processi paralleli.
Per comprendere realmente l’adozione bisogna osservare più dimensioni.
Per esempio:
- percentuale di processi completati interamente nel nuovo sistema;
- numero di eccezioni gestite fuori piattaforma;
- richieste di assistenza nel tempo;
- attività manuali ancora necessarie;
- tempi di completamento;
- errori;
- utilizzo delle funzionalità principali;
- abbandono delle modalità precedenti;
- feedback qualitativo degli utenti.
Non esiste un unico indicatore valido per qualsiasi progetto.
La domanda fondamentale resta:
il nuovo sistema è diventato il modo normale di svolgere quell’attività?
Quando la risposta è sì, l’adozione sta avvenendo.
La resistenza non è sempre irrazionale
“Resistenza al cambiamento” è una delle espressioni più utilizzate quando un progetto incontra difficoltà.
A volte descrive correttamente ciò che accade.
Il cambiamento può mettere in discussione abitudini, competenze, equilibri e comfort consolidati.
Ma utilizzare questa spiegazione troppo rapidamente è pericoloso.
Una persona può opporsi a un nuovo processo perché:
- richiede più tempo;
- perde un’informazione che prima aveva;
- aumenta il numero dei passaggi;
- rende meno chiara una responsabilità;
- è incompatibile con una situazione operativa reale;
- introduce un controllo ridondante;
- non gestisce un’eccezione frequente.
In questi casi la resistenza contiene informazione.
Non va semplicemente superata.
Va capita.
Non ogni obiezione è resistenza al cambiamento. A volte è un requisito che abbiamo scoperto troppo tardi.
La capacità di distinguere tra le due situazioni è parte del lavoro di innovazione.
Anche ciò che funziona deve poter cambiare
Un altro rischio compare quando il progetto ha successo.
Il sistema entra in uso.
Gli utenti imparano.
I problemi iniziali diminuiscono.
A quel punto può nascere la tentazione di considerarlo definitivamente concluso.
Ma un processo digitale genera una quantità di informazioni che prima spesso non avevamo.
Possiamo osservare:
dove si accumulano le attività;
quanto tempo richiede un passaggio;
quali eccezioni compaiono più spesso;
quali campi vengono corretti;
quali funzionalità vengono utilizzate poco;
dove gli utenti interrompono il flusso.
Sono dati preziosi.
Permettono di trasformare il processo da qualcosa che abbiamo progettato sulla base di ipotesi in qualcosa che possiamo migliorare sulla base dell’esperienza.
L’adozione non significa quindi soltanto stabilizzare il nuovo sistema.
Significa anche creare le condizioni affinché possa evolvere.
Il progetto finisce. Il cambiamento no.
Ogni progetto ha bisogno di una conclusione.
Budget, attività e responsabilità non possono restare aperti indefinitamente.
Ma la fine del progetto e la fine del cambiamento non coincidono.
A un certo punto la piattaforma smette di essere “il nuovo sistema”.
Diventa semplicemente il sistema.
La procedura precedente non viene più consultata.
Il file parallelo scompare.
Le persone nuove imparano direttamente il nuovo processo senza conoscere quello vecchio.
Le domande diminuiscono.
L’attenzione si sposta dallo strumento al lavoro che permette di svolgere.
È probabilmente questo il momento in cui possiamo parlare di vera adozione.
Non quando la tecnologia è stata installata.
Non quando tutti hanno partecipato alla formazione.
Non quando il progetto è stato formalmente chiuso.
Ma quando il cambiamento smette di essere percepito come qualcosa di nuovo e diventa il modo normale di lavorare.
technology innovationadozione digitalechange managementtrasformazione digitalepersoneprocessiformazioneuser experience