Le automazioni non servono se non sai cosa vuoi automatizzare, e questa frase dovrebbe essere scritta sopra ogni progetto aziendale che parte dall’entusiasmo per l’intelligenza artificiale, dai diagrammi pieni di frecce, dai moduli collegati fra loro, dai webhook, dai fogli aggiornati automaticamente, dalle email generate, dai post pubblicati senza intervento manuale, dagli agenti che promettono di lavorare al posto nostro e da tutta quella retorica dell’efficienza che spesso arriva prima della domanda più semplice: quale problema stiamo cercando di risolvere?
Molte aziende e molti professionisti si avvicinano alle automazioni con l’idea che automatizzare sia, di per sé, un segno di modernità. Se un processo è automatico, sembra più evoluto. Se un flusso parte da solo, sembra più intelligente. Se una richiesta passa da un modulo a un foglio, poi a un modello AI, poi a una mail, poi a un archivio, tutto appare più professionale. Ma un’automazione non è buona perché funziona tecnicamente. È buona solo se migliora un processo reale. E per migliorare un processo reale bisogna prima conoscerlo, descriverlo, guardarlo senza abbellirlo e capire dove perde tempo, dove produce errori, dove richiede giudizio e dove invece ripete sempre lo stesso gesto.
Automatizzare un processo che non hai capito significa accelerare la confusione.
Questo è il punto più importante. Se un’attività è disordinata, non diventa ordinata solo perché viene collegata a uno strumento. Se una procedura è ambigua, non diventa chiara solo perché passa attraverso un’automazione. Se le persone non sanno chi deve approvare una risposta, un flusso automatico non risolve il problema: lo sposta. Se i dati entrano già incompleti, l’automazione li distribuirà incompleti più rapidamente. Se una comunicazione aziendale è generica, l’AI potrà produrne dieci versioni più fluide, ma non per questo avrà creato una strategia. La tecnologia non corregge automaticamente il pensiero organizzativo. Spesso lo rende solo più veloce.
E un errore più veloce resta un errore.
A volte diventa persino peggiore, perché prima poteva essere fermato dalla lentezza manuale, mentre ora attraversa il sistema senza incontrare abbastanza resistenza. Una mail sbagliata inviata a mano è un errore. Una mail sbagliata generata e inviata automaticamente a cento clienti è un processo. Un dato copiato male in un foglio è un problema. Un dato sbagliato che alimenta report, notifiche e decisioni automatiche diventa un’infrastruttura fragile. Un post generico scritto una volta è dimenticabile. Un flusso che produce ogni giorno contenuti generici costruisce lentamente una comunicazione senza voce.
Per questo la prima domanda non dovrebbe essere “che cosa possiamo automatizzare?”, ma “che cosa accade davvero oggi?”.
Questa domanda sembra banale, ma raramente viene affrontata con sufficiente precisione. Le aziende hanno spesso una versione ufficiale dei propri processi e una versione reale. Nella versione ufficiale, una richiesta cliente arriva, viene presa in carico, classificata, gestita, archiviata, trasformata eventualmente in preventivo o risposta. Nella versione reale, invece, la richiesta arriva da email, sito, telefono, WhatsApp, messaggio privato, passaparola, vecchia conversazione, contatto personale; qualcuno la inoltra, qualcuno la dimentica, qualcuno risponde a memoria, qualcuno cerca un file, qualcuno chiede al collega, qualcuno aggiorna un foglio solo se ha tempo. Il processo ufficiale è ordinato. Il processo reale è umano, stratificato, pieno di eccezioni.
Le automazioni falliscono quando vengono costruite sulla versione ufficiale ignorando quella reale.
Per automatizzare bene, bisogna avere il coraggio di guardare il lavoro così com’è, non come dovrebbe essere in una presentazione. Bisogna chiedere chi fa cosa, quando, con quali strumenti, con quali eccezioni, quali dati mancano, quali passaggi si ripetono, quali decisioni vengono prese sempre nello stesso modo e quali invece richiedono esperienza. Bisogna osservare dove le persone si interrompono, dove copiano informazioni, dove aspettano approvazioni, dove riscrivono testi simili, dove cercano materiali, dove commettono errori, dove chiedono sempre le stesse cose. Solo dopo questa osservazione l’automazione può diventare utile.
Prima di automatizzare, bisogna mappare.
Mappare non significa costruire subito un diagramma complicato. Significa raccontare il processo in modo abbastanza chiaro da poterlo vedere. Da dove parte? Quale evento lo attiva? Quali informazioni entrano? Chi le controlla? Dove vengono salvate? Quali passaggi sono obbligatori? Quali sono opzionali? Che cosa succede se manca un dato? Chi riceve una notifica? Chi decide? Qual è l’output finale? Dove finisce? Come sappiamo se il processo è andato a buon fine? Quali errori sono possibili? Quali errori sono accettabili e quali no?
Queste domande sono meno affascinanti dell’automazione stessa, ma decidono tutto.
Un flusso automatico è una forma di pensiero cristallizzato. Una volta attivato, ripete una logica. Se quella logica è buona, l’automazione libera tempo, riduce errori, aumenta continuità. Se quella logica è debole, l’automazione ripete debolezza. Per questo è pericoloso automatizzare solo perché una cosa “si può fare”. Nel mondo dell’AI e degli strumenti no-code o low-code, moltissime cose si possono collegare. Un modulo può attivare un foglio, un foglio può attivare un modello linguistico, un modello può generare testo, quel testo può essere pubblicato, archiviato, inviato, tradotto, trasformato in immagine. Ma la possibilità tecnica non è ancora una ragione.
La domanda non è se si può fare.
La domanda è se ha senso che avvenga da solo.
Questa distinzione vale per ogni automazione. Una cosa può essere tecnicamente automatizzabile e professionalmente sconsigliabile. Si può automatizzare una risposta a un cliente, ma forse alcune richieste richiedono lettura umana. Si può automatizzare la pubblicazione di contenuti, ma forse serve una revisione editoriale. Si può automatizzare la classificazione di una richiesta, ma forse alcune categorie sono troppo ambigue. Si può automatizzare la generazione di un preventivo, ma forse ci sono condizioni commerciali che richiedono valutazione. Si può automatizzare un follow-up, ma forse il tono deve cambiare in base alla relazione.
Automatizzare bene significa anche sapere dove fermarsi.
Questa è una competenza spesso trascurata. Molti pensano che l’obiettivo sia automatizzare il più possibile. In realtà, l’obiettivo è automatizzare ciò che conviene automatizzare. Ci sono passaggi ripetitivi, a basso rischio, con regole chiare, che sono ottimi candidati. Ci sono passaggi ripetitivi ma delicati, che possono essere assistiti ma non lasciati completamente soli. Ci sono passaggi non ripetitivi, relazionali, strategici, creativi o critici, in cui l’automazione deve entrare con molta cautela. Una buona cultura dell’automazione non cerca di togliere l’umano ovunque. Cerca di metterlo dove serve davvero.
Il problema è che molte aziende non distinguono.
Vedono un processo lungo e pensano che vada automatizzato. Ma un processo può essere lungo perché contiene passaggi inutili, oppure perché contiene decisioni importanti. Può essere lento perché è mal organizzato, oppure perché richiede controllo. Può essere ripetitivo perché è meccanico, oppure perché ogni ripetizione contiene una piccola differenza che qualcuno esperto sa leggere. Se non si analizza il processo, si rischia di automatizzare nel modo sbagliato: si velocizzano passaggi che andavano eliminati, si eliminano controlli che andavano mantenuti, si standardizzano situazioni che richiedevano interpretazione.
Prima di automatizzare, quindi, bisogna anche semplificare.
Questa è una regola fondamentale. Non si automatizza il caos così com’è. Lo si osserva, lo si riduce, lo si rende leggibile e solo dopo, se ha senso, lo si automatizza. A volte il miglior intervento non è costruire un flusso nuovo, ma togliere un passaggio. A volte non serve AI, serve un modulo fatto meglio. A volte non serve un agente, serve una cartella ordinata. A volte non serve una catena di automazioni, serve decidere chi approva cosa. A volte non serve generare testi, serve scrivere una risposta standard decente. A volte il processo è lento perché nessuno ha mai avuto il coraggio di cancellare abitudini vecchie.
Automatizzare senza semplificare significa rendere più efficiente una cattiva abitudine.
E le cattive abitudini efficienti sono difficili da smontare, perché producono l’illusione di funzionare. Se un flusso automatico alimenta un report che nessuno legge, sembra comunque un sistema. Se un’automazione pubblica contenuti che non costruiscono valore, sembra comunque attività. Se un assistente risponde a domande interne usando materiali vecchi, sembra comunque supporto. La tecnologia produce movimento, e il movimento può essere scambiato per progresso. Ma non ogni movimento migliora l’organizzazione. A volte la rende solo più rumorosa.
Il rischio della produttività automatizzata è proprio questo: generare più materiale di quanto l’azienda sia capace di usare.
Più email, più notifiche, più bozze, più report, più contenuti, più file, più messaggi, più aggiornamenti. Ogni elemento nasce con l’intenzione di semplificare, ma se non è inserito in un processo chiaro può aumentare il carico. Una notifica inutile è un’interruzione. Un report non letto è rumore. Una bozza generata ma non revisionata è accumulo. Una classificazione automatica non controllata è rischio. Un archivio aggiornato automaticamente ma non consultato è solo ordine apparente.
Le automazioni devono ridurre complessità, non distribuirla in modo più elegante.
Per farlo, bisogna definire un obiettivo misurabile. Non necessariamente un numero sofisticato. Può essere semplice: ridurre il tempo di risposta, evitare la perdita di richieste, uniformare alcune comunicazioni, diminuire errori di copia, rendere più facile recuperare materiali, trasformare riunioni in azioni, aggiornare uno stato, generare bozze da revisionare, archiviare in modo coerente. Se non sappiamo quale miglioramento vogliamo ottenere, non sapremo nemmeno se l’automazione funziona. Dire “automatizziamo il marketing” non significa nulla. Dire “trasformiamo ogni scheda prodotto approvata in tre bozze di contenuto da revisionare” è già un processo.
La precisione dell’obiettivo protegge dall’entusiasmo generico.
L’entusiasmo generico è pericoloso perché porta a costruire automazioni dimostrative. Funzionano in apparenza, fanno vedere una catena di strumenti, impressionano chi non le ha mai viste, ma non risolvono un problema abbastanza importante da entrare davvero nelle abitudini. Dopo qualche settimana vengono dimenticate, oppure usate male, oppure disattivate perché generano più lavoro di quanto ne risparmino. Non è colpa degli strumenti. È colpa del fatto che l’automazione era nata per mostrare una possibilità, non per risolvere una frizione reale.
Una buona automazione, invece, nasce quasi sempre da un fastidio preciso.
Una richiesta che si perde. Un dato copiato troppe volte. Una risposta ripetuta sempre uguale. Un contenuto riscritto da zero partendo da materiali già disponibili. Una riunione che produce confusione. Un file che nessuno sa dove trovare. Un cliente che chiede informazioni già presenti da qualche parte. Una scadenza dimenticata. Un passaggio che dipende da una sola persona. Il fastidio è una buona guida perché è concreto. Non parla di innovazione in astratto. Dice: qui perdiamo tempo, qui sbagliamo, qui ci interrompiamo, qui il lavoro si inceppa.
Da quel punto si può costruire.
Non prima.
Un altro errore frequente è partire dallo strumento invece che dal processo. “Voglio usare Make.” “Voglio creare un agente.” “Voglio un chatbot.” “Voglio collegare ChatGPT al mio gestionale.” “Voglio automatizzare i post.” Queste richieste possono avere senso, ma partono già da una soluzione. Prima bisogna capire il problema. Make può essere lo strumento giusto, oppure no. Un chatbot può essere utile, oppure prematuro. Un agente può essere potente, oppure eccessivo. Automatizzare post può essere sensato, oppure produrre spazzatura più velocemente. Lo strumento è una risposta possibile, non il punto di partenza.
Le aziende confuse amano gli strumenti perché gli strumenti danno la sensazione di agire.
Mappare processi, invece, sembra più lento. Chiedere alle persone come lavorano davvero sembra meno innovativo. Ordinare materiali, definire responsabilità, eliminare passaggi inutili, scrivere procedure, creare criteri di controllo: tutto questo appare meno brillante. Ma è proprio qui che l’automazione trova le sue fondamenta. Senza queste fondamenta, lo strumento diventa un vestito tecnologico su un corpo organizzativo debole.
L’intelligenza artificiale amplifica ancora di più questo problema.
Perché prima molte automazioni erano basate su regole abbastanza rigide: se succede questo, fai quello. Con l’AI entrano in gioco generazione linguistica, classificazione semantica, interpretazione, sintesi, trasformazione. Questo rende i flussi più potenti, ma anche più delicati. Se un modello deve classificare richieste, bisogna definire bene le categorie. Se deve generare risposte, bisogna dargli tono, limiti, fonti, esempi. Se deve riassumere documenti, bisogna sapere cosa conta. Se deve produrre contenuti, bisogna definire identità, pubblico, vincoli. L’AI non elimina la progettazione. La rende più necessaria.
Un prompt dentro un’automazione non è una frase volante.
È una regola di comportamento.
Se quella regola è scritta male, il sistema lavorerà male molte volte. Se è troppo vaga, produrrà output variabili. Se è troppo libera, inventerà. Se è troppo rigida, non si adatterà. Se non prevede eccezioni, gestirà male i casi limite. Se non viene aggiornata, diventerà vecchia. Per questo automatizzare con l’AI richiede ancora più chiarezza rispetto alle automazioni tradizionali. Non basta collegare moduli. Bisogna progettare il comportamento del sistema.
E progettare comportamento significa sapere cosa vuoi ottenere.
Non “voglio che l’AI risponda ai clienti”. Quali clienti? A quali domande? Con quali fonti? Con quali limiti? Quando deve fermarsi? Quando deve passare la richiesta a una persona? Quale tono deve usare? Quali informazioni non deve promettere? Dove salva la conversazione? Chi controlla la qualità? Come correggiamo una risposta sbagliata? Senza queste domande, non hai un’automazione. Hai una scommessa.
Lo stesso vale per i contenuti. Non “voglio automatizzare i social”. Quali contenuti? Da quali fonti? Con quale calendario? Con quale tono? Con quale livello di revisione? Quali canali? Quali formati? Quali parole evitare? Quali immagini usare? Quale obiettivo hanno i post? Informare, vendere, intrattenere, educare, posizionare, costruire fiducia? Se non sai rispondere, l’automazione produrrà contenuti perché può produrli. Ma non ogni contenuto prodotto è comunicazione. Spesso è solo riempimento.
Automatizzare il vuoto non crea valore.
Lo moltiplica.
Questa è una delle frasi più importanti per chi lavora oggi con AI e automazioni. Se non hai una strategia, l’automazione non la inventa. Se non hai materiali, li compensa con genericità. Se non hai un processo, ne simula uno. Se non hai criteri, produce output che sembrano accettabili. Se non hai un pubblico chiaro, parla a un pubblico medio. Se non hai identità, genera una voce simile a tante altre. In tutti questi casi l’automazione sembra funzionare, ma sta rendendo operativo un vuoto.
Per evitare questo, bisogna distinguere fra automazione e sistema.
Un’automazione è un flusso che esegue passaggi. Un sistema è un insieme di processi, regole, materiali, persone, controlli e obiettivi. L’automazione da sola è fragile. Il sistema le dà senso. Per esempio, un flusso che genera post da un foglio è un’automazione. Ma diventa sistema solo se esistono una strategia editoriale, materiali approvati, una procedura di revisione, criteri di pubblicazione, controllo del tono, archiviazione dei contenuti prodotti, misurazione dei risultati. Senza sistema, l’automazione è solo una catena tecnica.
Molte aziende vogliono automazioni.
Poche sono pronte a costruire sistemi.
Questo è comprensibile, perché un’automazione si vede. Puoi mostrarla. Puoi dire: quando succede questo, parte quello. Un sistema invece è meno spettacolare. È fatto di decisioni, criteri, documentazione, ruoli, manutenzione. Ma nel tempo è il sistema a determinare se l’automazione regge. Il flusso tecnico può essere costruito in un giorno. La cultura operativa che lo rende utile richiede più tempo. E se questa cultura manca, anche l’automazione migliore verrà usata male.
Un altro aspetto decisivo è la manutenzione.
Le automazioni non sono oggetti che si costruiscono e poi si dimenticano. Cambiano gli strumenti, cambiano le API, cambiano i campi nei fogli, cambiano i modelli AI, cambiano i processi aziendali, cambiano i prodotti, cambiano i responsabili, cambiano i canali. Un flusso che oggi funziona potrebbe rompersi domani o, peggio, continuare a funzionare producendo risultati non più corretti. Per questo, prima di automatizzare, bisogna sapere chi controllerà il sistema. Chi riceve gli errori? Chi aggiorna i prompt? Chi verifica gli output? Chi decide quando modificare il flusso? Chi documenta le modifiche?
Se nessuno mantiene un’automazione, l’automazione diventa un rischio differito.
All’inizio fa risparmiare tempo. Poi nessuno sa più come è fatta. Poi cambia qualcosa. Poi produce errori. Poi tutti hanno paura di toccarla. Oppure viene abbandonata, e l’azienda torna al metodo manuale con una nuova sfiducia verso l’innovazione. Questo accade spesso non perché l’automazione fosse inutile, ma perché non era stata pensata come parte di un processo vivo. Anche qui, sapere cosa automatizzare significa sapere anche come mantenere ciò che viene automatizzato.
La manutenzione è parte del costo reale.
E il costo reale non è solo il tempo per costruire il flusso. È il tempo per pensarlo, testarlo, correggerlo, documentarlo, formare le persone, monitorarlo, aggiornarlo. Quando un cliente o un’azienda chiede “quanto ci vuole ad automatizzare questa cosa?”, la risposta onesta dovrebbe includere anche questa parte. Si può costruire un prototipo rapidamente, ma trasformarlo in un processo affidabile richiede più attenzione. L’AI ha aumentato la velocità dei prototipi, non ha eliminato la responsabilità dei sistemi.
Una buona automazione dovrebbe essere testata sul reale.
Non solo su casi ideali. Bisogna provarla con dati incompleti, richieste strane, errori di compilazione, testi ambigui, eccezioni, casi limite. Bisogna vedere cosa succede quando manca un campo, quando arriva una richiesta non prevista, quando il modello genera una risposta debole, quando un file non viene trovato, quando una persona non approva in tempo. Le automazioni fragili funzionano solo nel mondo perfetto della demo. Le automazioni utili resistono almeno un po’ alla realtà.
La realtà è sempre più sporca del flusso.
Per questo, paradossalmente, automatizzare bene richiede una profonda conoscenza del lavoro manuale. Devi sapere dove le persone improvvisano, dove correggono a occhio, dove interpretano, dove aggirano il sistema, dove salvano il processo con esperienza. Se ignori queste micro-competenze, rischi di automatizzare solo la parte visibile e perdere quella invisibile. Un operatore esperto magari non segue una procedura perfetta, ma sa riconoscere una richiesta delicata. Se l’automazione non prevede quella delicatezza, potrà essere più ordinata e meno intelligente.
Non tutta la conoscenza aziendale è scritta nei campi di un modulo.
Molto sapere è tacito, incorporato nelle persone, nelle abitudini, nelle eccezioni gestite senza pensarci. Prima di automatizzare, bisogna cercare anche questo sapere. Chiedere a chi fa il lavoro ogni giorno. Osservare. Non limitarsi al racconto del responsabile, che spesso descrive il processo come dovrebbe essere. Le automazioni migliori nascono quando il sapere operativo viene portato in superficie e trasformato in regole, controlli, eccezioni, soglie, note. Senza questo passaggio, il sistema rischia di essere elegante ma ingenuo.
Automatizzare non è solo collegare strumenti.
È tradurre il lavoro in una logica.
E ogni traduzione perde qualcosa se non viene fatta con attenzione. Il compito è capire cosa può essere tradotto in regole, cosa può essere assistito dall’AI, cosa deve restare umano, cosa va controllato, cosa va escluso. Questa è una competenza progettuale, non semplicemente tecnica. Chi sa usare uno strumento di automazione ma non sa leggere un processo costruirà flussi spettacolari e spesso inutili. Chi sa leggere processi potrà anche usare strumenti semplici e ottenere risultati molto più solidi.
Questo è particolarmente importante per le piccole imprese.
Una piccola azienda non ha bisogno di automatizzare tutto. Ha bisogno di scegliere bene. Spesso bastano poche automazioni semplici per migliorare molto il lavoro: raccogliere richieste in modo ordinato, inviare conferme, creare bozze, aggiornare stati, ricordare scadenze, trasformare materiali in contenuti, archiviare documenti, generare riepiloghi. Ma se parte da un progetto troppo ampio, rischia di perdersi. Meglio un flusso piccolo, chiaro e usato davvero che un sistema complesso che nessuno mantiene.
La semplicità è una forma di intelligenza operativa.
Un’automazione semplice permette di imparare. Si vede dove funziona, dove sbaglia, dove le persone la usano, dove la aggirano. Si può correggere. Si può estendere. Una grande automazione costruita troppo presto, invece, concentra molti rischi. Se qualcosa non funziona, è difficile capire dove. Se le persone non si fidano, la rifiutano. Se il processo cambia, tutto va rivisto. La maturità nell’automazione è progressiva. Prima si automatizza un pezzo chiaro. Poi si misura. Poi si aggiunge. Poi si collega. Non si costruisce una macchina enorme sopra un processo che nessuno ha descritto.
Un buon metodo può essere molto pratico.
Prima: osserva il processo reale. Secondo: elimina passaggi inutili. Terzo: definisci input e output. Quarto: stabilisci chi controlla. Quinto: automatizza solo la parte ripetitiva. Sesto: testa con casi reali. Settimo: misura se ha ridotto tempo, errori o dispersione. Ottavo: documenta. Nono: aggiorna. Questa sequenza non è glamour, non fa molta scena, non produce subito l’effetto “wow”. Ma funziona. E soprattutto evita di costruire automazioni che servono più a dimostrare competenza tecnica che a migliorare il lavoro.
Il mondo dell’AI è già pieno di dimostrazioni.
Ha bisogno di meno demo e più processi che reggono.
Una demo mostra che qualcosa è possibile. Un processo che regge mostra che qualcosa è utile. La differenza è enorme. Possibile significa che il sistema può generare un risultato in condizioni controllate. Utile significa che quel risultato migliora il lavoro nel tempo. Molti confondono le due cose, soprattutto quando l’AI produce output sorprendenti. Ma un’azienda non vive di sorprese. Vive di continuità, affidabilità, responsabilità, manutenzione. Un’automazione utile deve entrare in questa vita quotidiana, non limitarsi a impressionare in una presentazione.
Per questo, prima di automatizzare, bisogna anche chiedersi chi userà davvero il risultato.
Se un flusso produce un report, chi lo legge? Se genera una bozza, chi la revisiona? Se archivia file, chi li cerca? Se invia notifiche, chi le riceve e cosa deve fare? Se aggiorna un foglio, chi prende decisioni da quel foglio? Se crea contenuti, chi li approva e con quale criterio? Ogni output automatico dovrebbe avere un destinatario reale e un uso reale. Altrimenti diventa materiale morto. E l’automazione di materiale morto è solo produzione di polvere digitale.
Un’automazione deve avere una conseguenza chiara.
Altrimenti è teatro.
Il teatro tecnologico è molto diffuso: sistemi che fanno cose perché si può, dashboard che mostrano dati non usati, flussi che generano documenti non letti, AI che produce sintesi che nessuno integra, automazioni che inviano messaggi ignorati. Tutto sembra avanzato. Poco cambia davvero. Il criterio dovrebbe essere più duro: se spegniamo questa automazione, chi sente la mancanza? Se nessuno la sente, forse non serviva. Se qualcuno la sente perché gli evita una fatica reale o gli permette di decidere meglio, allora ha valore.
Questa domanda è crudele, ma sana.
Le automazioni non servono se non sai cosa vuoi automatizzare perché la tecnologia non sostituisce la chiarezza. Può amplificarla, può tradurla in flussi, può renderla più efficiente, può distribuirla meglio. Ma se la chiarezza non c’è, l’automazione diventa un moltiplicatore di ambiguità. Prima confusione manuale, poi confusione automatica. Prima errori lenti, poi errori rapidi. Prima contenuti generici occasionali, poi contenuti generici programmati. Prima processi impliciti, poi processi impliciti travestiti da sistemi.
La buona automazione, invece, è quasi umile.
Risolve un passaggio preciso. Toglie una fatica reale. Riduce un errore. Rende visibile uno stato. Ricorda una scadenza. Prepara una bozza. Archivia nel posto giusto. Trasforma un input in un output utile. Non pretende di essere intelligente in senso assoluto. È intelligente perché sta nel punto giusto. E il punto giusto non lo decide lo strumento. Lo decide la comprensione del lavoro.
Alla fine, automatizzare bene significa fare una cosa molto umana: guardare con attenzione ciò che facciamo ogni giorno.
Guardarlo senza vergogna e senza mitologia. Vedere dove siamo lenti perché siamo disorganizzati e dove siamo lenti perché stiamo pensando. Vedere dove ripetiamo passaggi inutili e dove invece stiamo esercitando giudizio. Vedere dove i dati si perdono, dove le persone si interrompono, dove le responsabilità si sfumano. Solo dopo questa osservazione l’automazione può diventare una forma di intelligenza pratica.
Prima di allora è solo movimento.
E nel lavoro non serve muoversi di più.
Serve sapere che cosa vale la pena far muovere da solo, che cosa deve essere fermato, che cosa deve essere semplificato e che cosa, nonostante tutta la tecnologia disponibile, deve restare nelle mani di qualcuno che sa davvero cosa sta facendo.