Il documento era impeccabile. E ragionava come dieci anni fa.

Qualche settimana fa ho letto un documento di analisi funzionale. Una società di consulenza proponeva a una PMI italiana di servizi tecnici un progetto di trasformazione digitale: centotrentacinque punti funzionali mappati, un Gantt dettagliato, le integrazioni stimate riga per riga, un piano di formazione per centocinquanta persone. Tecnicamente non c’era nulla da eccepire. Eppure, leggendolo, ho avuto una sensazione netta e fastidiosa: sembrava scritto dieci anni fa. Non per la piattaforma scelta, che è attuale e potente. Per la logica sotto: un grande progetto monolitico, i costi tutti davanti, i benefici tutti alla fine, e l’intelligenza artificiale appiccicata in coda come un accessorio. Il cambiamento è già avvenuto. Solo che in molti non l’hanno ancora messo dentro il modo di progettare.

Perché i grandi progetti falliscono

Il copione è sempre lo stesso, e per anni ha funzionato. Si parte da una grande analisi: si fotografano i processi, si mappano i requisiti, si disegna la soluzione completa. Poi un Gantt a mesi, una migrazione massiva, la formazione di tutti, e finalmente il go-live. I costi si concentrano all’inizio; i benefici, quando arrivano, si concentrano alla fine. Funzionava perché il contesto era abbastanza stabile da reggere un anno di cantiere senza cambiare troppo nel frattempo. Quella stabilità oggi non c’è più, e il conto si vede nei numeri. Gartner stima che entro il 2027 più del 70% delle iniziative ERP recenti non raggiungerà gli obiettivi di business previsti, con un quarto destinato a fallire in modo grave: è una proiezione, ma è in linea con la storia di questi progetti. Lo Standish Group lo dice da decenni con un’altra lente: i progetti piccoli riescono in circa il 90% dei casi, quelli grandi sotto il 10%. Più grande è il cantiere, più alta è la probabilità che salti. Non è un problema di piattaforma. È un problema di forma.

E se si partisse dall’altra parte?

Torno al documento. L’azienda — la descrivo senza nominarla — è una PMI di servizi tecnici: una manciata di milioni di fatturato, una trentina di persone e otto o nove sistemi che convivono senza parlarsi. Un ERP, un gestionale tecnico fatto in casa, un CRM minimale, parecchi Excel, un portale documentale, le app dei tecnici sul campo. I problemi quotidiani erano quelli classici: la stessa informazione inserita due volte, anagrafiche duplicate da un sistema all’altro, lo scadenziario dei contratti tenuto a mano su un foglio, nessuna visibilità in tempo reale per chi deve decidere. Avevano persino appena acquisito un’altra azienda, con altri dati da far entrare. Il documento di consulenza vedeva tutto questo, ma non lo trattava come il problema da risolvere per primo: non nominava mai la qualità dei dati, non stimava quanto sarebbe costato — in ore delle persone interne — formarsi e reggere il cambiamento, e metteva l’AI in fondo, come funzione di contorno. Leggendolo mi sono fatto una domanda semplice: e se invece di buttare tutto all’aria si partisse dall’altra parte?

Il punto non è sostituire la piattaforma con l’AI. È usare l’AI per preparare il terreno prima di scegliere qualsiasi piattaforma. Concretamente significa collegare ai sistemi esistenti dei connettori — chiamiamoli traduttori che permettono all’AI di leggere i dati dove sono, senza toccare nulla (lo standard che li rende possibili è recente e si chiama MCP) — e cominciare a lavorarci sopra. Sostituire gli Excel critici con viste sempre aggiornate. Far normalizzare e deduplicare le anagrafiche all’AI, invece che a mano. Mettere un alert automatico sui contratti in scadenza. Tutto questo si fa in settimane, non in mesi: i dati dicono che chi procede così, nel mid-market, passa dal pilota alla produzione in circa novanta giorni, contro i nove mesi o più dei progetti monolitici. E produce due risultati che valgono più del software. Il primo: i dati si puliscono, e dati puliti sono esattamente ciò che serve il giorno in cui si migra davvero — la pulizia diventa la migrazione, non un suo prerequisito rimandato. Il secondo: le persone cambiano modo di lavorare un pezzo alla volta, così quando arriva la piattaforma strutturata trovano un team che ha già fatto il salto mentale. La differenza non è negli strumenti. È nell’ordine in cui li si usa.

Le domande da fare prima della piattaforma

Non è una questione tecnica, è una questione di ordine mentale. Prima di scegliere la piattaforma, le domande giuste sono altre. I miei dati sono affidabili, o sto per migrare anni di duplicati e di errori dentro un sistema nuovo e più costoso? Le mie persone capiscono perché stiamo cambiando, non solo cosa cambierà? Ho messo a budget il costo vero del progetto, incluse le ore della mia gente sottratte al lavoro di tutti i giorni? Sono domande scomode perché spostano l’attenzione dal prodotto da comprare alle fondamenta su cui appoggiarlo. Ma se la risposta a una sola di queste è no, la qualità della piattaforma non conta: stai costruendo su terreno molle. E il costo dei dati sporchi non è un’astrazione — Gartner lo quantifica in quasi tredici milioni di dollari l’anno per l’organizzazione media. Si paga comunque. La differenza è se lo paghi prima, con metodo, o dopo, a migrazione fatta.

Così, la prossima volta che qualcuno ti mette davanti un piano di trasformazione digitale, prova a fare una domanda sola: quante settimane passano prima che io veda il primo risultato misurabile? Se la risposta è “al go-live”, e il go-live è tra dodici mesi, hai già la risposta che cercavi. Non stai guardando il futuro. Stai guardando la logica del decennio scorso, vestita con gli strumenti di oggi.