Punti chiave
- Quasi nessuno dei pattern di fallimento e tecnico. La tecnologia di solito funziona. Il problema e quasi sempre a monte: problema sbagliato, ownership poco chiara, nessun piano di adozione, o misurazione che inizia troppo tardi.
- L'errore piu costoso e automatizzare prima di capire il processo. Costruire una soluzione tecnicamente corretta al problema sbagliato costa quanto costruire quella giusta e non consegna nulla.
- L'entusiasmo del team al lancio di un progetto IA non e adozione. L'adozione reale e quello che succede sei settimane dopo, quando la novita si e esaurita e le persone sono sotto pressione di scadenza.
- Un'IA che appartiene a tutti non viene mantenuta da nessuno. Ogni automazione ha bisogno di una persona nominata, il cui compito sia tenerla funzionante e migliorarla nel tempo.
- Il pattern alla base di quasi ogni fallimento e lo stesso: l'implementazione e iniziata prima che la diagnostica fosse completa. Due-quattro settimane di pensiero strutturato prima di qualsiasi build prevengono la maggior parte di questi problemi.
Gli articoli che appaiono cercando perche i progetti IA falliscono condividono una caratteristica comune: citano un numero e poi non spiegano quasi nulla. "Il settanta percento dei progetti IA fallisce" seguito da una lista di cause astratte come "mancanza di qualita dei dati" o "change management insufficiente." Vero probabilmente, e non molto utile se sei nel mezzo di un progetto che non sta funzionando.
Questo articolo adotta un approccio diverso. Descrive gli errori specifici e concreti che ho visto ripetersi in progetti di IA e automazione di diverse dimensioni e settori. Ognuno ha una firma riconoscibile: lo riconosci quando lo vedi. E ognuno ha una correzione pratica che non richiede una ristrutturazione importante del progetto.
Perche questo continua ad accadere
Prima dei singoli errori, vale la pena nominare il motivo strutturale per cui si ripetono cosi affidabilmente. I progetti di implementazione IA hanno una pressione specifica che la maggior parte degli altri progetti tecnologici non ha: l'aspettativa di risultati visibili e veloci. La leadership ha approvato un budget basato sui risparmi proiettati. Un vendor ha dimostrato capacita impressionanti. Il team e entusiasta. C'e una pressione enorme per mostrare qualcosa di funzionante rapidamente.
Questa pressione e la causa principale della maggior parte dei fallimenti. Spinge i team a saltare il lavoro lento e non glamour di capire il processo attuale prima di iniziare a cambiarlo. Premia l'attivita visibile (automazioni costruite, demo consegnate) rispetto ai risultati reali (tempo risparmiato, errori ridotti). E crea un ambiente in cui ammettere che il progetto sta prendendo la direzione sbagliata sembra un fallimento, quindi i problemi si accumulano silenziosamente finche non sono troppo grandi per essere corretti in modo incrementale.
I cinque errori che compaiono in quasi ogni progetto fallito
Automatizzare prima di capire il processo
Un founder con cui ho parlato l'anno scorso aveva speso quattro mesi e circa 40.000 euro costruendo un sistema IA per automatizzare il flusso di reporting del suo team operations. Il sistema funzionava. Produceva report piu velocemente e con meno passaggi manuali. Il problema era che il flusso di reporting non era effettivamente il collo di bottiglia. Il vero collo di bottiglia era il processo decisionale che avveniva dopo la produzione dei report, che l'automazione non toccava affatto. Il team operations risparmiava due ore a settimana sulla generazione dei report e spendeva ancora dodici ore ad aspettare che venissero prese decisioni sull'output.
Questo pattern si ripete costantemente. I team automatizzano il processo manuale piu visibile, non quello piu prezioso. I due raramente coincidono. I processi piu visibili sono di solito quelli che sembrano laboriosi alle persone che li svolgono. I piu preziosi sono quelli che stanno effettivamente rallentando il business. Trovare la seconda categoria richiede una fase diagnostica prima che venga selezionato qualsiasi strumento o inizi qualsiasi build.
Segnale d'allarme
Il progetto e iniziato con uno strumento o un flusso di lavoro in mente, non con un problema di business. Se la prima conversazione e stata "automatizziamo il nostro processo X con Make" invece di "cosa ci sta costando piu tempo o denaro," il progetto e a rischio di questo errore.
Confondere l'entusiasmo del lancio con l'adozione
Ogni progetto di automazione ha una luna di miele. Il team usa il nuovo sistema con entusiasmo. Le metriche iniziali sembrano promettenti. La leadership dichiara il successo. Poi, sei-otto settimane dopo, arriva una settimana ad alta pressione. Ci sono scadenze, compaiono casi limite e l'automazione richiede un workaround o produce output che necessita di revisione. Sotto pressione, le persone tornano a quello che conoscono. L'automazione viene usata selettivamente, poi occasionalmente, poi non affatto da alcuni membri del team.
L'adozione non e entusiasmo. E quello che succede dopo che la novita si e esaurita e le persone devono scegliere tra il nuovo sistema e le vecchie abitudini in condizioni reali. I progetti che non pianificano questa transizione falliscono sull'adozione anche quando la tecnologia e solida. Pianificarla significa identificare le condizioni specifiche in cui le persone torneranno indietro, formarsi per quegli scenari, e avere un owner reale che nota quando l'utilizzo cala e risponde ad esso.
Segnale d'allarme
I dati di utilizzo non vengono tracciati, o nessuno li guarda. Se non riesci a rispondere quanti membri del team usano l'automazione regolarmente rispetto a occasionalmente rispetto a per nulla, non sai se e stata adottata.
Scegliere lo strumento prima di definire il problema
Questa e la versione guidata dal vendor dell'errore numero uno. Un'azienda partecipa a una demo, rimane impressionata e si iscrive a una piattaforma. La piattaforma poi modella quali problemi vengono risolti, perche il team cerca naturalmente problemi che lo strumento puo gestire invece di chiedersi quali problemi abbiano piu bisogno di essere risolti. Si finisce con un workspace Make splendidamente configurato che automatizza processi che non erano effettivamente ad alta priorita, mentre i veri colli di bottiglia rimangono intatti perche non si adattano ai punti di forza dello strumento.
L'ordine delle operazioni conta: definisci prima il problema, identifica i requisiti secondo, poi valuta gli strumenti rispetto a quei requisiti. Suona ovvio ed e quasi universalmente ignorato. La selezione dello strumento e eccitante. La definizione del problema e lenta e a volte scomoda perche fa emergere disaccordi su cosa sia effettivamente importante. I team ci passano sopra rapidamente.
Segnale d'allarme
Il progetto e stato avviato da una valutazione di strumenti invece che da un audit dei problemi. Se il primo passo e stato confrontare Zapier con Make invece di mappare quali processi costano di piu, l'ordine e invertito.
Nessun owner chiaro dell'automazione dopo il lancio
I progetti di IA e automazione vengono frequentemente trattati come progetti invece che come prodotti. Hanno una fase di build e un lancio, e poi vengono considerati completati. Cio di cui hanno davvero bisogno e un owner: una persona specifica il cui compito sia tenere il sistema funzionante, gestire i casi limite, aggiornarlo quando i processi a monte cambiano, e migliorarlo nel tempo in base a cio che mostrano i dati di utilizzo.
Senza un owner, l'automazione degrada. I formati dei dati a monte cambiano e l'automazione inizia a produrre errori. Un passaggio del processo viene modificato e nessuno aggiorna il flusso di lavoro. Un caso limite diventa frequente e viene gestito con un workaround manuale che nessuno documenta. Sei mesi dopo il lancio, il sistema e parzialmente rotto e parzialmente aggirato, e nessuno sa con certezza qual e lo stato attuale di cio che e automatizzato e cio che non lo e.
Segnale d'allarme
La persona che ha costruito l'automazione non e piu attivamente coinvolta e nessuno ne ha formalmente assunto la proprieta. Chiedi chi e responsabile che l'automazione funzioni correttamente il mese prossimo. Se la risposta e vaga, l'ownership non e stata stabilita.
Aspettarsi che l'IA sostituisca il giudizio invece di supportarlo
Questo errore e specifico dei componenti IA rispetto all'automazione basata su regole, e sta diventando piu comune man mano che i modelli linguistici vengono integrati nei flussi di lavoro aziendali. Un team costruisce un sistema in cui l'IA prende una decisione o produce un output che entra direttamente nel processo senza revisione umana. Questo funziona bene finche non appare un caso limite che il modello gestisce male. Poiche non esiste un passaggio di revisione, l'output errato si propaga a valle prima che qualcuno lo individui, e il costo dell'errore si moltiplica.
Il design migliore e trattare gli output dell'IA come input per il giudizio umano piuttosto che come sostituzioni di esso, almeno finche il sistema non ha dimostrato affidabilita consistente sui tuoi dati e caso d'uso specifici. Questo significa costruire un passaggio di revisione leggero, non per ogni output per sempre, ma abbastanza a lungo da capire dove il modello performa bene e dove no.
Segnale d'allarme
Non esiste un passaggio di revisione per gli output generati dall'IA che entrano nei processi a valle. Se l'output dell'IA viene usato direttamente senza alcun checkpoint umano, chiedi cosa succede quando e sbagliato. Se la risposta e "si propaghera nel sistema prima che qualcuno se ne accorga," e necessario aggiungere un passaggio di revisione.
Il pattern alla base di tutti e cinque gli errori
Ognuno di questi errori sembra diverso in superficie. Ma condividono una radice comune: l'implementazione e iniziata prima che la diagnostica fosse completa.
Una diagnostica appropriata, eseguita prima che venga selezionato qualsiasi strumento o inizi qualsiasi build, farebbe emergere la maggior parte di questi problemi prima che diventino costosi. Identificherebbe quali processi sono effettivamente il collo di bottiglia, non solo i piu visibili. Farebbe emergere disaccordi su cosa sia effettivamente il progetto. Stabilirebbe chi possiede cosa dopo il lancio. Definirebbe come appare il successo in termini misurabili, in modo da avere qualcosa rispetto a cui tracciare invece di un'impressione.
La diagnostica richiede due-quattro settimane. Non e glamour. Non produce nulla immediatamente visibile. E la parte che la maggior parte delle organizzazioni salta perche la pressione per mostrare progressi e gia alta prima che il progetto sia ufficialmente iniziato.
L'ironia e che saltarla non accelera il progetto. Accelera l'arrivo al punto in cui il progetto deve essere parzialmente o completamente riavviato. Il tempo perso in una build sbagliata piu un riavvio e quasi sempre piu lungo del tempo che avrebbe richiesto una diagnostica.
Per un framework pratico su come misurare se un progetto IA sta funzionando una volta avviato, vedi come misurare il ROI di un progetto di automazione IA. Per una guida su quali processi automatizzare per primi, vedi automazione IA per startup e PMI.
Cosa fare se riconosci il tuo progetto in questa lista
Se stai leggendo questo perche un progetto e gia in difficolta, il primo passo e separare i problemi tecnici da quelli strategici. I problemi tecnici (l'automazione e inaffidabile, la qualita dell'output e scarsa, il sistema si rompe su certi input) spesso possono essere corretti senza ripartire da zero. I problemi strategici (stai automatizzando il processo sbagliato, nessuno possiede il sistema, il team non lo sta effettivamente usando) richiedono di tornare alla diagnostica prima di aggiungere altro lavoro tecnico.
Aggiungere funzionalita o complessita a un progetto con un problema strategico rende il problema strategico piu costoso da affrontare in seguito, non meno. L'istinto quando un progetto non funziona e fare di piu. Di solito la mossa giusta e fermarsi, diagnosticare e decidere se cio che e stato costruito vale la pena continuare o se le risorse siano meglio spese partendo da un problema meglio definito.
Lavora con Ipernovation
Riconosci uno di questi pattern in un progetto che stai gestendo?
Una sessione diagnostica focalizzata puo identificare quale di questi problemi stai affrontando e qual e il passo pratico successivo. Nessun pitch, nessuna proposta: una conversazione diretta sulla tua situazione specifica.
Inizia una conversazione