Diverse analisi di settore stimano che una quota significativa dei progetti iniziali di Robotic Process Automation non raggiunga gli obiettivi attesi, con percentuali indicate tra il 30% e il 50%.
Le cause sono diverse, ma una ricorre con fastidiosa regolarità: si è automatizzato il processo sbagliato, o nel modo sbagliato.
Per anni abbiamo costruito automazioni aziendali partendo da una domanda apparentemente ovvia: “cosa possiamo automatizzare?”. La risposta arrivava da workshop, interviste, analisi manuali. Poi entravano in gioco i tool di RPA e si costruivano bot pensati per replicare le azioni umane. In molti casi ha funzionato. In molti altri, no: automazioni fragili, difficili da mantenere, incapaci di gestire le eccezioni, costose da aggiornare ogni volta che il processo reale, quello che vive nei sistemi, non nei manuali, cambiava di qualche elemento.
Oggi, con l’arrivo degli agenti AI, il rischio concreto è di ripetere lo stesso schema. Cambia la tecnologia, ma non l’approccio.
La vera discontinuità arriva quando si cambia la domanda: non più “cosa automatizzare?”, ma “cosa succede davvero nei nostri processi?”. Questa domanda, più scomoda, più lenta da rispondere, è quella che produce automazioni che funzionano. Ed è esattamente la domanda a cui risponde il Process Mining.
Indice degli argomenti
Guardare i processi per quello che sono non per come li immaginiamo
Il Process Mining è una disciplina che analizza i log dei sistemi informativi aziendali (ERP, CRM, piattaforme di gestione documentale, sistemi di ticketing) per ricostruire i processi reali: non quelli descritti nelle procedure operative o raccontati nelle riunioni di allineamento, ma quelli effettivamente eseguiti ogni giorno dagli operatori.
In pratica: ogni sistema informativo registra eventi con un identificativo del caso di lavoro, un’attività svolta e un timestamp. Il Process Mining aggrega questi eventi per ricavare i flussi reali, visualizzarli come grafi di processo e analizzarne tempi, frequenze, deviazioni.
Quello che emerge è quasi sempre sorprendente per chi non l’ha mai visto. I processi non sono lineari. Non seguono un unico flusso ordinato come nei diagrammi BPMN appesi alle pareti delle sale riunioni. Sono fatti di varianti, deviazioni, percorsi alternativi. Un’analisi tipica su un processo order-to-cash in un’azienda manifatturiera di medie dimensioni può rivelare centinaia di varianti distinte. E soprattutto, ed è qui che sta il punto chiave, queste varianti non hanno tutte lo stesso peso.
La realtà nascosta: poche varianti contano davvero
Uno dei pattern più ricorrenti nel Process Mining, e spesso sottovalutato da chi si avvicina alla disciplina per la prima volta, è che le varianti di processo tendono a seguire una distribuzione di Pareto.
Un esempio concreto: in un’analisi su 80.000 ordini di acquisto elaborati in 12 mesi da una società di distribuzione, sono emerse 1.340 varianti di processo distinte. Le prime 18 varianti coprivano il 76% dei casi totali. Le restanti 1.322 si distribuivano sul 24% rimanente, con molte varianti che comparivano meno di cinque volte nell’intero dataset.
Questa distribuzione, poche varianti dominanti, lunga coda di eccezioni rare, è la regola, non l’eccezione. Si ripete in settori diversi: dalla gestione sinistri nel mondo assicurativo, ai processi di approvazione del credito in banca, all’onboarding fornitori nel manifatturiero.
Questo cambia completamente il modo in cui ha senso pensare all’automazione. Perché se il grosso del lavoro si concentra su poche varianti ricorrenti, è lì che si gioca la partita. Non nelle eccezioni.
L’errore classico: inseguire le eccezioni
Molti progetti di automazione hanno cercato di coprire l’intero processo, eccezioni incluse. Il risultato è quasi sempre lo stesso: sistemi complessi, zeppi di regole condizionali, difficili da gestire e ancora più difficili da aggiornare.
Un caso emblematico, comune in molte realtà assicurative: il processo di liquidazione sinistri viene automatizzato “al 100%”, includendo gestione di documentazione incompleta, casi in contenzioso, polizze con clausole speciali, richieste oltre soglia. Ogni eccezione diventa una regola nel sistema. Ogni nuova eccezione non prevista produce un crash o un risultato sbagliato. Dopo 18 mesi, il team IT dedica più tempo a manutenere il bot che a qualsiasi altro sistema aziendale.
Il problema non è tecnico. È concettuale. Le eccezioni sono tali proprio perché non sono standardizzabili facilmente: cambiano spesso, richiedono interpretazione del contesto, coinvolgono informazioni incomplete o ambigue. Insistere per automatizzarle completamente porta a costi crescenti e a un’efficacia decrescente.
Un approccio diverso: core automatizzato, eccezioni gestite
Il Process Mining suggerisce un approccio più pragmatico e, paradossalmente, più efficace.
• Automatizzare in modo deciso le varianti più frequenti, dove il volume giustifica l’investimento e i pattern sono stabili e prevedibili.
• Trattare le varianti rare come eccezioni, lasciando spazio all’intervento umano o a soluzioni ibride che combinino AI e supervisione.
Questo non significa rinunciare all’automazione sulle eccezioni: significa non sprecare risorse per automatizzarle tutte completamente, ma costruire un sistema che le intercetti, le classifichi e le indirizzi nel modo giusto. È qui che gli agenti AI trovano il loro spazio naturale e mostrano una discontinuità reale rispetto alla generazione RPA precedente.
Dalla sequenza di task alla rete di agenti
I bot RPA tradizionali replicano sequenze di azioni predefinite: clic, lettura campi, compilazione form. Funzionano bene in contesti altamente stabili e ripetitivi. Fuori da quel perimetro, non sono in grado di dare risposte.
Gli agenti AI operano in modo diverso: interpretano il contesto, prendono decisioni sulla base di informazioni parziali, si coordinano con altri agenti. Non seguono un copione: ragionano su un obiettivo. Questo permette di costruire architetture ben più flessibili, che è esattamente ciò di cui i processi reali hanno bisogno.
In questo senso, è più corretto parlare di reti di agenti che operano in modo distribuito lungo il processo. Il Process Mining diventa la base progettuale di queste reti: identifica le attività chiave, mappa i punti decisionali, mostra come le informazioni fluiscono e dove si concentrano i colli di bottiglia.
Su questa base si può costruire un’architettura in cui:
• alcuni agenti classificano i casi in ingresso e li instradano sul percorso corretto;
• altri verificano la completezza e la coerenza dei dati;
• altri ancora eseguono le operazioni di processo o attivano escalation verso l’operatore umano quando necessario.
Un esempio concreto: gestione delle richieste di rimborso spese
Prendiamo un processo reale e ricorrente in molte aziende: la gestione delle note spese dei dipendenti.
L’analisi dei log su 24.000 richieste elaborate in un anno rivela che:
• il 71% segue un flusso standard (importo entro policy, documentazione completa, categoria riconosciuta): dalla sottomissione all’approvazione in meno di 24 ore;
• il 18% richiede una verifica aggiuntiva (importo borderline, categoria ambigua, scontrino illeggibile);
• l’11% devia significativamente (importo fuori policy, richiesta retroattiva, documentazione mancante).
In questo scenario, la rete di agenti si struttura in modo naturale:
• un agente di classificazione analizza ogni richiesta in ingresso e la assegna al percorso corretto;
• un agente di verifica gestisce il 71% standard in autonomia, end-to-end, richiedendo zero intervento umano;
• le richieste borderline vengono arricchite con un’analisi contestuale e presentate all’approvatore con una raccomandazione motivata;
• i casi anomali vengono segnalati al team di controllo con priorità e contesto già strutturati.
Il risultato non è solo efficienza. È anche maggiore controllo e tracciabilità: si sa esattamente dove e perché interviene l’uomo, e ogni decisione è documentata.
Meno intuizione, più evidenza
Il vero cambio di paradigma è questo: si passa da un’automazione guidata dall’intuizione e dalle opinioni dei referenti di processo a una guidata dall’evidenza dei dati.
Il Process Mining permette di vedere dove si concentra davvero il lavoro, capire quali attività sono stabili e ripetibili, evitare di investire su casi marginali. E, forse la cosa più controintuitiva, aiuta a fare una scelta che molti team faticano ad accettare: non tutto va automatizzato completamente. Accettarlo non è una sconfitta. È il prerequisito per costruire un’automazione che tenga.
Automazione sostenibile: dati, agenti, persone
Integrare Process Mining e agenti AI significa costruire un’automazione selettiva, resiliente e progettata per evolvere nel tempo senza richiedere riscritture continue.
Gli esseri umani restano nel loop — ma in un ruolo diverso, più utile: gestiscono le eccezioni che richiedono giudizio contestuale, supervisionano il sistema, contribuiscono al suo miglioramento continuo segnalando i casi che il modello non gestisce bene.
È questa combinazione — dati di processo, agenti capaci di ragionare, intervento umano mirato — a rendere l’automazione scalabile nel senso autentico del termine. Non perché si automatizza tutto, ma perché si sa con precisione cosa vale la pena automatizzare, quando, e in che modo.
La domanda giusta, alla fine, non è “quanto possiamo automatizzare?” ma “cosa ci dicono i dati su dove dovremmo farlo?”. Rispondere a questa domanda prima di scrivere una riga di codice o configurare un agente è la differenza tra un progetto che scala e uno che si inceppa al primo caso d’uso reale.
