Perché falliscono i progetti AI

I progetti AI falliscono raramente per limiti della tecnologia. Falliscono per ragioni organizzative prevedibili, e il fallimento quasi mai è un evento: è un degrado lento che nessuno dichiara.

Prima qualche caso viene gestito «a parte». Poi le persone tornano al metodo vecchio per comodità. Infine il sistema resta acceso e non lo usa nessuno. Nessuno decide di fermarlo, semplicemente smette di contare.

Le sei cause, in ordine di frequenza

1. Nessun referente interno con tempo. Il progetto ha bisogno di qualcuno che risponda alle domande del fornitore, provi il sistema, raccolga le segnalazioni. Se quella persona ha già un lavoro a tempo pieno e nessuno le ha liberato ore, il progetto si allunga e il risultato somiglia a quello che il fornitore ha immaginato.

2. Perimetro troppo largo. Dieci casi d'uso invece di due. Il sistema arriva tardi, copre male molte situazioni, e la prima impressione — quella che conta — è di uno strumento che sbaglia spesso.

3. Nessuna misura di partenza. A fine progetto la valutazione è un'opinione. Anche un buon risultato non è dimostrabile, e l'argomento si chiude con un «non è servito granché».

4. Il processo era confuso. L'AI non mette ordine: amplifica quello che trova. Automatizzare un processo con regole incerte produce un sistema con comportamenti incerti.

5. Nessuno lo mantiene. Il gestionale si aggiorna, arrivano casi nuovi, un'integrazione smette di funzionare. Senza manutenzione il sistema si degrada in mesi — vedi quanto costa mantenere un sistema AI.

6. Aspettative sbagliate. Presentato come trasformazione dell'azienda, un progetto che migliora un processo del quaranta per cento viene percepito come deludente.

Il degrado lento, riconoscerlo

Il quarto punto della colonna sinistra è il più insidioso: quando le segnalazioni smettono di arrivare non significa che va tutto bene. Significa quasi sempre che le persone hanno smesso di aspettarsi che vengano risolte.

Come si previene, causa per causa

1. Referente: nome, cognome e ore liberate prima dell'inizio.
2. Perimetro: due casi d'uso nella prima versione, scritti.
3. Misura: un mese di dati prima di toccare qualsiasi cosa.
4. Processo: se è confuso, prima si sistema e poi si automatizza.
5. Manutenzione: a budget dal primo giorno, con un responsabile.
6. Aspettative: presentarlo come «questo processo funzionerà meglio».

Nessuna di queste sei richiede competenze tecniche. Sono tutte decisioni organizzative prese prima dell'inizio, ed è per questo che la maggior parte dei fallimenti è prevenibile a costo zero.

Esempi pratici

Progetto tecnicamente riuscito, mai adottato. Sistema costruito bene, consegnato, nessuno formato, nessun referente. Alla prima difficoltà le persone sono tornate al metodo precedente. Costo: l'intero investimento.

Perimetro allargato in corsa. Partito con due casi d'uso, arrivato a sette per richieste successive. Tempi triplicati, qualità media scesa, prima impressione negativa. Il progetto è stato giudicato fallito benché i due casi originali funzionassero bene.

Degrado silenzioso. Automazione documentale funzionante per un anno. Poi il fornitore del gestionale ha cambiato un formato di esportazione, le eccezioni sono cresciute, nessuno le ha guardate, e in tre mesi l'amministrazione era tornata a inserire a mano.

Il fallimento che non sembra tale

C'è una categoria di progetti che nessuno considera fallita e che ha comunque prodotto zero valore: quelli che funzionano perfettamente su un processo che non serviva automatizzare.

Il sistema è tecnicamente ottimo, le persone lo usano, le metriche di qualità sono eccellenti. Semplicemente il processo automatizzato accadeva dieci volte al mese e il risparmio è irrilevante rispetto a quanto è costato.

È un fallimento di selezione, non di esecuzione, e si previene esclusivamente con la misura di partenza: se avessi contato quante volte accadeva e quanto costava, avresti scelto un altro processo.

Cosa fare quando un progetto sta andando male

Riconoscerlo presto è metà del lavoro. L'altra metà è sapere cosa fare, e le opzioni sono tre.

Ridurre il perimetro. Se il sistema funziona su una parte dei casi e non su altri, tenere la parte che funziona è quasi sempre meglio che continuare a inseguire la copertura totale.

Sistemare il processo a monte. Se il problema è che il processo è confuso, nessun intervento sul sistema lo risolverà. È il momento di fermarsi e affrontare la causa.

Chiudere. Se il processo scelto non aveva volumi o le eccezioni dominano, chiudere presto costa molto meno che trascinare. E l'informazione acquisita rende migliore il progetto successivo.

Quello che non funziona quasi mai è la quarta opzione, che è anche la più praticata: aggiungere funzioni sperando che l'adozione migliori.

Le cause a colpo d'occhio

Nessuna riga della colonna di destra richiede competenze tecniche o budget aggiuntivo.

Errori da evitare

• Nessun referente con tempo reale. Causa numero uno.
• Allargare il perimetro in corsa. Sposta il bersaglio e allunga tutto.
• Automatizzare processi confusi. Il risultato viene attribuito all'AI.
• Non guardare più i numeri dopo il rilascio. Il degrado passa inosservato.
• Ignorare «lo facciamo ancora a mano». È il segnale precoce più affidabile.
• Promettere trasformazioni. Garantisce delusione.

Come applicarlo in azienda

Prima di iniziare, rispondi onestamente a tre domande: chi lo seguirà e con quante ore, quanti casi d'uso copre la prima versione, e qual è il numero di partenza. Se una delle tre non ha risposta, il progetto ha già una causa di fallimento attiva.

Dopo il rilascio, fai una sola domanda ogni mese a chi ci lavora: «in quali casi lo fai ancora a mano?». È la diagnostica più economica ed efficace che esista, e intercetta il degrado quando costa poco correggerlo.

Il metodo completo è in progetto AI: come iniziare, le metriche in KPI di un progetto AI.

Come si comunica un progetto chiuso

Chiudere un progetto che non ha funzionato è una decisione sana, e il modo in cui viene comunicata determina se l'azienda potrà riprovare.

Se viene raccontato come «l'AI non funziona», l'argomento si chiude per anni e anche i progetti che avrebbero senso non partiranno. Se viene raccontato come «questo processo non era il candidato giusto, ecco cosa abbiamo imparato», resta la possibilità di riprovare meglio.

La differenza non è retorica: nella prima versione la causa è la tecnologia, nella seconda è una scelta correggibile. E nella quasi totalità dei casi la seconda versione è anche quella vera.

Il metodo per scegliere meglio il candidato successivo è in progetto AI: come iniziare.

Vale la pena aggiungere una considerazione sui tempi: quasi tutti i fallimenti descritti diventano visibili tra il terzo e il sesto mese dal rilascio. È la finestra in cui l'entusiasmo iniziale è passato, le eccezioni sono emerse e le abitudini si stanno consolidando in un senso o nell'altro. Presidiare quella finestra con qualche minuto di attenzione al mese è l'intervento con il miglior rapporto tra sforzo e progetti salvati, e non richiede nulla di più che guardare i numeri e fare una domanda alle persone.

Conclusione

I progetti AI falliscono per motivi organizzativi e prevedibili: nessuno che li segua, perimetro troppo largo, nessuna misura, processi confusi, nessuna manutenzione, aspettative gonfiate.

Nessuna di queste cause è tecnologica, e tutte si prevengono con decisioni prese prima. La più efficace è anche la più semplice: liberare tempo vero a una persona che conosce il lavoro, e ascoltarla quando dice che qualcosa non funziona.

Se vuoi capire quali processi della tua azienda possono essere automatizzati con l'AI, Giallo Studio può aiutarti a trasformare il problema in un workflow reale.

Vale infine la pena dire che un progetto chiuso presto non è un fallimento costoso: è il modo più economico di scoprire che quel processo non era il candidato giusto. Il fallimento costoso è quello che si trascina per un anno perché nessuno ha voluto prendere la decisione, come descritto in progetto pilota AI.

Schema consigliato: Article + FAQPage + BreadcrumbList