Nu am pornit la drum cu ideea că trebuie să învăț Power BI. De fapt, nici nu cred că, la început, mă interesa foarte mult Power BI în sine. Aveam niște date și, mai important, aveam curiozitatea de a vedea ce pot face cu ele.
În timp, ajunsesem să strâng informații din tot felul de locuri. Unele erau în Excel, unele veneau din aplicații sau din exporturi, altele erau introduse și controlate manual. Pentru cineva care privește lucrurile din exterior, toate acestea pot părea pur și simplu niște tabele. Pentru mine însă începeau să devină din ce în ce mai interesante, pentru că nu mai voiam doar să le păstrez. Voiam să pot să le întreb lucruri.
Excel-ul fusese, mult timp, suficient. Și nici astăzi nu cred că problema este că Excel nu poate face lucruri foarte complexe. Poate. Doar că, la un moment dat, întrebările pe care începi să le pui datelor se schimbă, iar atunci începi să simți că ai nevoie de altceva.
Așa am ajuns să mă uit la Power BI. Nu pentru că aveam nevoie de un dashboard spectaculos și nici pentru că voiam să intru în lumea „business intelligence”. Termenul în sine nu era ceea ce mă atrăgea. Mă interesa mai degrabă posibilitatea de a lua niște date pe care le aveam deja și de a vedea ce se poate întâmpla cu ele dacă încep să le organizez altfel.
Primele încercări au fost exact ceea ce ar trebui să fie o primă încercare: experimente. Am importat date, am schimbat lucruri, am încercat vizualizări, am construit relații și, evident, am făcut și lucruri care ulterior s-au dovedit că nu erau tocmai bine gândite. Uneori rezultatul era ceea ce mă așteptam să obțin. Alteori nu. Iar când ceva nu ieșea, prima reacție era, probabil, să încerc să repar ceea ce vedeam pe ecran.
Numai că, treptat, am început să înțeleg că problema nu era întotdeauna ceea ce vedeam pe ecran. Uneori problema era chiar în date 🙂
Un tabel poate arăta foarte bine pentru un om și totuși să nu fie o structură bună pentru analiză. O denumire care pare suficient de clară poate ascunde mai multe lucruri. Două tabele pot părea că vorbesc despre același subiect, dar să nu se poată lega corect. O categorie poate părea evidentă până când trebuie să o folosești în mod consecvent în sute sau mii de înregistrări.
Și, fără să-mi dau seama exact când s-a întâmplat, am început să mă uit la date cu ceva mai multă atenție. Nu mai era suficient să am un tabel și să obțin un grafic. Trebuia să înțeleg ce reprezintă fiecare lucru din acel tabel și de ce ar trebui să se lege de celelalte.
Primele proiecte au avut un rol important tocmai pentru că nu semănau foarte mult între ele. Am trecut de la date personale la Potaissa și apoi la proiecte de ”Asociație”, unde informațiile aveau o altă logică. Au apărut clasificări, proiecte, venituri și cheltuieli și, odată cu ele, întrebări pe care nu mi le pusesem atunci când lucram pur și simplu în Excel.
A fost interesant să descopăr că nu toate lucrurile trebuie neapărat automatizate. Uneori o clasificare poate fi dedusă din date, alteori omul care cunoaște contextul trebuie să spună ce înseamnă acea înregistrare. În unele situații automatizarea este evident utilă, în altele controlul manual rămâne cea mai sigură soluție.
Apoi au venit datele din StatsHunters și experiența a devenit puțin diferită. Nu mai porneam de la date pe care le controlam integral. Ele veneau dintr-o sursă externă și trebuia să înțeleg ce primesc, ce trebuie transformat și ce pot considera suficient de sigur pentru model. A apărut astfel o distincție care avea să devină din ce în ce mai importantă: sursa datelor și modelul în care ajung datele nu sunt același lucru.
Pentru activitățile outdoor, lucrurile au devenit și mai interesante. Aveam distanțe, durate, altitudini, tipuri de activitate, dispozitive, date calendaristice și locații. Dintr-odată, aceeași activitate putea fi privită din mai multe direcții. Nu mai era doar o înregistrare într-un tabel, ci ceva care se putea lega de timp, de spațiu, de echipament și de alte activități.
Cred că aici începe să se vadă cel mai bine cum experimentul cu Power BI a început să se transforme în experiență. AlpinHub a apărut tocmai din această nevoie. Nu mai voiam doar să construiesc încă un raport care funcționează. Începusem să mă întreb dacă experiența acumulată într-un proiect putea fi transformată într-o structură pe care să o pot folosi și în următorul.
Așa am ajuns la ideea unei structuri standard pentru activități, la SSA și la separarea dintre sursa datelor și modelul în care acestea sunt analizate. Nu a fost o idee pe care am avut-o de la început și pe care apoi am executat-o metodic. A fost mai degrabă rezultatul mai multor încercări și al unor probleme pe care le întâlnisem deja.
Și cred că aceasta a fost una dintre schimbările importante de perspectivă. Până atunci mă gândeam mai ales la raportul pe care voiam să-l obțin. Cu AlpinHub am început să mă gândesc mai mult la modelul care trebuie să existe înaintea raportului.
De aici, lucrurile au început să se extindă în direcții la care nu mă gândisem inițial. AutoMonitor și Trip au adus alte tipuri de informații. Valea Arieșului a introdus o componentă geografică și o altă logică de organizare. iNaturalist a adus observații din natură, clasificări, timp și locație. Mai târziu, AlpinHub Catalog a dus aceeași idee către date despre conținut și URL-uri, iar DM Valea Arieșului a arătat că principiile pe care le testasem în proiecte personale pot fi folosite și într-un context complet diferit.
Privind toate aceste proiecte împreună, este interesant că datele sunt foarte diferite, dar problemele fundamentale încep să semene. De unde vin datele? Ce reprezintă? Cum le structurez? Cum le leg între ele? Ce pot automatiza? Ce trebuie verificat? Și, poate cel mai important, ce anume vreau să pot afla din ele mai târziu?
La un moment dat am realizat că nu mai învățam doar Power BI. Power BI rămăsese instrumentul cu care făceam experimente, dar întrebările deveniseră mai largi. Începusem să mă intereseze mai mult datele decât aplicația. Dacă un rezultat nu era corect, nu mai căutam imediat problema într-un grafic. Mă uitam la sursă, la structură, la relații și la modul în care construisem modelul.
Nu pot spune că a existat un moment precis în care am „învățat Power BI”. A fost mai degrabă o succesiune de proiecte, încercări, greșeli, refaceri și mici descoperiri care s-au legat una de alta. Unele soluții au rămas, altele au fost abandonate. Unele idei s-au dovedit utile într-un proiect și nepotrivite în altul. Tocmai această diferență m-a ajutat să înțeleg că nu există neapărat un singur model bun pentru orice situație.
Astăzi, când mă uit înapoi, cred că cea mai importantă schimbare nu este faptul că am învățat să folosesc mai bine Power BI. Este faptul că am început să privesc altfel informația pe care o am în față. La început voiam să văd ce pot face cu niște date. După câteva proiecte, am început să vreau să înțeleg datele. Iar apoi am început să construiesc modele pentru ele.
Poate că acesta este motivul pentru care Power BI a ajuns să aibă un loc atât de important în AlpinHub. Nu pentru că ar fi fost scopul proiectului, ci pentru că a fost instrumentul prin care am putut vedea, experimentând, cum se schimbă felul în care privești datele atunci când începi să le organizezi, să le relaționezi și să le pui întrebări.
Și, poate fără să-mi dau seama la început, aici s-a deschis o altă etapă. Nu mai era vorba atât despre Power BI, cât despre ceea ce începeam să înțeleg lucrând cu datele prin intermediul lui. Proiectele deveniseră tot mai diferite, iar fiecare dintre ele aducea alte surse, alte structuri, alte probleme și alte întrebări.
De aici încolo, povestea poate fi privită puțin diferit: nu ca o poveste despre un instrument pe care am învățat să-l folosesc, ci ca o experiență despre ce se întâmplă atunci când începi să lucrezi, cu adevărat, cu date foarte diferite între ele.
Iar partea aceasta este, probabil, cea mai interesantă.
