O directoare de IT de la o companie de logistică spune întâmplător la o cafea: „Avem patru proiecte BI încheiate. Trei sunt nefolosite, unul rulează doar pentru CFO”. Nu e o anomalie. E un pattern care se repetă în proiectele de business intelligence din întreaga piață mid-market.

Statisticile pe care le citează vendorii de software vorbesc de rate de eșec între 60% și 80%. Sună exagerat până când stai și încerci să găsești o companie mid-market care să nu aibă cel puțin un proiect BI „mort în portofoliu”. Apoi observi că definiția eșecului e neclară. Un proiect care a livrat dashboard-uri pe care nu le deschide nimeni — a eșuat? A consumat buget. A produs output. Dar nu a produs valoare.

Cele șapte cauze de mai jos nu sunt despre alegerea tehnologiei greșite. Sunt despre cele șapte feluri în care echipele bune cu buget bun și tooluri bune ajung tot la dashboard-uri pe care nu le folosește nimeni.

1. Lipsa unui sponsor executiv real

Proiectele BI care reușesc au, fără excepție, un sponsor executiv care e implicat săptămânal. Nu lunar. Nu „la steering committee”. Săptămânal.

Un proiect cu sponsor nominal — un VP care a aprobat bugetul și apare la milestone-uri — e mort în apă. Diferența o face cineva care să spună: „nu vreau încă un grafic, vreau să răspundă la întrebarea X. Asta e ce vreau să fac luni dimineață cu raportul. Construiți-l pentru asta”.

În practică, un sponsor real face trei lucruri concrete. Definește problema, nu cere soluții. Apără proiectul când vin presiuni să devieze în zona altora. Folosește output-ul personal, nu doar îl aprobă.

Lipsa lui se vede repede. Echipa de BI face „ce crede că vrea business-ul”. Stakeholderii cer „și putem să mai adăugăm și asta?”. După șase luni, dashboard-ul are 47 de vizualizări și niciun unghi clar. Toți l-au validat. Nimeni nu îl folosește. Sponsorul l-a aprobat la final pentru că era ok din punct de vedere politic.

2. Datele sunt în stare proastă și se ignoră asta

Aproape orice proiect BI care eșuează are aceeași poveste de început. „Avem datele”. Conducerea spune asta cu încredere. Echipa de proiect intră în detaliu și descoperă că „avem datele” înseamnă: există un ERP din 2014 cu schema modificată artizanal, există un CRM separat cu definiții diferite pentru aceiași clienți, există spreadsheet-uri SharePoint care țin loc de master data pe câteva entități critice, iar definițiile cheilor primare diferă între sisteme.

Echipa nu spune asta în primele săptămâni pentru că ar trezi panică. Continuă cu construcția, sperând că „o să rezolvăm pe parcurs”. Pe parcurs nu se rezolvă. Se acumulează workaround-uri.

Rezultatul final: un Power BI sau Tableau frumos care arată cifre. Numai că cifrele nu se aliniază între dashboard-uri. CFO-ul vede $14M vânzări pe Q1 în raportul A și $13.7M în raportul B. Cere explicații. Echipa BI răspunde: „depinde cum agregăm comenzile cu retururile”. Răspunsul nu satisface. Încrederea în întreg sistemul cade.

Antidotul nu e exotic. E un audit de calitate a datelor făcut în primele 4-6 săptămâni, cu raportare onestă spre sponsor. Costul perceput: 2 săptămâni de întârziere. Costul real al evitării: 6-9 luni de proiect pierdut.

3. KPI-urile nu sunt definite. Sunt presupuse

„Avem 12 KPI principali” — fraza apare frecvent în briefs. Echipa BI construiește pentru cei 12. La review, un manager spune: „dar ce înseamnă conversion rate aici? Eu îl calculez altfel”. Începe negocierea internă.

Există însă o capcană aici. Negocierea internă nu trebuie să se întâmple în proiectul de BI. Trebuie să se fi întâmplat înainte. Când nu s-a întâmplat, BI devine câmpul de bătălie unde se ciocnesc definițiile.

Un exemplu real: o companie de servicii financiare a încercat să construiască un dashboard de „customer lifetime value”. Trei departamente aveau definiții diferite pentru LTV. Marketing-ul îl voia bazat pe revenue brut. Finance-ul îl voia net, cu costuri alocate. Operations-ul îl voia pe orizont de 24 de luni, nu pe „toată durata”. Proiectul a durat 4 luni în loc de 6 săptămâni, dintre care 11 săptămâni au fost discuții politice între departamente.

Lecția pragmatică: o organizație care nu are un data dictionary cu definiții agreate ale celor 10-15 KPI-uri principale nu e pregătită pentru un proiect mare de BI. Construiește dictionary-ul mai întâi. Apoi construiește dashboard-urile.

4. Modelul de date e construit din grabă

În Power BI, în Tableau, în Looker — semantic model-ul e fundația. Un model prost construit produce răspunsuri inconsistente în orice instrument de vizualizare s-ar folosi deasupra.

Echipele sub presiunea livrării construiesc modele „cât să funcționeze pentru raportul curent”. Adaugă tabele când e nevoie de un raport nou. Relațiile devin un graf complicat. Calculation groups încep să se înmulțească. După 18 luni, modelul are 60 de tabele, 200 de măsuri, 8 perspective, și nimeni nu mai înțelege complet ce se întâmplă.

Asta nu e doar o problemă tehnică. E o problemă de încredere. Când nimeni nu mai poate verifica de ce un număr e ce e, dashboard-urile devin oracule. Le crezi sau nu le crezi. Echipele serioase nu cred oracule.

Modelarea curată cere disciplină: star schema acolo unde e posibil, dimensiuni reutilizabile, măsuri documentate, refactoring periodic. E muncă care nu are demo. Sponsorul nu o vede. Dar diferența între un proiect care rezistă 5 ani și unul care expiră în 18 luni se decide aici.

5. Designul pleacă de la „ce date avem”, nu „ce decizii susținem”

Cel mai frecvent eșec creativ. Echipa de BI primește un dump de coloane disponibile și încearcă să le pună pe un dashboard. Iese o pagină cu 14 vizualizări, fiecare arătând „ceva interesant”.

Întrebarea care nu se pune: ce decizie va lua cineva privind acest raport? Dacă răspunsul e „depinde, e mai mult informativ”, proiectul e deja în zona „nice to have”, nu „critical”. Și ce e nice to have moare la primul cost-cutting.

Designul corect pornește invers. Cine deschide raportul, când, pentru ce decizie? Care e acțiunea ulterioară? Care sunt cele 2-3 metrici care contează pentru acea decizie? Restul vizualizărilor devin distragere.

În practică, dashboard-urile încărcate cu 12 KPI sunt aproape întotdeauna semnul că nimeni nu a hotărât ce contează. Și dashboard-urile pe care nimeni nu a hotărât ce contează sunt cele care nu se deschid săptămânal.

6. Self-service e promis fără infrastructură

„Vrem self-service BI”. Frază aproape obligatorie în orice proiect modern. Înseamnă, în teorie, că utilizatorii de business își construiesc propriile rapoarte fără să ceară echipei tehnice.

În practică, înseamnă haos dacă nu există infrastructură care să o susțină.

Self-service real cere: un semantic model curat, măsuri standardizate, template-uri de raport, training pentru utilizatori, governance pe ce se publică și ce nu, monitoring pe ce rapoarte sunt folosite și de cine.

Fără aceste elemente, „self-service” devine: 200 de rapoarte duplicate, fiecare cu propria definiție a metricilor, niciunul auditat, multe împărtășite pe Teams sau email fără context. CFO-ul deschide trei rapoarte despre același KPI, vede trei numere diferite, întreabă care e corect. Răspunsul nu există. Încrederea moare a doua oară.

Companii care reușesc self-service investesc în primii 3-6 ani aproximativ jumătate din bugetul de BI în governance și infrastructure. Restul în vizualizări. Companii care eșuează inversează raportul, văd vizualizările frumoase, ratează fundația. Diferența nu e vizibilă în primul an. Devine devastatoare în al treilea.

7. Adoption-ul nu e planificat ca proiect separat

Un dashboard care nu e folosit nu e dashboard. E artă digitală. Și totuși, fazele de adoption sunt cele mai subbugetate în orice plan de BI.

Echipele tehnice cred că „odată ce livrăm, business-ul va folosi”. Logic, ar trebui. În realitate, oamenii sunt creaturi ale obișnuinței. Un manager care a folosit timp de 6 ani un raport Excel trimis săptămânal de un analyst nu va trece spontan la un dashboard Power BI doar pentru că există. Va deschide noul dashboard de două ori, va găsi că nu e exact ca raportul vechi, va reveni la email.

Adoption-ul cere efort dedicat: traininguri specifice pe roluri, sesiuni 1:1 cu power users, întâlniri de feedback la 30, 60, 90 de zile după lansare, ajustări iterative bazate pe utilizare reală.

În practică, asta înseamnă bugetare separată: o persoană sau echipă responsabilă cu adoption-ul, nu doar cu livrarea tehnică. Companii care lansează BI fără un „BI evangelist” sau „analytics enablement lead” se uită după 12 luni la rate de utilizare sub 30%.

Tabel rapid: cauză și antidot

Pattern-uri pe care le observi când un proiect se îndreaptă spre eșec

Câteva semnale timpurii care merită observate, înainte ca eșecul să devină evident:

Sponsorul anulează două meeting-uri consecutive. Echipa BI nu reacționează. Asta se transformă în șase luni de drift fără direcție clară.

La review-uri, stakeholderii cer „dacă tot facem asta, adăugați și X”. Lista cu „și X” crește la 30 de elemente. Scope-ul devine vag.

Echipa tehnică începe să spună „depinde cum agregăm”. E codul jargonului pentru „nu avem definiții agreate, dar trebuie să livrăm ceva”.

Apare un al doilea proiect BI în paralel, condus de alt departament. Cele două nu vor vorbi între ele. Resursele și energia se fragmentează.

Sponsorul se schimbă (promovare, plecare, reorganizare). Noul sponsor nu e onboarded corect. Proiectul devine orfan.

Costul ascuns al fiecăruia dintre aceste pattern-uri e de obicei vizibil abia la 6-9 luni distanță. Dar oricine a făcut 4-5 proiecte de BI le recunoaște la 6 săptămâni.

Tema se leagă natural de discuția despre strategie BI, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. Pentru actualizări și detalii suplimentare, Power BI Blog rămâne sursa principală pe acest subiect. În fond, proiectele BI nu sunt doar un concept tehnic — sunt o decizie de business cu impact direct pe productivitatea echipei.

Ce caracterizează proiectele care reușesc

Mai puține lucruri decât crezi. Câteva semne comune ale celor 20-30% care livrează valoare reală:

Au scope mic la început. Un dashboard, o decizie, un audience. Cresc după ce primul livrabil e folosit săptămânal, nu înainte.

Au sponsor care folosește output-ul personal. Nu pentru raport către board. Pentru deciziile lui zilnice.

Au un analyst sau analytics engineer care e responsabil singur de calitatea semantic model-ului. Nu un comitet. O persoană cu putere de decizie.

Iterează lunar, nu trimestrial. Feedback rapid, ajustări rapide.

Investesc în training mai mult decât în dezvoltare în primele 6 luni post-lansare.

Niciunul dintre aceste lucruri nu e revoluționar. Sunt practici banale, repetate. Diferența între succes și eșec în BI nu vine din alegerea Power BI vs Tableau. Vine din rigoarea cu care echipa și organizația tratează aceste banalități. Companiile care nu le tratează cu rigoare ajung la rate de eșec de 70-80%. Cele care le tratează ajung la 30-40%. Asta e tot „secretul” pe care îl vând consultanții. Doar că, scris așa, sună mai puțin impresionant decât „transformare digitală”.

Întrebări frecvente

Care e prima cauză de eșec a unui proiect BI?

Lipsa unui sponsor executiv real. Proiectele care reușesc au, fără excepție, un sponsor implicat săptămânal. Unul nominal — un VP care a aprobat bugetul și apare la milestone-uri — înseamnă proiect mort în apă.

De ce eșuează proiectele din cauza datelor?

Pentru că starea proastă a datelor se ignoră la început. Echipa nu o spune în primele săptămâni, ca să nu trezească panică, iar rezultatul final e un Power BI sau Tableau frumos care arată cifre în care nu are nimeni încredere.

Ce înseamnă că „avem 12 KPI principali”?

De obicei că KPI-urile sunt presupuse, nu definite. Lecția pragmatică din articol: o organizație care nu are un data dictionary cu definiții agreate pentru cele 10-15 KPI-uri principale nu e pregătită pentru un proiect mare de BI.