Business process automation: quali processi automatizzare davvero in una PMI

La business process automation promette una cosa semplice: togliere alle persone il lavoro ripetitivo e affidarlo al software. Nella pratica italiana accade spesso l’opposto. Si compra uno strumento, si automatizza il processo sbagliato, e dopo qualche mese qualcuno lo disattiva perché genera più eccezioni di quante ne risolva. Il problema quasi mai è la tecnologia. È che nessuno ha messo per iscritto, prima di iniziare, quale processo valeva la pena automatizzare, chi ne risponde quando si rompe e cosa succede sul piano legale quando una decisione che riguarda una persona la prende una macchina. Questo articolo affronta esattamente quei tre punti, con i dati aggiornati sul mercato italiano e con quello che ho visto funzionare, e fallire, in trent’anni di progetti.

Business process automation: che cos’è davvero

La business process automation, abbreviata in BPA, è l’uso di tecnologia per eseguire in modo automatico sequenze di attività aziendali che oggi richiedono intervento manuale. Non è un prodotto che si compra. È una strategia che si applica a un processo specifico, con un obiettivo dichiarato e un modo per misurare se ha funzionato.

La distinzione conta perché sposta la conversazione. Quando un imprenditore dice “voglio fare automazione dei processi aziendali”, nella sua testa c’è quasi sempre un software. Quando un consulente onesto sente quella frase, la prima domanda che fa non riguarda lo strumento ma il processo: come funziona adesso, quante volte al mese viene eseguito, quanto tempo consuma per singola esecuzione, quante volte devia dal percorso previsto e chi decide cosa fare quando devia. Senza quelle cinque risposte, qualsiasi strumento è una scommessa.

La differenza tra BPA, RPA e BPM che conta davvero

I tre acronimi vengono usati come sinonimi e non lo sono. La differenza pratica è questa.

Il business process management (BPM) è la disciplina che mappa, misura e migliora i processi. Non richiede tecnologia. Un’azienda può fare ottimo BPM con un foglio di carta, intervistando chi esegue il lavoro e ridisegnando i passaggi. È lo strato di pensiero.

La business process automation è ciò che accade quando si decide di far eseguire quel processo, in tutto o in parte, a un sistema. Lavora sul flusso completo, attraversa reparti, integra sistemi diversi, gestisce approvazioni e condizioni.

La robotic process automation (RPA) è una tecnica specifica dentro la BPA: un software che imita le azioni di un utente sull’interfaccia di altri programmi. Copia un dato da un gestionale, lo incolla in un portale, clicca invia. È utilissima quando due sistemi non hanno modo di parlarsi. È anche la più fragile, perché dipende dall’aspetto grafico dei programmi che pilota: basta un aggiornamento che sposti un pulsante e il robot si ferma.

Detto in modo brutale: il BPM decide cosa fare, la BPA lo fa accadere, l’RPA è l’attrezzo che si usa quando non esiste una strada migliore. Chi parte dall’attrezzo costruisce automazioni che nessuno ha progettato.

I tre livelli di automazione dei processi

Nella pratica, i progetti si collocano su tre livelli di complessità crescente, e conoscerli evita di promettere il terzo quando il budget e la maturità organizzativa reggono solo il primo.

• Automazione di attività: un singolo passaggio isolato. L’invio di una conferma, la generazione di un documento, il salvataggio di un allegato nella cartella giusta. Si implementa in giorni, il rischio è basso, il beneficio è reale ma limitato.
• Automazione di flusso: una sequenza con condizioni e approvazioni. La richiesta di ferie che passa dal responsabile, poi all’amministrazione, poi al calendario condiviso. Qui si comincia a toccare l’organizzazione, non solo il software.
• Automazione di processo end to end: l’intero ciclo attraversa più reparti e più sistemi. Dall’ordine del cliente alla consegna alla fatturazione all’incasso. È dove si trova il valore vero ed è anche dove i progetti muoiono, perché richiede che qualcuno abbia autorità su tutti i reparti coinvolti.

A questi tre si è aggiunto negli ultimi tempi un quarto livello, l’automazione basata su agenti, in cui il sistema non esegue una regola scritta ma decide autonomamente la sequenza da seguire. È promettente ed è ancora immatura per la maggior parte delle piccole e medie imprese. Se vuoi capire dove si colloca rispetto al resto, ne ho scritto in modo esteso nella guida completa all’automazione con intelligenza artificiale.

Perché in Italia l’automazione dei processi resta ferma

Qui i numeri servono, perché smontano due luoghi comuni opposti: quello di chi pensa che ormai automatizzino tutti e quello di chi pensa che sia roba da multinazionali.

Secondo i dati dell’Osservatorio Intelligent Business Process Automation del Politecnico di Milano, il 62% delle grandi imprese italiane utilizza almeno una tecnologia di process automation, in crescita di dieci punti rispetto all’anno precedente, ma solo l’8% ha un’adozione su larga scala guidata da una visione strategica. Tra le piccole e medie imprese la quota scende al 15%, con una spesa media annua sotto i diecimila euro, come riportato nell’analisi dell’Osservatorio sul mercato italiano.

Il dato interessante non è il 15%. È l’8%. Significa che anche tra le aziende grandi, che hanno budget e persone dedicate, nove su dieci stanno automatizzando pezzi scollegati senza un disegno complessivo. La business process automation, nella maggior parte dei casi italiani, è un insieme di cerotti tecnologici, non una strategia.

Il quadro si completa con la fotografia dell’adozione tecnologica generale. I dati Istat sulle imprese e le tecnologie dell’informazione mostrano che nel 2025 il 16,4% delle imprese italiane con almeno dieci addetti utilizzava sistemi di intelligenza artificiale, il doppio rispetto all’8,2% dell’anno precedente, con un divario netto tra grandi imprese (53,1%) e piccole e medie (15,7%). Tra gli ostacoli dichiarati da chi ci ha pensato e non ha proceduto, il primo è la mancanza di competenze adeguate, indicata dal 58,6%, seguita dalla mancanza di chiarezza normativa al 47,3%, secondo il comunicato Istat su imprese e ICT.

Vale la pena leggere quei due ostacoli insieme. Le aziende non si fermano perché la tecnologia costa troppo o non funziona. Si fermano perché non sanno chi la governa dentro casa e perché non sanno se quello che stanno per fare sia consentito. Sono due problemi di progetto, non di software, e sono esattamente i due che il mercato dell’automazione tende a non affrontare.

Quali processi automatizzare per primi: quattro filtri

Nella mia pratica uso quattro filtri in sequenza. Un processo deve passarli tutti e quattro per meritare l’investimento. Se ne fallisce anche uno, va rimandato o ridisegnato prima di essere automatizzato.

Primo filtro: frequenza per tempo unitario

Non conta quanto un’attività sia noiosa. Conta il prodotto tra quante volte viene eseguita e quanto tempo consuma ogni volta. Un’attività che richiede due ore ma capita tre volte l’anno vale sei ore. Un’attività da quattro minuti che capita cinquanta volte al giorno vale oltre settecento ore l’anno. La seconda è il candidato, anche se nessuno se ne lamenta, proprio perché nessuno se ne lamenta: il costo è diluito e invisibile.

Il calcolo va fatto con un cronometro, non a memoria. Le stime a memoria sui tempi di processo, nella mia esperienza, sbagliano sistematicamente per difetto sulle attività frequenti e per eccesso su quelle rare.

Secondo filtro: stabilità della regola

Un processo si automatizza bene se la regola che lo governa è stabile e scrivibile. “Se l’importo supera la soglia, l’approvazione passa al responsabile” è una regola. “Dipende, di solito ci pensa Marco che sa come si fa” non lo è. Non perché Marco sbagli, ma perché il suo criterio non è esplicito e quindi non è trasferibile a un sistema.

Quando la regola non è stabile, il lavoro da fare non è automatizzare. È tirare fuori il criterio dalla testa di Marco e metterlo per iscritto. Spesso quella sola operazione produce già metà del beneficio atteso, perché rende il processo eseguibile anche quando Marco è in ferie.

Terzo filtro: costo dell’errore

Ogni automazione sbaglierà. La domanda non è se, ma quanto costa quando succede e quanto tempo passa prima che qualcuno se ne accorga. Un’automazione che sbaglia l’invio di una newsletter costa imbarazzo. Un’automazione che sbaglia l’emissione di una fattura costa una nota di credito e una telefonata. Un’automazione che sbaglia la sospensione di un servizio a un cliente costa il cliente.

Il costo dell’errore non è un motivo per non automatizzare. È il motivo per cui alcuni processi vanno automatizzati con un punto di controllo umano prima dell’azione irreversibile, mentre altri possono girare completamente da soli. Il progetto deve dire quale delle due cose sia, e deve dirlo prima.

Quarto filtro: chi possiede il processo

Un processo automatizzato deve avere un proprietario interno con nome e cognome, che risponde di come funziona, che riceve le segnalazioni quando devia e che ha l’autorità di fermarlo. Se il proprietario è “il fornitore”, il progetto è già fragile. Se il proprietario è “l’ufficio IT” ma il processo è di amministrazione, il progetto è già fragile in modo diverso.

Questo è il filtro che più spesso viene ignorato ed è quello che uccide più progetti. La tecnologia regge. È la catena di responsabilità che si spezza, di solito nel momento peggiore.

Quando l’automazione dei processi è la scelta sbagliata

Nel mercato dell’automazione quasi nessuno ha interesse a dire quando non serve. Lo dico io, perché il progetto che non parte costa meno di quello che parte male.

Il primo caso è il processo rotto. Automatizzare un processo mal disegnato non lo aggiusta, lo accelera. Se oggi ogni pratica passa da tre persone che si rimbalzano la responsabilità, l’automazione produrrà lo stesso rimbalzo alla velocità della luce, con in più la difficoltà di capire dove si è inceppata. Prima si semplifica il flusso, poi lo si automatizza. Sempre in quest’ordine.

Il secondo caso è il processo che sta per cambiare. Se l’azienda ha in programma di sostituire il gestionale entro l’anno, costruire automazioni su quel gestionale significa buttare via il lavoro. Sembra ovvio scritto qui. Non lo è quando la scelta di cambiare gestionale la fa l’amministrazione e il progetto di automazione lo segue il marketing.

Il terzo caso è il processo a bassissimo volume con alta variabilità. Quello dove ogni pratica è diversa dall’altra. Lì l’automazione diventa un labirinto di eccezioni che nessuno riesce più a manutenere, e la persona che esegue il lavoro ci mette meno a farlo a mano che a spiegare al sistema perché stavolta è diverso.

Il quarto caso è quello culturalmente più scomodo: il processo che esiste solo per giustificare un ruolo. Automatizzarlo apre un problema organizzativo che il progetto tecnico non è attrezzato a risolvere. Va affrontato prima, con chiarezza, altrimenti l’automazione verrà sabotata in modo passivo da chi la vive come una minaccia. Ho visto succedere più volte di quante mi faccia piacere ricordare.

Gli otto passaggi di un progetto di business process automation che regge

Superati i filtri, il progetto ha una sequenza che conviene rispettare. Non è burocrazia: ogni passaggio saltato si ripresenta più avanti moltiplicato.

1. Mappare il processo come è davvero, non come dovrebbe essere secondo la procedura scritta. La differenza tra i due si scopre solo osservando chi lavora, e in quella differenza si nascondono le eccezioni che faranno saltare l’automazione.
2. Definire l’obiettivo in una metrica sola. Ridurre il tempo di evasione da tre giorni a uno. Portare gli errori di inserimento sotto l’uno per cento. Un obiettivo, misurabile, con il valore di partenza rilevato prima di toccare qualsiasi cosa. Senza valore di partenza non esiste ritorno dimostrabile.
3. Scegliere lo strumento dopo aver definito il processo, mai prima. Lo strumento giusto è quello che parla con i sistemi che l’azienda ha già, non quello con la demo più convincente.
4. Assegnare ruoli espliciti: chi possiede il processo, chi mantiene l’automazione, chi riceve gli avvisi di errore, chi ha l’autorità di fermarla. Quattro nomi, scritti.
5. Coinvolgere chi esegue il lavoro dal primo giorno. Le persone che oggi fanno l’attività a mano conoscono le eccezioni che nessun documento riporta. Sono la fonte più preziosa del progetto e, se escluse, la resistenza più efficace.
6. Progettare la gestione delle eccezioni prima del percorso principale. Il percorso felice è la parte facile. Il progetto vive o muore su cosa succede quando il dato manca, il sistema non risponde, l’importo è anomalo.
7. Partire in piccolo con un periodo in doppio binario, in cui automazione e processo manuale girano insieme e si confrontano i risultati. È il modo meno costoso per scoprire le differenze tra ciò che si era progettato e ciò che accade.
8. Prevedere manutenzione e piano di rientro. Le automazioni si rompono quando cambia un’interfaccia, scade una credenziale, un fornitore aggiorna una API. Serve sapere in anticipo chi interviene, in quanto tempo, e come si torna a lavorare a mano nel frattempo.

L’ottavo punto è quello che nei preventivi sparisce per primo e nella realtà pesa di più. Un’automazione non è un’opera finita, è un impianto che va tenuto acceso. Chi la vende come progetto chiuso sta spostando un costo dal proprio preventivo al bilancio del cliente.

L’automazione come superficie d’attacco: quello che non entra nei preventivi

Arriviamo alla parte che nella letteratura sulla business process automation manca quasi sempre, e che invece dovrebbe stare in prima pagina.

Per automatizzare un processo bisogna dare a un software le credenziali per agire al posto di una persona. Accesso al gestionale, al CRM, alla casella di posta, spesso al portale della banca o dei pagamenti. Quelle credenziali stanno da qualche parte, hanno certi permessi, e vengono usate ventiquattro ore al giorno senza che nessuno guardi. Il punto lo dico da tecnico che si occupa anche di sicurezza offensiva: un’automazione mal configurata è uno dei modi più eleganti per prendere il controllo di un’azienda, perché è un accesso legittimo, sempre attivo e mai sospetto.

Le tre cose che vedo sbagliate più spesso sono sempre le stesse. La prima: l’automazione gira con un utente amministratore perché “così funziona di sicuro”, quando le servirebbero i permessi su tre tabelle. La seconda: le credenziali sono scritte in chiaro dentro la configurazione del flusso, visibili a chiunque abbia accesso alla piattaforma, compresi collaboratori esterni ormai usciti dal progetto. La terza: nessuno riceve un avviso quando l’automazione fa qualcosa di anomalo, perché il monitoraggio previsto riguarda solo il caso in cui si ferma, non il caso in cui continua a funzionare producendo il risultato sbagliato.

Un caso concreto, reso anonimo. Un’azienda di distribuzione aveva automatizzato l’invio degli ordini ai fornitori. Il flusso leggeva le richieste da una casella condivisa e generava l’ordine. Ha funzionato bene per mesi. Poi qualcuno ha capito come era fatta la logica e ha iniziato a inviare a quella casella richieste costruite apposta. Gli ordini partivano regolarmente, con il formato giusto, verso un destinatario nuovo. Nessun sistema ha segnalato niente, perché tutto era formalmente corretto. Ci si è accorti al controllo delle fatture, settimane dopo. Non era stata violata nessuna password. Era stata usata l’automazione esattamente come era stata progettata.

La lezione operativa è che ogni automazione va progettata come se un domani qualcuno provasse a usarla contro l’azienda. Il che vuol dire tre cose: permessi minimi indispensabili, credenziali gestite in un archivio dedicato con rotazione periodica, e soglie di anomalia che generano un avviso a un essere umano. Sono tre voci di capitolato, non tre opinioni. Se vuoi approfondire la parte di rischio legata all’uso di sistemi intelligenti nei processi, ho raccolto il quadro nell’articolo sui rischi dell’intelligenza artificiale in azienda.

GDPR e AI Act: quando automatizzare diventa una responsabilità legale

Il secondo vuoto sistematico riguarda la conformità, e nel 2026 è diventato un vuoto costoso.

Partiamo dal principio più stabile. Il Regolamento europeo sulla protezione dei dati stabilisce che una persona ha diritto a non essere sottoposta a una decisione basata unicamente su un trattamento automatizzato che produca effetti giuridici o incida in modo analogamente significativo sulla sua persona, e che quando tali decisioni sono ammesse devono essere previste garanzie, tra cui il diritto di ottenere l’intervento umano, di esprimere la propria opinione e di contestare la decisione. Il testo del regolamento è consultabile nella versione ufficiale pubblicata su EUR-Lex.

Tradotto nella pratica di un progetto di automazione dei processi aziendali: se il flusso che stai costruendo scarta candidature, assegna un punteggio di affidabilità a un cliente, decide chi riceve una condizione peggiorativa o sospende un servizio, non stai facendo solo efficienza operativa. Stai costruendo un sistema decisionale che deve prevedere un punto in cui una persona può intervenire, e deve poter spiegare la logica seguita. Non è un adempimento da aggiungere dopo. È un vincolo di progettazione, perché aggiungere un intervento umano a un flusso costruito per non averlo significa rifarlo.

A questo si è aggiunto il regolamento europeo sull’intelligenza artificiale. La sua applicazione generale è scattata il 2 agosto 2026, dopo che gli obblighi sulle pratiche vietate e sull’alfabetizzazione in materia di intelligenza artificiale erano già entrati in vigore nel febbraio 2025 e le regole sui modelli di uso generale nell’agosto 2025, secondo la timeline pubblicata dalla Commissione europea. Per chi automatizza processi la conseguenza pratica è duplice: da un lato l’obbligo di garantire che il personale che usa questi sistemi abbia un livello adeguato di competenza, dall’altro la necessità di sapere in quale categoria di rischio ricade ciò che si sta costruendo, perché alcuni ambiti tipici dell’automazione aziendale, a partire dalla selezione del personale e dalla gestione dei lavoratori, sono classificati come ad alto rischio con obblighi specifici.

Qui parlo con il cappello di chi ha svolto incarichi peritali per il Tribunale e collabora con FederPrivacy, e la mia osservazione è questa: nel contenzioso non si discute quasi mai se il software funzionasse. Si discute se l’azienda fosse in grado di spiegare perché il sistema avesse deciso in quel modo, e chi avesse la possibilità di intervenire. Le aziende che hanno documentato il processo decisionale mentre lo costruivano se la cavano. Quelle che devono ricostruirlo a posteriori, partendo da configurazioni scritte da un fornitore che nel frattempo ha cambiato referente, se la cavano molto meno.

Non è consulenza legale e non sostituisce il parere di chi la fa di mestiere. È un avvertimento su dove va messa l’attenzione. Chi vuole partire dalle basi della conformità può cominciare dalla panoramica sugli adempimenti GDPR per le imprese.

Come si misura il ritorno di un progetto di automazione

Il ritorno di un progetto di business process automation si misura male per due motivi: perché il valore di partenza non viene rilevato, e perché si contano solo le ore risparmiate.

Sul primo punto non c’è scorciatoia. Prima di attivare qualsiasi cosa vanno registrati il tempo medio di esecuzione, il numero di esecuzioni nel periodo, il tasso di errore e il tempo di attraversamento complessivo, cioè quanto passa tra l’ingresso della richiesta e la sua chiusura. Sono quattro numeri. Rilevarli richiede due settimane di attenzione e cambia completamente la conversazione a sei mesi, quando qualcuno chiede se sia valsa la pena.

Sul secondo punto, le ore risparmiate sono la voce più facile e la meno interessante. Il valore vero di solito sta altrove: nella riduzione del tempo di attraversamento, che si traduce in incassi più rapidi o clienti che aspettano meno; nella riduzione degli errori che generavano rilavorazione; nella capacità di reggere un aumento di volume senza assumere. Un’azienda che evade il doppio degli ordini con lo stesso organico ha ottenuto qualcosa che nessun conteggio di ore riesce a rappresentare.

Va contata anche la colonna dei costi, per intero: licenze, implementazione, formazione, e soprattutto manutenzione ricorrente. Un progetto che si ripaga in nove mesi ignorando la manutenzione può ripagarsi in venti mesi contandola, e venti mesi è comunque un buon risultato se lo si sa in anticipo. È la sorpresa a rovinare i progetti, non il costo. Sul metodo di misurazione applicato al digitale ho scritto una guida dedicata al calcolo del ritorno nelle piccole e medie imprese.

Gli strumenti: cosa cambia tra suite, piattaforme di orchestrazione e agenti

Una nota sugli strumenti, senza classifiche, perché la classifica giusta dipende dai sistemi che l’azienda ha già.

Le suite integrate automatizzano bene i processi che vivono dentro il loro perimetro. Se l’azienda lavora già su una piattaforma gestionale completa, spesso l’automazione migliore è quella che quella piattaforma offre nativamente, anche se sembra meno brillante. Costa poco integrarla e non aggiunge un fornitore.

Le piattaforme di orchestrazione servono quando i sistemi da collegare sono diversi e nessuno può fare da centro. Sono flessibili, richiedono più competenza interna e vanno documentate, altrimenti diventano scatole nere che solo chi le ha costruite sa leggere. Chi vuole vedere come funziona questo approccio nella pratica può partire dalla guida all’automazione dei workflow aziendali con n8n.

Gli agenti basati su intelligenza artificiale sono l’area in cui oggi si concentrano aspettative altissime e risultati disomogenei. Funzionano bene dove il compito richiede interpretazione di testo non strutturato, come leggere una richiesta scritta in linguaggio libero e classificarla. Funzionano male quando gli si chiede di essere deterministici su operazioni che richiedono precisione contabile. La scelta sensata, oggi, è usarli sul pezzo interpretativo del processo e lasciare a regole esplicite il pezzo che deve essere sempre identico. Su come si progettano e dove hanno senso ho raccolto il quadro negli approfondimenti su agenti AI personalizzati e sulla automazione del CRM.

Il criterio di scelta che uso è banale e funziona: si sceglie lo strumento che l’azienda sarà in grado di manutenere fra due anni con le persone che ragionevolmente avrà. Non quello più potente. Quello sostenibile.

Da dove partire concretamente

Se stai leggendo perché devi decidere se avviare un progetto, il percorso minimo è questo. Scegli un solo processo, passalo ai quattro filtri, rileva i quattro numeri di partenza per due settimane, semplifica il flusso a mano dove serve, e solo allora valuta lo strumento. Metti per iscritto i quattro nomi delle responsabilità e le regole di sicurezza sulle credenziali. Fai girare l’automazione in parallelo al manuale per un mese. Poi misura.

Un solo processo fatto bene produce due cose: un beneficio misurabile e, soprattutto, competenza interna. Il secondo vale più del primo, perché è quello che rende possibile il progetto successivo senza dipendere da nessuno. Se il quadro d’insieme che ti manca è quello della trasformazione digitale complessiva, la roadmap pratica per le PMI inquadra l’automazione dentro il percorso più ampio.

Riepilogo dei punti chiave

La business process automation è una strategia applicata a un processo specifico, non un software da acquistare. Si distingue dal business process management, che è la disciplina di analisi dei processi, e dalla robotic process automation, che è una tecnica per far dialogare sistemi che non hanno altro modo di parlarsi. In Italia il 62% delle grandi imprese usa almeno una tecnologia di process automation ma solo l’8% ha una visione strategica, mentre tra le PMI l’adozione si ferma al 15%. I due ostacoli dichiarati più spesso sono la mancanza di competenze interne e la mancanza di chiarezza normativa, entrambi problemi di progetto e non di tecnologia. Un processo merita di essere automatizzato se supera quattro filtri: frequenza per tempo unitario, stabilità della regola che lo governa, costo dell’errore, presenza di un proprietario interno con autorità. Vanno esclusi i processi rotti, quelli in procinto di cambiare, quelli a bassissimo volume con alta variabilità. Due aspetti sistematicamente ignorati pesano più di tutti: la sicurezza, perché ogni automazione riceve credenziali permanenti che diventano una superficie d’attacco se non gestite con permessi minimi e monitoraggio delle anomalie; e la conformità, perché il GDPR impone garanzie sulle decisioni interamente automatizzate e il regolamento europeo sull’intelligenza artificiale, in applicazione generale dal 2 agosto 2026, aggiunge obblighi di competenza e classificazione del rischio. Il ritorno si misura solo se i quattro numeri di partenza vengono rilevati prima di attivare qualsiasi cosa.

Domande frequenti sulla business process automation

Che cos’è la business process automation?

La business process automation è l’uso di tecnologia per eseguire automaticamente sequenze di attività aziendali che oggi richiedono intervento manuale. Non è un singolo software ma una strategia applicata a un processo specifico, con un obiettivo misurabile e un proprietario interno che ne risponde. Opera su tre livelli: automazione di singole attività, automazione di flussi con approvazioni e condizioni, automazione di processi completi che attraversano più reparti e più sistemi.

Qual è la differenza tra BPA, RPA e BPM?

Il business process management è la disciplina che mappa, misura e migliora i processi e non richiede necessariamente tecnologia. La business process automation è l’esecuzione automatica di quei processi tramite software, e lavora sul flusso completo attraversando reparti e sistemi diversi. La robotic process automation è una tecnica specifica dentro la BPA: un software che imita le azioni di un utente sull’interfaccia di altri programmi, utile quando due sistemi non hanno modo di comunicare tra loro ma fragile perché dipende dall’aspetto grafico dei programmi che pilota.

Qual è un esempio concreto di processo automatizzato?

Un esempio tipico è il ciclo passivo di fatturazione: la fattura del fornitore arriva via posta elettronica, il sistema ne estrae i dati, li confronta con l’ordine e con la bolla di consegna, e se i tre documenti coincidono registra il documento e lo instrada al pagamento, mentre se emerge una differenza genera un’eccezione che viene assegnata a una persona. Altri esempi frequenti sono l’inserimento di un nuovo dipendente con l’attivazione automatica di account e dotazioni, e la gestione delle richieste di assistenza con classificazione e assegnazione al gruppo competente.

Come si automatizzano i processi aziendali passo dopo passo?

La sequenza che regge è questa: mappare il processo come funziona davvero e non come descritto nelle procedure, definire un solo obiettivo misurabile rilevando i valori di partenza, scegliere lo strumento solo dopo aver definito il processo, assegnare per iscritto quattro responsabilità (proprietario del processo, manutentore, destinatario degli avvisi, chi può fermare tutto), coinvolgere chi esegue oggi il lavoro a mano, progettare la gestione delle eccezioni prima del percorso principale, partire in piccolo con un periodo in cui automazione e processo manuale girano in parallelo, e prevedere fin dall’inizio manutenzione ricorrente e piano di rientro al manuale.

Quali processi conviene automatizzare per primi?

La scelta non dipende dal software di automazione processi aziendali che si adotta, ma dal processo stesso: conviene partire da quelli che superano quattro filtri. Primo, un alto prodotto tra frequenza di esecuzione e tempo unitario: un’attività da quattro minuti ripetuta cinquanta volte al giorno vale più di una da due ore ripetuta tre volte l’anno. Secondo, una regola stabile e scrivibile, non un criterio che vive nella testa di una persona. Terzo, un costo dell’errore compatibile con il livello di controllo previsto. Quarto, l’esistenza di un proprietario interno con nome e cognome e con l’autorità di fermare il processo.

L’automazione dei processi crea problemi di conformità al GDPR?

Può crearne quando il processo automatizzato produce decisioni che riguardano persone fisiche. Il Regolamento europeo sulla protezione dei dati riconosce il diritto a non essere sottoposti a decisioni basate unicamente su trattamento automatizzato che producano effetti giuridici o incidano in modo significativo, e richiede garanzie tra cui il diritto di ottenere l’intervento umano e di contestare la decisione. In pratica un flusso che scarta candidature, assegna punteggi di affidabilità o sospende servizi deve prevedere fin dalla progettazione un punto di intervento umano e la capacità di spiegare la logica seguita. Aggiungerlo dopo significa quasi sempre rifare il flusso.

Che impatto ha il regolamento europeo sull’intelligenza artificiale sui progetti di automazione?

L’applicazione generale del regolamento è scattata il 2 agosto 2026, dopo che gli obblighi su pratiche vietate e alfabetizzazione erano entrati in vigore nel febbraio 2025 e le regole sui modelli di uso generale nell’agosto 2025. Per chi automatizza processi le implicazioni pratiche sono due: garantire che chi utilizza questi sistemi abbia un livello adeguato di competenza, e verificare in quale categoria di rischio ricada il sistema costruito, dato che alcuni ambiti tipici dell’automazione aziendale, come la selezione del personale e la gestione dei lavoratori, rientrano tra quelli classificati ad alto rischio con obblighi specifici di documentazione e sorveglianza umana.

Quanto tempo serve per vedere un ritorno dall’automazione dei processi?

Dipende dal livello di complessità e dalla correttezza della misurazione. Un’automazione di singola attività può mostrare risultati in poche settimane, mentre un processo end to end che attraversa più reparti richiede in genere alcuni mesi prima di stabilizzarsi. Il fattore che più influenza la risposta non è tecnico: se i valori di partenza non sono stati rilevati prima di attivare l’automazione, il ritorno non sarà dimostrabile in alcun tempo. Vanno inoltre inclusi nel calcolo i costi ricorrenti di manutenzione, che spostano il punto di pareggio ma non lo rendono meno raggiungibile, purché siano noti in anticipo.

Una piccola impresa può fare business process automation senza un reparto IT?

Sì, a due condizioni. La prima è limitare l’ambito iniziale a un solo processo di livello semplice, tipicamente un’attività isolata o un flusso con una sola approvazione. La seconda è che esista comunque una persona interna, anche non tecnica, che possieda il processo e sappia dove intervenire. L’assenza di un reparto IT non è un ostacolo insormontabile, mentre l’assenza di un proprietario interno lo è: senza quella figura il progetto dipende interamente da un fornitore esterno e diventa fragile nel momento in cui cambia il referente.

Cosa portarsi via da qui

La business process automation funziona quando smette di essere una domanda sul software e diventa una domanda sul processo. Quale processo, con quale regola, con quale costo dell’errore, sotto la responsabilità di chi, con quali permessi tecnici e dentro quali vincoli normativi. Sono sei domande. Un’azienda che sa rispondere a tutte e sei può automatizzare con ragionevole tranquillità anche partendo da zero competenze interne. Un’azienda che non sa rispondere a nessuna comprerà uno strumento e, con buona probabilità, lo spegnerà entro l’anno.

Il vantaggio competitivo, in questo momento, non sta nell’automatizzare per primi. Sta nell’automatizzare i processi giusti mentre nove aziende su dieci automatizzano pezzi scollegati senza sapere come misurarne l’effetto. È una finestra che resterà aperta ancora per un po’, ma non per sempre.

Prenota una consulenza strategica: se vuoi capire quali processi della tua azienda passano davvero i quattro filtri e quali conviene lasciare stare, fissiamo una sessione di analisi e li esaminiamo insieme.