Ar trebui oare ca baza de date “de raportare” să fie aceeaşi cu baza de date “de integrare”?

Am mai vorbit despre asta aici garbage in garbage out 

Dacă externalizăm serviciul de system integration (update in sistemele operaţionale) către alta baza de date (diferită de baza de date de raportare), nu cumva pierdem din putere?  Pentru mine, e clar că da. La fel de clar este că integrarea între sisteme ar trebui făcuta de oameni apropiaţi de cei care au lucrat la implementarea sistemelor operaţionale. Ar trebui să fie oameni din lumea operaţională, nu din lumea de raportare…

În nici un caz nu e ok să folosim mai multe baze de date de unde sa actualizăm datele din sistemele operaţionale.

Ce ai alege?  Ce ai alege ca bază de date pentru partea analitică?

Opţiunea 1: Old, a bit daft, safe and tested

Baze de date relaţionale, row-level, cu primary key, foreign key, check constraints…

…OK, hai să zicem că avem baza de date in the cloud…

Opţiunea 2: New, cool, very unsafe and in development, not tested

Baze de date columnare, cu primary key şi foreign key doar declarate dar nu “enforced”…

Eu aş alege opţiunea 1. Astfel, m-aş asigura că înteleg perfect modelul de data şi că datele sunt corecte. Apoi aş încerca opţiunea 2.

..să construim un depozit de date/data lake?

Asta se intreabă cineva care a investit 2 ani plus nişte bani în construirea unui DWH. Scopul principal era obţinerea unor rapoarte. Cred ca şi scopul trebuie să fie altul: să construiasca un loc cu date corecte (single place of truth) şi utilizatorii de business să ştie, cel puţin,  ce date au acolo.

Ce nu a mers bine? …totul a fost constuit de o companie externă. Prost. Şi acum oamenii de business au primit de-a gata nişte indicatori pe care îi pot analiza dupa diferite criterii…acestea se vor fapte şi dimensiuni….ha ha :))

Problema e că nu prea înţelege nimeni ce semnificaţie au acele fapte şi dimensiuni. În plus, sunt cam multe şi nu iţi vine nici să te uiti în fuga prin ele.

Aşa că întrebarea: e prea devreme pt noi să fim data-driven?

Nu, nu e devreme, şi vă rog nu fiţi data-driven pt ca aşa e la moda. Mai bine fiţi business-driven, implicaţi-vă de la început în procesul de modelare date şi apoi ia sa vedeti voi ce frumos vă analizaţi datele, ce întrebări vă puneţi şi, în final, puteţi crea poveşti despre date şi poate descoperiţi şi câte un faimos “insight”…

Sau poate e prea devreme….dacă chiar vreţi să vă construiţi rapoartele manual….

Toate companiile vor să obţină data insights. Scopul este ca din mulţimea de date interne provenite din sistemele operaţionale (de obicei ERP, CRM) şi date generate de acţiunile utilizatorilor şi/sau maşinilor (Google Analytics, Social Media, Internet of Things) să identificăm nişte patternuri, să extragem maximum de informaţie utilă.

Obţinerea de data insights este pentru cele mai multe companii un proces continuu, costisitor şi predispus la erori. Dar intr-adevar, dacă reuşim să identificăm de ce pleacă clienţii sau cum anume se comportă, putem salva businessul de la faliment, putem obţine profit mult mai mare sau putem câştiga avantaje competitive. Un alt beneficiu foarte important dar de obicei nemenţionat este că toate procesele de business ale companiei vor deveni mai eficiente.

Dar cât de valoroase sunt informaţiile obţinute şi cum cuantificăm asta? Putem să numărăm clienţii pe care i-am câştigat/reţinut numai datorită faptului că avem data insights? Putem să prevedem cu acurateţe ce clienţi sunt la risc să plece şi putem acţiona într-un anumit fel astfel incât ei să nu mai plece? Şi putem să spunem uite, datorită echipei de date ştiam că X va pleca în următoarea lună, noi i-am oferit alt pachet şi ura, clientul X a rămas clientul nostru? Dacă putem face asta, data insights este un succes. Dacă nu, mai încercam. Până când? Şi merită?

Investiţia cuprinde în general următoarele: tool pentru data ingestion sau hand written code, mediu distribuit de storcare date (Hadooop, Apache, Databricks) şi/sau baze de date row-level sau columnare, tool de ETL/ELT, tool de BI, constuirea unei echipe de date, TIMP.

Şi ce obţinem dupa ce am investit atât? Păi, depinde…

…dacă totul este construit corect, obţinem informaţiile valoroase de care avem nevoie şi eficientizăm procesele…asta după ceva timp…

…dacă ceva nu este construit cum trebuie, ajungem să repetam la nesfârşit procesul  (ia datele, produ raportul, modifică, reia)…

Mă întreb oare ce simt oamenii din departamentul contabilitate şi financiar când văd sume imense alocate pt proiecte care nu se ştie ce produc…Mă întreb când vor decide că ROI este prea jos…şi ce va urma…

În faimoasa dispută dintre Ralph Kimball şi Bill Inmon referitor la construirea unui DWH işi are locul şi întrebarea următoare: construim de sus în jos sau de jos în sus?

Dar ce e sus şi ce e jos?

După ce am citit cărţile ambilor autori, eu zic că sus sunt datele şi jos sunt cerinţele de business procesele de business.

Inmon zice să pornim de la un model de date (care este de fapt o diagramă ERD, 3rd normal form modelată după regulile lui Ted Codd ). Apoi să construim diferite data mart-uri pentru diferite departamente satisfăcând astfel cerinţele venite de la business. Dar oare cum facem să obţinem modelul de date? Oare nu cumva, mai întâi începem cu analiza proceselor de business? 😯

Kimball zice că trebuie să pornim cu identificarea proceselor de business; să construim o matrice (enterprise bus matrix) care identifică toate procesele de business şi toate dimensiunile unde aceastea se intersectează. Apoi să construim modelul de date (star schema, denormalized). Argumentul este că procesele de business se schimbă foarte rar şi nu semnificativ (spre deosebire de cerinţele de business pentru partea de raportare). De exemplu, cât de des se schimbă felul în care înregistrezi clienţi noi, sau felul în care facturezi? Practic, folosim procesele de business ca pe o ancoră.

Ambii autori sunt de accord că cerinţele de raportare se schimbă şi că oamenii de business, gandesc cam asa: dă-mi ce info ai şi apoi îţi spun ce vreau să obţin. Şi e ok să gândească aşa, un DWH (bine modelat) susţine exact acest mod de gândire.

Oricum am construi DWH-ul, cred că ar trebui să fim “business-driven” şi nu cum e la modă azi “data-driven”. Business driven înseamnă că modelarea datelor se face în funcţie de procesele de business si apoi putem lua nişte decizii pornind de la nişte informaţii (obţinute din datele produse de procesele de business).

Data-driven înseamna doar că luăm nişte decizii bazate pe date (pe date! corecte, gresite?). Tot data-driven înseamnă (după Inmon) să construim pe moştenirea istorică de cod şi date pornind de la modelul de date. Inmon însa nu spune nimic despre cum ajungem să avem un model de date.

Gata! Am hotarât, imi fac tricou cu BUSiness driven. Cu scris alb pe tricou negru. Problema e că business driven sună mai urât decât data driven…şi parcă nici nu sună aşa smart…dar nu-i nimic! compensăm prin ceva… atitudine!?

Lucrez pe partea de dezvoltare DWH de ceva vreme. Am schimbat mai multe echipe, unele mai organizate alte mai puţin organizate.

Ei bine, pe proiectul actual de DWH avem “garbage in” (date de calitate proastă din sistemul operaţional), avem “garbage out”(rapoarte eronate) şi mai avem ceva: flux ETL care citeşte din sistemul operaţional, aduce datele la noi in DWH, le transformă şi apoi actualizează înapoi datele în sistemul operaţional 😮 !

Daaaaaa….seamănă cu circuitul apei în natura. Singura problemă este că doar apa poate face asta fară “side effects”! Vorbind de efecte secundare, să vedem cam ce s-ar putea întampla:

• actualizăm din greşeală mai mult decat vrem, cu date greşite, etc.
• pt că nu ştim care sunt interdependenţele în sistemul operaţional, nu ştim unde anume în alta parte se propaga actualizarea noastră (poate de exemplu, exista nişte trigeri care actualizează şi alte tabele…)
• poate ca atunci cand noi actualizăm, cineva lucrează folosind o interfaţă(care trimite date in aceeaşi tabelă) şi apoi cand dă refresh, surpriză, apar nişte modificari pe care nu şi le poate explica…ta da :)))

Adăugam la ce e mai sus faptul că pe soluţia actuală nu putem spune în nici un fel că modificarea vine din DWH şi gata, am obtinut spaghete, nu DWH :))
Parcă scopul unui DWH era sa avem o sursa centralizată de date pe care sa ne putem baza in luarea deciziilor.
Acum, stau eu şi ma gandesc (asta dureaza ceva), poate oi fi eu mai fricoasă, hai sa fiu şi eu flexibila, să discut, să inteleg…măcar să definim nişte procese astfel încat lumea sa înteleaga ce se întampla, să fie documentat şi clar pt toţi.

Discut cu colegul meu care dupa ce m-a ascultat liniştit, a răspuns că nu ne-ar ajuta cu nimic nici macar să definim nişte procese pt că tot aşa am acţiona doar că va fi mai multa birocraţie…
Well, true… doar că procesele astea au şi ele un scop… greu de explicat, trebuie sa ma gandesc si deocamdata sunt blocata de uimire…doar asta pot spune:
Sunt motive importante pt care bucătăria este diferită de toaletă.
In general, ţine de igienă şi de tot ce s-ar putea întampla dacă am face totul într-un singur loc…

Nevoia de a face modificări înapoi în sistemele operaţionale clar există. Şi printre atributiile unui DWH este sa identifice erorile în datele provenite din sistemele sursă. Apoi, se setează un proces prin care datele din sistemele operaţionale sunt actualizate şi gata. Dar e greşit să le actualizăm direct din DWH! Asta e parerea mea.

De ce să nu le trimitem datele înapoi lor, celor care au grijă de sistemele operaţionale şi ei de acolo, să facă corecţiile necesare? Teoria DHW e de partea mea, datele curg tot timpul de la sursă către stage, target, data mart.

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?