Quali processi conviene automatizzare e come riconoscerli

Quattro domande con cui Lei stesso può setacciare il lavoro quotidiano: se è una catena con un risultato, se la macchina riceve dati o un’immagine, se un passaggio decide qualcosa su una persona, e se il processo ha già un termine esterno.

La domanda «che cosa dovremmo automatizzare» di solito arriva troppo tardi, perché presuppone che la risposta sia un elenco di strumenti. Nella pratica la maggior parte dei progetti di automazione andati male è cominciata con lo strumento giusto, applicato sopra un lavoro scelto male, ed è stata proprio la scelta, non lo strumento, a decidere il risultato.

Questo articolo non tenta di definire che cosa sia l’automazione dei processi aziendali, perché la definizione non decide nulla; dà invece quattro domande con cui Lei stesso può setacciare il proprio lavoro quotidiano e, dopo ciascuna, mostra come si presenta un caso che la supera e un caso che non la supera. Il vaglio non costa nulla e richiede un pomeriggio, ma fa risparmiare ben più di qualsiasi confronto tra strumenti, perché risponde alla domanda più a monte della catena.

Prima domanda: è una catena con un risultato o una sequenza di clic

Questo è il confine che decide di più, ed è il caso di tracciarlo con precisione: un processo è una catena di attività che ha dati in ingresso, un esito e un responsabile: l’emissione della fattura a partire dall’ordine, l’inserimento di un nuovo dipendente, il percorso di una richiesta del cliente dal modulo fino alla risposta. Una procedura, ossia una singola attività, è il modo in cui si esegue un passaggio concreto: dove cliccare, che cosa copiare, in quale campo inserire il numero.

Si possono automatizzare entrambi, ma il ritorno differisce di parecchie volte, ed è proprio per questo che l’ordine conta: se Lei automatizza la catena, cambia il risultato — il documento arriva in contabilità da solo, e nessuno lo ricopia più. Se Lei automatizza una sequenza di clic, accelera un solo passaggio di una catena che per il resto resta uguale, e il beneficio è esattamente grande quanto era la quota di quel singolo passaggio.

Il modo pratico per riconoscerlo è semplicemente chiedere che cosa succede al risultato dopo, e la risposta di solito dice tutto: se è «allora qualcuno prende questo file e lo mette in un altro sistema», la catena continua e automatizzare un solo passaggio significa spostare il collo di bottiglia, non toglierlo. Se la risposta è «allora il lavoro è finito e il risultato è nel sistema», allora Lei ha un processo con un punto finale chiaro, e proprio questi sono quelli che conviene prendere per primi.

Prendiamo una catena tipica e seguiamola fino in fondo, perché proprio seguirla mostra dove sta davvero il beneficio: il cliente compila un modulo sul sito, la richiesta arriva per e-mail, qualcuno la ricopia nel sistema di anagrafica clienti, qualcun altro prepara l’offerta, e dopo l’approvazione un altro ancora emette la fattura nel programma di contabilità. Qui c’è un solo processo con un risultato chiaro (dalla richiesta alla fattura), e in esso ci sono almeno tre punti in cui gli stessi dati vengono ricopiati da capo, ogni volta con la possibilità di sbagliare.

Se da questa catena si automatizza soltanto la ricopiatura della richiesta nel sistema di anagrafica, il beneficio è reale ma piccolo, perché restano le altre due ricopiature. Se si automatizza l’intera catena, cambia il carattere stesso del lavoro: la persona non ricopia più, ma verifica e prende decisioni là dove servono davvero. Proprio per questo i confini della catena conviene disegnarli prima di qualsiasi conversazione sugli strumenti, perché determinano quanto grande può essere il beneficio possibile.

La catena ha anche un responsabile, ed è una domanda che spesso resta senza essere posta. Se nessuna persona in concreto sa dire come il processo avviene dall’inizio alla fine, l’automazione sarà una serie di ipotesi su come probabilmente avviene, e il primo caso reale le spezzerà. Trovare il responsabile di solito richiede una conversazione, ma fa risparmiare diverse settimane, perciò è la parte più economica del progetto.

Seconda domanda: la macchina riceve dati o un’immagine

Questa è la differenza tecnica più importante di tutta l’automazione, e in Italia ha anche un lato normativo. Se il sistema riceve dati strutturati (XML, JSON, un record in un database), può elaborarli senza indovinare. Se riceve un’immagine, cioè un file PDF o una pagina scansionata, allora prima dell’elaborazione qualcuno deve indovinare che cosa ci sta scritto, ed è proprio questo indovinare a produrre gli errori che poi qualcuno corregge a mano.

L’esempio delle fatture lo mostra meglio di tutti, perché lì le due possibilità coesistono e si chiamano quasi allo stesso modo. La fattura elettronica strutturata, nel quotidiano chiamata anche fattura elettronica, è un documento leggibile da una macchina in un formato determinato: in Italia è un file XML conforme alle specifiche FatturaPA e si trasmette attraverso il Sistema di Interscambio (SdI). Il sistema del destinatario può contabilizzarla senza la partecipazione di una persona, ed è proprio questo formato quello a cui si applicano i termini normativi.

Una fattura in PDF, che il destinatario ha accettato di ricevere per via elettronica, resta un documento che si può leggere: la guida dell’Agenzia delle Entrate precisa però che, se l’obbligo di fattura elettronica si applica, una fattura predisposta in un formato diverso dall’XML o trasmessa con modalità diverse dal Sistema di Interscambio si considera non emessa. Resta un file leggibile, non una fattura elettronica, e per la macchina è comunque un’immagine.

Da ciò segue una conclusione che fa risparmiare molto denaro: riconoscere una fattura PDF con OCR (riconoscimento ottico dei caratteri) non è introdurre la fattura elettronica. È un’attività separata, che le persone automatizzano a ragione, perché riduce le ricopiature, ma non produce un documento strutturato e non adempie l’obbligo di emetterlo. Un’azienda che considera l’OCR la risposta al requisito normativo, dopo un paio d’anni scopre di aver automatizzato l’estremità sbagliata, e allora il progetto va ricominciato da capo con il sistema che emette le fatture, non con quello che le riceve.

Il modo pratico di verificarlo qui è semplice: chieda in quale formato il sistema è in grado di emettere e di ricevere i dati. Se la risposta è «si può esportare un CSV», quelli sono già dati strutturati, solo automatizzati in modo incompleto. Se la risposta è «si può stampare» o «si può salvare in PDF», allora l’immagine è l’unico output, e il lavoro successivo o richiede un’interfaccia, o resterà un indovinare.

Conviene anche sapere che la risposta spesso è migliore di quanto in azienda si pensi, perché molti programmi di contabilità e di magazzino un’interfaccia ce l’hanno, solo che nessuno l’ha mai chiesta, perché il lavoro quotidiano si accontenta dell’esportazione. Una domanda al fornitore su se il sistema abbia un’interfaccia software e che cosa si possa farne spesso decide se il progetto merita proprio di essere cominciato.

Terza domanda: il passaggio decide qualcosa su una persona

La maggior parte dell’automazione è lo spostamento di numeri tra sistemi, e lì non ci sono questioni giuridiche particolari. C’è però un gruppo di passaggi che va riconosciuto a parte: i passaggi che decidono qualcosa su una persona concreta — se assumerla, se concederle un credito, se licenziarla, se attribuirle una prestazione.

L’articolo 22 del Regolamento generale sulla protezione dei dati — Processo decisionale automatizzato relativo alle persone fisiche, compresa la profilazione — stabilisce che l’interessato ha il diritto di non essere sottoposto a una decisione basata unicamente sul trattamento automatizzato e che produca effetti giuridici che lo riguardano o che incida in modo analogo significativamente sulla sua persona. Esistono eccezioni (necessità per un contratto, una norma di legge con misure di salvaguardia, un consenso esplicito), ma anche allora restano il diritto all’intervento umano, a esprimere la propria opinione e a contestare la decisione. Le linee guida delle autorità di controllo aggiungono una sfumatura importante: l’intervento umano deve essere sostanziale, e un pulsante formale di approvazione che qualcuno preme senza guardare il contenuto non toglie il processo dall’articolo 22.

Non è un divieto di automatizzare, ma un’indicazione su che cosa, in un processo del genere, è automatizzabile: si può automatizzare il lavoro preparatorio (raccolta dei dati, verifica, preparazione della proposta), ma la decisione stessa resta di una persona che la prende davvero. In pratica cambia l’ampiezza del progetto, perciò conviene accorgersene prima dello sviluppo, non dopo.

Accanto a questo conviene conoscere un termine che non è ancora arrivato, ma che influisce sui piani di lungo periodo: le prescrizioni della legge sull’IA per i sistemi ad alto rischio in materia di occupazione, cioè selezione e decisioni sul personale, cominciano ad applicarsi il 2 dicembre 2027. Significa che oggi la scelta è più libera, ma per un sistema che si costruisce nel lungo periodo questa data va messa nel piano.

Quarta domanda: il processo ha già un termine esterno

Per una parte dei processi il termine non lo fissano le priorità dell’azienda, ma un obbligo esterno, e quelli salgono da soli in cima all’elenco, perché su di essi non si deve più decidere se fare, ma soltanto quando e come. In Italia l’esempio più chiaro sono di nuovo le fatture, e lì ci sono tre date diverse che spesso si confondono.

Innanzitutto, un’azienda che emette una fattura verso la pubblica amministrazione usa il formato strutturato già dal 31 marzo 2015. In secondo luogo, dal 1° gennaio 2019 le fatture tra soggetti residenti o stabiliti in Italia sono file XML trasmessi al Sistema di Interscambio, e i dati arrivano così all’Agenzia delle Entrate nel momento stesso della trasmissione. In terzo luogo, l’obbligo di emettere fattura elettronica anche per i forfettari rimasti esclusi vale dal 1° gennaio 2024, e nel mezzo, dal 1° luglio 2022, chi superava 25.000 euro di ricavi nell’anno precedente era già obbligato, mentre sotto quella soglia l’invio restava possibile su base volontaria.

Proprio questa terza data è quella che nella circolazione pubblica è più spesso sbagliata, e il motivo è semplice: l’obbligo è stato esteso a tappe, una soglia intermedia è restata in vigore due anni, e una parte degli articoli secondari non ha mai corretto il testo. Per un’azienda che pianifica il bilancio, la differenza tra due anni è grande, perciò la data conviene verificarla nella fonte primaria, non nel riassunto.

Termini esterni ce ne sono anche altrove: la registrazione dell’orario di lavoro deve essere oggettiva e accessibile, i documenti contabili hanno termini di conservazione, e nei contratti capitano date di rendicontazione. Il tratto comune è che questi termini non sono negoziabili, e un processo che ne ha uno dà una motivazione chiara al lavoro — a differenza di un processo che si automatizza perché sembra moderno.

Come si presenta un processo che conviene prendere per primo

Se si uniscono tutte e quattro le domande, esce un ritratto abbastanza concreto, che si può accostare a qualsiasi elenco: il primo candidato più prezioso è una catena con un risultato chiaro, in cui i dati esistono già in forma strutturata o possono diventarlo, in cui nessun passaggio decide nulla su una persona, e che ha un termine esterno o almeno un volume misurabile.

Nella pratica di solito si presenta così: l’ordine dal negozio arriva nel sistema contabile senza ricopiatura; una catena di approvazioni in cui la richiesta va alla persona giusta e torna con un segno; la sincronizzazione dei dati tra magazzino e sito, dove oggi una persona esporta un file due volte al giorno. Tutti e tre hanno un tratto comune — tra due sistemi oggi cammina una persona con un file.

Proprio questo tratto è il più facile da notare e il più difficile da dimenticare, perciò da lì conviene cominciare l’inventario. Scriva dove, nella Sua azienda, qualcuno esporta, copia o ricopia, quanto spesso e per quanto tempo. Questo elenco di solito è più corto del previsto, e in esso c’è quasi sempre una voce che spicca.

Il secondo tratto che fa spiccare un candidato è il costo dell’errore, e nei calcoli di solito lo si omette: se un errore di ricopiatura in questa catena significa una fattura sbagliata al cliente, una giacenza sbagliata in magazzino o un termine mancato, allora il beneficio dell’automazione non è solo le ore risparmiate, ma anche gli errori evitati, e quello di solito è il più grande dei due numeri. Un processo in cui l’errore è invisibile e innocuo, in questo senso, è un candidato meno prezioso, anche se occupa altrettanto tempo.

Il terzo tratto è il modo in cui il volume cambia insieme all’azienda, ed è il più importante dei tre: un lavoro che cresce con l’azienda, perché più ordini significano più ricopiature, col tempo diventa sempre più caro, e proprio lì l’automazione si ripaga due volte: libera tempo oggi e toglie un costo che altrimenti crescerebbe. Un lavoro dal volume fisso, indipendente dal fatturato, non dà questo secondo beneficio.

Al ritratto conviene aggiungere una cosa sull’ordine, perché lì le aziende sbagliano più spesso che nella scelta dello strumento: il primo processo automatizzato non va scelto in base a quale è il più grande o il più doloroso, ma in base a quale è il meglio compreso e il più rapido da portare a termine, perché il primo progetto insegna all’azienda come questi progetti avvengono in generale — come descrivere le eccezioni, come testare e come trattare gli errori. Questa lezione è molto più economica da ricevere su un lavoro semplice che su quello da cui dipende il flusso di cassa.

Come si presenta un processo che non conviene prendere per primo

Tanto utile quanto riconoscere un buon candidato è riconoscere ciò che sembra attraente ma si ripaga male, e di questi casi ce ne sono quattro. Il primo è un lavoro che avviene di rado (una volta a trimestre o una volta all’anno), perché i costi di sviluppo restano gli stessi, ma il risparmio viene diviso per quattro o per uno.

Il secondo è un processo il cui svolgimento sta ancora cambiando, ed è il caso in cui la fretta costa di più: se nell’ultimo semestre quello svolgimento è stato modificato tre volte, l’automazione fisserà la versione che comunque tra poco cambierà, e la manutenzione si mangerà il beneficio. Qui la sequenza giusta è prima accordarsi sullo svolgimento e soltanto poi automatizzarlo, anche se nella pratica capita spesso il contrario.

Il terzo è un lavoro in cui ogni caso è un’eccezione, e lì il confine sta nella natura stessa del compito, perché l’automazione se la cava bene con il frequente e il prevedibile, ma male con una situazione in cui dieci casi hanno dieci percorsi diversi; lì il giudizio della persona è il lavoro stesso, e sostituirlo con un albero di regole di solito produce più eccezioni di quante ne tolga.

Questi tre casi li unisce un tratto: in essi l’automazione fissa qualcosa che non è ancora pronto per essere fissato. Il lavoro raro non è abbastanza rodato da meritare di essere cristallizzato; il processo variabile sta ancora cercando la propria forma; il lavoro delle eccezioni, per sua natura, è un giudizio. In tutti e tre l’azione giusta è aspettare o prima mettere in ordine, non automatizzare più in fretta.

Il quarto è il caso in cui si imita la schermata perché il sistema non ha un’interfaccia. A volte è l’unica via possibile, ma è anche la più fragile: basta un cambiamento sullo schermo, e il lavoro si ferma. Se il sistema un’interfaccia ce l’ha o la si può pretendere, quella è quasi sempre una scelta più conveniente che imitare la schermata.

Che cosa succede alle persone il cui lavoro si automatizza

Questa domanda nelle offerte di automazione di solito si evita, anche se in azienda la si pone già il primo giorno, e senza risposta diventa una resistenza silenziosa, che può fermare il progetto più sicuramente di qualsiasi problema tecnico. La risposta onesta nella maggior parte delle piccole e medie imprese è che l’automazione libera tempo, non una persona: la ricopiatura è quella parte del lavoro che nessuno vuole, e la sua scomparsa di solito significa che la stessa persona riesce finalmente a fare ciò per cui prima non bastava il tempo.

Da ciò segue una raccomandazione pratica, che suona morbida ma è una questione pura di gestione di progetto: la persona che fa il lavoro oggi va coinvolta nel progetto come la fonte più competente, non informata del risultato. Conosce le eccezioni che nessuno ha scritto, e proprio le eccezioni sono ciò che spezza l’automazione. Un progetto in cui questa conversazione avviene all’inizio costa meno di uno in cui avviene dopo il primo errore.

È anche onesto dire l’altra faccia, perché il contrario sarebbe fingere: se in azienda il lavoro di una persona consiste interamente nel trasferire dati tra due sistemi, allora l’automazione questo lavoro lo sostituisce davvero, ed è una conversazione sul cambio di ruolo, che la guida l’azienda, non il fornitore. Un’offerta che questa domanda non la pone affatto non è delicata — semplicemente non è pensata fino in fondo.

Come calcolare il Suo numero

Il calcolo che serve alla decisione sta in una pagina sola e non richiede né un consulente né uno studio. Servono quattro numeri: quante volte a settimana avviene questo lavoro, quanti minuti occupa ogni volta, quanto costa l’ora alla persona che lo fa, e quanto spesso vi nasce un errore che poi qualcuno corregge.

I primi tre danno il costo diretto del tempo in un anno, e questo numero di solito è più piccolo del previsto — proprio per questo fondare il progetto soltanto su quello spesso non riesce. Il quarto numero è quello che per lo più decide, perché il costo dell’errore di rado è soltanto il tempo per correggerlo: una fattura sbagliata significa corrispondenza con il cliente, una giacenza sbagliata significa o merce che resta invenduta, o un ordine di merce che in magazzino non c’è più, e un termine mancato a volte significa una sanzione.

Di fronte a questi numeri si mettono i costi di sviluppo e la manutenzione, e proprio la manutenzione è quella che si dimentica. Un’automazione che collega due sistemi è viva tanto a lungo quanto sono vive entrambe le interfacce, perciò nel piano ci deve essere posto per i cambiamenti che chiederà qualcun altro. Se il calcolo si ripaga soltanto quando il costo di manutenzione non lo si include, allora in realtà non si ripaga affatto.

Un’altra cosa che conviene chiarire prima della conversazione è quanto spesso i sistemi cambiano. Un servizio in cloud che si aggiorna da solo può cambiare l’interfaccia senza preavviso, mentre un programma installato in locale resta uguale per anni, ma il suo aggiornamento un giorno chiede di ricontrollare tutto da capo. Nessuna delle due varianti è peggiore, ma richiedono un piano di manutenzione diverso, e un’offerta che non lo riflette sarà troppo a buon mercato proprio nel punto in cui più tardi nasceranno i costi.

Perché alle percentuali degli studi non bisogna credere

Nelle offerte di automazione compare quasi sempre un numero: che si può automatizzare metà del lavoro, che i progetti falliscono in un terzo dei casi, che qualcuno ha risparmiato decine di migliaia di ore. Questi numeri esistono e si possono citare, ma quasi mai descrivono l’azienda a cui li si mostra, ed è proprio questo a farne una cattiva base per una decisione.

L’indicatore ampiamente citato secondo cui una gran parte delle attività è automatizzabile è un calcolo sulle operazioni nella massa salariale di un Paese concreto e di un anno concreto, con le tecnologie di quell’anno, e l’ha pubblicato una società di consulenza che vende questo stesso servizio. L’indicatore sui fallimenti dei progetti viene dall’esperienza di un consulente con clienti che l’hanno chiamato dopo i primi insuccessi, perciò il campione è distorto già per definizione. Il numero sulle ore risparmiate descrive un ufficio contabile concreto di quaranta persone in un altro Paese, di diversi anni fa.

Da ciò non segue che l’automazione non si ripaghi, ma che il numero giusto è il Suo: quante volte a settimana avviene questo lavoro, quanto tempo occupa e quanto costa un’ora. Questo calcolo lo si può fare in una pagina, descrive proprio la Sua azienda, ed è l’unico sul cui fondamento conviene decidere.

Che cosa sapere dei sistemi prima di chiedere un’offerta

Quando il candidato è scelto, il passo successivo non è chiedere un’offerta, ma cinque minuti di verifica sui sistemi stessi, perché proprio quella decide se la conversazione con l’esecutore sarà su una soluzione o sulla fattibilità. Verifichi se ciascuno dei sistemi coinvolti abbia un’interfaccia software, se sia disponibile al livello della Sua licenza e se il fornitore ne chieda un pagamento separato, perché tutte e tre le risposte tendono a differire.

La seconda domanda è chi conserva i dati e chi può modificarli. Se due sistemi contengono la stessa informazione, per esempio i dati anagrafici del cliente o la giacenza di un articolo, allora prima di collegarli va deciso quale dei due è il principale, perché altrimenti l’automazione comincerà a sovrascriverli l’uno con l’altro e il risultato sarà peggiore di prima. Questa decisione è gratuita se la si prende all’inizio, e cara se la si scopre in fase di test.

La terza è la domanda su che cosa succede quando qualcosa non va. In ogni automazione ci sono casi che non passano (manca un campo, il sistema non risponde, i dati sono contraddittori), e a essi serve un posto dove arrivare, e una persona che li guardi. Un’automazione senza gestione degli errori funziona tanto a lungo quanto tutto è in ordine, e non dura mai a lungo.

Conviene anche decidere in anticipo in base a che cosa valuterà se è andata, perché senza di ciò il progetto non finisce mai, ma semplicemente si interrompe. La misura può essere del tutto semplice: quante volte al mese qualcuno ricopia ancora i dati a mano, quanti errori si sono corretti il mese scorso e quanto ci mette una richiesta dal modulo alla risposta. Questo numero ha senso misurarlo una volta prima di cominciare il lavoro, affinché più tardi ci sia con che confrontare. Le aziende che questa misura non la fanno, dopo sei mesi discutono se sia cambiato qualcosa.

Infine conviene ricordare che l’automazione non è un lavoro una tantum, ma qualcosa che resta in azienda e chiede un proprietario come qualsiasi altro sistema. Quando il processo è collegato, qualcuno deve sapere dove guardare se si ferma, e qualcuno deve avere il diritto di fermarlo se il risultato sembra sbagliato. Nelle aziende in cui questo ruolo non è nominato, l’automazione smette piano di funzionare, e lo si nota soltanto dopo un mese, quando qualcuno cerca un documento scomparso.

Da dove cominciare in pratica

L’inizio non è la scelta dello strumento, né la richiesta di un’offerta, ma una settimana in cui si annota che cosa avviene: quale lavoro si ripete, quanto spesso, per quanto tempo e dove in esso una persona trasferisce dati tra sistemi. Poi a ogni voce ponga le quattro domande di questo articolo, e la maggior parte dell’elenco cadrà già dopo le prime due.

Di solito restano uno o due candidati, ed è un bene, perché proprio tanti contemporaneamente conviene anche cominciare: due lavori finiti danno più di sei iniziati. Quando il candidato è scelto, il passo successivo è accertare se i sistemi coinvolti abbiano interfacce, perché ciò decide sia il prezzo sia la tenuta della soluzione.

Se a questo punto è chiaro quale processo è il Suo, ma non è chiaro come collegarlo, lo si può discutere con noi: l’automazione dei processi aziendali nel nostro modo di farla sono integrazioni e flussi di lavoro tra i sistemi che Lei ha già. Se vuole prima capire in che cosa differiscono i vari approcci e i gruppi di strumenti, ci scriva o ci mandi il Suo elenco — spesso la risposta è che basta un collegamento, non una piattaforma.