Il gestionale nuovo che nessuno usa
Consegnato non vuol dire adottato
Il progetto si chiude, il sistema gira, la formazione è stata fatta. Tre mesi dopo si scopre che il commerciale tiene ancora il suo foglio, che in magazzino stampano la lista e la segnano a penna, e che i dati dentro il gestionale sono aggiornati a metà.
Non è un caso raro ed è la forma più costosa di fallimento di un progetto software: il conto è stato pagato per intero e il beneficio è arrivato in parte. Peggio, adesso i modi di lavorare sono due — quello nuovo e quello vecchio che non è morto — e i dati non tornano più.
La reazione istintiva è dare la colpa alla resistenza al cambiamento. Quasi sempre è una spiegazione pigra. Le persone tornano al metodo vecchio per ragioni precise, e sono ragioni che si possono conoscere in anticipo.
Perché si torna indietro
Perché il modo nuovo, per quella persona, è più lento. Un sistema può far risparmiare due ore all'ufficio e costarne una in più a chi inserisce i dati. Chi la paga vede solo il proprio pezzo, e ha ragione a vederlo. Se nessuno ha riconosciuto quello scambio e nessuno ha detto perché vale la pena, il ritorno al foglio è la scelta razionale.
Perché il caso strano non è previsto. Il flusso funziona per l'ottanta per cento degli ordini. Poi arriva quello con la consegna spezzata su due date, e nel sistema non si può fare. Basta questo: la persona si costruisce un foglio per i casi difficili, e nel giro di settimane il foglio si mangia anche i casi facili.
Perché nessuno ha spento il vecchio. Finché il file condiviso è ancora lì e funziona, continuerà a essere usato. Non per dispetto: perché è più familiare.
Perché chi lo usa non ha partecipato. Se le specifiche sono state raccolte solo con i responsabili, il sistema riflette come si crede che si lavori, non come si lavora. La distanza fra le due cose la conoscono soltanto le persone che fanno quel lavoro tutti i giorni.
Cosa funziona
Coinvolgere prima, e sul serio. Non una riunione di presentazione: qualche ora passata a guardare chi lavora, con le domande giuste. Cosa fai quando arriva questo caso? Perché tieni questo file? Cosa ti fa perdere più tempo? Da lì escono i requisiti veri, e le persone arrivano al lancio avendo già visto le proprie osservazioni finire dentro il prodotto.
Partire da un gruppo ristretto. Un'area, o cinque persone, per qualche settimana. Trovano i problemi quando correggerli costa poco e diventano i primi a saper rispondere ai colleghi — cosa che vale più di qualsiasi corso.
Rendere il modo nuovo più comodo di quello vecchio nel punto giusto. Se l'inserimento è più lungo, va compensato da qualcosa che prima non c'era e che serve a quella stessa persona: la ricerca che trova, lo storico del cliente sotto gli occhi, la stampa che prima si faceva a mano.
Chiudere il vecchio con una data. Annunciata, con un periodo di sovrapposizione dichiarato, e poi rispettata. Senza questo passaggio la convivenza dura per sempre.
Lasciare un canale per dire che qualcosa non va. Se l'unico modo di segnalare un problema è aprire un ticket formale, le persone non lo useranno: si arrangeranno. Un canale diretto nelle prime settimane, con risposte rapide su cose piccole, cambia completamente il rapporto con il sistema.
Il ruolo di chi ha voluto il progetto
C'è una parte che il fornitore non può fare al posto vostro, ed è la più determinante: dire in modo chiaro perché si sta cambiando e che il cambiamento non è reversibile.
Se il messaggio interno è tiepido — "proviamo, poi vediamo" — il reparto capisce che il vecchio metodo è ancora un'opzione, e la tiene. Se è chiaro, resta comunque lo spazio per correggere il sistema, ma non per aggirarlo.
Conta anche l'esempio: se chi guida chiede ancora il riepilogo per email invece di guardarlo nel sistema, tutti capiscono qual è la fonte che conta davvero.
Come si misura l'adozione
Serve un numero, altrimenti si discute di impressioni. Non è complicato: quante persone hanno usato il sistema questa settimana, quanti documenti sono passati dal flusso nuovo rispetto al totale, quanti casi sono ancora gestiti fuori.
La curva dice più del valore assoluto. Se dopo il lancio l'uso sale e poi cala, c'è un punto preciso in cui le persone hanno sbattuto contro qualcosa. Vale la pena trovarlo mentre è ancora fresco: quasi sempre è un dettaglio piccolo e riparabile, che dopo sei mesi sarà diventato un'abitudine consolidata a non usare il sistema.
Quando il problema non sono le persone
Va detta anche l'altra metà. A volte l'adozione non parte perché il software non regge il lavoro reale: è lento nei momenti di punta, chiede dieci passaggi dove ne servirebbero tre, non gestisce un caso che si presenta ogni giorno.
Distinguere i due casi è semplice se si guarda dove si inceppa. Se le persone saltano lo stesso passaggio, quel passaggio è sbagliato. Se lo usano in modo disomogeneo, il problema è di accompagnamento. Un fornitore serio vuole saperlo: nella nostra esperienza le settimane subito dopo il rilascio, quelle in cui si correggono le cose che l'uso reale fa emergere, valgono quanto quelle di sviluppo.
Un gestionale non si giudica il giorno della consegna. Si giudica il primo lunedì in cui nessuno, per fare il proprio lavoro, ha avuto bisogno di aprire un foglio a parte.
