RPA cos'è: quando il robot che clicca serve e quando basta un'API
Un robot che clicca al posto tuo funziona, finché nessuno cambia un pulsante. Ecco cos'è l'RPA, quando è l'unica strada e come scegliere rispetto alle API.
RPA cos'è, in parole semplici
RPA sta per Robotic Process Automation: un software che usa i programmi come farebbe una persona, muovendo il mouse, premendo tasti e leggendo lo schermo, per eseguire attività ripetitive e basate su regole. Non modifica il programma su cui lavora: ci sta sopra, dall'esterno. Per questo funziona anche dove non esiste altra porta d'ingresso.
Il «robot» non ha nulla di meccanico. È uno script, o un prodotto dedicato, che apre un gestionale, entra con un utente, cerca una fattura, copia un importo e lo incolla in un altro programma. Fa quello che faceva l'impiegato, ma senza stancarsi e senza distrarsi alle quattro del pomeriggio.
Un equivoco frequente riguarda l'intelligenza artificiale. L'RPA segue un percorso fisso, passo dopo passo. L'AI interpreta: legge una email e capisce che cosa chiede il cliente. Le due cose si possono unire, ma un'AI che «guarda» lo schermo e clicca resta, nella sostanza, un robot che clicca, con gli stessi limiti.
RPA cos'è in pratica: come lavora un robot che clicca
Il robot si muove nell'interfaccia, quella pensata per gli umani. Individua un campo dalla sua posizione, dal nome interno o dall'aspetto, ci scrive, passa alla schermata dopo, attende che si carichi, preme «Conferma». Se il percorso è sempre identico, il risultato è affidabile. Se qualcosa si discosta, il robot non ragiona: si ferma, oppure peggio, va avanti dove non dovrebbe.
I lavori adatti hanno un profilo preciso: riportare gli ordini da un portale del cliente al gestionale, scaricare ogni mattina un estratto da un sito che non offre altro, inserire righe in un programma vecchio che nessuno vuole toccare. Sono noiosi, regolari, con regole chiare. Proprio per questo l'RPA piace.
Automazione via API: cosa cambia davvero
Un'API è la porta di servizio di un programma. Invece di fingere di essere una persona davanti allo schermo, il tuo sistema parla direttamente con l'altro: «dammi gli ordini di oggi», «crea questo cliente». Nessun pulsante da cercare, nessuna pagina da attendere. Le informazioni passano in un formato pensato per le macchine, e chi ha costruito il programma si impegna, almeno in teoria, a mantenere quella porta stabile.
La differenza pratica si vede quando qualcosa cambia. Se il fornitore ridisegna la schermata, l'API non se ne accorge. Se aggiunge un campo obbligatorio, l'API di solito risponde con un errore leggibile, che si corregge. Il robot, nello stesso caso, magari clicca un pulsante spostato e nessuno lo sa fino a sera.
Strumenti come n8n nascono proprio per collegare programmi tramite le loro API: ne abbiamo parlato in n8n cos'è, cosa ci fai in azienda e quando conviene rispetto al codice.
RPA e API a confronto
| Aspetto | RPA (robot che clicca) | Automazione via API |
|---|---|---|
| Dove si aggancia | All'interfaccia visibile | Alla porta tecnica del programma |
| Serve la collaborazione del fornitore | No | Sì, l'API deve esistere ed essere abilitata |
| Se cambia la schermata | Spesso si rompe | Di norma non cambia nulla |
| Se cambia l'API | Non interessa | Si rompe, ma di solito con un errore leggibile |
| Velocità | Una operazione alla volta, come una persona | Di norma molto più rapida |
| Come ti accorgi di un guasto | Spesso tardi | Subito, se hai un controllo sugli errori |
| Manutenzione nel tempo | Interventi frequenti e difficili da prevedere | Più stabile, con aggiornamenti legati alle versioni dell'API |
La nostra posizione è netta: dove l'API esiste e fa quello che serve, si usa l'API. L'RPA non è una scorciatoia più economica, è un debito che si paga a rate, con gli interessi.
Perché l'RPA è fragile
Immagina un robot che ogni mattina entra in un portale fornitori, scarica gli ordini e li carica in azienda. Funziona per mesi. Poi il portale aggiunge un avviso sui cookie, o un secondo passaggio di verifica dell'accesso, o semplicemente rinomina un menu. Il robot non trova più il pulsante. Se è fatto bene, si ferma e manda un avviso. Se è fatto così così, resta in attesa in silenzio, e il giorno in cui qualcuno chiede «ma gli ordini di martedì?» scopri che nessuno li ha caricati da tre giorni.
Le cause della fragilità sono poche e ricorrenti:
- Dipendenza dall'aspetto. Il robot si appoggia a elementi che il fornitore considera liberi di cambiare.
- Tempi di attesa. Una pagina più lenta del solito, e il robot agisce prima che il campo sia pronto.
- Sessioni e accessi. Password che scadono, verifiche in due passaggi, utenti bloccati: il robot è un utente come gli altri e ne subisce le regole.
- La macchina su cui gira. Se lavora sullo schermo, ha bisogno di una sessione aperta: un riavvio dopo un aggiornamento o uno schermo bloccato bastano a fermarlo.
- Nessun contratto. Nessuno ti ha promesso che la schermata resterà com'è. Con un'API, almeno, qualcuno ha scritto una documentazione.
C'è poi un problema meno noto: il robot sa fare solo il percorso felice. Il caso strano, come il cliente senza partita IVA, l'importo con un decimale in più, l'ordine duplicato, lo conosce l'operatore, non lui. Prima di consegnare il lavoro a una macchina conviene mappare le eccezioni con chi ci lavora ogni giorno. Per decidere da dove cominciare c'è un metodo in quali processi automatizzare per primi in una PMI.
Se hai già un processo di questo tipo e non sai se tenerlo, rifarlo o sostituirlo, il punto di partenza è la mappatura di come il lavoro si svolge oggi, non lo strumento: è il lavoro delle automazioni su misura.
Quando l'RPA è l'unica strada
Esistono casi in cui il robot è la scelta giusta, e fingere il contrario sarebbe disonesto. Sono quasi sempre questi:
- Programmi senza alcuna porta tecnica. Un gestionale installato anni fa, che il fornitore non aggiorna più e che non espone nulla all'esterno.
- Portali di terzi che non controlli. Il portale di un cliente grande, di un ente o di un fornitore: puoi chiedere un accesso tecnico, ma raramente lo ottieni.
- Un ponte temporaneo. Il programma sarà sostituito a breve e non vale la pena costruire un'integrazione definitiva.
- Volumi bassi, rischio basso. Poche operazioni a settimana, dove un errore si nota e si ripara in fretta.
Nel primo e nel secondo caso l'RPA è davvero l'unica strada, ma va costruita sapendo che si romperà. Questo cambia il modo di farla: un controllo che confronta il risultato atteso con quello ottenuto, un messaggio chiaro quando qualcosa non torna, una persona con nome e cognome che riceve l'avviso. Un robot senza allarme non è un'automazione, è una scommessa.
Nel terzo caso, l'errore più comune è dimenticarsi del «temporaneo». Il ponte provvisorio resta in piedi per anni perché «tanto funziona», finché il collaboratore che lo conosceva se ne va.
Quattro domande per scegliere
Prima di decidere, fai queste domande, in quest'ordine:
- Il programma ha un'API, o una funzione di importazione ed esportazione ufficiale? Se sì, parti da lì. Spesso esiste e nessuno l'ha mai cercata. Chiedilo per iscritto al fornitore.
- Chi controlla l'interfaccia? Se è tua o di un fornitore che ti avvisa dei cambi, il rischio è gestibile. Se è di un terzo che non ti deve nulla, conta di dover riparare il robot più volte.
- Cosa succede se il processo si ferma per tre giorni? Se la risposta è «niente di grave», puoi permetterti un robot. Se sono fatture, ordini o scadenze, serve un'automazione con controlli seri o un'alternativa.
- Quanto durerà questo programma? Se verrà sostituito, non investire in un'integrazione elegante. Se resta per anni, il robot costerà più dell'integrazione fatta bene.
Resta il caso in cui il problema non è ripetere dei clic, ma leggere e capire documenti: preventivi, email, estratti. Lì l'AI fa la parte di comprensione, e il passaggio finale verso il programma va fatto via API quando possibile. Un esempio per un settore preciso è in automazioni per studi commercialisti.
La prima cosa da fare: scegli un solo processo manuale che ti irrita da mesi, scrivi il nome del programma coinvolto e manda al suo fornitore una domanda sola: «ha un'API o un'esportazione automatica, e dove trovo la documentazione?». La risposta ti dice già se ti serve un robot o un collegamento.
Domande frequenti
L'RPA è la stessa cosa dell'intelligenza artificiale?
No. L'RPA esegue un percorso fisso, passo dopo passo, come una persona che ripete la stessa procedura. L'AI interpreta contenuti, per esempio un testo o un documento. Possono lavorare insieme, ma sono cose diverse.
Meglio RPA o automazione via API?
Dove l'API esiste e copre ciò che serve, conviene l'API: è di norma più rapida, più stabile e i guasti sono più facili da individuare. L'RPA ha senso quando il programma o il portale non offre altra porta, o come ponte temporaneo.
Perché un robot RPA smette di funzionare?
Di solito perché l'interfaccia su cui si appoggia cambia: un pulsante spostato, un avviso nuovo, una verifica di accesso aggiuntiva. Anche pagine lente, password scadute e sessioni chiuse lo fermano. Per questo serve sempre un controllo che avvisi una persona.