Cluster · progetto pilota AI
Progetto pilota AI: come impostarlo
Come si imposta un progetto pilota AI: perimetro, durata, criteri di successo definiti prima. Come evitare che diventi un prototipo infinito.
Tempo di lettura: 9 min
Guida operativa · Avviare e misurare
Un progetto pilota è una realizzazione limitata nel perimetro ma vera nel funzionamento: viene usata da chi lavora, su lavoro reale, per un periodo definito. Non è un prototipo che dimostra la fattibilità, e non è un progetto pieno rimpicciolito.
La sua funzione è rispondere a una domanda che nessuna analisi può risolvere: serve davvero, nel nostro contesto specifico? Ed è una domanda che si risponde solo mettendo il sistema nelle mani di chi fa quel lavoro.
In sintesi
- Il pilota entra nel lavoro reale: è ciò che lo distingue da un prototipo.
- Perimetro ristretto ma funzionamento completo, non una versione dimezzata.
- I criteri di successo vanno scritti prima, in una riga.
- Serve una data di fine, o resta in pilota per sempre.
- Va fatto con chi svolge davvero quel processo, non con un campione.
- Un pilota che dice «non conviene» ha funzionato, non fallito.
Come si imposta
- Perimetro: un processo, un tipo di richiesta, un reparto. Scritto in una riga.
- Misura di partenza: com'è adesso, con numeri raccolti prima di iniziare.
- Criterio di successo: cosa deve succedere perché valga la pena estendere.
- Criterio di chiusura: cosa ti farebbe decidere di fermarti.
- Durata: una data, non «finché non funziona».
- Chi lo usa: le persone che fanno quel lavoro ogni giorno.
- Cosa si misura durante, e chi lo guarda.
I punti 3 e 4 sono quelli che quasi nessuno scrive e che determinano se il pilota produrrà una decisione. Senza, alla fine si discute per settimane se «è andato bene», con posizioni che dipendono da quanto ciascuno si è affezionato al lavoro.
Pilota, prototipo e proof of concept
Sono tre cose diverse che vengono usate come sinonimi.
| Domanda a cui risponde | Entra nel lavoro reale | Durata | |
|---|---|---|---|
| Proof of concept | Si può fare tecnicamente? | No | Giorni |
| Prototipo | Come sarebbe? | No | Giorni o settimane |
| Pilota | Serve, nel nostro contesto? | Sì | Mesi |
La confusione più costosa è tra proof of concept e pilota: si costruisce qualcosa che dimostra la fattibilità, lo si mostra in riunione, tutti sono entusiasti, e si passa direttamente al progetto pieno senza aver mai verificato se quel processo, nel lavoro vero, ne trae beneficio. Il tema è approfondito in proof of concept AI.
Cosa misurare durante
- Il numero che avevi misurato prima: ore, errori, tempi di attesa
- Quante volte il sistema è stato usato davvero, non quante era disponibile
- Quante eccezioni ha incontrato e di che tipo
- Quante volte le persone hanno aggirato il sistema, e perché
L'ultimo punto è il più informativo e nessuno lo raccoglie. Se chi lavora torna al metodo vecchio per certi casi, quei casi dicono esattamente dove il sistema non regge — e lo dicono meglio di qualunque questionario.
Il pilota che non finisce
È il fallimento più comune e il più difficile da riconoscere, perché non sembra un fallimento: il sistema funziona, viene usato, nessuno si lamenta. Semplicemente non si decide mai se estenderlo.
Pilota sano
- Ha una data di fine scritta
- Ha criteri decisi prima
- Qualcuno guarda i numeri durante
- Alla scadenza si prende una decisione
Pilota che si trascina
- «Vediamo come va»
- Si aggiungono funzioni durante
- Nessuno raccoglie i dati
- Dopo un anno è ancora un pilota
Il secondo punto della colonna destra è la causa più frequente: aggiungere funzioni durante il pilota sposta il bersaglio e rende impossibile valutare quello che si stava valutando.
Esempi pratici
Pilota su un tipo di documento. Un'azienda che riceve fatture da cento fornitori parte da venti, quelli più ricorrenti. Criterio: se l'ottanta per cento passa senza correzioni in tre mesi, si estende. Perimetro chiaro, misura semplice, decisione automatica.
Pilota su un reparto. Un assistente interno attivato solo per l'amministrazione prima che per tutta l'azienda. Permette di correggere le risposte sbagliate con un pubblico ristretto e tollerante.
Pilota chiuso con esito negativo. Un'azienda ha provato ad automatizzare la gestione dei resi. Dopo due mesi le eccezioni erano più numerose dei casi standard e il sistema veniva aggirato regolarmente. Chiuso, con la decisione documentata. Costo contenuto, informazione preziosa: quel processo va prima semplificato.
Chi deve parteciparvi
La composizione del gruppo che usa il pilota determina la qualità dell'informazione che ne esce, e viene scelta quasi sempre con il criterio sbagliato: si prendono le persone più disponibili o più entusiaste.
Servono invece le persone che fanno quel lavoro ogni giorno, comprese quelle scettiche. Chi è entusiasta tende a giustificare i limiti del sistema e a non segnalare i problemi; chi è scettico li segnala tutti, ed è esattamente quello che serve in questa fase.
- Includi chi svolge il processo quotidianamente, non occasionalmente
- Includi almeno una persona scettica: segnalerà quello che gli altri tacciono
- Evita di coinvolgere solo chi ha proposto il progetto
- Chiarisci che segnalare problemi è il compito, non una lamentela
L'ultimo punto va detto esplicitamente. In molte aziende segnalare che qualcosa non funziona viene percepito come opposizione al progetto, e le persone tacciono per quieto vivere. Un pilota in cui nessuno segnala nulla non è un pilota riuscito: è un pilota senza informazione.
Cosa fare alla scadenza
Arrivata la data, le decisioni possibili sono quattro e vanno nominate prima per non trovarsi a improvvisare.
Estendere. I criteri sono soddisfatti, si allarga il perimetro. È la decisione più semplice ma va comunque accompagnata dalla domanda: estendere a cosa, esattamente?
Prorogare una volta sola. I dati sono promettenti ma insufficienti. Va concesso una volta, con una nuova data e senza aggiungere funzioni, altrimenti diventa il pilota infinito.
Ridimensionare. Il sistema funziona su una parte dei casi e non su altri. Si tiene la parte che funziona e si rinuncia al resto: è un esito frequente e spesso il migliore.
Chiudere. I criteri non sono soddisfatti. È una decisione che va presa senza drammatizzare: ha prodotto un'informazione che valeva il costo del pilota, e ha evitato un progetto pieno sbagliato.
Il pilota a confronto con le alternative
| Approccio | Cosa dimostra | Rischio |
|---|---|---|
| Nessuna prova, progetto pieno | Niente | Alto: si scopre tutto alla fine |
| Proof of concept | Fattibilità tecnica | Medio: non dice se serve |
| Pilota | Utilità nel contesto reale | Basso: perimetro contenuto |
| Pilota infinito | Niente, dopo un po' | Alto: consuma senza decidere |
L'ultima riga è quella in cui si finisce senza volerlo, ed è il motivo per cui la data di fine va scritta insieme al resto.
Errori da evitare
- Non scrivere il criterio di successo prima. Alla fine si discute all'infinito.
- Non prevedere la chiusura. Il pilota si trascina per sempre.
- Aggiungere funzioni durante. Sposta il bersaglio.
- Non misurare il punto di partenza. Rende la valutazione impossibile.
- Farlo con chi non fa quel lavoro. Non incontrerà le eccezioni vere.
- Confonderlo con un proof of concept. Rispondono a domande diverse.
Come applicarlo in azienda
Prendi un foglio e scrivi cinque righe: cosa copre il pilota, cosa misuro, com'è adesso, cosa considero un successo, quando decido. Se non riesci a scriverle tutte e cinque, il pilota non è pronto per partire.
Poi scegli le due o tre persone che fanno quel lavoro ogni giorno e coinvolgile nella definizione, non solo nell'uso. Le eccezioni che conoscono loro sono quelle che decideranno l'esito.
Il quadro completo è in progetto AI: come iniziare, le metriche in KPI di un progetto AI.
Il pilota e il resto dell'azienda
Un aspetto che si trascura: mentre il pilota è in corso, il resto dell'azienda guarda. E quello che vede determina come sarà accolta l'estensione.
Se il pilota viene raccontato come «stiamo provando una cosa», le persone lo osservano con curiosità e senza timore. Se viene presentato come «l'inizio della trasformazione digitale», genera aspettative e ansie sproporzionate rispetto a un esperimento su un processo.
Vale anche la pena decidere cosa comunicare alla fine, qualunque sia l'esito. Un pilota chiuso senza spiegazioni lascia l'impressione che sia andato male, anche quando la decisione era semplicemente di ridimensionare o rimandare. Dire cosa si è imparato costa cinque minuti e mantiene aperta la porta per il progetto successivo.
Il quadro delle metriche da seguire durante è in KPI di un progetto AI, e le cause tipiche di fallimento in perché falliscono i progetti AI.
Conclusione
Un pilota serve a rispondere a una domanda sola — serve davvero da noi? — e ci riesce solo se ha un perimetro stretto, criteri scritti prima e una data di fine.
Il valore non sta nel dimostrare che l'AI funziona: quello lo sappiamo. Sta nel scoprire, con dati veri, se funziona in questo processo con queste persone. Ed è un'informazione che vale anche, e forse soprattutto, quando la risposta è no.
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.
Da ultimo, conserva quello che hai imparato in forma scritta, anche poche righe: cosa hai provato, cosa è emerso, cosa decideresti diversamente. Nelle PMI questa memoria non esiste, e due anni dopo si riparte da zero sullo stesso tema con le stesse domande.
Schema consigliato: Article + FAQPage + HowTo + BreadcrumbList
Risorse correlate
FAQ
Cos'è un progetto pilota AI?
È una realizzazione limitata nel perimetro ma completa nel funzionamento, messa in produzione su una parte del lavoro reale per un periodo definito. Si distingue da un prototipo perché viene usata davvero da chi lavora, e da un progetto pieno perché copre un perimetro volutamente ristretto.
Quanto deve durare?
Abbastanza da raccogliere dati significativi, tipicamente qualche mese di uso reale. Meno non basta perché non si vedono le eccezioni; molto di più è un progetto che non ha mai deciso di finire, e nella pratica resta in pilota per sempre senza che nessuno lo valuti.
Come si definisce se è andato bene?
Scrivendo prima, in una riga, cosa considereresti un successo. «Il tempo di gestione scende sotto X», «gli errori scendono sotto Y». Senza un criterio scritto prima, alla fine la valutazione dipende dall'umore di chi la fa e dal fatto che ci si è affezionati al lavoro svolto.
Cosa distingue un pilota da un prototipo?
Il prototipo dimostra che una cosa è possibile e non entra nel lavoro reale. Il pilota entra nel lavoro reale, su un perimetro ridotto, e produce dati su cosa succede davvero. Il primo risponde a «si può fare?», il secondo a «serve?».
Cosa succede se il pilota fallisce?
È un esito legittimo e va previsto fin dall'inizio, con un criterio scritto per chiuderlo. Un pilota che dimostra che quel processo non conviene automatizzare ha prodotto un'informazione utile a un costo contenuto: è esattamente quello che doveva fare.
Su quante persone va fatto?
Sulle poche che svolgono davvero quel processo, non su un campione rappresentativo. In una PMI spesso significa due o tre persone. L'importante è che siano quelle che ci lavorano ogni giorno, perché sono le uniche che incontreranno le eccezioni vere.