In dorinţa de a fi agile, companiile se grăbesc să construiască rapoarte pe bandă rulantă. Şi exact asta obţin, nişte rapoarte care în cel mai bun caz au datele corecte. De obicei, diferite persoane din companie (product owners, management, sales leaders) compară valorile unor indicatori (KPI) pe diverse perioade de timp…apoi dacă au nevoie de mai multe detalii apleaza la echipa de dwh/business intelligence şi de acolo începe iar munca de la capat J). Altă problemă este cum sunt definiţi aceşti KPI si ce înseamnă pt că (incredibil!) diferă de la o persoana la alta. Adică practic, se compară mere cu pere şi se pierde extrem de mult timp pana cand ne dăm seama de diferenţe. Dar despre asta vom vorbi în curand.

Inapoi la rapoartele noastre. Rapoartele clasice sunt parte a ceea ce numim azi “Analiză descriptivă” adică intelegem ce s-a întamplat şi poate chiar şi de ce. Dar tendinţa este să ne îndreptam către analiza predictivă (modele de churn de exemplu) şi analiza prescriptivă (cam ce actiuni trebuie să luăm pt a reduce numarul de clienţi care pleacă). Mai multe detalii în engleză, aici

https://halobi.com/blog/descriptive-predictive-and-prescriptive-analytics-explained/

Nu se poate sa faci analiză predictivă corecta cand ai ca input nişte date pe care nu te poţi baza.
Oare nu ar fi mai bine sa pornim cu analiza proceselor de business? Cerinţele de raportare se schimbă, e normal, însa procesele de business nu suferă schimbari majore şi le putem folosi ca ancora. Adică ne constuim modelul de date pornind de la procesele de business dupa metodologia folosită de Kimball…ştiu, unii spun ca nu mai e in business şi nu se mai poarta…Eu cred că Kimball este înca utilizabil inclusiv pe bazele de date columnare.

Primul pas este sa ştim că ne bazam pe nişte date, să calculam cu toţii aceeaşi indicatori, să ştim că toţi vorbim aceeaşi limbă şi să întelegem care este fluxul de date. Să ii implicam pe ei, pe oamenii care trebuie sa ia decizii bazandu-se pe nişte date, în creare modelului de date. Sa organizăm workshopuri interactive şi să discutam despre  de unde vin datele, unde se duc, cum lucram cu ele, care sunt validarile pe care le facem în sistemele operaţionale, cine este responsabil pt ce, ce indicatori sunt importanţi pt compania noastra şi cum ii calculăm. E important sa ajungem la un consens. Uşor de zis, greu de facut :))

O data ce am stabilit aceste lucruri, construim fluxul de date aşa cum reteaua de apă (sau de canalizare dacă vreti) pt un oraş este construită doar o data şi apoi doar intretinută. Ideea e ca acest ETL sa functioneze, să nu presupuna mult effort pt a adauga din cand in cand cate o coloana.

Apoi, ne definim rapoartele si asta e. Daca oamenii de business işi cunosc datele, işi pot defini propriile rapoarte cu uşurinta.

Simplu, nu? Ei bine, sunt extrem de multe companii care nu au reuşit sa implementeze acest lucru simplu.

Pentru mine, toate situaţiile de mai sus sunt consecintă directă a lipsei un model de date corect definit.

Cred ca acum (avand Big Data, Spark,ML) este şi mai necesar sa construim un model de date pentru ca apoi sa furnizam cu uşurinta datele necesare ca input pt analiza predictivă.

Modelul de date nu este doar un view, aşa cum am avut neşansa să aud. Modelul de date reflecta toata complexitatea proceselor si regulilor de business. Şi da, în final pe baza modelului de date, putem construi un view ca bază pentru un raport.

Dar cine mai are nevoie de reguli şi modele daca putem construi, dărama şi reconstrui?