Quando un'azienda ci chiama per portare l'AI nei processi, la prima riunione non parla mai di modelli. Parla di una lista. Qualcuno ha scritto su un foglio sei o sette attività che «si potrebbero automatizzare», e la domanda vera è quale viene prima.
A quella domanda, di solito, non risponde un metodo. Risponde chi ha spinto di più.
Come si sceglie davvero oggi
Nelle aziende che vediamo, il processo da automatizzare per primo viene scelto in tre modi. Nessuno dei tre è scritto da nessuna parte.
Lo sceglie il reparto più rumoroso. Il responsabile che ha portato il tema in direzione ottiene il progetto pilota. Non perché il suo processo sia il più adatto, ma perché era in quella stanza.
Lo sceglie il fornitore. Arriva chi vende una piattaforma, mostra tre casi d'uso che quella piattaforma sa fare bene, e la lista si accorcia da sola. La domanda «qual è il nostro processo più adatto» si trasforma silenziosamente in «quale dei nostri processi assomiglia alla demo».
Lo sceglie la visibilità. Si parte da ciò che si vede: il centralino, la mail, il documento che passa in dieci mani. Non da ciò che costa. Sono cose diverse, e quasi mai coincidono.
Il risultato lo conosci: il pilota funziona, viene presentato, e poi non scala. Non perché la tecnologia abbia fallito, ma perché nessuno saprebbe rifare la stessa scelta una seconda volta, su un altro processo, e difenderla.
Il problema non è la selezione sbagliata. È che la selezione non è ripetibile.
Un metodo, e da dove viene
Un gruppo di ricerca ha pubblicato l'8 settembre su arXiv un framework in quattro moduli per decidere quali processi automatizzare (arXiv 2609.09137). È pensato per gli ospedali statunitensi e per la RPA classica, non per gli agenti AI.
Dico subito da dove viene, perché conta. È applicato a un portafoglio sintetico di venti processi ospedalieri, non a dati veri. Gli autori scrivono a chiare lettere che si tratta di una sintesi concettuale della letteratura, non di uno strumento calibrato su dati ospedalieri primari. E l'affermazione che apre il lavoro — che il 30-50% delle iniziative RPA renda meno del previsto — non porta una fonte.
Quindi: i numeri di quel paper non valgono per la tua azienda, e nemmeno per un ospedale vero. Ma la struttura della decisione sì, ed è l'unica cosa che ci interessa prendere.
I quattro moduli sono: catalogare i processi, prioritizzarli, scegliere lo strumento, stimare il ritorno. Sembra ovvio scritto così. Non lo è: nella quasi totalità dei progetti che vediamo, i primi tre passaggi vengono saltati e si comincia dal quarto, con un ROI calcolato su un processo che nessuno ha mai descritto per intero.
Prima catalogare, poi scegliere
Il primo modulo costruisce una tassonomia: venti processi ricorrenti distribuiti su cinque flussi di valore.
L'operazione noiosa è anche quella che decide tutto. Finché i processi candidati non sono scritti nella stessa forma — chi li avvia, quante volte al mese, quanto durano, quante persone toccano, dove si rompono — non sono confrontabili. E se non sono confrontabili, l'unico criterio disponibile torna a essere chi ha parlato più forte.
In una PMI questo elenco non ha bisogno di essere lungo. Otto o dieci processi descritti in mezza pagina ciascuno bastano. Quello che non può mancare è la frequenza e il tempo-persona: sono i due numeri che quasi nessuno ha, e senza i quali ogni stima di risparmio è un'opinione.
Prioritizzare in modo che qualcuno possa contestarti
Il secondo modulo assegna a ogni processo un indice di idoneità all'automazione, usando una matrice di confronti a coppie con un controllo esplicito di coerenza.
Qui c'è il pezzo che vale la pena rubare, ed è meno tecnico di quanto sembri. Confrontare i criteri a due a due — conta di più il volume o il rischio di errore? il rischio di errore o la facilità di integrazione? — costringe a esprimere preferenze che, messe in fila, possono contraddirsi. Il controllo di coerenza serve a scoprirlo.
Ed è esattamente lì che si annidano le decisioni aziendali sbagliate: non nelle preferenze, ma nelle preferenze incompatibili fra loro che nessuno ha mai messo una accanto all'altra.
Nel portafoglio sintetico del paper, dodici processi su venti superano la soglia, e la classifica regge a perturbazioni dei pesi del ±20%. Prendi il secondo dato, non il primo: significa che una graduatoria costruita così non si ribalta se cambi un po' idea sull'importanza relativa dei criteri. È il minimo che si chieda a una decisione che dovrai difendere in consiglio fra sei mesi.
Lo strumento meno costoso che basta
Il terzo modulo è quello che, per un'azienda italiana, cambia di più le cose.
Raccomanda la tecnologia meno costosa sufficiente al profilo del processo — complessità, integrazione, conformità — e propone tre livelli: uno script in Python, un orchestratore open source come n8n, una piattaforma enterprise come UiPath.
In quest'ordine. Non nell'ordine del listino.
È l'inversione di come funziona il mercato. Normalmente si sceglie prima la piattaforma, poi si cercano processi che la giustifichino. Qui si descrive il processo, e la piattaforma diventa l'ultima risorsa: quella che si prende solo quando complessità, integrazioni o vincoli normativi la rendono davvero necessaria.
Sulla nostra scala — aziende dai venti ai duecento dipendenti — la maggior parte dei processi che arrivano in lista non ha bisogno del terzo livello. Ha bisogno del primo o del secondo. Il costo che conta non è la licenza: è che una piattaforma enterprise porta con sé un modello di governo, ruoli e un ciclo di rilascio che un'azienda da trenta persone non ha, e che finisce per non usare.
Il ritorno, e il punto in cui smette di crescere
Il quarto modulo stima risparmio di lavoro, costo degli errori evitati, tempo di rientro e valore attuale netto.
Due osservazioni, entrambe indipendenti dai numeri del paper.
La prima: nel loro portafoglio il valore marginale decresce man mano che la spesa cresce. Automatizzare i primi processi rende molto, gli ultimi molto meno. È un argomento contro il progetto unico e grande, e a favore di partire da pochi processi e fermarsi presto a rileggere i risultati.
La seconda: il framework marca alcuni processi come a rischio critico pur essendo idonei. Idoneo e prudente non sono la stessa cosa. Un processo può essere perfetto da automatizzare sulla carta e pessimo da cui cominciare, perché se sbaglia se ne accorge un cliente.
Come lo si fa in un'azienda da trenta persone
Il framework, così com'è, è sovradimensionato: matrici di confronto, simulazioni Monte Carlo e ottimizzazione di portafoglio non stanno in una PMI. Ma i quattro passaggi sì, ridotti all'osso:
- Scrivi otto processi nella stessa forma, con frequenza e tempo-persona. Mezza pagina l'uno.
- Decidi i criteri prima di guardare i processi, e mettili in ordine. Sono tre o quattro: volume, costo dell'errore, difficoltà di integrazione, sensibilità dei dati. Farlo dopo significa costruire la classifica attorno alla risposta che si era già scelta.
- Per i primi due processi in classifica, chiediti quale sia lo strumento più semplice che basta. Se la risposta è uno script, è uno script.
- Fissa prima come farai a sapere se ha funzionato. Un numero, misurato dove il processo tocca il cliente o il bilancio, non nella percezione del reparto.
Il passaggio che salta più spesso è il secondo. Ed è quello che trasforma una decisione difendibile in una preferenza mascherata da analisi.
In conclusione
La tecnologia per automatizzare oggi si trova. È diventata la parte facile. La parte difficile è sempre stata scegliere dove metterla, e su quella non è cambiato quasi niente: si decide in riunione, a voce, e la motivazione non viene scritta.
Il valore di un metodo come questo non sta nell'accuratezza dei suoi numeri — che, come abbiamo visto, in questo caso non si trasferiscono affatto. Sta nel fatto che rende la scelta verificabile da qualcun altro. Che è la sola difesa contro il progetto pilota che funziona benissimo e non scala mai.
Prima di chiedere quale tecnologia serve: sapresti spiegare, con criteri scritti prima, perché stai automatizzando quel processo e non un altro? Se la risposta richiede più di dieci minuti e coinvolge il nome di una persona invece di un numero, il problema non è ancora tecnologico.