Il sistema più caro è quello che le vostre persone non usano.

Situazione tipo. Un'azienda firma il contratto per un nuovo sistema. Analisi, migrazione dei dati, test, formazione, consegna. Sei mesi dopo il commerciale invia l'offerta dal proprio foglio Excel, la produzione tiene il piano su un disco condiviso e l'amministrazione esporta i dati per elaborarli altrove.

Il sistema intanto funziona, le integrazioni trasferiscono i dati, il fornitore ha rispettato le specifiche. Eppure si tratta di un fallimento, che non si manifesta come un guasto, ma come silenzio.

L'implementazione è il momento in cui il software funziona. L'adozione è lo stato in cui l'organizzazione lo usa. Tra questi due punti si trova la maggior parte del valore che le aziende perdono, e nel budget raramente esiste una voce dedicata.

Perché dopo sei mesi le persone lavorano ancora in Excel

Il giorno del go live Excel batte il nuovo sistema su tutto ciò che conta per l'utente: costo di apprendimento nullo, feedback immediato, struttura libera, errore senza traccia. Il nuovo sistema offre dati consolidati, tracciabilità e visibilità per la direzione. Sono vantaggi dell'azienda, non della persona che entro sera deve inviare gli ordini.

Lo strumento diagnostico più utile è quindi una sola frase: se un dipendente ha bisogno di Excel accanto al sistema per riuscire a usare il sistema, il problema potrebbe non essere il dipendente. Il foglio ombra non nasce dalla pigrizia, mantenerlo costa tempo e comporta rischi. Chi lo tiene comunque sta affermando che il sistema da solo è più caro del sistema più un foglio in aggiunta. Ogni file di questo tipo è un reclamo formalizzato sull'interfaccia e la ricerca utente più economica che l'azienda abbia a disposizione.

Fred Davis, nel lavoro del 1989 su cui poggia il Technology Acceptance Model, scrive che i guadagni di performance sono spesso ostacolati dalla riluttanza degli utenti ad accettare e utilizzare i sistemi disponibili. Nei suoi due studi con 152 utenti la facilità d'uso percepita risultava una probabile causa dell'utilità percepita: ciò che si governa con fatica non sembra utile. Il campione è ridotto e il lavoro è datato, non è una previsione, solo la direzione della relazione.

L'adozione è il denominatore del ritorno

Il costo è fisso e noto il giorno della firma. Il beneficio nasce solo quando qualcuno lavora davvero nel sistema. Un sistema con adozione zero ha un ritorno zero, a prescindere dal prezzo. Un sistema adottato a metà ha un ritorno peggiore della metà: l'azienda paga le licenze e insieme la manutenzione dei processi ombra, e non ha un'unica fonte di verità.

Lo stesso quadro emerge dall'ERP Report 2026 di Panorama Consulting Group, un'indagine su 170 organizzazioni con un fatturato annuo mediano di 200,5 milioni di dollari. Secondo il report i problemi con l'ERP sono legati più spesso a una proprietà dei processi poco chiara, a una debole adozione da parte degli utenti e alla mancanza di allineamento sugli obiettivi. La vera sfida non è la scelta del fornitore, ma fare in modo che dopo il rilascio l'organizzazione funzioni diversamente.

Il prezzo di quel silenzio si calcola con un prodotto semplice: tempo per frequenza per numero di persone per costo. Prendete un'operazione che nel nuovo sistema richiede più tempo di prima e moltiplicate la differenza per il numero di ripetizioni al giorno, per il numero di persone e per il costo orario. Il risultato è la cifra che l'azienda paga ogni giorno per una singola decisione di design dell'interfaccia, e allo stesso tempo il tetto di un budget ragionevole per correggerla. La stessa aritmetica l'ho analizzata nel testo su perché il buon design non è decorazione, ma il modo in cui un'azienda risparmia tempo e denaro.

Perché si è tollerato a lungo che il software interno fosse scadente

Il software consumer combatte per ogni clic, perché l'utente può andarsene. Il software interno ha un utente prigioniero e viene comprato da qualcuno che non ci lavora. I criteri di scelta sono la matrice funzionale, il prezzo, le referenze e le integrazioni. Nessuno inserisce nella tabella una riga su quanto tempo impiega un neoassunto a inserire il primo ordine, e il fornitore ottimizza ciò che viene valutato.

Nielsen Norman Group descrive le applicazioni aziendali complesse come strumenti per obiettivi non strutturati di professionisti altamente formati, che investono nel lavoro molta attenzione e molto tempo e hanno quindi bisogno di un annullamento affidabile e di un recupero dagli errori. Ricorda anche il paradosso dell'utente attivo: le persone iniziano a usare una cosa prima di provare a capirla. È un argomento contro la formazione come strumento principale di adozione.

Change management, formazione e carico cognitivo

Il change management prepara l'organizzazione a cambiare il modo di lavorare, non è una mail collettiva e un corso di due ore prima dell'avvio. Prosci, in uno studio con oltre 2.600 professionisti, ha correlato la qualità della gestione del cambiamento con il raggiungimento degli obiettivi di progetto: con un programma eccellente l'88% dei progetti ha raggiunto o superato gli obiettivi, con un programma debole il 13%. È una correlazione, non un esperimento, ma quel divario è troppo ampio per liquidarlo. Secondo Panorama Consulting Group, intanto, meno di un quarto delle organizzazioni ha dichiarato una forte attenzione alla gestione del cambiamento.

L'altra metà del problema è il carico cognitivo, cioè la quantità di risorse mentali necessarie per governare il sistema. Nielsen Norman Group lo divide in intrinseco, che appartiene al compito, ed estraneo, che consuma attenzione senza aiutare a comprendere il contenuto. Nei sistemi interni di carico estraneo ce n'è parecchio: schermate sovraccariche, campi privi di senso per quel ruolo, termini presi dal modello dati al posto di quelli aziendali. La formazione non lo elimina, l'azienda lo paga a ogni nuova persona. Il design lo elimina una volta sola.

Harvard Business Review, in un testo di ricercatori di Gartner, riporta che nel 2022 il dipendente medio ha attraversato dieci cambiamenti aziendali pianificati contro i due del 2016, e la sostituzione di un sistema obsoleto è uno dei tipi di cambiamento citati. Il vostro progetto non compete con il non fare nulla, ma con altri nove cambiamenti.

Resistenza al cambiamento o software legittimamente scadente

Qui le aziende commettono l'errore più costoso del progetto. Quando le persone non usano il sistema, la direzione lo interpreta come resistenza al cambiamento e aggiunge pressione e altra formazione. Se il software è davvero scadente, la pressione non aumenta l'adozione, sposta soltanto i fogli ombra fuori dalla vista e l'azienda perde anche l'informazione sul problema. Distinguere le due situazioni, del resto, non è costoso.

• Dove è concentrata la resistenza. Se si distribuisce in modo sottile su tutta l'azienda, si tratta piuttosto del cambiamento. Se sta in un solo ruolo, si tratta del design: è proprio il suo flusso di lavoro che il sistema non supporta.
• Come suona l'obiezione. «Non lo voglio» è un atteggiamento. «Non so dove registrare la commessa quando il cliente paga con acconto e si fattura a una terza società» è una segnalazione di errore.
• Chi rifiuta. Se a tornare a Excel sono le vostre persone più performanti, cioè quelle che da un'accelerazione guadagnerebbero di più, l'ipotesi dell'atteggiamento è debole.
• Che cosa dice il tempo di esecuzione. Misurate la stessa operazione prima e dopo il rilascio. Se richiede più tempo, la resistenza è razionale.

Nielsen Norman Group aggiunge un dato controintuitivo: gli errori di disattenzione colpiscono soprattutto chi svolge il compito in modo abituale, perché nel lavoro rodato dedichiamo meno attenzione. Aggiunge anche una frase da appendere al muro di ogni riunione sui sistemi interni: se l'errore è stato così facile da commettere, la responsabilità è di chi ha progettato. L'aumento degli errori tra gli utenti esperti dopo il rilascio non è un segnale sulla competenza, ma sull'interfaccia.

Nel design servono gli utenti, non solo i loro manager

Il manager descrive il processo come dovrebbe essere. L'utente sa com'è davvero. La differenza sta nelle eccezioni: il cliente che vuole la fatturazione divisa, il fornitore che manda un PDF invece dei dati. Il flusso principale è simile ovunque, il denaro e l'attrito stanno nelle eccezioni, che il manager non gestisce e quindi non conosce.

McKinsey aggiunge un dato dalla sua indagine sulle trasformazioni digitali: quando sono i dipendenti stessi a proporre idee su dove la digitalizzazione potrebbe aiutare, gli intervistati riportano il successo 1,4 volte più spesso, e la ridefinizione di ruoli e responsabilità in linea con gli obiettivi della trasformazione aumenta di 1,5 volte la probabilità di successo. Coinvolgere le persone non è un gesto culturale, è una variabile nell'equazione.

Il metodo costa poco: mezza giornata seduti accanto a persone di ruoli diversi, osservando dove esitano e che cosa aggirano. In un workshop non emerge, con il tempo nessuno si accorge più delle scorciatoie che si è costruito.

La conseguenza onesta è spesso sgradevole per il fornitore. A volte emerge che non c'è nulla da costruire: il processo va eliminato, basta configurare meglio lo strumento che l'azienda già paga, oppure comprare due moduli in meno. Un processo marginale con pochi casi al mese deve restare in un foglio di calcolo con un titolare chiaro, perché lo sviluppo non si ripagherebbe. L'ordine dei passi non è casuale: eliminare, semplificare, automatizzare, ampliare. Lo sviluppo su misura ha senso dove il processo è un vantaggio competitivo o un collo di bottiglia, non dove esiste semplicemente un foglio. L'ho approfondito nel testo su come un'azienda è un solo prodotto e ogni processo scadente è il suo debito tecnico.

Quattro decisioni di design che determinano l'adozione

• Rivelazione progressiva (progressive disclosure). L'interfaccia mostra prima le opzioni comuni e rende accessibili quelle avanzate solo su richiesta. Jakob Nielsen la descrive come una tecnica che migliora tre delle cinque componenti dell'usabilità: apprendibilità, efficienza d'uso e tasso di errore. Aggiunge anche un secondo principio: ciò che sta nella schermata iniziale è importante per l'utente. La prima schermata è un'affermazione sulle priorità dell'azienda, e la maggior parte dei sistemi afferma che la priorità è tutto insieme.
• Valori predefiniti sensati. Un default è una decisione che l'azienda prende una volta sola, invece di farla prendere a ciascuno su ogni record. Un buon default non è un campo vuoto, ma il valore corretto più frequente. Nielsen Norman Group include qui anche il richiamo dei dati già inseriti e i nomi presi dal linguaggio aziendale, non dalle colonne del database.
• Prevenzione degli errori (error prevention). L'interfaccia va progettata perché l'errore sia impossibile, o quantomeno non facile. Nielsen Norman Group consiglia quattro strategie: vincoli utili, suggerimenti di valore, buoni default e un trattamento tollerante dell'input. Un errore intercettato all'inserimento costa un secondo, lo stesso errore in fatturazione costa ore uomo e un pezzo di relazione con il cliente.
• Interfacce per ruolo (role-based interface). Un solo database, schermate diverse. Il magazziniere non ha bisogno di vedere il margine, e ogni campo in più è un peso per tutti quelli che non lo compilano. Nielsen Norman Group avverte che ogni utente prima o poi raggiunge un plateau di efficienza, dove l'uso ulteriore non alza più le prestazioni. Oltre quel tetto lo portano gli acceleratori: scorciatoie da tastiera, macro, gesti.

Come misurare l'adozione

L'adozione non si misura con le sensazioni in riunione. Definite questa serie di metriche prima dell'avvio, per avere un termine di paragone.

• Adozione. La quota di utenti previsti che nel periodo di riferimento ha eseguito nel sistema un'operazione chiave. Non i login, il login non è lavoro.
• Utenti attivi nel tempo. Un picco dopo la formazione seguito da un calo è l'immagine di un sistema che le persone hanno provato e abbandonato.
• Tempo di esecuzione. Sulle operazioni più frequenti, misurato prima e dopo il rilascio. È l'input diretto del calcolo indicato sopra.
• Tasso di errore. Correzioni, storni, interventi manuali, documenti da rifare.
• Ticket al supporto. Non il numero, ma il rapporto tra «non so come si fa» e «il sistema non me lo permette». Il primo è onboarding, il secondo è design.
• Numero di fogli ombra. La metrica più sincera: il foglio sparisce solo quando il sistema è più veloce del foglio stesso.

Questi numeri mettono a confronto il costo di correggere l'interfaccia con il costo dell'attrito che l'azienda paga ogni mese. Con la stessa aritmetica ho confrontato quando un buon sistema interno si ripaga prima di una nuova assunzione.

La dashboard direzionale e l'interfaccia operativa non devono somigliarsi

La dashboard risponde alla domanda su come stiamo andando. Si legge e tollera qualche secondo di caricamento. L'interfaccia operativa risponde alla domanda su che cosa devo fare adesso con questo ordine. Si apre decine di volte al giorno, ci si scrive dentro, ha bisogno di velocità, tastiera e prevenzione degli errori. Se vengono progettate allo stesso modo, nascono due prodotti mediocri.

Dietro c'è anche un meccanismo politico. Nelle presentazioni si mostra la dashboard, quindi è lei a ricevere attenzione progettuale e budget. La schermata operativa non si mostra mai, benché sia proprio lì che il denaro si crea e si perde. Il budget di design dovrebbe seguire la frequenza d'uso, non la seniority di chi guarda lo schermo.

Cosa portarsi a casa

• Scrivete nelle specifiche l'obiettivo di adozione e il metodo di misurazione prima di firmare il contratto. Senza una metrica d'uso il fornitore non ha motivo di occuparsene.
• Misurate il tempo di esecuzione delle operazioni più frequenti già prima del rilascio. Senza un valore di partenza non si può dimostrare né un miglioramento né un peggioramento.
• Fate l'inventario dei fogli ombra. Ognuno è una specifica per correggere un processo o un'interfaccia, più precisa di qualsiasi cosa esca da un workshop.
• Prima del prossimo corso chiedetevi se state formando le persone al lavoro oppure ad aggirare un'interfaccia scadente. La prima è un investimento, la seconda un costo ricorrente.
• Prima di commissionare uno sviluppo, verificate se il problema non si risolva eliminando un passaggio, semplificando il processo o configurando meglio uno strumento che già pagate. La diagnosi costa meno dell'implementazione.