4 milioni di euro, due multinazionali, zero software: storia vera di un fallimento annunciato

La storia che sto per raccontare è vera. I nomi non li faccio — non per diplomazia, ma perché i nomi non servono. Quello che serve è capire il meccanismo. Perché questo meccanismo si ripete, identico, in decine di aziende italiane. E costa milioni.

🏢 Il cliente: un gruppo assicurativo con un’ambizione legittima #

Un’azienda solida del settore assicurativo. Operazioni in Italia, Francia, paesi del Nord Europa, Spagna. Migliaia di dipendenti, milioni di polizze gestite, un business che cresce.

Ad un certo punto, la direzione prende una decisione ragionevole: ci serve un software gestionale su misura. Un sistema che rispecchi i nostri processi, le nostre regole di business, le specificità normative di ogni paese in cui operiamo.

Decisione legittima. Sensata. Strategica, perfino.

Il problema non è la decisione.
Il problema è a chi la affidano.

💰 Primo atto: la grande multinazionale (2013-2018) #

Viene ingaggiata — in pieno outsourcing — una delle Big della consulenza IT mondiale. Nome che tutti conoscono. Migliaia di consulenti, sedi in ogni continente, presentazioni in PowerPoint che farebbero piangere di commozione.

Il progetto parte. Si definiscono i requisiti. Si stima il budget. Si firmano i contratti.

Passano i mesi. Poi gli anni.

I deliverable arrivano — sulla carta. Ma il software non funziona come dovrebbe. Le specifiche cambiano. I costi lievitano. I consulenti ruotano: quello che aveva capito il dominio se ne va, arriva un altro che ricomincia da zero. Il classico schema della consulenza a corpo che diventa, nei fatti, una consulenza a tempo indeterminato.

Dal 2013 al 2018: oltre 2,5 milioni di euro spesi.
Risultato: un software incompleto, instabile, che nessuno internamente sapeva manutenere.

Perché il codice l’avevano scritto loro. Con le loro convenzioni. Con la loro architettura. E quando se ne sono andati, si sono portati via anche la conoscenza.

🔄 Secondo atto: cambiamo fornitore (2018-2022) #

Il management, scottato ma non rassegnato, decide di cambiare. “Il problema era il fornitore”, pensano. “Prendiamone uno migliore.”

Entra in scena un’altra multinazionale. Altrettanto famosa. Altrettanto grande. Altrettanto costosa.

Nuovo kickoff. Nuova analisi dei requisiti — perché ovviamente non possono ripartire dal lavoro del fornitore precedente. Nuove slide. Nuove promesse.

E la storia si ripete.

Stessi problemi, attori diversi. Turnover dei consulenti. Perdita di know-how. Tempi che si allungano. Budget che esplodono. Riunioni infinite in cui si discute di milestone che non arrivano mai.

Dal 2018 al 2022: altri 1,5 milioni di euro.
Risultato: un altro software che non soddisfa le esigenze aziendali.

Totale investito in quasi dieci anni: oltre 4 milioni di euro.
Software funzionante: zero.

📊 Facciamo i conti del disastro #

Quattro milioni di euro. Quasi dieci anni di progetto. Due dei nomi più prestigiosi della consulenza IT globale.

E alla fine, l’azienda si ritrova esattamente al punto di partenza.

Non è sfortuna. È un pattern.
E chi lavora in questo settore da trent’anni, come me, lo riconosce a prima vista.

🧠 Perché succede: l’anatomia del fallimento #

Questo tipo di fallimento non è un incidente. È il risultato prevedibile di un modello di business che ha un difetto strutturale.

1. L’incentivo è sbagliato.
Una grande società di consulenza guadagna vendendo giornate-uomo. Più il progetto dura, più fattura. Non c’è alcun incentivo reale a chiudere il progetto in fretta e bene. C’è un incentivo a tenerlo in vita il più a lungo possibile.

2. Il turnover è endemico.
Le multinazionali della consulenza hanno tassi di turnover del 15-25% annuo. In un progetto che dura cinque anni, il team si rinnova completamente almeno due volte. Ogni volta si ricomincia: nuova curva di apprendimento, nuova interpretazione dei requisiti, nuovi errori.

3. Il know-how esce dalla porta (vendor lock-in ).
Quando il fornitore finisce (o viene cacciato), la conoscenza del sistema se ne va con lui. Il cliente resta con un software che non capisce, non sa manutenere e non può evolvere.

4. Le specifiche diventano un’arma (scope creep ).
In un progetto custom di questa portata, le specifiche sono sempre incomplete — perché il business è complesso e in evoluzione. Questo diventa l’alibi perfetto: “il software non funziona perché le specifiche sono cambiate”. Ed è sempre colpa di qualcun altro.

✅ La svolta: comprare, non costruire #

Alla fine, dopo quasi un decennio e oltre 4 milioni bruciati, l’azienda prende la decisione che avrebbe dovuto prendere all’inizio:

Acquistare un software di mercato già funzionante e adattarlo internamente alle proprie esigenze.

Un prodotto assicurativo commerciale, collaudato, con una base di codice stabile e una community di supporto. E un team interno — persone che conoscono il business, che restano in azienda, che accumulano conoscenza invece di disperderla — incaricato di personalizzarlo ed evolverlo.

Costo? Una frazione di quello speso nei dieci anni precedenti.
Risultato? Un sistema che funziona. Che evolve. Che l’azienda possiede davvero.

La lezione è brutale nella sua semplicità:

Non tutto va costruito da zero. E soprattutto, non tutto va delegato a chi non ha interesse a finire.

🏗️ Il paragone che fa male: il nostro Data Warehouse #

E qui entra la parte della storia che conosco da dentro. Perché per la stessa azienda, nello stesso periodo, io e un collega abbiamo costruito qualcosa che funziona. Ogni singolo giorno.

Un **Data Warehouse** completo. Progettato, sviluppato, messo in produzione e mantenuto in due persone.

Non una demo. Non un prototipo. Un sistema di produzione che:

• Carica dati ogni giorno — l’intero ciclo ETL gira in un’ora e mezza
• Integra 4 sistemi sorgenti diversi — ognuno con il suo formato, il suo protocollo, le sue particolarità
• Raccoglie dati da 4 aree geografiche: Italia, Francia, paesi del Nord Europa, Spagna
• Comprende circa 60.000 righe di codice scritte a quattro mani
• L’architettura è stata disegnata da me — dal modello dati alla strategia di caricamento, dalla gestione degli errori alla storicizzazione

Due persone. Tre anni. Un sistema che ogni mattina si sveglia, raccoglie dati da quattro angoli d’Europa, li trasforma, li carica e li rende disponibili per le decisioni aziendali. In un’ora e mezza.

Sessantamila righe di codice. Ognuna pensata, testata, mantenuta da chi l’ha scritta.

Nessun PowerPoint. Nessun kickoff. Nessun consulente che se ne va portandosi via la conoscenza.
Solo competenza, architettura solida e lavoro fatto bene.

🎯 La lezione #

Quando parlo con aziende che stanno per intraprendere un grande progetto IT, gli dico sempre la stessa cosa:

Non pagate un brand. Pagate le persone.

Un team piccolo di professionisti che conoscono il dominio, che restano sul progetto, che sono responsabili del risultato — vale più di cento consulenti a rotazione che fatturano giornate.

Il software non si costruisce con le slide. Si costruisce con le mani nel codice, con l’architettura nella testa e con la responsabilità addosso.

Quattro milioni di euro in fumo insegnano una cosa sola:

Il costo più alto non è quello del fornitore che sbagli.
È quello del tempo che perdi prima di capire che la soluzione era più semplice di quello che ti avevano venduto.

💬 A chi sta per firmare quel contratto #

Se la tua azienda sta per affidare un progetto critico a una grande società di consulenza, fermati un momento.

Chiediti:

• Chi scriverà il codice? Resterà in azienda tra due anni?
• Se il fornitore se ne va domani, sapremmo manutenere il sistema?
• Esiste un prodotto di mercato che copre l'80% delle nostre esigenze?
• Possiamo costruire un team interno piccolo, competente e stabile?

Le risposte a queste domande valgono più di qualsiasi proposta commerciale.
Perché la differenza tra un progetto che funziona e uno che brucia milioni non sta nella tecnologia.

Sta nelle persone. Nella continuità. Nella responsabilità.

E nella capacità di dire “no” a chi ti vende la complessità quando la soluzione è semplice.

Glossario #

Data Warehouse — Sistema centralizzato di raccolta e storicizzazione dati da fonti diverse, progettato per l’analisi e il supporto alle decisioni aziendali. Nel caso descritto, costruito in due persone con 60.000 righe di codice.

ETL — Extract, Transform, Load: processo di estrazione dati dai sistemi sorgente, trasformazione e caricamento nel data warehouse. Il ciclo ETL del DWH descritto gira in un’ora e mezza.

Vendor Lock-in — Dipendenza strutturale da un fornitore esterno che rende difficile cambiare provider. Si instaura quando il know-how e il codice restano nelle mani del fornitore.

Scope Creep — Espansione incontrollata dei requisiti di progetto oltre il perimetro iniziale. Le specifiche incomplete diventano l’alibi per ritardi e costi aggiuntivi.

Outsourcing — Esternalizzazione di attività IT a fornitori esterni. Rischioso per progetti strategici a lungo termine, dove il turnover dei consulenti e la perdita di know-how possono bruciare milioni.