Otto domande per capire se hai davvero qualcosa da automatizzare
Prima di cercare un software, prova a capire se hai davanti una regola, un'eccezione o soltanto un'abitudine costosa.
Prendi una delle attività che ti infastidisce di più in studio. Quella che torna ogni settimana, magari ogni giorno. Qualcuno apre una cartella, cerca un documento, legge una data, confronta due informazioni, prende una decisione e poi si annota che dovrà rifarlo.
La tentazione è immediata: automatizziamola.
Ma automatizzare non significa prendere un lavoro noioso e affidarlo a un software. Prima bisogna capire che cosa, dentro quel lavoro, è davvero una regola e che cosa invece richiede ancora giudizio. Altrimenti si rischia di digitalizzare l'attrito: lo stesso percorso di prima, solo con più pulsanti.
Il DURC è un buon esempio perché rende visibile il problema. Scaricare automaticamente un PDF è già un miglioramento, ma non significa avere automatizzato il controllo. Se poi una persona deve ancora trovare il file, leggerne l'esito, verificare la scadenza, collegarlo al fornitore e confrontarlo con il pagamento, il documento è arrivato prima. Il lavoro, però, è rimasto quasi tutto lì.
Prima di parlare di automazione, quindi, conviene fare otto domande. Non al software. Al processo.
1Qual è l'ingresso?
Ogni automazione seria deve partire da qualcosa di riconoscibile. Un codice fiscale, una fattura, una richiesta, una data, un movimento bancario, una scadenza. Se non sai indicare con precisione che cosa entra nel processo, difficilmente riuscirai a stabilire che cosa il sistema dovrebbe fare da solo.
Nel caso del DURC l'ingresso può essere il codice fiscale del fornitore. Da lì il documento può essere interrogato e associato. Se invece l'ingresso è «quando qualcuno si ricorda che manca il DURC», non hai definito un processo: hai descritto una dipendenza dalla memoria.
2Quale uscita ti serve davvero?
Qui si sbaglia spesso. L'uscita non è necessariamente il documento prodotto o scaricato. È l'informazione che deve essere disponibile nel punto in cui serve.
Per un pagamento non basta sapere che esiste un PDF. Serve sapere se il controllo ha uno stato definito, se quell'informazione è ancora valida e se il caso può proseguire oppure deve uscire dal flusso ordinario. Se l'output non cambia una decisione successiva, probabilmente stai automatizzando un gesto e non il processo.
3La decisione segue una regola certa?
Documento presente? Data compatibile? Importo entro una soglia? Stato già classificato? Sono domande che, quando le condizioni sono chiare, possono essere trasformate in regole.
Una regola automatizzata è una decisione presa una volta e applicata ogni volta che ricorre la stessa condizione. Se invece la risposta richiede interpretazione, valutazione del contesto o assunzione di responsabilità professionale, quella parte non va nascosta dentro l'automazione. Va resa visibile come eccezione.
4Il controllo arriva nel momento utile?
Un controllo corretto fatto troppo tardi può essere organizzativamente pessimo. Se l'anomalia emerge soltanto quando la distinta è pronta, la pratica si ferma: bisogna cercare, attendere, ricostruire e poi ripartire.
L'informazione dovrebbe arrivare prima del punto in cui può bloccare il lavoro. È qui che cambia il significato dell'automazione: non fare più velocemente la stessa verifica, ma fare in modo che il suo esito sia già disponibile quando deve essere usato.
5I casi regolari possono avanzare senza una persona?
Immagina cento pratiche. Novantanove sono regolari e una richiede attenzione. Se una persona deve aprirle tutte per trovare quella anomala, hai trasformato l'essere umano nel collo di bottiglia del sistema.
Il flusso migliore lascia avanzare ciò che soddisfa le regole note e porta in evidenza soltanto ciò che non le soddisfa. Questo non riduce il controllo. Riduce il numero di volte in cui una persona deve dimostrare che tutto è normale.
6L'eccezione viene separata oppure blocca tutto?
Un'anomalia non dovrebbe paralizzare il processo intero. Dovrebbe cambiare percorso.
Se manca un'informazione, se una scadenza non è compatibile o se lo stato non è affidabile, quel caso deve diventare visibile, essere assegnato e arrivare alla persona che può decidere. Gli altri casi, quelli regolari, devono continuare a scorrere. Automatizzare significa anche progettare dove va a finire ciò che l'automazione non può risolvere.
7Rimane una prova del controllo?
Far accadere qualcosa automaticamente non basta. Devi poter ricostruire che cosa è successo.
Quale stato aveva la pratica? Quale regola è stata applicata? Perché un caso è proseguito e un altro si è fermato? Se il sistema produce soltanto un esito ma non consente di risalire al percorso, hai guadagnato velocità e perso governabilità. Un processo affidabile non nasconde la decisione: la rende ricostruibile.
8Hai eliminato lavoro oppure hai aggiunto un altro strumento?
È la domanda più scomoda, perché molte automazioni falliscono proprio qui.
Se per «automatizzare» hai creato una nuova schermata da controllare, un'altra scadenza da ricordare, un elenco da verificare e una procedura separata da lanciare, forse non hai ridotto il lavoro. Lo hai spostato.
Il salto vero avviene quando un controllo entra in un flusso che esiste già. Nel DURC, per esempio, acquisire l'informazione insieme alle fatture o renderla disponibile durante la preparazione del pagamento cambia il ciclo della pratica. Il tempo tecnico continua a esistere, ma non si trasforma più necessariamente in tempo aggiuntivo dell'operatore.
Il test finale
Se riesci a rispondere bene a queste otto domande, hai quasi disegnato il contratto operativo della tua automazione: che cosa entra, che cosa deve uscire, quale regola applicare, quando produrre l'esito, che cosa può avanzare, che cosa deve diventare eccezione e quale traccia lasciare.
Solo a quel punto ha senso chiedersi quale software usare.
Prima, la domanda è diversa: stai davvero cercando di automatizzare una decisione ripetitiva oppure stai cercando un modo più elegante per continuare a ricordartela?