C’è una categoria di fallimento tecnologico di cui non si parla quasi mai. Non è il progetto cancellato a metà. Non è il sistema che non funziona. È il sistema che funziona, è stato consegnato, è in produzione — e l’organizzazione continua a lavorare esattamente come prima.
Le licenze vengono rinnovate ogni anno. Gli aggiornamenti vengono applicati. E nei reparti, le persone usano il foglio Excel che usavano prima, il file condiviso su Teams, la procedura informale consolidata negli anni.
Il sistema non è fallito. È semplicemente irrilevante.
Perché succede
La spiegazione standard è il cambiamento: le persone resistono al nuovo, serve più formazione, serve un piano di change management. Tutto vero. Tutto parziale.
La resistenza all’adozione non nasce dal caso. Nasce da un’esperienza concreta e razionale: il sistema nuovo è più complicato del metodo che sostituisce, richiede più passaggi per fare la stessa cosa, non rispecchia il modo in cui il lavoro è organizzato davvero. Le persone non sono irrazionali quando lo evitano. Stanno ottimizzando il loro tempo.
Il problema non è la resistenza al cambiamento. È che il sistema è stato progettato senza capire abbastanza i processi che doveva supportare.
Il momento in cui si decide tutto
Ogni sistema software nasce da una fase di analisi dei requisiti. È il momento in cui si definisce quello che il sistema dovrà fare.
Nella maggior parte dei progetti, questa fase viene condotta con le figure che hanno commissionato il lavoro — i responsabili, chi ha il budget — non con chi il sistema lo userà ogni giorno. Non sui processi reali: eccezioni, varianti e casi limite che esistono in ogni azienda ma non compaiono mai nelle slide di presentazione.
Il risultato è un sistema che risponde ai requisiti dichiarati. Non a quelli reali.
Succede allora che il gestionale preveda tre livelli di approvazione formale, mentre in azienda le decisioni operative vengono prese in dieci minuti via Teams tra due responsabili. Che il flusso di inserimento ordini richieda sei campi obbligatori di cui quattro nessuno sa cosa significhino. Che il modulo di reportistica produca dati che nessuno ha mai chiesto, nel formato sbagliato, con tre giorni di ritardo.
A quel punto l’adozione è già compromessa. Non perché le persone non vogliano cambiare, ma perché il sistema non è abbastanza utile da giustificare il costo del cambiamento.
Il costo che non appare nei report
Un’organizzazione che mantiene in parallelo il sistema ufficiale e i metodi informali che nessuno ha ufficialmente autorizzato paga due volte: paga il sistema e paga l’inefficienza che il sistema avrebbe dovuto eliminare. I dati rimangono duplicati e incoerenti. I processi restano non tracciati. Le decisioni vengono prese su informazioni parziali.
E quando si vuole integrare AI o automazione su quei processi, si scopre che non c’è nulla di strutturato su cui costruire. Il sistema inutilizzato non è un problema isolato. È il segnale che l’organizzazione ha pagato per risolvere un problema che non ha risolto — e ripartirà daccapo, con meno budget e meno fiducia interna.
Come si evita
Non con più formazione. Non con campagne di comunicazione interna.
Con una fase di analisi che coinvolge chi il sistema lo userà davvero, che mappa i processi come esistono — non come dovrebbero esistere in teoria — e che verifica la coerenza tra il sistema progettato e il lavoro reale prima che lo sviluppo inizi.
È una fase che richiede tempo. Molto meno del tempo che richiede gestire per anni un sistema che nessuno usa.
Un software entra davvero in un’organizzazione solo quando smette di essere percepito come un sistema imposto e diventa il modo più semplice per lavorare. Progettarlo così non è un dettaglio. È il punto di partenza.
