Le aziende investono in AI e vedono risultati deludenti perché automatizzano processi rotti. Il problema non è il modello: è il tempo perso tra un passaggio e l'altro. Ecco perché l'AI va usata per ridisegnare il lavoro, non per verniciarlo.

Una pratica impiega tre settimane per attraversare un'azienda. Il lavoro vero, quello in cui qualcuno legge, decide, compila, dura forse mezz'ora. Il resto è attesa: la mail che nessuno apre, l'approvazione che dorme nella casella di un dirigente in ferie, il file Excel che passa da un ufficio all'altro come un pacco postale.

Ora immagina di comprare il miglior modello AI sul mercato e renderlo capace di dimezzare quella mezz'ora. Hai risparmiato quindici minuti. Su tre settimane.

È questo, in sintesi, il motivo per cui così tanti progetti di AI in azienda producono demo brillanti e bilanci immutati. E la cosa più frustrante è che non è un problema nuovo: lo avevamo già visto, documentato e teorizzato più di trent'anni fa.

Indice

1. Lastricare i sentieri delle mucche, versione 2026
2. Il lavoro non è dove pensi
3. Perché nessuno ridisegna davvero
4. Il falso prerequisito
5. Come si fa in concreto
6. Il fattore umano

1. Lastricare i sentieri delle mucche, versione 2026

Nel 1990 Michael Hammer scrisse sulla Harvard Business Review un articolo destinato a diventare un classico, Reengineering Work: Don't Automate, Obliterate. La sua diagnosi era semplice: le aziende avevano investito somme enormi nell'informatica ottenendo pochissimo, perché usavano la tecnologia per meccanizzare il modo in cui avevano sempre lavorato.

Hammer aveva un'immagine efficace per questo errore: paving the cow paths, lastricare i sentieri tracciati dalle mucche. Prendi un percorso nato per caso, tortuoso e inefficiente, e invece di chiederti se abbia senso ci versi sopra l'asfalto. Ora è un sentiero tortuoso e inefficiente, ma pavimentato.

Sostituisci "informatica" con "AI generativa" e la frase funziona ancora perfettamente. Le aziende comprano licenze, lanciano chatbot interni, distribuiscono assistenti a migliaia di dipendenti. Poi misurano, e scoprono che l'impatto è marginale.

Un esempio pubblico: tra ottobre e dicembre 2024 il Department for Business and Trade britannico ha sperimentato Microsoft 365 Copilot su circa mille licenze. Il rapporto finale, pubblicato ad agosto 2025, descrive un uso modesto: in media poco più di un'azione al giorno per utente. Le slide venivano prodotte circa sette minuti più in fretta ma con qualità inferiore, e i risparmi sulle email erano definiti "estremamente piccoli".

La conclusione è netta: nessuna prova solida che il tempo risparmiato si traduca in maggiore produttività. Eppure il 72% dei partecipanti si è dichiarato soddisfatto.

Ethan Mollick, che studia l'adozione dell'AI alla Wharton School, lo ha formulato così: l'AI che migliora la performance individuale non si traduce automaticamente in un miglioramento della performance organizzativa. Rendere ogni singolo dipendente un po' più veloce non rende più veloce l'azienda, se l'azienda è lenta per ragioni che con la velocità del singolo non c'entrano nulla.

2. Il lavoro non è dove pensi

Nel suo articolo Hammer cita la stima di una compagnia assicurativa: una richiesta di polizza impiegava in media 22 giorni per essere evasa, ma qualcuno ci lavorava sopra, in tutto, per 17 minuti.

Fai il conto: se l'AI raddoppiasse la velocità di ogni singolo passaggio, risparmieresti otto minuti e mezzo. I 22 giorni resterebbero quasi intatti, perché quei giorni non sono fatti di lavoro: sono fatti di code, passaggi di mano, attese.

Non serve un caso di studio per riconoscere quanto siano lontane: nella maggior parte dei processi aziendali la distanza tra le due è abissale. Pensa all'ultima volta che hai dovuto far approvare una spesa, aprire un fornitore o ottenere l'accesso a un sistema. Quanto è durato il lavoro, e quanto l'attesa? Un'apertura pratica che richiede 25 minuti di lavoro può impiegare da 2 a 14 giorni di calendario.

Dove finisce tutto quel tempo? In attività che chiameremmo overhead di coordinamento: sollecitare un collega, aspettare un documento, inoltrare una mail al reparto giusto, capire chi deve approvare, rimettere a posto un dato che arriva in un formato diverso.

Nessuno di questi passaggi crea valore. Esistono perché il processo è stato disegnato, o più spesso si è sedimentato, attorno a confini organizzativi, sistemi che non si parlano e abitudini mai messe in discussione.

Applicare l'AI al lavoro "vero" è come ottimizzare il motore di un'auto ferma al semaforo: il collo di bottiglia è altrove.

3. Perché nessuno ridisegna davvero

Se il problema è così evidente, perché le aziende continuano a commettere questo errore? Le ragioni sono tre, e nessuna è tecnologica.

1. La prima è un problema di autorità.
   L'AI arriva quasi sempre dall'IT o da un team dedicato all'innovazione, che ha il budget per gli strumenti ma non l'autorità sui processi: può decidere quali assistenti adottare, quante licenze acquistare o che prototipi costruire, ma non chi debba firmare cosa. E i processi che contano attraversano più reparti. L'amministrazione dipende dagli acquisti, gli acquisti dalla logistica, e nessuno può ridisegnarli da solo. Il risultato è che l'AI viene appoggiata sopra la struttura esistente, perché è l'unica cosa che si può fare senza chiedere il permesso a nessuno.
2. La seconda è un'asimmetria del rischio.
   Ridisegnare un processo vuol dire esporsi. Pensa a chi dovrebbe guidare il cambiamento: se il progetto riesce, il merito si diluisce tra tanti; ma se fallisce, il process owner rischia il posto. Gli operatori, d'altra parte, temono di essere sostituiti e non hanno alcun incentivo a raccontare come funzionano davvero le cose. Rivelare tutte le scorciatoie e le inefficienze può sembrare un modo per dimostrare che il proprio lavoro è superfluo. Lo status quo sembra quindi la scelta prudente, anche quando strategicamente è la più pericolosa.
3. La terza è un errore di prospettiva.
   Si guarda all'AI come a uno strumento di produttività personale, da distribuire come si distribuiva Office. In questo modo la domanda diventa "come può questo assistente aiutare Maria a scrivere le email più velocemente?" invece di "perché Maria deve scrivere quelle email?".

4. Il falso prerequisito

C'è un'obiezione che si sente spesso nelle aziende, soprattutto in quelle più strutturate: prima di introdurre l'AI dobbiamo consolidare i dati, migrare il gestionale, unificare i sistemi. Sembra una posizione responsabile, ma spesso è una trappola.

Le grandi migrazioni sono tra i progetti più rischiosi che un'azienda possa affrontare. Il caso della banca britannica TSB è diventato un manuale di cosa può andare storto. Nel 2018 il passaggio a una nuova piattaforma di core banking ha lasciato per settimane una parte consistente dei suoi 5,2 milioni di clienti senza servizi. I costi legati all'incidente hanno superato i 330 milioni di sterline, e nel 2022 i regolatori britannici, FCA e PRA, hanno inflitto alla banca una multa complessiva di 48,65 milioni.

Nel settembre 2025 Zimmer Biomet, produttore di dispositivi medici, ha fatto causa a Deloitte chiedendo almeno 172 milioni di dollari. Secondo l'azienda, il passaggio al nuovo gestionale SAP l'aveva lasciata per mesi incapace di spedire prodotti, emettere fatture e produrre report di vendita. Deloitte contesta le accuse.

Il punto interessante è che gli agenti AI cambiano questa equazione. Un'integrazione tradizionale è deterministica: se i dati non sono esattamente nel formato atteso, si rompe. Un agente, invece, tollera l'incoerenza:

• sa leggere un estratto conto in formati diversi o una fattura elettronica in XML e una estera in PDF,
• sa riconoscere che due anagrafiche descrivono lo stesso cliente anche se scritte in modo diverso (es. "Rossi S.r.l." e "ROSSI SRL"),
• sa ricostruire il contesto di una pratica da fonti sparse (es. mettendo insieme una mail, un allegato e una riga del gestionale).

Questo significa che si può costruire un layer di orchestrazione sopra i sistemi esistenti, senza aspettare il giorno, che potrebbe non arrivare mai, in cui tutto sarà finalmente pulito e unificato. Il disordine dei sistemi diventa un problema da gestire, non una condizione da risolvere prima di cominciare.

5. Come si fa in concreto

Ridisegnare un processo non significa fare un bel diagramma di flusso. Significa prima di tutto capire come il lavoro scorre davvero, che è quasi sempre diverso da come è scritto nelle procedure.

Per farlo servono due strumenti, insieme. Il process mining, cioè l'analisi dei log e dei timestamp nei sistemi, che mostra dove il tempo si accumula. E le interviste agli operatori, che spiegano perché: le eccezioni non documentate, le scorciatoie, il collega che "sa come si fa". Uno senza l'altro restituisce una mappa incompleta. I log senza le persone non spiegano le cause, le persone senza i log ricordano male le proporzioni.

Una mappatura seria deve rispondere almeno a queste domande:

• qual è il percorso standard, quando tutto va bene?
• quanto dura il processo dall'inizio alla fine, e quanta parte di quel tempo è lavoro effettivo?
• dove si ferma la pratica, e per quanto tempo?
• quante volte passa di mano, e tra quali reparti?
• cosa succede quando qualcosa va storto: quante sono le eccezioni, chi le gestisce e come?
• quali processi stanno a monte e a valle?
• quali regole sono scritte, e quali esistono solo nella testa di qualcuno?
• da dove arrivano i dati, in quali formati, e quale sistema fa fede quando due si contraddicono?
• come cambia il processo tra sedi, Paesi o società del gruppo?
• quanto è grande il divario tra touch time ed elapsed time?
• chi possiede il processo, e quanto è pronto il personale a cambiarlo?

Una volta mappato il processo, ogni passaggio va collocato in una di tre categorie.

I passaggi deterministici seguono una logica condizionale, del tipo "se X allora Y", senza alcun giudizio. Una fattura sotto una certa soglia, con un ordine d'acquisto corrispondente, si paga. Una richiesta di ferie entro i giorni residui si approva. Qui l'AI non serve: basta il software tradizionale, che costa poco, è verificabile e non ha allucinazioni. Usare un LLM per una regola if-then è come assumere un avvocato per leggere un semaforo.

I passaggi agentici sono quelli in cui serve un giudizio, ma un giudizio che si può imparare e controllare. Pensa a classificare una mail in arrivo e mandarla all'ufficio giusto, a capire se un allegato è davvero il documento richiesto, ad assegnare un ticket alla categoria corretta.

Il modello dà il meglio quando ha alle spalle molti casi già decisi o molti esempi storici con un esito registrato e deve scegliere tra poche opzioni, il cui esito si verifica a colpo d'occhio e l’output è una scelta discreta, come approvare o rifiutare, instradare verso un ufficio o un altro, segnalare una corrispondenza o no. Se invece produce un documento che qualcuno dovrà comunque rileggere riga per riga, il tempo guadagnato nella scrittura evapora nella verifica.

I passaggi “human-in-the-loop” sono quelli troppo rischiosi o troppo poco documentati per essere delegati: concedere un fido a un nuovo cliente, accettare il cambio di IBAN di un fornitore, rispondere a un reclamo che può finire in contenzioso. Qui l'agente non decide, prepara: raccoglie le evidenze, ricostruisce il contesto, presenta il caso già istruito a chi deve prendere la decisione.

Prendiamo due processi tipici.

Esempio 1: la riconciliazione bancaria mensile in un gruppo con centinaia di conti e più sedi.

Il processo classico prevede di sollecitare gli estratti conto, normalizzarli a mano perché ogni paese li produce in modo diverso, confrontare le righe una per una, scambiarsi email tra fusi orari diversi per chiarire le partite aperte, aspettare risposte, consolidare. Un mese intero, o quasi.

Ridisegnato, lo stesso processo si riduce a tre momenti.

1. Flussi automatici degli estratti conto, senza nessuna AI.
2. Abbinamento basato su regole per la maggior parte delle partite, con agenti che si occupano delle eccezioni assemblando per ciascuna le evidenze necessarie.
3. Revisione umana delle sole eccezioni, con il contesto già pronto.

Esempio 2: l'apertura di un nuovo fornitore.

Nella versione classica, l'ufficio acquisti chiede i documenti via mail: visura camerale, DURC, coordinate bancarie, certificazioni. Il fornitore li manda a rate, in formati diversi. Qualcuno li controlla uno per uno, sollecita quelli mancanti e li inoltra all'amministrazione, che li ricontrolla e inserisce i dati a mano nel gestionale. Poi serve la firma di un responsabile, che magari è in trasferta. Il lavoro vero è forse di un'ora. Il calendario, spesso, dice settimane.

Ridisegnato:

1. Un modulo strutturato raccoglie tutti i documenti in un unico punto, con controlli automatici su campi obbligatori e scadenze. Nessuna AI.
2. Un agente legge i documenti e verifica che siano coerenti tra loro: ragione sociale, partita IVA, sede. Segnala ciò che è scaduto o mancante e chiede direttamente al fornitore le integrazioni.
3. Una persona interviene solo sui casi che lo richiedono, come un fornitore estero o un IBAN intestato a un soggetto diverso, e trova il fascicolo già pronto.

In entrambi i casi, nota cosa è sparito: i solleciti, le mail avanti e indietro, il doppio controllo, le attese, le ridigitazioni. Non hai reso più veloce il lavoro, hai proprio eliminato i passaggi che non erano lavoro. Il risparmio - e quindi il guadagno - si misura in settimane, non in minuti.

6. Il fattore umano, di nuovo

Sarebbe disonesto presentare il business process reengineering come una ricetta infallibile. Negli anni Novanta molti di quei progetti non mantennero le promesse. Già nel 1993 Hammer e Champy stimavano che tra il 50% e il 70% delle aziende che ci provavano non ottenesse i risultati sperati. Qualche anno dopo, Hammer ammise al Wall Street Journal di aver sottovalutato la dimensione umana. Eliminare i passaggi di mano significava, molto spesso, licenziare le persone che quei passaggi li eseguivano. Non sorprende che queste persone non collaborassero.

L'AI non cancella questo problema, ma ne sposta i termini. Il lavoro che il redesign elimina oggi è in gran parte proprio l'overhead di coordinamento: rincorrere, inoltrare, ricopiare. È il lavoro che nessuno ha scelto di fare e che le persone spesso detestano. Quello che resta è il lavoro ad alto contenuto di giudizio, che è anche quello per cui sono state assunte.

Questo non rende il cambiamento indolore, e chi lo racconta come tale sta vendendo qualcosa. Ma rende possibile un patto diverso con chi lavora: non "ti sostituiamo con una macchina", ma "ti togliamo la parte del lavoro che ti fa perdere tempo". Funziona solo se è vero, e solo se gli operatori vengono coinvolti dall'inizio, perché senza di loro la mappa del processo sarà sbagliata.

Da qui discendono alcune condizioni senza le quali è meglio non partire.

• Uno sponsor con autorità reale su più funzioni per cambiare il processo da un capo all'altro, perché i processi che contano attraversano i reparti.
• Le persone che fanno il lavoro coinvolte dal primo giorno, perché sono le uniche che sanno come funziona davvero;
• Team che mettano insieme competenze diverse allo stesso tavolo: chi conosce il processo, chi sa costruire software affidabile, chi sa cosa un modello può e non può fare.
• Architetture agnostiche, che non dipendano da un solo modello, perché i modelli cambiano, vengono limitati, ritirati e quello migliore oggi non sarà il migliore domani.
• KPI misurati prima di costruire qualsiasi cosa: durata complessiva, passaggi di mano, quota di eccezioni. Senza questa misura, dopo non saprai dire se è cambiato qualcosa;

E un criterio per scegliere da dove cominciare: non il processo più visibile, né quello su cui si lavora di più, ma quello in cui la distanza tra touch time ed elapsed time è più grande. È lì che si nasconde il tempo.

La domanda giusta, quindi, non è "dove possiamo applicare l'AI?". È "quale lavoro non dovrebbe esistere?".

La prima porta a un sentiero per mucche asfaltato. La seconda, finalmente, a una strada.

Simone Conversano - AI Transformation & Marketing Specialist - Datapizza