Il progetto è andato live. Non è la stessa cosa di "ha funzionato".

Il nuovo gestionale è andato live nei tempi previsti. Il fornitore ha chiuso il progetto, la formazione iniziale è stata erogata, il sistema vecchio è stato spento. In riunione qualcuno lo dichiara «un successo». Nessuno, in quella riunione, ha controllato se le persone lo stanno davvero usando per lavorare diversamente da prima — solo se il sistema è acceso.

È probabilmente la forma più comune di autoinganno nei progetti di digitalizzazione delle PMI italiane: il criterio informale di successo è quasi sempre «il fornitore ha chiuso il progetto», non «i dati vengono usati per decidere diversamente». E finché nessuno lo mette in discussione, quel criterio basta a se stesso.

La metrica che inganna più della sua assenza

Un'analisi di Prosci, pubblicata il 27 agosto 2026, mette un numero su questo errore — e il numero è controintuitivo. Secondo i dati Prosci Research, le organizzazioni che misurano il successo di un progetto ERP con le metriche sbagliate — ore di formazione erogate, milestone tecniche raggiunte, «il sistema è andato live» — hanno un tasso di successo del 7%. Quelle che non misurano affatto l'adozione arrivano al 26%. Quelle che usano le metriche giuste hanno 2,5 volte più probabilità di superare le aspettative della trasformazione.

Cioè: misurare le cose sbagliate è peggio che non misurare niente. Il dato è di Prosci Research e non è ulteriormente scomposto per campione nella fonte consultata — va preso come indicazione di un editore specializzato in change management, non come statistica di settore indipendente, ma il meccanismo che descrive si riconosce a occhio in qualunque azienda che abbia fatto un investimento del genere.

Il motivo per cui l'errore è così diffuso non è la pigrizia. È che avere una metrica, qualunque metrica, dà la sensazione di avere il controllo. Ed è proprio quella sensazione a impedire di andare a cercare un problema che si pensa di aver già misurato — nessuno riapre un fascicolo che considera chiuso.

Cosa costa, davvero, dichiarare il successo troppo presto

Il primo costo è che il progetto smette di essere seguito. Formalmente è andato bene, quindi nessuno torna a controllarlo — ed è esattamente nel momento in cui servirebbe più attenzione che l'attenzione si esaurisce, perché tutti sono già passati al progetto successivo.

Il secondo è più silenzioso e più caro: l'investimento tecnico è stato pagato per intero, ma rende solo in parte, e quella parte mancante non compare in nessun bilancio. Non è un costo aggiuntivo che qualcuno segnala a fine anno. È un ricavo mancato che nessuno registra come tale, perché non esiste una riga apposita per «quello che il sistema avrebbe dovuto far risparmiare e non ha risparmiato».

Il terzo è che l'errore si ripete. Se il criterio di successo del prossimo progetto resta «è andato live», la stessa illusione si riproduce identica alla volta successiva, e a quella dopo ancora. L'azienda accumula progetti «riusciti» sulla carta e non impara mai a distinguere un'implementazione che ha cambiato il modo di lavorare da una che si è semplicemente conclusa.

Le tre domande da mettere al posto di «è live»

Prosci propone tre indicatori alternativi, costruiti sul proprio modello di adozione ADKAR: velocità di adozione, utilizzo effettivo, proficiency. Tradotti in una domanda ciascuno, da porre prima di dichiarare concluso un progetto — non dopo un anno, quando ormai il sistema vecchio è tornato a essere quello vero:

• Con che velocità le persone coinvolte sono diventate autonome nell'usarlo, e non solo capaci di seguire una procedura guidata con qualcuno accanto?
• Lo stanno usando davvero, o mantengono in parallelo — «per sicurezza», «finché non siamo sicuri» — il metodo di prima?
• Quanto bene, non solo quanto spesso, lo usano per il lavoro che dovrebbe effettivamente supportare?

La terza è quella che quasi nessuno si fa. Un tasso di accesso alto dice che le persone aprono il programma, non che sanno chiudere un mese, gestire un'eccezione o produrre un report corretto senza chiedere aiuto a chi conosceva la procedura vecchia.

Queste tre verifiche vanno pianificate con una scadenza precisa — un mese dopo il lancio, tre mesi dopo — non lasciate a un controllo informale e occasionale che nella pratica non arriva mai, perché nessuno lo ha messo in calendario. E se la verifica mostra un uso parziale o parallelo, va trattata come un problema del progetto, non come un dettaglio da sistemare più avanti: è esattamente il segnale che il criterio «è live» avrebbe nascosto.

Un caso tipico

Un'azienda di distribuzione di componenti industriali introduce un nuovo CRM per la gestione delle offerte commerciali. Il progetto chiude nei tempi, il fornitore fattura l'ultima tranche, i tre commerciali seguono la formazione e sanno inserire un'offerta nel sistema. In riunione, il progetto viene archiviato come concluso con successo.

Sei mesi dopo, il direttore commerciale scopre — controllando un margine che non tornava — che due dei tre commerciali inseriscono l'offerta nel CRM solo dopo averla chiusa a voce col cliente, e continuano a fare i conti veri durante la trattativa sul proprio file Excel personale, quello che usavano prima. Il CRM registra l'esito. Non registra il percorso. Le informazioni che il sistema avrebbe dovuto produrre — quante offerte si perdono e perché, su quali margini si tratta davvero, quanto tempo passa fra preventivo e chiusura — non sono mai esistite, anche se il sistema, tecnicamente, «funziona» da sei mesi.

Nessuno, dopo il lancio, aveva mai chiesto se il sistema veniva usato al posto del metodo precedente o solo insieme ad esso. Se lo avessero chiesto a tre mesi, lo avrebbero scoperto con tre mesi di margine reale in meno perso, non con sei.

È un problema imparentato, ma distinto, con quello di chi scopre che il gestionale nuovo non lo usa più nessuno: lì il sistema vecchio riprende apertamente il sopravvento, e la resistenza si vede. Qui il sistema nuovo resta in vita solo per le apparenze — è la versione più difficile da individuare, perché da fuori assomiglia esattamente a un successo.

Il bersaglio va dichiarato prima, non improvvisato dopo

C'è un dettaglio pratico che fa la differenza fra una metrica utile e una che si limita a esistere: la soglia va scritta prima del lancio, non cercata a posteriori per giustificare quello che è successo. Non «monitoriamo l'utilizzo del CRM», ma «entro trenta giorni dal lancio, l'80% dei commercialisti chiude un'offerta senza uscire dal sistema per fare i conti a parte». La prima frase non impegna nessuno a niente. La seconda si può verificare il trentunesimo giorno, e se non regge lo si scopre subito, non sei mesi dopo controllando un margine che non torna.

Non servono venti indicatori. Tre o quattro, ciascuno con un responsabile e una soglia sotto cui scatta un intervento — più formazione mirata, affiancamento, o la revisione di un passaggio del processo che si è rivelato più scomodo del previsto — bastano a rendere la misura uno strumento di decisione invece che un rendiconto da allegare al progetto chiuso. È la differenza fra sapere che cosa è successo e sapere cosa fare di conseguenza, e solo la seconda cosa vale il tempo che costa misurarla.

Da dove ripartire

Prendi l'ultimo progetto tecnologico che in azienda avete dichiarato concluso con successo. Prova a rispondere, con dati reali e non con un'impressione raccolta al volo, a una sola domanda: le persone che dovrebbero usarlo lo stanno usando al posto del metodo precedente, o insieme ad esso?

Se non lo sai, non hai un progetto riuscito. Hai un progetto che nessuno ha ancora verificato — e la differenza, sul conto economico dell'anno prossimo, si vede.

Come funziona il metodo TIMONE →