Robotic process automation: la guida per le aziende

2026-08-18 · Tommaso Maria Ricci

Nella maggior parte delle aziende italiane che hanno provato la robotic process automation esiste un bot che nessuno tocca più. Gira di notte, sposta dati da un gestionale a un foglio, e se si rompe lo sistema il consulente che lo ha costruito tre anni fa. Nessuno sa dire quanto valga, nessuno sa dire cosa succederebbe spegnendolo. Non è un fallimento tecnologico: è un progetto che non ha mai avuto un proprietario dentro l'azienda.

Faccio l'imprenditore, ho fondato e gestito aziende, e lavoro con imprese che vogliono togliere lavoro ripetitivo dalle spalle delle persone senza aggiungere costo fisso. La robotic process automation è la tecnologia con il rapporto più alto tra risultato immediato e complessità tecnica: non richiede di rifare i sistemi, non richiede data scientist, e il risparmio si misura in ore già dal primo mese. È anche la tecnologia dove ho visto più soldi buttati, perché è facile automatizzare la cosa sbagliata e chiamarla innovazione.

Questa guida spiega cosa fa davvero un software robot, quali processi valgono la pena, come si calcola il ritorno, e soprattutto cosa cambia adesso che gli agenti basati su modelli linguistici stanno mangiando una parte del terreno storico della RPA. Non è una rassegna di prodotti. È il metodo che uso quando un'azienda mi chiede se conviene ancora partire.

Che cos'è la robotic process automation

La robotic process automation è una tecnologia software che replica le azioni che una persona esegue su un computer: aprire un'applicazione, leggere un campo, copiare un valore, incollarlo altrove, cliccare, salvare, inviare. Il robot non è un oggetto fisico. È uno script che lavora sull'interfaccia dei programmi esistenti, esattamente come farebbe un impiegato, ma senza pause e senza errori di distrazione.

La differenza rispetto a un'integrazione tradizionale è il punto in cui si attacca. Un'integrazione parla con il sistema attraverso le sue interfacce di programmazione, quindi richiede che quelle interfacce esistano, che qualcuno le documenti e che l'azienda abbia accesso al fornitore. Un robot RPA lavora dove lavora l'utente, sopra la superficie del software. Per questo si installa su gestionali vecchi, portali web di enti pubblici, applicazioni desktop senza API, tutto quel patrimonio informatico che nessun fornitore aggiornerà mai.

Da qui derivano i due tratti che decidono se il progetto vale: la RPA è veloce da mettere in piedi e fragile da mantenere. Veloce perché non tocca i sistemi sottostanti. Fragile perché dipende dalla forma dell'interfaccia: se il fornitore del gestionale sposta un pulsante, il robot si ferma.

La definizione tecnica e la panoramica delle componenti tipiche di una piattaforma, dal recorder all'orchestratore, sono ben sintetizzate nella scheda tecnica di IBM sulla robotic process automation, utile a chi deve spiegare la materia a un consiglio di amministrazione senza entrare nel merito dei fornitori.

I tre tipi di robot che vi verranno proposti

Il vocabolario commerciale confonde apposta. Nella pratica esistono tre configurazioni, con costi e implicazioni organizzative diverse.

Robot non presidiato. Gira da solo su un server o su una macchina virtuale, tipicamente di notte o a intervalli programmati. È la configurazione con il ritorno più alto perché lavora quando nessuno è in ufficio, ma richiede governance: qualcuno deve accorgersi se non parte.

Robot presidiato. Vive sul computer della persona e si attiva quando lei lo lancia, di solito con un pulsante. Serve nei processi dove serve un giudizio umano a metà strada, tipicamente il servizio clienti. Il ritorno è più basso ma l'adozione è più facile, perché l'operatore lo percepisce come un aiuto e non come una minaccia.

Robot ibrido. Una parte del flusso gira in autonomia, una parte si ferma e chiede a una persona. È la configurazione realistica per la maggior parte dei processi amministrativi italiani, dove l'eccezione è la norma e la delega piena non è accettabile.

La scelta non è tecnica, è organizzativa. Un robot non presidiato che elabora fatture senza controllo umano richiede una fiducia nel processo che quasi nessuna amministrazione ha il primo anno. Partire presidiati e passare al non presidiato quando i numeri lo giustificano è la sequenza che vedo funzionare più spesso.

RPA, intelligenza artificiale e agenti: dove passa il confine

Qui si concentra la confusione che costa di più, perché i fornitori vendono tutto sotto la stessa etichetta.

La RPA classica esegue regole deterministiche. Fa esattamente quello che è stato programmata a fare, sempre allo stesso modo. Non capisce, non decide, non improvvisa. Se il documento cambia formato, si ferma. Questo limite è anche la sua garanzia: il comportamento è prevedibile e verificabile, e in un processo amministrativo la prevedibilità vale più dell'intelligenza.

L'intelligenza artificiale tradizionale aggiunge percezione e classificazione. Lettura di documenti non strutturati, riconoscimento di categorie, previsioni su dati storici. Nel gergo commerciale la combinazione di RPA e modelli di questo tipo si chiama intelligent automation o iperautomazione, ed è il punto dove la maggior parte dei progetti seri si trova oggi.

Gli agenti basati su modelli linguistici pianificano. Ricevono un obiettivo, decidono i passi, usano strumenti, si adattano quando qualcosa cambia. Non richiedono che il flusso sia scritto in anticipo, e sopportano l'eccezione che manda in crisi un robot a regole.

La tentazione è concludere che gli agenti rendano la RPA obsoleta. Non è così, e chi lo dice sta vendendo. La regola pratica che uso è semplice: dove il processo è ripetitivo, ad alto volume e con esito verificabile a colpo d'occhio, la RPA resta più economica, più veloce e molto più facile da certificare in caso di verifica. Dove il processo è variabile, richiede lettura di testo libero e comporta decisioni, l'approccio a regole diventa una gabbia e conviene la strada agentica.

Il mercato sta imparando la lezione a proprie spese. Gartner prevede che oltre il quaranta per cento dei progetti di AI agentica sarà cancellato entro la fine del 2027 per costi fuori controllo, valore poco chiaro o controlli di rischio inadeguati, e segnala che gran parte dei fornitori che oggi si presentano come agentici stanno semplicemente rietichettando prodotti esistenti, inclusi i robot RPA di ieri. Chi valuta un'offerta oggi dovrebbe pretendere di vedere cosa succede quando il flusso incontra un caso non previsto: la risposta separa la sostanza dal marketing. Il quadro di come si costruisce un progetto agentico serio è nella mia guida agli agenti AI per le aziende.

Quali processi valgono davvero

Il criterio di selezione è più importante della tecnologia scelta. Un processo è un buon candidato quando soddisfa cinque condizioni contemporaneamente.

È basato su regole. Le decisioni si possono scrivere come condizioni esplicite. Se per descrivere il processo servono le parole "dipende" e "di solito" più di due volte, non è pronto.

Ha volume. Poche decine di esecuzioni all'anno non ripagano mai la costruzione e la manutenzione. La soglia dipende dalla durata dell'attività, ma sotto le duecento ore annue di lavoro umano il caso raramente regge.

Usa dati strutturati o strutturabili. Campi, tabelle, tracciati fissi. I documenti in formato libero richiedono un modulo di lettura intelligente, che aggiunge costo e incertezza.

È stabile. Se il processo cambierà tra sei mesi per una riorganizzazione o per un nuovo gestionale, automatizzarlo adesso significa pagare due volte.

È noioso e odiato. Non è un criterio sentimentale. I processi che le persone detestano sono quelli dove l'errore umano è più frequente e dove l'adozione interna sarà immediata invece che conflittuale.

Le famiglie di processi dove questi cinque criteri coincidono più spesso sono sempre le stesse: riconciliazione tra sistemi che non si parlano, inserimento di ordini ricevuti via email o portale, estrazione di dati da portali istituzionali, generazione e invio di report ricorrenti, controlli di completezza su anagrafiche, apertura e chiusura di utenze informatiche per nuovi assunti e dimissionari, solleciti di pagamento, caricamento di listini.

Il costo reale di un progetto RPA

Le voci in ordine di importanza, con le proporzioni che vedo ricorrere nel mercato italiano. Non sono preventivi, sono grandezze relative.

Licenza della piattaforma. Canone annuo per robot, spesso con un costo separato per l'orchestratore. È la voce che tutti confrontano e quasi mai quella che decide.

Sviluppo del primo processo. Analisi, disegno del flusso, costruzione, test. Un processo amministrativo di media complessità impegna tipicamente da due a sei settimane uomo. Il costo del primo processo è sempre più alto degli altri, perché include l'apprendimento della piattaforma.

Infrastruttura. Macchine virtuali, utenze dedicate, ambienti separati per test e produzione. Voce piccola in valore, grande in ritardi se l'informatica non è coinvolta dal primo giorno.

Manutenzione. È la voce sottovalutata sistematicamente. Ogni aggiornamento dei sistemi sottostanti può rompere un robot. Un portafoglio di robot in produzione richiede un presidio continuo, non un intervento occasionale, e chi non lo mette a budget scopre il problema quando il robot si ferma il giorno della chiusura contabile.

Gestione del cambiamento. Formazione, comunicazione, ridisegno dei ruoli. Se la persona che faceva quel lavoro non sa cosa farà dopo, il progetto genera resistenza indipendentemente dalla qualità tecnica.

I dati sui tempi di rientro raccontano una storia che vale la pena guardare in faccia. Nella ricerca Deloitte sull'automazione intelligente il periodo medio di payback dichiarato dalle organizzazioni in fase pilota è salito da sedici a ventidue mesi tra le due rilevazioni, mentre la riduzione di costo attesa su tre anni si attesta intorno al trenta per cento e viene sostanzialmente confermata da chi ha già scalato. La lettura corretta non è che la RPA non funziona: è che i pilota isolati rientrano lentamente, mentre chi arriva a un portafoglio di automazioni ottiene i numeri promessi. La stessa ricerca indica nella frammentazione dei processi la barriera più citata, davanti alla tecnologia.

Come si calcola il ritorno senza raccontarsi favole

La formula che uso in fase di business case è volutamente grezza, perché deve reggere una discussione con chi firma.

Prendete il numero di esecuzioni annue del processo, moltiplicatelo per i minuti di lavoro umano per esecuzione, e traducete in ore. Moltiplicate le ore per il costo orario pieno della persona che oggi lo fa, non per la sua retribuzione netta. A questo aggiungete due voci che quasi tutti dimenticano: il costo degli errori, stimato come numero di correzioni annue per il tempo medio di correzione, e il costo del ritardo, cioè quanto vale avere il dato disponibile la mattina invece che tre giorni dopo.

Dal totale sottraete la parte di processo che il robot non gestirà. È il numero che i fornitori arrotondano per eccesso. Un robot che copre l'ottanta per cento dei casi lascia il restante venti per cento a una persona che deve comunque conoscere il processo, quindi il risparmio non è mai proporzionale alla copertura.

Confrontate il risultato con il costo totale del primo anno, licenze e sviluppo e manutenzione inclusi. Se il rapporto non è almeno di due a uno sul primo processo, o il processo è sbagliato o la piattaforma è sovradimensionata. Il metodo completo di valutazione degli investimenti tecnologici, con le trappole di calcolo più comuni, è nella mia guida al ROI dell'intelligenza artificiale.

Un avvertimento sul risparmio dichiarato in teste. Quasi nessun progetto RPA italiano si traduce in riduzione di organico, e chi lo promette al consiglio di amministrazione crea un'aspettativa che non manterrà. Il beneficio reale è capacità liberata: le stesse persone assorbono più volume senza assunzioni, chiudono prima, e smettono di fare lavoro che le demotiva. Vale la pena scriverlo nel business case con queste parole, perché a consuntivo verrà confrontato con quello. E se il calcolo non torna, o non è chiaro dove il processo perde valore, conviene far analizzare i processi da qualcuno che non abbia una licenza da vendervi prima di impegnare il budget: una diagnosi indipendente si chiude in poche settimane e costa una frazione del primo anno di progetto.

Il contesto italiano, con i numeri

Vale la pena inquadrare dove siamo davvero, perché la percezione è più avanti dei fatti. Secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano, il mercato italiano dell'intelligenza artificiale ha raggiunto 1,8 miliardi di euro nel 2025 con una crescita del cinquanta per cento, e il settantuno per cento delle grandi imprese ha avviato almeno un progetto. Il dato che conta per chi legge questa guida è però l'altro: tra le piccole e medie imprese la quota resta a una cifra o poco sopra.

Questo divario spiega perché la RPA in Italia sia ancora una leva sensata e non una tecnologia superata. Nelle grandi imprese la discussione si è spostata sugli agenti perché i processi ad alto volume sono già automatizzati. Nella media impresa italiana, dove convivono un gestionale degli anni duemila, tre fogli di calcolo critici e una persona che tiene insieme tutto, il primo salto di produttività non è agentico: è togliere il lavoro di copia e incolla. Chi parte da qui trova il quadro complessivo nella mia guida all'intelligenza artificiale per le PMI.

Governance, controlli e rischi

Un robot è un utente informatico a tutti gli effetti, e quasi nessuna azienda lo tratta come tale. I punti che sollevo sempre in fase di disegno, in ordine di gravità.

Identità dedicata. Il robot deve avere una propria utenza nominale nei sistemi, mai le credenziali di una persona. Con le credenziali di un dipendente ogni operazione risulta compiuta da lui, il che rende impossibile ricostruire cosa ha fatto chi e rende il dipendente responsabile di azioni che non ha compiuto.

Gestione dei segreti. Le password dei sistemi non vanno scritte nel flusso. Vanno in un archivio credenziali gestito dalla piattaforma o dall'infrastruttura, con rotazione periodica.

Tracciabilità. Ogni esecuzione deve lasciare un registro consultabile: quando è partita, cosa ha toccato, come è finita. Serve alla diagnosi tecnica, ma serve soprattutto quando un revisore o un ispettore chiede come è stato prodotto un dato.

Segregazione dei compiti. Chi disegna il robot non dovrebbe essere l'unico a poterlo mandare in produzione. Nei processi contabili è un principio di controllo interno, non una formalità.

Gestione dell'errore. Ogni flusso deve prevedere cosa succede quando il sistema di destinazione non risponde o il dato è inatteso: fermarsi e notificare, oppure procedere e segnalare. Deciderlo prima evita il caso peggiore, che è un robot che continua a lavorare su dati sbagliati per una settimana.

Dati personali. Se il flusso tocca dati di dipendenti, clienti o pazienti, il trattamento va documentato con la stessa serietà di qualsiasi altro sistema. L'automazione non crea un'esenzione, e nella pratica aumenta il volume dei dati trattati e la velocità con cui un errore si propaga.

Continuità. Un robot che regge un processo critico va documentato al punto che una persona possa rifare il lavoro a mano in caso di fermo prolungato. La procedura manuale di emergenza va scritta e provata, non immaginata.

Gli errori che bruciano il budget

Dalla pratica, in ordine di costo.

Automatizzare un processo rotto. Se il flusso attuale ha passaggi inutili ereditati da una vecchia organizzazione, il robot li eseguirà più in fretta e per sempre. Prima si semplifica, poi si automatizza. Nella metà dei casi la semplificazione da sola produce buona parte del beneficio atteso, e il progetto tecnologico si ridimensiona.

Partire dal processo più complesso. La spinta interna porta sempre verso il caso più doloroso, che è anche il meno adatto al primo tentativo. Il primo processo deve funzionare, perché sarà la prova che convincerà tutti gli altri.

Non nominare un proprietario interno. Se la competenza resta solo nel fornitore, l'azienda non potrà mai modificare un flusso senza aprire un ticket a pagamento. È il modo più rapido per trasformare un risparmio in una dipendenza.

Sottovalutare la manutenzione. Un portafoglio di dieci robot non è dieci volte un robot: è un piccolo sistema informativo con dipendenze, priorità e guasti. Senza presidio, la disponibilità crolla nel giro di un anno.

Contare il risparmio in teste. Genera resistenza interna immediata e non si realizza quasi mai. Contate ore liberate e capacità aggiuntiva.

Ignorare chi faceva il lavoro. Le persone che eseguono il processo conoscono le eccezioni che non stanno in nessuna procedura. Se vengono escluse dall'analisi, quelle eccezioni si presenteranno in produzione.

Comprare la piattaforma prima di aver scelto i processi. L'ordine corretto è inverso. La scelta del fornitore dipende dal tipo di processi, dai sistemi coinvolti e dai volumi, non dal quadrante di un analista.

Non misurare il punto di partenza. Senza il tempo attuale per esecuzione, il numero di errori e il tempo di attraversamento, tra un anno il beneficio sarà un'opinione. E le opinioni non superano la revisione del budget.

Scorecard di autovalutazione

Assegnate 0 se falso, 1 se in parte, 2 se vero. Massimo 40 punti.

Processi

Esiste una mappa scritta dei processi amministrativi con i volumi annui.
Almeno un processo supera le duecento ore uomo all'anno ed è basato su regole.
Le eccezioni dei processi candidati sono state elencate e quantificate.
Il processo candidato non cambierà nei prossimi dodici mesi per riorganizzazione o cambio di sistema.
Il processo è stato semplificato prima di essere considerato per l'automazione.

Dati e sistemi

I sistemi coinvolti sono identificati con versione e fornitore.
È chiaro se esistono interfacce di programmazione utilizzabili in alternativa al robot.
Gli ambienti di test sono disponibili e separati dalla produzione.
I dati in ingresso sono strutturati o riconducibili a un tracciato fisso.

Organizzazione

Esiste un proprietario interno del progetto con nome e cognome.
L'informatica interna o il fornitore di sistemi è stato coinvolto prima della scelta della piattaforma.
Chi esegue oggi il processo è coinvolto nell'analisi.
È chiaro cosa faranno le persone con il tempo liberato.
Esiste un budget di manutenzione annuo, non solo di progetto.

Governance

È previsto un account dedicato per il robot.
Le credenziali sono gestite in un archivio protetto.
Ogni esecuzione produce un registro consultabile.
È definito il comportamento in caso di errore.

Misurazione

Il tempo attuale per esecuzione è misurato, non stimato.
Il numero di errori e rilavorazioni annue è misurato.

Come leggere il punteggio. Sotto 14: il problema non è la piattaforma, è che i processi non sono descritti in forma esplicita. Comprare adesso significa pagare la mappatura al prezzo di un progetto. Tra 14 e 28: la base esiste ma manca quasi sempre la parte di governance o quella di manutenzione, ed è dove il progetto si degrada dopo il primo anno. Sopra 28: potete partire con un pilota e ragionare da subito su un portafoglio, non su un singolo bot.

Roadmap 30, 60, 90 giorni

Questa è la sequenza che uso per portare un'azienda dal primo interesse a un robot in produzione con numeri difendibili.

Giorni 1-30: selezione e baseline

Mappate i processi candidati con tre dati per ciascuno: esecuzioni annue, minuti per esecuzione, numero di errori o rilavorazioni.
Scartate i processi che cambieranno entro l'anno e quelli sotto la soglia di volume.
Scegliete un solo processo pilota, il più noioso tra quelli stabili, non il più critico.
Scrivete il processo passo per passo, comprese le eccezioni, insieme a chi lo esegue oggi.
Semplificate il flusso a mano. Quello che resta è ciò che va automatizzato.
Registrate la baseline: tempo, errori, tempo di attraversamento. Serve firmata, non a memoria.

Giorni 31-60: costruzione del pilota

Predisponete ambiente di test, utenza dedicata e gestione delle credenziali prima di scrivere una riga di flusso.
Costruite il robot sul percorso principale, senza inseguire tutte le eccezioni. Il primo obiettivo è coprire il caso normale.
Definite il comportamento di errore e le notifiche.
Fate girare il robot in parallelo alla persona per due o tre settimane, confrontando gli esiti. Ogni scostamento è un'eccezione non codificata.
Formate il proprietario interno mentre si costruisce, non alla consegna.

Giorni 61-90: produzione e portafoglio

Passate il pilota in produzione con un periodo di sorveglianza dichiarato.
Misurate le stesse metriche della baseline e calcolate il ritorno reale.
Documentate il flusso al livello che permette a un'altra persona di manutenerlo.
Scrivete la procedura manuale di emergenza e provatela una volta.
Selezionate i due processi successivi con lo stesso metodo, riusando i componenti già costruiti.
Portate al vertice un documento con baseline, risultato e piano dei prossimi sei mesi. È il momento in cui il progetto diventa programma oppure muore.

Alla fine dei novanta giorni l'azienda dovrebbe avere un robot in produzione, un proprietario interno formato, numeri confrontati con il punto di partenza e una lista di candidati successivi. Chi arriva qui senza uno di questi quattro elementi ha comprato un bot, non una capacità.

Dove funziona meglio, settore per settore

Le differenze contano nella selezione dei processi, e trattare tutti i settori allo stesso modo è l'errore più costoso.

|---|---|---|---|

Nell'amministrazione e nella contabilità la RPA resta il caso d'uso più solido in assoluto, perché i processi sono ripetitivi, normati e ad alto volume. Chi lavora su questo perimetro trova un approfondimento nella mia guida all'intelligenza artificiale per la contabilità.

Nella logistica il fattore critico è la fragilità: i portali dei clienti cambiano senza preavviso, quindi il costo di manutenzione va stimato più alto della media e il presidio deve essere reattivo.

Nelle assicurazioni e nel credito la RPA da sola copre solo la parte a valle. La parte che vale davvero è la lettura dei documenti, che richiede modelli e non regole, e che porta il progetto dentro il perimetro della digitalizzazione dei processi aziendali invece che dentro un progetto RPA puro.

Casi reali

Esempi presi dal lavoro diretto, con i dettagli identificativi rimossi dove il cliente ha preferito così. Non sono progetti di sola automazione: sono situazioni in cui togliere lavoro ripetitivo ha spostato un numero.

Centro medico, capacità aumentata di circa il venti per cento. Nessuna sala in più, nessun professionista aggiuntivo. Le leve sono state il recupero automatico degli slot liberati dalle disdette, i promemoria che hanno ridotto le mancate presentazioni e l'allineamento degli orari del personale alla domanda reale. La parte automatizzata era interamente a regole, il che l'ha resa verificabile dalla direzione sanitaria senza discussioni sulla tecnologia.

Gruppo alberghiero, ricavi passati da nove a dieci milioni. La leva principale è stata commerciale, sul canale diretto contro l'intermediazione. Sul lato amministrativo il contributo è arrivato dal togliere alla reception e all'amministrazione ore di riconciliazione tra portali, gestionale e banca, ore che sono tornate al cliente e al controllo dei prezzi.

Organizzazione sportiva e retail, vendite in crescita di circa il trenta per cento. Qui la leva è stata la velocità di iterazione sulle campagne. L'effetto collaterale rilevante è che la reportistica commerciale, prima costruita a mano ogni lunedì, è diventata automatica: la squadra ha smesso di discutere quali numeri fossero giusti e ha iniziato a discutere cosa farne.

Agriturismo, ospiti circa raddoppiati. Struttura piccola, budget minimo, nessuna piattaforma costosa. Il lavoro è stato tutto sul processo, con strumenti elementari. Serve a ricordare che sotto una certa scala la RPA non è la risposta: un flusso ben disegnato con gli strumenti che l'azienda già paga batte una licenza nuova, sempre.

Il filo comune: in tutti e quattro i casi il risultato è arrivato dal togliere lavoro manuale su un processo ripetitivo e stabile, e dal restituire quel tempo a un'attività che genera ricavo. La sofisticazione tecnologica è arrivata dopo, dove c'era volume sufficiente a giustificarla. Chi vuole il quadro metodologico completo lo trova nella mia guida all'automazione dei processi aziendali con l'AI.

Come si sceglie il fornitore

Non farò una classifica, perché invecchia in un trimestre e perché il quadrante giusto per un'impresa da mille dipendenti è quello sbagliato per una da cinquanta. Do i criteri, che invece reggono.

Modello di licenza compatibile con la scala. Alcune piattaforme hanno un costo di ingresso pensato per portafogli da decine di robot. Sotto quella soglia il canone divora il beneficio del primo processo.

Competenza disponibile sul mercato locale. Se l'unico partner capace di manutenere quella piattaforma è a mille chilometri o è un solo professionista, avete comprato un rischio.

Trasferibilità delle competenze. Chiedete quante giornate servono perché una persona interna diventi autonoma su modifiche semplici. Se la risposta è vaga, il fornitore vive di manutenzione.

Gestione delle eccezioni e visibilità. Chiedete di vedere il pannello dove si controllano le esecuzioni fallite. È lì che vivrà il vostro proprietario interno, non nel recorder.

Percorso verso l'automazione intelligente. Se in due anni servirà leggere documenti o gestire casi variabili, la piattaforma deve permetterlo senza rifare tutto. Le analisi di mercato indipendenti come la valutazione Forrester sui fornitori RPA servono a questo, a capire la traiettoria del prodotto, non a scegliere il vincitore.

Costo di uscita. Chiedete prima di firmare come si esportano i flussi e cosa resta accessibile alla scadenza. Un fornitore che rende difficile uscire userà quel potere al rinnovo.

Prima di partire

Checklist finale, dieci punti, da usare come ultimo controllo prima di firmare qualsiasi contratto.

Avete un processo candidato con volumi misurati, non stimati a memoria.
Il processo è stato semplificato prima di essere considerato.
Le eccezioni sono state elencate e sapete quale percentuale del volume rappresentano.
Esiste un proprietario interno con nome, cognome e tempo dedicato.
L'informatica interna conosce il progetto e ha detto sì all'infrastruttura.
È previsto un account dedicato al robot e una gestione sicura delle credenziali.
La manutenzione è a budget per almeno tre anni, non solo il primo.
La baseline è registrata e firmata.
Sapete cosa faranno le persone con il tempo liberato, e loro lo sanno.
Avete definito il numero che deve migliorare perché il progetto si consideri riuscito.

Se cinque di questi dieci punti sono aperti, il progetto non è pronto. Partire adesso significa pagare due volte: una per la licenza, una per rifare l'analisi tra un anno. In quel caso la mossa più economica è far guardare i processi a qualcuno che non ha interesse a vendervi una piattaforma. Una diagnosi seria si chiude in poche settimane e costa una frazione di un anno di licenze inutilizzate.

E se invece i dieci punti sono in ordine, la raccomandazione è opposta: non aspettate il progetto perfetto. Il valore della robotic process automation non sta nel singolo robot, sta nel costruire dentro l'azienda l'abitudine a guardare un processo e chiedersi quale parte non ha bisogno di una persona. Quella capacità, una volta acquisita, si applica a tutto quello che verrà dopo, agenti compresi.

FAQ

Che cos'è la robotic process automation in parole semplici?

La robotic process automation è un software che replica le azioni che una persona compie su un computer: apre programmi, legge campi, copia dati, compila moduli, invia email. Non è un robot fisico e non è intelligenza artificiale in senso stretto, perché segue regole scritte in anticipo e non prende decisioni autonome. Il suo vantaggio è che lavora sopra i sistemi esistenti senza modificarli, quindi funziona anche con gestionali vecchi e portali senza interfacce di programmazione. Il suo limite è che si ferma quando l'interfaccia o il dato cambiano forma.

Che differenza c'è tra RPA e intelligenza artificiale?

La RPA esegue, l'intelligenza artificiale interpreta. Un robot RPA fa sempre gli stessi passi nello stesso ordine e il suo comportamento è prevedibile e verificabile. Un modello di AI classifica, legge testo non strutturato o fa previsioni, quindi produce risultati probabilistici che vanno controllati. Gli agenti basati su modelli linguistici aggiungono la capacità di pianificare i passi da soli. Nella pratica le tre tecnologie si combinano: il modello legge il documento, il robot esegue l'inserimento, la persona valida le eccezioni.

Quanto costa un progetto di robotic process automation?

Le voci sono quattro: licenza annua della piattaforma per robot, sviluppo del primo processo, che impegna tipicamente da due a sei settimane uomo per un flusso amministrativo di media complessità, infrastruttura, e manutenzione ricorrente. È quest'ultima la voce che decide se il progetto regge nel tempo, perché ogni aggiornamento dei sistemi sottostanti può rompere un flusso. Il costo del primo processo è sempre più alto dei successivi, quindi valutare il ritorno su un solo bot penalizza il caso reale.

Quali processi conviene automatizzare per primi?

Quelli che soddisfano cinque condizioni insieme: sono basati su regole scritte, hanno volume sufficiente, tipicamente sopra le duecento ore uomo all'anno, usano dati strutturati, non cambieranno nei prossimi dodici mesi e sono percepiti come noiosi da chi li esegue. Le famiglie più ricorrenti sono riconciliazioni tra sistemi che non si parlano, inserimento ordini, estrazione dati da portali, report ricorrenti e gestione delle utenze informatiche. I processi critici e complessi vanno affrontati per secondi, mai per primi.

La robotic process automation è superata dagli agenti AI?

No, ma il perimetro si è ristretto. Dove il processo è ripetitivo, ad alto volume e con esito verificabile, la RPA resta più economica, più prevedibile e molto più facile da difendere in caso di verifica o ispezione. Dove il processo è variabile, richiede lettura di testo libero e comporta decisioni, l'approccio a regole diventa una gabbia e conviene un agente. Attenzione al marketing: molti prodotti presentati oggi come agentici sono automazioni a regole rietichettate, e il modo per accorgersene è chiedere cosa succede davanti a un caso non previsto.

Quanto tempo serve per mettere in produzione il primo robot?

Un processo amministrativo stabile, selezionato bene e già semplificato, arriva in produzione in novanta giorni: circa un mese per selezione, analisi e baseline, un mese per la costruzione e i test in parallelo con la persona, un mese di sorveglianza in produzione e misurazione. I progetti che promettono la produzione in due settimane stanno saltando l'analisi delle eccezioni, ed è esattamente lì che i robot si fermano il primo giorno di picco.

La RPA elimina posti di lavoro?

Nella pratica italiana quasi mai si traduce in riduzione di organico, e promettere quel risparmio al vertice crea un'aspettativa che non si realizza. Il beneficio reale è capacità liberata: le stesse persone assorbono più volume senza assunzioni e smettono di fare il lavoro che le demotiva. Il rischio vero non è il licenziamento, è la resistenza: se chi esegue il processo non sa cosa farà con il tempo liberato, non collaborerà all'analisi e le eccezioni che conosce resteranno fuori dal flusso.

Serve un fornitore esterno o si può fare in casa?

Il primo processo conviene farlo con qualcuno che abbia già costruito flussi in produzione, perché gli errori di impostazione si pagano per anni. La condizione da mettere nel contratto è il trasferimento di competenza: una persona interna deve diventare autonoma sulle modifiche semplici entro la fine del pilota. Senza questa clausola ogni cambiamento futuro, anche di un campo, passerà da un ticket a pagamento, e il risparmio del progetto si trasformerà in una dipendenza costosa dal fornitore.