In due righe
- Durata: 4-8 settimane scritte all'inizio, non decise dopo.
- Perimetro: un solo processo, non un'area.
- Metriche: due, fissate prima dell'avvio.
- Criterio di stop: una soglia scritta sotto la quale si chiude.
Un progetto pilota di automazione sopravvive se, prima di partire, decidi cinque cose e le scrivi: una durata fissa di 4-8 settimane, un perimetro di un solo processo, il nome di chi ci sta dentro, due metriche (una di risultato, una di adozione) e il criterio di stop. È quest'ultimo a fare la differenza: senza una soglia scritta all'inizio, il pilota non ha modo di chiudersi e muore nel limbo della sperimentazione infinita. Chi lo imposta così decide con i numeri, non con l'entusiasmo.
Un progetto pilota è un test a durata e perimetro definiti, eseguito su un processo reale con utenti reali, per decidere con i numeri se estendere, correggere o fermare l'automazione. Il divario è misurabile: secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano, il 71% delle grandi imprese ha avviato progetti di AI contro l'8% delle PMI. Il pilota serve a colmare questo divario senza mettere a rischio l'azienda.
La scheda del pilota: cinque decisioni da prendere prima di partire
| Elemento |
Decisione |
Perché va scritta prima |
| Durata |
4-8 settimane, calcolate sul ciclo del processo |
Un termine fisso impedisce al pilota di trascinarsi |
| Perimetro |
Un solo processo, non un'area |
Se il perimetro è largo non sai cosa ha funzionato |
| Team |
Uno sponsor, un referente operativo, da uno a tre utenti reali |
Senza utenti veri il pilota non testa niente |
| Metriche |
Una di risultato e una di adozione, con numero di partenza e target |
Senza numeri fissati prima il giudizio arriva a posteriori |
| Criterio di stop |
Una soglia minima sotto la quale si ferma |
Se non è scritto, non lo rispetti |
Quanto deve durare un progetto pilota di automazione?
Quattro-otto settimane, non di più. La durata si calcola dal ciclo del processo: servono almeno una ventina di ripetizioni per giudicare con i numeri. Se il processo gira ogni giorno bastano quattro settimane; se gira una volta a settimana servono più settimane. Il termine va scritto all'inizio, non deciso dopo. Una scadenza fissa impedisce al pilota di trascinarsi e obbliga a prendere la decisione finale sul serio.
Come si delimita il perimetro del pilota
Un solo processo, non un'area. I candidati giusti hanno quattro caratteristiche: alto volume di ripetizioni, regole chiare, dati già digitali, errore umano costoso. Sono i criteri che usa anche la letteratura sull'automazione intelligente, e servono a escludere il progetto affascinante ma ambiguo. Il perimetro è il confine del pilota: quale processo, quali persone e quali dati sono dentro, tutto il resto è fuori.
Se il processo è ripetitivo e basato su regole rigide, spesso la tecnologia giusta è la RPA (Robotic Process Automation), che replica le azioni di un operatore su applicazioni digitali, come copiare dati o compilare campi. Su un processo semplice si può partire con strumenti no-code come Zapier, Make o n8n; su uno complesso serve sviluppo e integrazione.
Per individuare l'area da cui partire serve una vista sulle aree aziendali, come quella del PMI Speed Test, l'analisi delle cinque aree aziendali. Non allargare il perimetro a metà. Il classico "visto che ci siamo automatizziamo anche questo" è il modo più rapido per non capire più cosa ha funzionato.
Chi deve stare dentro al progetto pilota
Tre ruoli, non un comitato. Uno sponsor con il potere di togliere tempo alle persone, un referente operativo che risponde del risultato, e da uno a tre utenti veri che oggi fanno il processo a mano. Se dentro ci sono solo il titolare e il consulente IT, il pilota non testa niente. Chi fa il processo va coinvolto da subito, non quando l'automazione è pronta. Il suo giudizio sulla nuova procedura conta più della demo del fornitore.
Le due metriche da fissare prima di partire
Due sole metriche, non una dashboard. La prima è di risultato: tempo risparmiato, errori o volumi gestiti. La seconda è di adozione: quanti passaggi o quante persone usano davvero il nuovo flusso. Un KPI è un numero definito prima dell'avvio che misura se il progetto sta producendo il risultato atteso; qui ne servono due, non dieci. La metrica di adozione misura quante persone o transazioni passano davvero dal nuovo flusso automatizzato, non quante potrebbero farlo. Vanno scritte con il numero di partenza e la soglia target prima dell'avvio.
Il momento di misurarle è prima, non dopo. Secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano, tra le grandi aziende che usano strumenti di intelligenza artificiale generativa solo il 54% tenta di misurare il beneficio dell'AI. Il resto giudica a sensazione, e il pilota annega nelle opinioni.
Facciamo un conto su un'azienda tipo. Un'azienda di servizi con 12 persone riceve 60 richieste di assistenza a settimana via email, smistate a mano in 5 minuti ciascuna: 300 minuti, circa 6 ore a settimana. Il pilota automatizza classificazione e instradamento. Prima dell'avvio si fissano le due metriche. Risultato: tempo medio di smistamento sotto i 2 minuti a richiesta entro la settimana 4. Adozione: almeno l'80% delle richieste passa dal flusso automatico. Il criterio di stop è scritto all'inizio: alla fine della settimana 4, se l'adozione è sotto il 60% o il tempo medio è sopra i 4 minuti, si ferma e non si estende.
Lo strumento
Delera Agent AI costruisce agenti su misura sui processi che oggi ti portano via ore ogni settimana.
Scopri Delera Agent AI
Il criterio di stop: perché si scrive all'inizio
La decisione che salva il pilota è quella di quando fermarlo, presa prima. Si scrive una soglia minima sotto la quale si chiude: per esempio adozione sotto il 60% o tempo risparmiato sotto le due ore a settimana. Se il criterio non è scritto, alla terza settimana il pilota galleggia, nessuno sa decidere e muore di inerzia. Il limbo ha un nome: AI pilot purgatory, il purgatorio in cui i progetti restano bloccati perché nessuno li chiude né li estende.
La supervisione umana resta nel flusso. L'AI Act, applicabile dal 2 agosto 2026, impone obblighi di trasparenza e controllo umano per molti usi dell'AI. Se il processo tocca dati personali, il GDPR si applica anche al pilota, non solo a regime. Anche in un pilota, il referente operativo controlla gli output prima di estendere.
Secondo caso. Un'azienda pilota l'inserimento automatico delle fatture con OCR e Intelligent Document Processing e scrive all'inizio che se dopo 6 settimane il tasso di errore non scende sotto il 5%, il pilota si chiude e non si estende all'archivio.
Quando il pilota finisce: le tre uscite possibili
Estendere, correggere o fermare. Con le due metriche e il criterio di stop la decisione è quasi già presa dai numeri. Il pilota è una tappa del percorso di adozione dell'AI, non il percorso intero: lo scale-up ad altre aree è un passo successivo e separato. Non confondere il pilota con il percorso complessivo: chiudere un pilota che non raggiunge la soglia è un successo, perché evita di estendere un'automazione che non rende.
Gli errori più frequenti
- Confondere il pilota con la demo del fornitore: la demo usa i dati del fornitore, il pilota usa i tuoi dati e i tuoi utenti.
- Allargare il perimetro a metà, con il classico "visto che ci siamo automatizziamo anche questo".
- Misurare solo alla fine invece di fissare le due metriche prima dell'avvio.
- Non scrivere il criterio di stop: il pilota non ha modo di chiudersi e muore di inerzia, il cosiddetto AI pilot purgatory.
- Coinvolgere solo il titolare e il reparto IT, lasciando fuori chi fa davvero il processo.
- Scegliere il processo che fa notizia invece di quello ad alto volume e basse ambiguità.
- Confondere il pilota con il percorso complessivo di adozione dell'AI: lo scale-up è un passo successivo e separato.
Il primo passo domani mattina
Prendi un foglio e scrivi cinque righe: durata, perimetro, team, due metriche con numero di partenza e target, criterio di stop. Se non riesci a riempirle in un'ora, il pilota non è pronto per partire. Meglio fermarsi prima che avviare un progetto che galleggerà.
Domande frequenti
Quanto dura un progetto pilota di automazione?
Quattro-otto settimane. La durata giusta si calcola dal ciclo del processo: servono almeno una ventina di ripetizioni per giudicare con i numeri. Un processo che gira ogni giorno si valuta in quattro settimane, uno che gira una volta a settimana ne richiede di più. Il termine va scritto all’inizio, non deciso a posteriori.
Che differenza c’è tra un progetto pilota e una demo?
La demo la fa il fornitore sui suoi dati per mostrare che lo strumento funziona. Il pilota lo fa il tuo team sui tuoi dati reali, con il tuo processo e i tuoi utenti, per scoprire se funziona da te. La demo non prevede un criterio di stop, il pilota sì. Confonderle è il modo più rapido per comprare uno strumento che poi nessuno usa.
Quali sono le metriche giuste per un progetto pilota?
Due. Una di risultato, che misura l’esito del processo: tempo risparmiato, errori, volumi gestiti. Una di adozione, che misura quante persone o transazioni passano davvero dal nuovo flusso. Entrambe vanno fissate con il numero di partenza e la soglia target prima dell’avvio. Una dashboard con dieci KPI è un segnale che non si è deciso cosa conta davvero.
Quando bisogna fermare un progetto pilota?
Quando scatta il criterio di stop scritto all’inizio. È una soglia minima: per esempio adozione sotto il 60% o tempo risparmiato sotto le due ore a settimana. Se il criterio non è scritto, il pilota galleggia e nessuno decide. Fermare non è un fallimento: è il pilota che ha fatto il suo lavoro, e ha evitato di estendere un’automazione che non rende.
Quanto costa un progetto pilota di automazione?
Dipende dal processo e dallo strumento. Su un processo semplice si può partire con strumenti no-code e un costo contenuto, su uno complesso servono sviluppo e integrazione. Il pilota esiste proprio per spendere poco prima di spendere tanto: con perimetro e criterio di stop definiti, il costo resta sotto controllo e la decisione di proseguire si prende sui numeri.