Perché il primo progetto di IA deve risolvere un solo problema

La trappola inizia nella riunione di scoping

La conversazione va di solito così: l'azienda decide che è arrivato il momento di fare sul serio con l'IA, convoca i responsabili di area, e ciascun manager porta un problema. Il servizio clienti è lento. I report dipendono da una sola persona. Il magazzino riserva sempre delle sorprese. L'offerta commerciale impiega tre giorni.

Tutto reale. Tutto legittimo.

Il risultato è un progetto che vuole risolvere i quattro problemi contemporaneamente, con sei mesi di tempo e un budget che sembra alto fino al giorno in cui finisce. Quando la scadenza salta, ciò che viene consegnato risolve raramente qualsiasi problema per intero.

Il perimetro ampio è ciò che rende un progetto costoso e lento. Questa frase sembra ovvia, ma nella maggior parte delle conversazioni che abbiamo con i responsabili delle medie imprese, l'errore è già stato commesso prima che esista una sola riga di codice.

Un problema risolto per intero vale più di quattro problemi affrontati a metà

Pensiamo a un'attività concreta: il team di logistica consolida i report di consegna ogni mattina. Due persone, quaranta minuti ciascuna, cinque giorni alla settimana. Sono più di sei ore di lavoro settimanale dedicate ad aggregare fogli di calcolo e verificare lo stato in sistemi diversi.

Questo numero non richiede ricerche. Si rifa il calcolo con i propri dati in due minuti.

Risolvere questo problema per intero significa che, il lunedì successivo all'implementazione, nessuno esegue più quel lavoro manualmente. Il report appare pronto, all'orario stabilito, senza intervento. Le due persone trascorrono la mattina facendo altro.

Questo è valore che il team percepisce il primo giorno. Non è la promessa di un risultato tra sei mesi.

Quando il progetto cerca di risolvere contemporaneamente il servizio clienti, il magazzino e i report, nessuno dei tre fronti raggiunge quel punto di completamento. Il team vive in modalità pilota, validando, correggendo, e nessuno riesce a dire se qualcosa abbia davvero funzionato.

Perché la media impresa cade in questa trappola

Dietro il perimetro gonfiato c'è una logica, e non è stupidità. È difesa.

Quando l'azienda investe in un progetto tecnologico, c'è una pressione naturale a giustificare il budget dimostrando che molte cose cambieranno. Un progetto piccolo sembra poco ambizioso. Sembra che il valore non sia proporzionale allo sforzo necessario per approvare l'investimento.

Il ragionamento inverte causa ed effetto. Il progetto che consegna una cosa per intero genera fiducia reale. È con questa fiducia che il ciclo successivo parte più velocemente, con meno resistenza interna e con l'apprendimento del ciclo precedente già incorporato.

Il progetto che tenta di fare tutto non crea questo patrimonio. Crea riunioni di revisione.

Come scegliere il problema giusto

Il problema giusto ha tre caratteristiche, tutte pratiche da identificare.

Prima: è ripetitivo. Accade ogni giorno, ogni settimana, ogni mese, con la stessa struttura. Più il lavoro è prevedibile, più diventa diretto trasformarlo in qualcosa che gira da solo.

Seconda: il suo costo è visibile. Ore del team, scadenze che slittano, clienti che aspettano. Se riesci a descrivere il problema in una frase del tipo "questo consuma X ore di Y persone Z volte alla settimana", ha un costo misurabile. Il costo misurabile diventa argomento di approvazione e, in seguito, prova di risultato.

Terza: è circoscritto. Significa che risolvere quel problema non dipende dalla riforma dell'intero processo aziendale. Il problema ha input, elaborazione e output definiti. Il report di logistica ha questa caratteristica. L'"esperienza del cliente" non ce l'ha.

In FM Solutions, quando arriviamo in una nuova operazione, chiediamo al responsabile di elencare le dieci attività che consumano più tempo al team. Poi chiediamo di cancellare quelle che dipendono da un giudizio umano difficile da trasferire. Ciò che rimane è il punto di partenza.

Cosa significa "risolvere per intero" nella pratica

Risolvere per intero non significa installare uno strumento e sperare. Significa garantire che l'attività abbia smesso di esistere nel formato manuale. Il team non apre più quel foglio di calcolo. Non manda più quella e-mail di sollecito per le informazioni. Non verifica più quello stato uno per uno.

Questo richiede tre cose: che il processo venga mappato con onestà, che le eccezioni vengano gestite prima del go-live, e che il team sappia esattamente cosa è cambiato e cosa spetta ancora a lui.

La terza parte viene spesso ignorata. Un'automazione che il team non capisce diventa un'automazione che il team aggira. Il lavoro manuale rientra dalla porta sul retro.

Cosa rimane per il ciclo successivo

Risolvere un problema per intero richiede, nella maggior parte dei casi, alcune settimane. Al termine, l'azienda ha tre cose che non aveva prima: un processo in meno da gestire, un team che ha visto la trasformazione funzionare da vicino, e un budget che non è andato via tutto in una volta.

Questo è il momento di scegliere il secondo problema. Con l'apprendimento del primo ciclo, il secondo va più veloce. Il team arriva con meno scetticismo. Il responsabile arriva con meno necessità di giustificare ogni decisione.

L'azienda che cerca di costruire tutto in una volta difficilmente arriva al secondo progetto. È rimasta bloccata nel tentativo di finire il primo.

Cosa cambia quando il perimetro è onesto

Un progetto con un perimetro onesto ha una scadenza che il responsabile riesce a difendere davanti al board. Ha un criterio di successo che qualsiasi persona dell'operazione comprende. Ha un momento preciso in cui è possibile dire "ha funzionato" o "non ha funzionato".

Questo criterio di successo è ciò che separa un investimento da una scommessa.

In pratica, la domanda che facciamo prima di qualsiasi proposta è: qual è l'attività che, se smette di esistere il lunedì mattina, il team percepisce nello stesso giorno? Se il responsabile riesce a rispondere, abbiamo un punto di partenza. Se la risposta è "diverse cose", il lavoro inizia un passo prima: aiutare a sceglierne una.