Trenta o quaranta miliardi di dollari investiti dalle imprese in intelligenza artificiale generativa, e il 95% delle organizzazioni che non registra alcun ritorno sul conto economico. Il dato viene da The GenAI Divide: State of AI in Business, lo studio del progetto NANDA del MIT Media Lab costruito su 52 casi aziendali, 153 questionari a figure di vertice e l’analisi di 300 iniziative pubbliche.
Il numero è circolato molto più del metodo che lo ha prodotto, e vale la pena dirlo: 52 interviste non sono un campione statistico rappresentativo, la definizione di ritorno adottata è quella dell’impatto misurabile a conto economico, e diverse iniziative escluse potrebbero produrre valore su orizzonti più lunghi.
Il segnale però resta forte, e soprattutto la spiegazione degli autori è verificabile per chiunque abbia visto qualche progetto da vicino: la differenza fra chi ottiene risultati e chi no è organizzativa prima che tecnologica.
Indice degli argomenti:
Il costo di licenza pesa meno di un quinto del totale
Un business case tipico mette a numeratore un risparmio di ore stimato e a denominatore il canone del fornitore. Quella frazione produce quasi sempre ritorni spettacolari, ed è il motivo per cui i progetti vengono approvati con facilità e disattesi con la stessa facilità.
Le voci che mancano sono quattro e insieme superano largamente la licenza.
- L’integrazione verso i sistemi esistenti, che nei contesti con gestionali stratificati assorbe più giornate di quante ne assorba la configurazione del modello.
- La preparazione dei dati, che nei progetti arrivati in produzione vale spesso metà dell’effort.
- Il presidio continuativo, perché il sistema va monitorato, i casi limite vanno raccolti e le configurazioni riviste quando il fornitore aggiorna.
- Il tempo delle persone che il processo lo eseguono oggi, sottratto al lavoro corrente per sessioni di validazione e formazione.
Un ordine di grandezza che serve a smontare la frazione ottimistica: nei progetti seguiti fino alla produzione il canone del fornitore raramente supera il 20% del costo totale del primo anno. Chi costruisce il business case sull’altro 80% invisibile costruisce un impegno che non manterrà.
Le ore risparmiate non diventano euro finché qualcuno non le riassegna
Sul lato del beneficio l’errore è speculare e più insidioso, perché sembra rigoroso. Si misura il tempo che l’attività richiedeva prima, si misura quello che richiede dopo, si moltiplica la differenza per il costo orario e per il numero di ripetizioni annue. Il risultato è un numero grande e falso.
Quel numero diventa vero soltanto se accade una di tre cose: l’organizzazione riduce la capacità impiegata su quel processo, oppure aumenta il volume gestito a parità di persone, oppure riassegna il tempo liberato ad attività che generano ricavo. Se non accade nessuna delle tre, il tempo risparmiato si disperde nella giornata lavorativa e il conto economico non se ne accorge.
La conseguenza pratica è che il business case va scritto insieme a chi guida la funzione, non soltanto insieme all’IT, e deve contenere una dichiarazione esplicita su cosa si fa del tempo liberato. Una frase, con un nome e una data. È la riga che distingue un progetto che produce valore da una dimostrazione riuscita.
Esistono poi benefici che vale la pena contabilizzare separatamente, perché reali e difficili da monetizzare: riduzione della varianza qualitativa fra operatori, minore tempo di inserimento dei nuovi assunti, recupero di conoscenza che oggi vive nella testa di poche persone. Metterli in una colonna a parte, dichiarati come non monetizzati, rende il business case più credibile e non meno.
La formula completa sta in due righe
Il calcolo che regge alla revisione di un direttore finanziario è meno elegante di quello che circola nelle presentazioni, e si scrive così.
Al denominatore il costo totale del primo anno: canone del fornitore, più costo di integrazione, più costo di preparazione dei dati, più costo del presidio annuo, più costo interno di adozione.
Al numeratore il beneficio realizzato, ovvero la quota di ore liberate che ha una destinazione dichiarata, valorizzata al costo pieno aziendale, più eventuali ricavi incrementali attribuibili, meno i costi evitati che si sarebbero comunque azzerati per altre ragioni.
Sul secondo anno il quadro cambia in modo sostanziale, perché integrazione e preparazione dati non si ripetono mentre il beneficio prosegue. Un progetto con ritorno negativo il primo anno e positivo dal secondo è un progetto normale, e presentarlo così protegge da revisioni difficili al primo trimestre. Presentarlo come positivo dal mese tre, invece, garantisce che qualcuno chieda conto dei numeri prima che il sistema sia entrato a regime.
Va aggiunta una voce che quasi nessuno mette e che i modelli a consumo rendono necessaria: il costo variabile di esercizio cresce con l’uso. Un pilota su venti persone e un rilascio su duemila hanno strutture di costo diverse, e il business case che estrapola linearmente dal pilota sottostima la bolletta di esercizio in modo sistematico.
Misurare prima di firmare, su una linea di base che esiste
Il vincolo più duro dell’intero esercizio arriva prima del progetto. Per dimostrare un miglioramento serve sapere quanto durava il processo, quanti errori produceva, quante volte richiedeva una rilavorazione. Nella maggior parte delle organizzazioni quel dato non esiste, e viene ricostruito a posteriori chiedendo alle persone una stima, che è il modo più rapido per rendere il risultato incontestabile e inutile.
Due settimane di misurazione prima dell’avvio cambiano completamente la solidità di quello che si potrà affermare dopo. Serve una linea di base su tre grandezze: tempo di attraversamento del processo, tasso di rilavorazione, volume gestito nel periodo. Se il processo non è misurabile su nessuna delle tre, il caso d’uso va scelto diversamente, perché qualunque risultato sarà un’opinione.
La misurazione va poi ripetuta con lo stesso strumento a tre e a sei mesi, e qui si presenta l’effetto che rovina più valutazioni: la curva di apprendimento. Le prime settimane sono sempre peggiori del previsto, perché le persone stanno imparando e il sistema sta ricevendo i casi limite. Chi misura a trenta giorni e conclude che non funziona sta osservando l’apprendimento, non la prestazione.
Chi ha portato progetti fino alla produzione lo riconosce: il ritorno di un progetto AI non si scopre, si costruisce, e passa quasi sempre per una decisione organizzativa che il business case rende esplicita mesi prima che qualcuno la debba prendere.
Partecipa alla community