4 milioane de euro, două multinaționale, zero software: povestea reală a unui eșec anunțat

Povestea pe care urmează să o spun este reală. Nu voi da nume — nu din diplomație, ci pentru că numele nu contează. Ceea ce contează este să înțelegem mecanismul. Pentru că acest mecanism se repetă, identic, în zeci de companii. Și costă milioane.

🏢 Clientul: un grup de asigurări cu o ambiție legitimă #

O companie solidă din sectorul asigurărilor. Operațiuni în Italia, Franța, țări din Europa de Nord, Spania. Mii de angajați, milioane de polițe gestionate, o afacere în creștere.

La un moment dat, conducerea ia o decizie rezonabilă: avem nevoie de un software de gestiune personalizat. Un sistem care să reflecte procesele noastre, regulile noastre de business, specificul normativ al fiecărei țări în care operăm.

Decizie legitimă. Sensibilă. Chiar strategică.

Problema nu este decizia.
Problema este cui i-o încredințează.

💰 Actul întâi: marea multinațională (2013–2018) #

Este angajată — în plin outsourcing — una dintre marile nume ale consultanței IT mondiale. Un nume pe care toată lumea îl cunoaște. Mii de consultanți, birouri pe fiecare continent, prezentări PowerPoint care te-ar face să plângi de emoție.

Proiectul pornește. Se definesc cerințele. Se estimează bugetul. Se semnează contractele.

Trec lunile. Apoi anii.

Livrabilele sosesc — pe hârtie. Dar software-ul nu funcționează cum ar trebui. Specificațiile se schimbă. Costurile explodează. Consultanții se rotesc: cel care înțelesese domeniul pleacă, vine altul care o ia de la zero. Schema clasică a consultanței la pachet care devine, în practică, o consultanță pe termen nedeterminat.

Din 2013 până în 2018: peste 2,5 milioane de euro cheltuiți.
Rezultatul: un software incomplet, instabil, pe care nimeni din interior nu știa să-l întrețină.

Pentru că codul îl scriseseră ei. Cu convențiile lor. Cu arhitectura lor. Și când au plecat, au luat cu ei și cunoștințele.

🔄 Actul al doilea: schimbăm furnizorul (2018–2022) #

Managementul, ars dar neresemnat, decide să schimbe. “Problema a fost furnizorul”, gândesc ei. “Să luăm unul mai bun.”

Intră în scenă o altă multinațională. La fel de faimoasă. La fel de mare. La fel de scumpă.

Nou kickoff. Nouă analiză a cerințelor — pentru că, evident, nu pot porni de la munca furnizorului anterior. Slide-uri noi. Promisiuni noi.

Și istoria se repetă.

Aceleași probleme, actori diferiți. Rotația consultanților. Pierderea know-how-ului. Termene care se lungesc. Bugete care explodează. Ședințe interminabile în care se discută milestone-uri care nu mai sosesc.

Din 2018 până în 2022: încă 1,5 milioane de euro.
Rezultatul: un alt software care nu satisface nevoile afacerii.

Total investit în aproape un deceniu: peste 4 milioane de euro.
Software funcțional: zero.

📊 Să facem bilanțul dezastrului #

Patru milioane de euro. Aproape zece ani de proiect. Două dintre cele mai prestigioase nume ale consultanței IT globale.

Și la final, compania se regăsește exact la punctul de plecare.

Nu e ghinion. E un pattern.
Iar cine lucrează în acest sector de treizeci de ani, ca mine, îl recunoaște din prima.

🧠 De ce se întâmplă: anatomia eșecului #

Acest tip de eșec nu este un accident. Este rezultatul previzibil al unui model de business cu un defect structural.

1. Incentivul este greșit.
O mare firmă de consultanță câștigă bani vânzând zile-om. Cu cât proiectul durează mai mult, cu atât facturează mai mult. Nu există niciun stimulent real pentru a încheia proiectul rapid și bine. Există un stimulent pentru a-l menține în viață cât mai mult posibil.

2. Rotația este endemică.
Multinaționalele de consultanță au rate de rotație de 15-25% pe an. Într-un proiect care durează cinci ani, echipa se reînnoiește complet de cel puțin două ori. De fiecare dată se o ia de la capăt: nouă curbă de învățare, nouă interpretare a cerințelor, noi greșeli.

3. Know-how-ul iese pe ușă (vendor lock-in ).
Când furnizorul termină (sau este concediat), cunoașterea sistemului pleacă odată cu el. Clientul rămâne cu un software pe care nu-l înțelege, nu știe să-l întrețină și nu-l poate evolua.

4. Specificațiile devin o armă (scope creep ).
Într-un proiect custom de această amploare, specificațiile sunt întotdeauna incomplete — pentru că afacerea este complexă și în evoluție. Aceasta devine alibiul perfect: “software-ul nu funcționează pentru că specificațiile s-au schimbat”. Și e mereu vina altcuiva.

✅ Punctul de cotitură: cumpără, nu construi #

La final, după aproape un deceniu și peste 4 milioane arse, compania ia decizia pe care ar fi trebuit să o ia de la început:

Să cumpere un software de piață deja funcțional și să-l adapteze intern la propriile nevoi.

Un produs asigurător comercial, testat, cu o bază de cod stabilă și o comunitate de suport. Și o echipă internă — oameni care cunosc afacerea, care rămân în companie, care acumulează cunoștințe în loc să le disperseze — însărcinată să-l personalizeze și să-l evolueze.

Costul? O fracțiune din ce s-a cheltuit în cei zece ani anteriori.
Rezultatul? Un sistem care funcționează. Care evoluează. Pe care compania îl deține cu adevărat.

Lecția este brutală în simplitatea ei:

Nu totul trebuie construit de la zero. Și mai ales, nu totul trebuie delegat celor care nu au interes să termine.

🏗️ Comparația care doare: Data Warehouse-ul nostru #

Și aici intră partea poveștii pe care o cunosc din interior. Pentru că pentru aceeași companie, în aceeași perioadă, eu și un coleg am construit ceva ce funcționează. În fiecare zi.

Un **Data Warehouse** complet. Proiectat, dezvoltat, pus în producție și întreținut de două persoane.

Nu o demo. Nu un prototip. Un sistem de producție care:

• Încarcă date în fiecare zi — întregul ciclu ETL rulează în o oră și jumătate
• Integrează 4 sisteme sursă diferite — fiecare cu formatul său, protocolul său, particularitățile sale
• Colectează date din 4 zone geografice: Italia, Franța, țări din Europa de Nord, Spania
• Cuprinde aproximativ 60.000 de linii de cod scrise în patru mâini
• Arhitectura a fost proiectată de mine — de la modelul de date la strategia de încărcare, de la gestionarea erorilor la istoricizare

Două persoane. Trei ani. Un sistem care în fiecare dimineață se trezește, colectează date din patru colțuri ale Europei, le transformă, le încarcă și le pune la dispoziție pentru deciziile de afaceri. Într-o oră și jumătate.

Șaizeci de mii de linii de cod. Fiecare gândită, testată, întreținută de cine a scris-o.

Niciun PowerPoint. Niciun kickoff. Niciun consultant care pleacă luând cunoștințele cu el.
Doar competență, arhitectură solidă și muncă făcută bine.

🎯 Lecția #

Când vorbesc cu companii care sunt pe punctul de a începe un mare proiect IT, le spun întotdeauna același lucru:

Nu plătiți pentru un brand. Plătiți pentru oameni.

O echipă mică de profesioniști care cunosc domeniul, care rămân pe proiect, care sunt responsabili pentru rezultat — valorează mai mult decât o sută de consultanți în rotație care facturează zile.

Software-ul nu se construiește cu slide-uri. Se construiește cu mâinile în cod, cu arhitectura în minte și cu responsabilitatea pe umeri.

Patru milioane de euro în fum învață un singur lucru:

Cel mai mare cost nu este cel al furnizorului greșit pe care îl alegi.
Este cel al timpului pe care îl pierzi înainte de a înțelege că soluția era mai simplă decât ce ți se vânduse.

💬 Către cei care sunt pe punctul de a semna acel contract #

Dacă compania ta este pe punctul de a încredința un proiect critic unei mari firme de consultanță, oprește-te un moment.

Întreabă-te:

• Cine va scrie codul? Va mai fi în companie peste doi ani?
• Dacă furnizorul pleacă mâine, am putea întreține sistemul?
• Există un produs de piață care acoperă 80% din nevoile noastre?
• Putem construi o echipă internă mică, competentă și stabilă?

Răspunsurile la aceste întrebări valorează mai mult decât orice propunere comercială.
Pentru că diferența dintre un proiect care funcționează și unul care arde milioane nu ține de tehnologie.

Ține de oameni. De continuitate. De responsabilitate.

Și de capacitatea de a spune “nu” celor care îți vând complexitate când soluția este simplă.

Glosar #

Data Warehouse — Sistem centralizat de colectare și istoricizare a datelor din surse diverse, proiectat pentru analiză și suport al deciziilor de afaceri. În cazul descris, construit de două persoane cu 60.000 de linii de cod.

ETL — Extract, Transform, Load: procesul de extragere a datelor din sistemele sursă, transformare și încărcare în data warehouse. Ciclul ETL al DWH-ului descris rulează într-o oră și jumătate.

Vendor Lock-in — Dependență structurală de un furnizor extern care face schimbarea providerului dificilă. Se instaurează când know-how-ul și codul rămân în mâinile furnizorului.

Scope Creep — Expansiune necontrolată a cerințelor proiectului dincolo de perimetrul inițial. Specificațiile incomplete devin alibiul pentru întârzieri și costuri suplimentare.

Outsourcing — Externalizarea activităților IT către furnizori externi. Riscant pentru proiecte strategice pe termen lung, unde rotația consultanților și pierderea know-how-ului pot arde milioane.