Ripensare l’IA: storie vere dai leader
Lezioni sull'IA: Molti leader trascurano le preziose lezioni dei progetti di IA falliti o messi in pausa, perdendo di vista insegnamenti fondamentali.
Fermarsi invece di forzare: Le aziende spesso traggono vantaggio dal mettere in pausa le iniziative di IA per consolidare i processi fondamentali e la qualità dei dati.
Prima manualmente: L'automazione dovrebbe arrivare solo dopo l'esecuzione manuale, così da garantire che i processi siano chiaramente definiti e compresi.
Misurare l'impatto: La chiave del successo consiste nel valutare i processi attuali e il potenziale impatto dell'IA prima di iniziare l'implementazione.
L'importanza della documentazione: Una documentazione efficace dovrebbe registrare non solo i processi, ma anche il ragionamento alla base delle decisioni e delle eccezioni.
La maggior parte delle storie sull'adozione dell'IA viene raccontata dal podio dei vincitori. Molti meno leader parlano del momento in cui hanno staccato la spina: l'automazione che è stata cancellata, l'implementazione che è stata sospesa, il progetto pilota che ha dovuto essere ricostruito da zero. Eppure, spesso è proprio in queste storie che si trovano le lezioni più importanti.
Abbiamo chiesto a tre esperti che ci sono passati: cosa è stato annullato, perché e cosa fareste diversamente? Le loro risposte convergono su un tema sorprendentemente coerente: il problema non è quasi mai l'IA in sé.
Quando la scelta più intelligente è fermarsi, non andare avanti
Per la maggior parte delle organizzazioni, eliminare completamente un investimento nell'IA non è realistico una volta che il denaro è stato speso. Tejinder, Responsabile senior presso Deloitte Consulting, afferma chiaramente che la rimozione completa non era un'opzione, considerando gli investimenti già effettuati, ma che una pausa deliberata lo era. Quando i risultati non erano all'altezza, il suo team ha fatto un passo indietro e ha “esaminato innanzitutto le basi”, chiedendosi se i processi sottostanti fossero stati definiti, se “la qualità dei dati” fosse “buona” e se i responsabili della pianificazione comprendessero il ruolo degli agenti rispetto al proprio. “Penso che, una volta risposte a queste domande, riattivare il progetto avesse senso”, afferma.
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 della riqualificazione e Responsabile dei processi di apprendimento presso l'Oregon State University, ha visto lo stesso schema ripetersi più volte. “Ho osservato diverse organizzazioni ritardare intenzionalmente l'espansione delle iniziative di IA dopo aver riconosciuto di non essere pronte dal punto di vista operativo.” In questi casi, il passo indietro non è stato un fallimento, ma un riorientamento. “Invece di espandere immediatamente l'IA, la leadership ha spostato la propria attenzione sul rafforzamento delle fondamenta organizzative”, spiega Dave. Ciò ha significato che “le organizzazioni hanno investito nella documentazione dei processi aziendali, nella standardizzazione dei flussi di lavoro, nel miglioramento della governance dei dati e nello sviluppo delle competenze dei dipendenti attraverso percorsi strutturati di apprendimento e gestione del cambiamento.”
Invece di espandere immediatamente l’IA, la leadership ha spostato la propria attenzione sul rafforzamento delle fondamenta organizzative.
Non automatizzare ciò che non hai fatto manualmente
A volte fare un passo indietro significa cancellare completamente un progetto e scoprire che, dopotutto, era la decisione giusta. Jaime Gil Martinez, Fondatore e Consulente principale presso Swift Ops Solutions, lo ha imparato a proprie spese. “Una volta ho creato un'automazione per produrre materiali di marketing per un cliente che non aveva mai svolto manualmente il processo”, racconta. “Poiché era una novità per lui, abbiamo pensato entrambi che fosse meglio costruirla automaticamente da zero. Sulla carta aveva senso. Col senno di poi, è stato un errore da principiante.”
Il sistema funzionava dal punto di vista tecnico. “L'automazione funzionava”, afferma Gil Martinez. “Il problema era che ogni volta che serviva un risultato, bisognava riconsiderare o modificare qualcosa (un obiettivo diverso, un formato diverso, un layout diverso), quindi continuavo a ricostruirla. Dopo alcuni cicli di questo tipo, lo schema era evidente: stavo automatizzando un processo che nessuno aveva ancora definito.”
Dopo alcuni cicli [di modifiche], era evidente che stavo automatizzando un processo che nessuno aveva ancora definito.
La soluzione è stata tornare indietro. “Così abbiamo cancellato completamente il progetto e siamo tornati a produrre i materiali a mano”, racconta. “Questo si è rivelato il punto fondamentale: ogni ciclo manuale ci ha fornito ciò che ci mancava, ovvero esempi di riferimento eccellenti e una visione chiara di ciò che variava e di ciò che non variava. In seguito abbiamo ripreso l'automazione, e quei risultati manuali sono diventati la base di conoscenza che abbiamo fornito all'IA.” L'esperienza gli ha fornito una regola che ora applica alla propria azienda e ai suoi clienti: “non automatizzare nulla finché non lo hai fatto manualmente almeno tre volte. Solo allora puoi iniziare a prenderlo in considerazione.”
Il passaggio che tutti saltano: misura prima di costruire
Chiedete a Gil Martinez cosa manca alla maggior parte dei piani di adozione dell'IA e la sua risposta è immediata: «Misurare prima di costruire. Alla partenza, alla maggior parte delle aziende mancano due numeri: quanto sia effettivamente valido o carente il processo attuale e quale impatto l'IA potrebbe realisticamente avere su di esso. Senza entrambi, non si può capire quanto sia stata efficace l'implementazione né se il costo fosse giustificato».
Indica il caso di una clinica sanitaria che voleva automatizzare la pianificazione per più di 100 pazienti. «Non sapevano quanto tempo ci stessero mettendo, sapevano solo che era un'attività dispendiosa e frustrante», racconta. «E se non sai quanto tempo richiede, non sai quanto ti costa». Prima di costruire qualsiasi cosa, quindi, il suo primo passo è stato calcolare le ore assorbite dalla pianificazione e il valore economico di quelle ore. «Questo ci ha fornito il punto di partenza: due settimane di lavoro completamente manuale. L'automazione ha ridotto il tutto a una giornata di lavoro assistito dall'IA, a un costo inferiore alla spesa equivalente attuale». Con quei numeri alla mano, «la decisione si è presa da sola».
Dave vede un'omissione diversa, ma altrettanto critica: la preparazione non riguarda solo la tecnologia. «Il passaggio che vedo trascurare più spesso dalle organizzazioni è la valutazione delle capacità della forza lavoro prima di implementare l'IA», afferma. E le lacune raramente riguardano la formazione sugli strumenti. In diverse valutazioni delle competenze, «le analisi hanno rivelato costantemente che le lacune più ampie riguardavano il pensiero analitico, il pensiero critico, la cultura dei dati, la comunicazione consulenziale e la capacità di risolvere i problemi». La sua conclusione è chiara: «La preparazione tecnologica e quella della forza lavoro sono sfide diverse. Un'adozione sostenibile dell'IA richiede entrambe».
Quando l'IA viene applicata a un processo non ancora pronto
Che cosa si rompe davvero quando l'IA viene sovrapposta a un processo immaturo? Tejinder lo ha visto in prima persona quando «l'IA è stata integrata in un processo aziendale (elaborazione degli ordini e assegnazioni) che non era sufficientemente maturo»: il risultato è stata una soluzione piena di bug. Ma è chiaro su dove ricadesse la responsabilità: «Credo che qui l'IA non fosse il problema», afferma, indicando invece la maturità del processo, i problemi relativi ai dati principali, le lacune nei requisiti non colmate e i test inadeguati.
L’IA è stata integrata in un processo aziendale (elaborazione degli ordini e assegnazioni) che non era sufficientemente maturo.
Dave descrive la stessa dinamica emersa dalle sue valutazioni: dipartimenti diversi che svolgono lo stesso lavoro in modi differenti, documentazione incompleta ed eccezioni che esistono solo nella mente dei dipendenti. «La preoccupazione era che l'IA si limitasse a riprodurre pratiche incoerenti in tutta l'organizzazione», spiega. È una conseguenza di un principio a cui torna spesso: «L'IA non risolve i problemi organizzativi. Amplifica i sistemi esistenti. Se i processi sono incoerenti o documentati male, spesso l'IA amplificherà tali incoerenze invece di migliorarle». La lezione, nelle sue parole, è questa: «La lezione ricorrente è stata che le organizzazioni dovrebbero migliorare i processi prima di tentare di automatizzarli».
Se i processi sono incoerenti o documentati male, spesso l'IA amplificherà tali incoerenze invece di migliorarle.
Gil Martinez ha le sue cicatrici anche in questo ambito: un'applicazione per la generazione di contatti commerciali che «la prima volta è fallita clamorosamente». La realizzazione è passata da semimanuale a completamente automatizzata senza requisiti o test definiti. «Il mio errore è stato presumere che l'IA avrebbe ricavato autonomamente parte della logica, perché quella logica sembrava ovvia e semplice», ammette. Da lì, la situazione è precipitata. «Il codice è diventato ingestibile ed era interamente sotto il controllo dell'IA, al punto che non riuscivo più a tornare a una fase sicura. È stato allora che ho capito che il problema era strutturale, non costituito soltanto da bug».
Il recupero ha richiesto un ripristino completo. «La soluzione era tanto dolorosa quanto ovvia: ricominciare», racconta. «Questa volta ho delineato ogni requisito e un test per ciascuno di essi, ho proceduto per incrementi e ho fornito all'IA istruzioni chiare per registrare errori e successi, insieme a un adeguato controllo delle versioni». Il secondo tentativo, condotto con disciplina, «ha richiesto all'incirca la metà del tempo che avevo sprecato nel primo per arrivare a una soluzione funzionante e di livello produttivo».
More Articles
Come si presenta davvero una buona documentazione per l'IA
Alla base di tutte e tre le storie c'è la stessa soluzione: una documentazione che descriva come si svolge realmente il lavoro. Per Dave, questo significa andare oltre gli elenchi di attività. «Una buona documentazione dei processi spiega non solo cosa fanno le persone, ma anche perché prendono determinate decisioni», afferma. E il materiale più prezioso è solitamente quello che non viene mai messo per iscritto. «Uno degli errori più comuni commessi dalle organizzazioni è documentare solo il flusso di lavoro standard. La maggior parte delle conoscenze organizzative spesso risiede nelle eccezioni, nelle decisioni discrezionali e nelle scelte contestuali compiute dai dipendenti più esperti».
Gil Martinez lo inquadra attraverso una prospettiva che i PM riconosceranno sempre più: “Una buona documentazione dei processi rispecchia l’ingegneria dei prompt. Gli stessi elementi che abbiamo imparato a fornire all’AI in un prompt (ruolo, contesto, attività, istruzioni, vincoli) dovrebbero comparire a livello di progetto.” Questo cambiamento ha implicazioni sul modo in cui i professionisti impiegano il proprio tempo. “Il tempo di esecuzione degli esseri umani sta scomparendo, delegato all’AI, quindi dobbiamo concentrare la nostra attenzione su una buona pianificazione e sulla validazione dei risultati. Dobbiamo comportarci come manager dell’AI.”
Conclusione: la sequenza è la strategia
Nessuno di questi leader si pente di aver investito nell’AI. Ciò di cui si pentono — o di cui hanno visto pentirsi altri — è l’ordine delle operazioni. Tejinder riassume così: “L’adozione dell’AI nelle imprese fallisce quando il modello viene implementato prima dei fondamenti operativi. La sequenza corretta prevede prima la maturità dei processi, la qualità dei dati e la chiarezza dei ruoli. Poi l’AI. Quando le organizzazioni invertono quest’ordine, attribuiscono la colpa all’AI, ma il problema di fondo è quasi sempre l’ambiente in cui l’AI è stata inserita.” Tornare sui propri passi, a quanto pare, non è il fallimento. Lo è implementare qualcosa prima di essere pronti.
Vuoi altri approfondimenti come questi? Iscriviti gratuitamente a un account DPM per ascoltare altri esperti come loro.