L'intelligenza artificiale non risolve i problemi di un'azienda mal progettata, ma li aggrava. Un modello linguistico applicato a un processo confuso non genera chiarezza, bensì confusione, ma a un ritmo più rapido e su scala maggiore. Ecco perché molte aziende che hanno implementato l'IA non vedono alcun ritorno sull'investimento in nessuna voce del loro bilancio: non hanno acquistato una soluzione, ma un moltiplicatore, applicandolo a qualcosa che non era pronto per essere moltiplicato.
Questa non è una posizione contraria all'IA. È esattamente il contrario. L'IA merita di essere applicata laddove possa generare un reale vantaggio e, per farlo, dobbiamo smettere di considerarla un prodotto da installare e iniziare a vederla come una capacità integrata in un sistema funzionante.
Un processo aziendale è una catena di decisioni, responsabilità, dati ed eccezioni. Quando questa catena è ben definita, automatizzarla libera capacità. Quando non lo è, automatizzarla trasforma l'ambiguità in risultati concreti.
Pensate a cosa succede esattamente quando si collega un assistente basato sull'intelligenza artificiale a un processo di approvazione degli ordini che non è stato documentato da nessuno. Il modello non sa quali ordini richiedono una doppia firma, perché questa regola esiste solo nella mente di qualcuno del reparto. Non sa cosa fare quando un cliente ha un problema aperto, perché questa condizione non è mai stata messa per iscritto. Non sa cosa sia un'eccezione, perché le eccezioni venivano gestite tramite conversazione.
Il risultato non è un malfunzionamento visibile del sistema. Il risultato è peggiore: il sistema funziona, produce risposte plausibili e queste risposte circolano in tutta l'organizzazione con l'implicita autorità di provenire da un sistema. L'errore smette di essere rilevabile a prima vista e diventa sistematico.
Questa è la differenza tra uno strumento e un amplificatore. Uno strumento esegue un compito. Un amplificatore amplifica il segnale che riceve e non distingue tra segnale e rumore.
McKinsey, nella sua indagine globale sullo stato dell'IA del 2025 (con 1.993 partecipanti in 105 paesi), ha rilevato che l'88,1% delle organizzazioni utilizza regolarmente l'IA in almeno una funzione aziendale. Questo dato è stato ripetuto in ogni presentazione aziendale nell'ultimo anno.
Il resto del rapporto è molto meno ripetitivo. Solo 39% riporta un impatto sull'EBIT a livello aziendale. Solo 6% si qualificano come *ad alte prestazioni*, con oltre 5% di EBIT attribuibili all'IA. E la conclusione di McKinsey è letterale: un impatto significativo sul risultato finale rimane raro.
IBM è giunta alla stessa conclusione percorrendo una strada diversa. Il suo studio del 2025 sui CEO, condotto su 2.000 amministratori delegati di 33 paesi, ha rilevato che solo il 251% delle iniziative di intelligenza artificiale aveva prodotto il ritorno sull'investimento previsto e solo il 161% era stato esteso a livello organizzativo.
La domanda interessante non è perché così tanti falliscono, ma cosa distingue quelli che hanno successo. McKinsey individua un fattore che più di ogni altro è correlato all'impatto sull'EBIT: aver riprogettato radicalmente i flussi di lavoro. Solo 211 delle organizzazioni che hanno adottato l'IA generativa lo hanno fatto.
In altre parole: la variabile che distingue chi guadagna da chi non guadagna non è il modello, bensì il lavoro svolto in precedenza.
Ciò non significa che si tratti di un'azienda mal gestita o non redditizia. Molte aziende con processi inefficienti sono redditizie perché compensano la disorganizzazione con l'impegno umano. Il problema sorge quando si cerca di automatizzare tale impegno.
Questi sono i quattro sintomi che riscontriamo più frequentemente in una diagnosi:
Il processo esiste solo nella testa di qualcuno. C'è qualcuno che sa come si fa davvero. Quando questa persona è in vacanza, il processo si deteriora. Un processo non documentato non può essere automatizzato; nella migliore delle ipotesi, può essere solo parzialmente imitato.
Non esiste un'unica fonte di verità. I dati dei clienti sono presenti nel CRM, nel foglio di calcolo del venditore e nell'ERP, e tutte e tre le fonti presentano lievi differenze. L'intelligenza artificiale non risolve questa contraddizione; sceglie una delle tre versioni senza comunicarlo all'utente.
Le eccezioni non si progettano, si scoprono. Nessuno ha elencato i casi rari. Vengono risolti man mano che si presentano. In produzione, questi casi rari si collocano tra 15% e 30% del volume effettivo, e corrispondono esattamente ai punti in cui l'automazione si blocca.
Nessuno è responsabile del risultato, ma solo del compito. C'è qualcuno che approva, qualcuno che registra e qualcuno che emette la fattura, ma nessuno è responsabile dell'intero processo. Quando questo viene automatizzato, il divario di responsabilità non scompare, anzi si amplia, perché ora c'è un sistema intermedio a cui attribuire la colpa.
Nessuno di questi quattro problemi è un problema tecnologico. Tutti e quattro sono aggravati dall'aggiunta di tecnologia.
La sequenza è più importante degli strumenti. Questa è la differenza tra i due approcci:
Approccio | Inizia con l'intelligenza artificiale | Inizia con il processo |
Primo passo | Scegli un modello o un fornitore | Mappare decisioni, dati ed eccezioni |
Metrica iniziale | Numero di utenti, query, demo | Tempo di ciclo, tasso di errore, costo per caso |
Dove si manifesta il problema? | In produzione, dopo tre mesi | Nella fase diagnostica, su carta |
Costo della correzione | Stop: le integrazioni devono essere rifatte | Di seguito: un diagramma è corretto |
Ciò che rimane alla fine | Uno strumento che nessuno usa | Un processo migliore, con o senza intelligenza artificiale. |
La colonna a destra possiede una caratteristica che quella a sinistra non ha: genera valore anche se l'IA viene scartata. Se, al termine dell'analisi, si conclude che il caso non giustifica un modello, l'azienda conserva comunque un processo mappato, le eccezioni identificate e i colli di bottiglia individuati. Quel lavoro non andrà mai perso.
In The Cloud Group, questa sequenza è formalizzata nella nostra metodologia TCG-SAF™: prima si definisce la visione dell'ecosistema; poi si mappano i domini funzionali; quindi si strutturano i moduli e i relativi contratti; e solo a questo punto inizia la fase di progettazione. Quando l'analisi dei processi precede lo sviluppo, il dibattito su quale modello utilizzare diventa ciò che dovrebbe essere: una decisione tecnica reversibile, non la decisione strategica del progetto.
Questo stesso principio è quello che applichiamo nei nostri servizi. Riprogettazione dei processi e consulenza tecnologica [link interno], dove la mappatura dei processi e l'identificazione dei colli di bottiglia precedono sempre qualsiasi raccomandazione di automazione.
Sarebbe disonesto affermare che non si dovrebbe mai iniziare da lì. Ci sono tre situazioni in cui iniziare direttamente con un modello è la decisione giusta:
Quando il processo è già pulito e il collo di bottiglia è il volume. Se il sistema di classificazione dei biglietti è ben definito, con criteri espliciti e dati coerenti, e il problema è che ogni mese arrivano diecimila biglietti, non c'è bisogno di riprogettare nulla. Ciò che serve è la capacità.
Quando l'obiettivo dichiarato è imparare, non produrre. Un esperimento limitato, con un budget fisso e un obiettivo finale definito, rappresenta un investimento ragionevole nelle capacità organizzative. L'errore non è sperimentare, ma definire un esperimento un "progetto" e aspettarsi un ritorno sull'investimento.
Quando il caso d'uso risiede nel linguaggio. Riassumere la documentazione, estrarre informazioni dai contratti, analizzare il sentiment nelle conversazioni di supporto. Questi sono problemi che i software tradizionali faticano intrinsecamente a risolvere, e in cui questo modello offre funzionalità che prima non esistevano.
Al di fuori di questi tre scenari, partire dal modello significa partire dalla fine.
La discussione nei comitati di gestione è spesso impostata sulla domanda "dove collochiamo l'IA?". È una domanda che garantisce una risposta mediocre, perché parte dalla soluzione e cerca il problema.
La versione utile di questa domanda si articola in tre parti:
Un'azienda che risponde onestamente a queste tre domande scopre quasi sempre che il suo primo progetto di intelligenza artificiale non è in realtà un progetto di intelligenza artificiale. Si tratta piuttosto di un progetto di chiarezza operativa che in seguito integrerà i modelli laddove questi offrano un vantaggio.
Questa è la differenza tra un'azienda che investe nell'intelligenza artificiale e un'azienda che ne trae profitto.
No. L'IA amplifica il processo a cui si connette: se il processo presenta regole ambigue, dati contraddittori o eccezioni non documentate, l'automazione riproduce tali difetti a una velocità e su una scala maggiori. La riprogettazione dei processi dovrebbe precedere l'automazione, non seguirla.
Quattro elementi fondamentali: documentare le decisioni e chi le prende, stabilire un'unica fonte di riferimento per i dati coinvolti, elencare e definire le eccezioni e assegnare a qualcuno la responsabilità del risultato complessivo del processo, non solo dei singoli compiti.
Secondo lo studio IBM CEO Study 2025, solo il 251% delle iniziative di intelligenza artificiale ha generato il ritorno sull'investimento previsto e solo il 161% è stato implementato su larga scala. McKinsey identifica la profonda riprogettazione dei flussi di lavoro come il fattore maggiormente correlato all'impatto sull'EBIT, e solo il 211% delle organizzazioni l'ha implementata.
Dipende dalla portata, ma la diagnosi di un processo specifico (mappa decisionale, dati, eccezioni e responsabili) si completa solitamente in settimane, non in mesi. Si tratta di un lasso di tempo molto più breve rispetto alla correzione di un sistema di automazione mal progettato una volta che è in produzione.
Quando il processo è già definito e il problema è di natura volumetrica, quando l'obiettivo dichiarato è apprendere attraverso un esperimento circoscritto con un criterio di arresto, oppure quando il caso d'uso risiede nel linguaggio naturale (riassunto di documenti, estrazione di informazioni, analisi del sentiment).
Digitalizzare significa trasferire il processo attuale in uno strumento. Riprogettare significa mettere in discussione il processo prima di trasferirlo. Digitalizzare un processo inefficiente produce un processo più veloce ma inefficiente; riprogettarlo produce un cambiamento nel risultato aziendale.
Vuoi sapere se il tuo processo è pronto per essere automatizzato? Noi di The Cloud Group partiamo da una diagnosi, non da una proposta tecnica. Analizziamo il tuo caso specifico in una consulenza gratuita di due ore e ti diciamo cosa merita di essere riprogettato e cosa merita di essere automatizzato, anche se la risposta è che non è ancora il momento. Parliamone → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
