Adozione del software aziendale: perché i progetti falliscono dopo il go-live e come evitarlo

Il paradosso dell’investimento non utilizzato

Esiste una stima consolidata nel mondo della consulenza gestionale secondo cui tra il 50 e il 70 percento delle funzionalità dei software aziendali non viene usato in modo stabile dopo i primi sei mesi dal go-live. I numeri variano a seconda della fonte e del tipo di sistema, ma il fenomeno è sufficientemente documentato da essere considerato la norma, non l’eccezione. Un’azienda che sostiene il costo pieno di un sistema e ne usa il quaranta percento ha realizzato il quaranta percento del beneficio atteso. Il valore non recuperato non appare in nessuna voce di bilancio, ma incide sul ritorno dell’investimento in modo altrettanto reale di un costo diretto.

Dal punto di vista del TCO questo è un problema di allocation: i costi fissi del sistema sono stati sostenuti interamente, i benefici sono stati realizzati solo in parte. Il costo per unità di valore prodotto è molto più alto di quello previsto nel business case originale. Se il tasso di adozione reale è significativamente inferiore a quello assunto nel business case, il payback period si allunga proporzionalmente.

Le radici organizzative della bassa adozione

La letteratura sul change management in contesti di implementazione ERP identifica tre categorie di cause ricorrenti. La prima è la mancanza di coinvolgimento degli utenti chiave nella fase di analisi dei requisiti. Quando il sistema viene configurato sulla base delle indicazioni del management o del fornitore senza un’analisi approfondita dei flussi di lavoro reali degli utenti finali, il risultato è un sistema che è corretto in astratto ma che non si adatta ai casi d’uso concreti che le persone incontrano ogni giorno. Gli utenti non sabotano il sistema: trovano percorsi alternativi più efficienti per il loro lavoro specifico, che invariabilmente passano fuori dal sistema nuovo.

La seconda categoria è la sottostima del costo di switching cognitivo. Imparare un sistema nuovo non è solo imparare nuovi comandi: è ricostruire i modelli mentali con cui si interpreta il proprio lavoro. Un operatore che usa lo stesso gestionale da anni ha sviluppato una serie di automatismi che gli consentono di lavorare velocemente con un carico cognitivo basso. Il sistema nuovo richiede di attivare nuovamente l’attenzione consapevole su operazioni che erano diventate automatiche, con un costo energetico reale che si manifesta come stanchezza, errori e resistenza. Questo costo è temporaneo, ma se non viene riconosciuto e gestito nella fase di transizione diventa un motivo sufficiente per tornare ai vecchi strumenti.

La terza causa è l’assenza di integrazione tra il nuovo sistema e il contesto lavorativo reale. Se il sistema non si connette agli altri strumenti che le persone usano, richiede inserimenti duplicati di dati già presenti altrove o produce output che devono essere rielaborati manualmente per essere utili, il costo di utilizzo percepito supera il beneficio percepito e il sistema viene usato al minimo indispensabile, generalmente per soddisfare reporting obbligatorio verso il management piuttosto che per supportare il lavoro operativo.

Misurare l’adozione con metriche operative, non con licenze attive

Il numero di licenze attive è un indicatore di acquisto, non di adozione. Per misurare l’adozione reale servono metriche di utilizzo che distinguano tra utenti attivi, utenti passivi (che accedono al sistema solo per operazioni obbligatorie) e utenti dormienti (che hanno una licenza ma non accedono mai). Su questa base si calcola l’adoption rate effettivo, che è la metrica rilevante per valutare il ritorno sull’investimento.

Le metriche di secondo livello misurano la profondità di utilizzo: quante funzionalità vengono usate su quelle disponibili, qual è la frequenza d’uso per funzionalità, dove si concentrano gli abbandoni nei flussi di lavoro (un utente che inizia un processo e non lo completa è un segnale di usabilità o di lacuna formativa). Strumenti di analytics applicati ai log del sistema producono queste informazioni senza costi aggiuntivi significativi se l’analisi viene pianificata all’inizio del progetto.

La segmentazione per ruolo è essenziale per interpretare questi dati correttamente. Un tasso di utilizzo basso per una funzionalità avanzata di un commerciale senior non è necessariamente un problema se quella funzionalità non è parte del suo flusso di lavoro standard. Un tasso di utilizzo basso per una funzionalità core che tutti dovrebbero usare ogni giorno è invece un segnale che richiede intervento.

Change management strutturato: il modello Kotter applicato all’IT

Il modello a otto step di Kotter, sviluppato per la gestione del cambiamento organizzativo su larga scala, si applica con buoni risultati ai progetti di implementazione software anche di dimensione media. I primi tre step (creare senso di urgenza, costruire una coalizione guida, sviluppare una visione del cambiamento) vengono quasi sempre saltati nei progetti IT perché sembrano overhead gestionale non necessario per un progetto tecnico. Il risultato è che il progetto arriva al go-live senza che l’organizzazione abbia realmente capito perché sta cambiando e cosa cambierà nel lavoro quotidiano.

Il senso di urgenza non è un’operazione di marketing interno. È la condivisione, basata su dati concreti, del costo dell’inefficienza attuale: quante ore si dedicano a riconciliazioni manuali, qual è il tasso di errore sui dati inseriti manualmente, quanto tempo impiega un processo che con il nuovo sistema impiegherebbe frazioni di quel tempo. Questi dati esistono, ma raramente vengono raccolti e comunicati in modo strutturato prima del progetto.

Formazione per competenza, non per funzionalità

La formazione tradizionale sui sistemi informativi aziendali è organizzata per moduli funzionali: si impara il modulo ordini, poi il modulo fatturazione, poi il modulo reporting. È un’organizzazione logica dal punto di vista del sistema, ma non dal punto di vista dell’utente, che nel suo lavoro non attraversa moduli ma processi. Un commerciale non ha bisogno di conoscere i moduli del sistema: ha bisogno di saper eseguire il proprio processo di lavoro dall’inizio alla fine. Quelle funzionalità attraversano moduli diversi, ma per chi le usa costituiscono un flusso unico.

Progettare la formazione per percorsi di ruolo invece che per moduli funzionali richiede più lavoro in fase di preparazione ma produce tassi di retention e trasferimento delle competenze significativamente più alti. L’approccio Kaizen applicato alla formazione suggerisce di partire dai processi più frequenti e più critici per ogni ruolo, padroneggiarli completamente, e aggiungere progressivamente i casi meno frequenti e le funzionalità avanzate. La curva di apprendimento è più graduale, ma porta effettivamente a un uso autonomo e corretto del sistema.

Key user e champions: costruire competenza distribuita

Nei progetti di implementazione con un alto tasso di adozione, si trova quasi sempre una rete di key user distribuita nell’organizzazione che funge da punto di riferimento di primo livello per i colleghi. Non sono esperti del sistema nel senso tecnico del termine: sono persone con buona padronanza operativa che conoscono il contesto lavorativo del proprio reparto e riescono a rispondere alle domande pratiche che emergono nel lavoro quotidiano.

Costruire questa rete richiede di identificare i key user prima del go-live, formarli in modo più approfondito rispetto agli altri utenti, coinvolgerli nella fase di test e configurazione del sistema (cosa che aumenta la loro padronanza e il loro senso di ownership), e riconoscere esplicitamente il loro ruolo durante la fase di hypercare post go-live. La variabile che distingue le organizzazioni in cui questa rete funziona da quelle in cui non funziona è quasi sempre la stessa: il tempo allocato. Se ai key user non viene riservato tempo esplicito per supportare i colleghi, il ruolo si svuota nel giro di settimane perché le priorità operative prevalgono.