Fare marcia indietro sull’IA: Storie vere dai leader
Lezioni sull’IA: Molti leader trascurano le lezioni preziose di progetti IA falliti o sospesi, mettendo in luce indicazioni cruciali.
Fermarsi prima di forzare: Le aziende spesso traggono vantaggio dal mettere in pausa le iniziative sull’IA per stabilire processi e qualità dei dati solidi.
Prima manuale: L’automazione dovrebbe essere successiva all’esecuzione manuale, così da garantire che i processi siano ben definiti e compresi.
Misurare l’impatto: La chiave del successo è valutare processi attuali e il potenziale impatto dell’IA prima dell’implementazione.
Importanza della documentazione: Una documentazione efficace deve raccogliere non solo i processi, ma anche le motivazioni dietro scelte ed eccezioni.
La maggior parte delle storie sull’adozione dell’AI viene raccontata dal podio dei vincitori. Sono molti meno i leader che parlano del momento in cui hanno deciso di fermarsi—dell’automazione annullata, del lancio bloccato, del progetto pilota che ha dovuto essere ricostruito da zero. Ma spesso sono proprio queste le storie dove vivono le vere lezioni.
Abbiamo chiesto a tre esperti che ci sono passati: cosa è stato annullato, perché, e cosa farebbero diversamente? Le loro risposte convergono verso un tema sorprendentemente coerente: quasi mai il problema è l’AI stessa.
Quando la scelta più intelligente è fermarsi, non andare avanti a tutti i costi
Per la maggior parte delle aziende, rinunciare totalmente a un investimento in AI non è realistico una volta che i soldi sono stati spesi. Tejinder, Senior Manager presso Deloitte Consulting, afferma che un annullamento totale non era in discussione dato l’investimento già effettuato—ma una pausa deliberata sì. Quando i risultati non erano all’altezza, il suo team si è fatto indietro e ha “guardato prima alle basi”, chiedendosi se i processi fondamentali fossero stati definiti, se “la qualità dei dati” fosse “buona” e se i responsabili della pianificazione avessero davvero compreso il ruolo degli agenti rispetto al proprio. “Penso che una volta risposto a queste domande, la riattivazione sia stata sensata”, dice.
Sblocca Gratis
Crea un account gratuito per terminare la lettura di questo articolo e unirti a una community di leader innovativi che accedono a strumenti, playbook e approfondimenti per prosperare nell’era dell’AI.
Have an account? Log In
Priyanka Dave, PhD, Responsabile Upskilling e Learning Process Owner presso la Oregon State University, ha visto questo schema ripetersi più volte nel tempo. “Ho osservato diverse organizzazioni scegliere deliberatamente di rimandare l’espansione di iniziative AI dopo aver realizzato di non essere ancora pronte operativamente.” In questi casi, il passo indietro non è stato un fallimento—ma un nuovo indirizzo. “Anziché espandere subito l’AI, la leadership ha spostato l’attenzione verso il rafforzamento delle fondamenta organizzative”, spiega Dave. Questo ha significato che “le organizzazioni hanno investito nel documentare i processi aziendali, standardizzare i flussi di lavoro, migliorare la governance dei dati e potenziare le capacità dei dipendenti tramite formazione strutturata e change management.”
Anziché espandere subito l’AI, la leadership ha spostato l’attenzione verso il rafforzamento delle fondamenta organizzative.
Non automatizzare ciò che non hai ancora fatto manualmente
A volte fare un passo indietro significa annullare del tutto un progetto—e scoprire che era la scelta giusta sin dall’inizio. Jaime Gil Martinez, fondatore e Principal Consultant di Swift Ops Solutions, l’ha imparato a sue spese. “Una volta ho creato un’automazione per produrre materiali di marketing per un cliente che non aveva mai gestito il processo manualmente”, ricorda. “Poiché era nuovo anche per loro, abbiamo entrambi pensato che valesse la pena costruirlo subito in modo automatizzato. Sulla carta aveva senso. Col senno di poi, è stato un errore da principianti.”
Il sistema funzionava tecnicamente. “L’automazione funzionava”, dice Gil Martinez. “Il problema era che ogni volta che serviva un risultato, qualcosa andava rivisto o modificato (un target diverso, un formato diverso, un layout diverso), quindi continuavo a ricostruirlo. Dopo alcuni cicli, era chiaro—stavo automatizzando un processo che nessuno aveva ancora definito.”
Dopo alcuni cicli [di modifiche] era chiaro che stavo automatizzando un processo che nessuno aveva ancora definito.
La soluzione è stata tornare indietro. “Abbiamo quindi annullato il progetto e ricominciato a produrre i materiali a mano”, racconta. “Ed è stato quello il punto: ogni iterazione manuale ci ha dato ciò che ci mancava, ovvero esempi di riferimento e una visione chiara di cosa variava e cosa no. Dopo abbiamo ripreso l’automazione, e quei contenuti manuali sono diventati la knowledge base che abbiamo consegnato all’AI.” Da questa esperienza ha ricavato una regola che ora applica nella sua azienda e con i clienti: “non automatizzare niente finché non l’hai fatto manualmente almeno tre volte. Solo allora puoi iniziare a prenderlo in considerazione.”
Il passo che tutti saltano: misurare prima di costruire
Chiedi a Gil Martinez cosa manca alla maggior parte dei piani di adozione dell’AI, e la sua risposta è immediata: “Misurare prima di costruire. Alla maggior parte delle aziende mancano due numeri nel momento in cui iniziano: quanto è buono o cattivo il loro processo attuale e quale impatto l’AI potrebbe realisticamente avere su di esso. Senza entrambi, non puoi sapere quanto sia stata efficace la tua implementazione o se il costo sia stato giustificato.”
Lui cita una clinica sanitaria che voleva automatizzare la pianificazione per oltre 100 pazienti. “Non sapevano quanto tempo impiegassero, solo che era dispendioso in termini di tempo e frustrante,” dice. “E se non sai quanto tempo impieghi, non sai quanto ti costa.” Quindi, prima di costruire qualsiasi cosa, il suo primo passo è stato calcolare le ore consumate dalla pianificazione e il valore finanziario di quelle ore. “Questo ci ha fornito il punto di partenza: due settimane di lavoro manuale completo. L’automazione lo ha ridotto a un giorno di lavoro assistito dall’AI, a un costo inferiore rispetto alla loro spesa attuale equivalente.” Con quei numeri in mano, “la decisione si è presa da sola.”
Dave individua un’assenza diversa ma altrettanto critica: la prontezza non riguarda solo la tecnologia. “Il passaggio che vedo le organizzazioni trascurare più frequentemente è valutare la capacità della forza lavoro prima di implementare l’AI,” dice. E raramente le lacune riguardano la formazione sugli strumenti. In diverse valutazioni delle competenze, “le analisi hanno costantemente rivelato che i maggiori divari riguardavano il pensiero analitico, il pensiero critico, la literacy sui dati, la comunicazione consulenziale e la risoluzione dei problemi.” La sua conclusione: “La prontezza tecnologica e quella della forza lavoro sono sfide diverse. Un’adozione sostenibile dell’AI richiede entrambe.”
Quando l’AI Viene Applicata a un Processo che non è Pronto
Cosa si rompe veramente quando l’AI viene sovrapposta a un processo immaturo? Tejinder l’ha visto in prima persona quando “l’AI è stata integrata in un processo aziendale (elaborazione e allocazione degli ordini) che non era sufficientemente maturo” — il risultato è stata una soluzione piena di bug. Ma è chiaro su dove sia stato il problema: “Credo che l’AI non sia stata il problema qui”, dice, indicando invece la maturità del processo, problemi con i dati master, lacune nei requisiti non chiuse e test inadeguati.
L’AI è stata integrata in un processo aziendale (elaborazione e allocazioni degli ordini) che non era sufficientemente maturo.
Dave descrive la stessa dinamica emersa dalle sue analisi: reparti diversi che eseguono lo stesso lavoro in modo diverso, documentazione incompleta ed eccezioni che esistono solo nella testa dei dipendenti. “La preoccupazione era che l’AI avrebbe semplicemente replicato pratiche incoerenti in tutta l’organizzazione,” dice. È la conseguenza di un principio a cui torna spesso: “L’AI non risolve i problemi organizzativi. Amplifica i sistemi esistenti. Se i processi sono incoerenti o poco documentati, l’AI spesso amplierà quelle incoerenze invece di migliorarle.” Morale della favola, a suo dire: “La lezione ricorrente era che le organizzazioni dovrebbero migliorare i processi prima di tentare di automatizzarli.”
Se i processi sono incoerenti o poco documentati, l’AI spesso amplierà quelle incoerenze invece di migliorarle.
Gil Martinez porta la sua esperienza diretta: un’applicazione di generazione dei lead che “fallì clamorosamente al primo tentativo.” Il progetto passò da semi-manuale a completamente automatico senza requisiti definiti né test. “Il mio errore fu presumere che l’AI avrebbe capito da sola parte della logica, perché sembrava ovvia e semplice”, ammette. La situazione poi è peggiorata. “Il codice divenne ingestibile e totalmente gestito dall’AI, fino al punto in cui non potevo tornare a una milestone sicura. È stato il momento in cui mi sono reso conto che era rotto a livello strutturale, non solo pieno di bug.”
La soluzione ha richiesto un reset totale. “La correzione è stata dolorosa quanto ovvia: ricominciare da capo,” dice. “Questa volta ho descritto ogni requisito e relativo test, costruito in modo incrementale e dato istruzioni precise all’AI per registrare successi e fallimenti insieme al giusto controllo delle versioni.” Il secondo tentativo, più disciplinato, “ha richiesto circa la metà del tempo che avevo sprecato nel primo per arrivare a una soluzione funzionante e pronto per la produzione.”
Come Deve Essere una Buona Documentazione per l’AI
Sotto tutte e tre le esperienze c’è la stessa soluzione: documentazione che cattura come avviene realmente il lavoro. Per Dave, significa andare oltre le liste di attività. “Una buona documentazione di processo spiega non solo cosa fanno le persone, ma anche perché prendono determinate decisioni,” dice. E spesso il materiale più prezioso è proprio quello che non viene mai scritto. “Uno degli errori più comuni che le organizzazioni compiono è documentare solo il flusso di lavoro standard. Le conoscenze organizzative più importanti spesso esistono nelle eccezioni, nelle decisioni discrezionali e nelle valutazioni contestuali fatte dai dipendenti più esperti.”
Gil Martinez lo presenta attraverso una lente che i project manager riconosceranno sempre di più: “Una buona documentazione dei processi rispecchia la prompt engineering. Gli stessi elementi che abbiamo imparato a fornire all’IA in un prompt (ruolo, contesto, compito, istruzioni, vincoli) dovrebbero comparire a livello di progetto.” Questo cambiamento ha implicazioni su come i professionisti impiegano il loro tempo. “Il tempo di esecuzione umano sta scomparendo, delegato all’IA, quindi il nostro focus deve spostarsi sulla pianificazione e sulla validazione dei risultati. Dobbiamo comportarci come manager dell’IA.”
Conclusione: La Sequenza è la Strategia
Nessuno di questi leader si pente di aver investito nell’IA. Ciò di cui si pentono — o che hanno visto altri rimpiangere — è l’ordine delle operazioni. Tejinder lo riassume così: “L’adozione dell’IA in azienda fallisce quando il modello viene implementato prima dei fondamentali operativi. La sequenza corretta è prima maturità del processo, qualità dei dati e chiarezza dei ruoli. Poi l’IA. Quando le organizzazioni invertono quest’ordine, danno la colpa all’IA, ma il problema sottostante è quasi sempre l’ambiente in cui l’IA è stata introdotta.” Tornare indietro, a quanto pare, non è il fallimento. Il vero fallimento è implementare prima di essere pronti.”
Vuoi altri approfondimenti come questi? Registrati gratuitamente a un account DPM per ascoltare altri esperti come questi.