L’automazione ha un problema di narrazione. Viene raccontata come una decisione tecnologica (quale strumento adottare), quando è quasi sempre una decisione organizzativa: quale parte del lavoro merita di essere descritta con precisione sufficiente da poter essere eseguita da un sistema.
È una distinzione che ha conseguenze pratiche. Automatizzare un processo che funziona male non lo aggiusta: lo rende più veloce a sbagliare, e più difficile da correggere. Per questo il lavoro comincia prima degli strumenti, guardando come le cose vengono fatte oggi.
Automatizzare significa descrivere, non solo collegare
Molti pensano all’automazione come al collegamento fra due programmi. In parte è così, ma la parte difficile viene prima: bisogna stabilire cosa succede in ogni caso possibile.
Se il form arriva senza numero di telefono, cosa deve accadere? Se il cliente esiste già nel gestionale con l’indirizzo scritto in modo diverso, si aggiorna o si crea un duplicato? Se il servizio esterno non risponde per tre minuti, si riprova, si scarta o si avvisa qualcuno?
Fino a quando queste risposte esistono solo nella testa di chi fa il lavoro manualmente, il processo non è automatizzabile: è solo abitudinario. La fase più utile di un progetto di automazione è quella in cui queste domande vengono poste e ricevono una risposta scritta.
Cosa conviene quasi sempre automatizzare
Alcune categorie ripagano lo sforzo con regolarità, perché sono frequenti, prevedibili e a bassa ambiguità.
Il trasferimento di dati fra sistemi. È il caso più comune e il più sottovalutato. Un contatto che arriva dal sito e viene ricopiato a mano nel CRM, un ordine che viene riscritto nel gestionale, un foglio di calcolo aggiornato ogni lunedì con dati che esistono già altrove. Il ricopiare non produce valore e introduce errori, ed è il primo posto dove guardare.
Le notifiche legate a condizioni chiare. Un preventivo fermo da dieci giorni, una scadenza che si avvicina, una soglia di magazzino superata, un pagamento non riconciliato. Sono regole semplici che nessuno riesce a controllare con costanza, e per questo vengono controllate solo quando qualcosa è già andato storto.
La qualificazione e lo smistamento delle richieste. Non decidere al posto di una persona, ma preparare la decisione: raccogliere la richiesta, verificare che sia completa, assegnarla alla persona giusta, allegare le informazioni già disponibili sul cliente.
Il seguito su una richiesta. Una conferma immediata, un promemoria dopo qualche giorno, un secondo messaggio se non è arrivata risposta. È la parte che salta per prima nei periodi pieni, ed è anche quella che incide di più sul risultato commerciale.
La generazione di documenti ricorrenti. Preventivi, conferme, riepiloghi mensili, allegati contrattuali standard: tutto ciò che viene composto ogni volta partendo dallo stesso schema e cambiando cinque campi.
Le operazioni di chiusura periodica. Estrazioni, riconciliazioni, report che qualcuno prepara ogni mese dedicandogli mezza giornata sempre uguale.
Il filo comune non è la tecnologia ma il tipo di attività: ripetute, descrivibili in modo completo e con conseguenze limitate se una singola esecuzione va storta.
Cosa è meglio lasciare in mano alle persone
Ci sono situazioni in cui automatizzare peggiora le cose, e riconoscerle in anticipo fa risparmiare più tempo di quanto ne farebbe risparmiare l’automazione stessa.
I processi che non sono ancora stabili. Se il modo di lavorare cambia ogni due mesi perché l’attività sta crescendo o sta cercando la sua forma, un workflow costruito adesso sarà da rifare a breve. Vale la pena aspettare che il processo si assesti, o automatizzare solo la parte che di sicuro non cambierà.
Le decisioni che richiedono giudizio. Concedere una deroga, valutare un reclamo delicato, decidere quanto sconto ha senso su una trattativa importante. Un sistema può raccogliere gli elementi e presentarli ordinati, ma la decisione resta di una persona che ne risponde.
Le eccezioni frequenti. Se metà dei casi finisce in «dipende», il flusso principale copre metà del lavoro e l’altra metà diventa una gestione manuale resa più complicata dal fatto che ora c’è anche un sistema da assecondare.
Ciò che accade cinque volte l’anno. Un’automazione ha un costo di costruzione e uno di manutenzione. Un’attività rara, anche se noiosa, spesso non li ripaga.
La domanda utile non è «si può automatizzare?». Quasi tutto si può. La domanda è: quante volte succede, quanto è stabile, e cosa succede quando si rompe.
Il costo che nessuno mette a preventivo
Un’automazione è software, e come tutto il software va mantenuta. Le API cambiano, i fornitori aggiornano i propri strumenti, le credenziali scadono, i formati dei dati vengono modificati da qualcuno che non sapeva ci fosse un processo collegato.
Un’automazione fragile è peggio del lavoro manuale che ha sostituito, perché fallisce in silenzio. Il lavoro manuale, quando si ferma, se ne accorge subito la persona che lo stava facendo. Un flusso automatico che smette di funzionare può restare fermo per settimane, e ci si accorge del problema dal risultato mancante: le richieste che non arrivavano più, i solleciti che non sono partiti.
Per questo la parte meno visibile di un progetto di automazione è anche la più importante: gestione degli errori, tentativi ripetuti dove ha senso, un registro di cosa è stato eseguito, e un avviso a una persona reale quando qualcosa non è andato a buon fine. Un sistema che si limita a funzionare quando tutto va bene non è finito.
Persone dentro il flusso, non fuori
L’immagine dell’automazione come sostituzione delle persone è quasi sempre sbagliata, e nei processi aziendali funziona meglio l’opposto: il sistema prepara, la persona conferma.
Un preventivo generato automaticamente e inviato senza controllo è un rischio. Lo stesso preventivo generato in trenta secondi, presentato completo e in attesa di un clic, elimina il lavoro noioso e mantiene il controllo dove serve. Il tempo risparmiato è quasi lo stesso, il rischio è molto diverso.
Il punto di approvazione va messo dove le conseguenze di un errore sono alte: comunicazioni verso l’esterno, importi, dati contrattuali, cancellazioni. Dove invece l’errore è recuperabile, l’approvazione è solo un ostacolo.
Cominciare piccolo, e per un motivo preciso
Il modo più efficace di partire è scegliere un processo solo, misurabile e noioso, e portarlo fino in fondo. Non perché sia prudente, ma perché il primo progetto serve a scoprire com’è fatta davvero l’azienda: quali dati esistono, quanto sono puliti, chi decide cosa, quali strumenti sono in uso e quali sono stati comprati e mai adottati.
Queste informazioni non emergono da una riunione. Emergono provando a descrivere un processo con la precisione che serve per farlo eseguire a una macchina. Il secondo progetto, dopo, costa molto meno del primo.
Il criterio, in una riga
Prima si guarda il processo, poi si decide cosa automatizzare. Nell’ordine inverso si ottengono flussi eleganti che risolvono problemi che nessuno aveva, mentre il lavoro che pesa davvero continua a essere fatto a mano.
ApprofondisciAI & Automazioni




