Praėję metai buvo įdomūs tuo, kad beveik visus juos praleidau dirbdamas kiek kitokį, nei man įprastą darbą – ne knaisiojausi po finansinius įmonių modelius, bandydamas suprasti, kas galėtų būti geros bendrovės investicijoms, o analizavau nemažus duomenų kiekius daugiausiai investicijų pritraukusiame lietuviškame startuolyje (ar tai iš vis yra teisingas žodis?) Vinted. Patirtis buvo labai įdomi, juolab, kad visada norėjau padirbėti ne vien su finansiniais modeliais, bet ir pamatyti kaip viskas atrodo iš realaus verslo pusės. O ir duomenų kiekiai Vinted įspūdingi: analizuoti keleto milijonų vartojojų duomenis labai įdomu. Ypač dar ir dėl to, jog Vinted kultūra yra labai stipriai paremta duomenų analize: verslo sprendimams duomenys yra pats svarbiausiais argumentas.
Analizuojant duomenis geriausiai išmokau dvi pamokas: 1) duomenys dažniausiai yra netobuli ir 2) duomenys nebūtinai reiškia tai, ką tu galvoji, kad jie reiškia. Tikriausiai dažnai dirbantys su duomenimis atlaidžiai palinguos galvą ir palaikys mane nepatyrusiu naivuoliu, bet iki realaus darbo su duomenimis niekada nebuvau pagalvojęs, jog didžioji duomenų analitiko darbo dalis yra duomenų paruošimas. Dažniausiai jie būna ne tokiame formate, kaip tau jų reikia, dalies duomenų trūksta, dalį duomenų reikia išsitraukti iš kitų duomenų bazių, dalį duomenų reikia atmesti dėl nepatikimumo, dalis duomenų būna svarais vietoje eurų, o dalis romėniškais skaitmenimis arabiška abėcėle. Tam, kad duomenis būtų galima sušerti kokiams nors modeliui arba patogiai jais naudotis, paskiriama iki 90 (taip, devyniasdešimt!) procentų duomenų analitiko darbo laiko. O aš iki tol galvojau, jog sunkiausia dalis – sugalvoti kaip ką su kuo kaip palyginti ar modeliuoti.
Antra pamoka: duomenys dažnai reiškia visai ne tai, ką tu galvoji, kad jie reiškia. Kažkurią savaitę krito vartotojų aktyvumas? Gal kaltos moksleivių atostogos, gal itin geras oras, o gal Vokietijoje prastėja ekonominė situacija. Gali būti, jog kažkas pakito svetainėje ir žmonės nebenori taip dažnai joje lankytis. Prielaidų gali būti labai įvairių, ir vien žiūrėdamas į plikus duomenis ne visada ką nors protingo išpeši. Visai gali būti, jog tiesiog tą savaitę buvo įvelta kokia nors klaida programiniame kode ir dalis duomenų buvo tiesiog prarasta – o to negalėtum atspėti, jeigu nepasiklaustum draugiškų programuotojų. Trumpai tariant: vien duomenų analizė kartais irgi būna bejėgė, reikia labai gerai žinoti visą kontekstą, kad galėtum suprasti, ką tie duomenys tau gali papasakoti.
Kita vertus, jeigu analitikai įdeda daug kruopštaus darbo į duomenų valymą, jų rinkimą ir gali būti tikri jų patikimumu, jeigu tikrai gerai išmano, ką tie duomenys gali reikšti, analizė gali papasakoti daug labai įdomių dalykų: nuo to, kuo skiriasi skirtingų vartotojų segmentų elgsena iki to, kaip vartotojus veikia vienas ar kitas tavo produkto pakeitimas. Kas smagiausia, jog turint daug vartotojų, visa tai galima stebėti ir daryti išvadas kone realiu laiku, o tai reiškia, jog galima operatyviai reaguoti ir daryti savo produkto korekcijas. Lyginant su ketvirtinėmis finansinėmis ataskaitomybėmis ar mėnesinėmis/savaitinėmis pardavimų ataskaitomis tai kosminis šviesos greitis. Tik visgi galioja tie esminiai „jeigu“: be kruopštaus darbo ir gero suvokimo pliki dideli duomenys savaime stogą nunešančių įžvalgų neatneš. Big data is hard, ok?.
Say Big data one more time :)
Ha! Na, nors įžvalgos vertingos, bet minėtais atvejais atrodo, jog reikia tiek darbo, kad norėtųsi jį automatizuoti, taigi http://goo.gl/JKmQ8L :).
O tuo tarpu, kol nėra tokios priemonės, man atrodo, kad kur kas smagiau skaičiuoti riziką jau turint tikimybes ir su jomis susijusius skaičius :)
Čia ir yra esmė, kad šio darbo automatizuoti negalima.
Na teko ragauti ir įmonių finansų ir duomenų analizės.
Duomenų analizėje tikrai labai svarbu duomenų paruošimas, ypač pirmą kartą juos ruošiant interpretacijai. Vėliau galima pasinaudojant ETL galimybėmis viską surišti (tarkim duomenų pjaustymui visai patogus koks nors QlikView ir galingesnis nei excel jei kiekiai dideli).
Problema yra kitur: žmonės dirbantys su duomenų analize dažnai nesugeba matyti globaliai – per daug užsižaidžia su susmulkintais duomenimis.
Žinoma, atvirkštinis variantas – švaistymasis apibendrintom globaliom frazėm neparemiant jų duomenų analize – taip pat dažnas. Tuo mėgsta piktnaudžiauti vadovai, kurie mano, kad žino, kaip viskas veikia, o realiai – kažkada žinojo ir mano, kad niekas nekinta..
Automatizavimas įmanomas iš principo tik ETL stadijoje. Visa kita – jau būtent “įžvalgų analitiko” arba “insights analyst” ekspertinis vertinimas:
Ką, kaip, kokiom apimtim analizuoti, į ką gilintis, o ką laikyti triukšmu.
Žinoma, susisteminus pagrindinius rodiklius galima automatizuoti ir jų surinkimą.
Tik reiktų periodiškai peržiūrėti kiek aktualus yra rodiklių rinkinys. O tai jau vėl neautomatinis darbas, o įžvalgų, patirties ir elementarių techninių sugebėjimų klausimas
Vienas iš tavo minėtų dalykų, kuriuos automatizuoti būtų sunku — tai priežastinių hipotezių kėlimas žinant tai, “kaip pasaulis veikia”, ir kokios priežastys galėjo įtakoti stebimas reikšmes.
Dėl tos pačios priežasties kol kas neturime labai tikslaus žmonių kalbos vertimo į kitas žmonių kalbas: teksto tikrosios reikšmės interpretacija būtinai atsiremia į pasaulio modelį, t.y., žinias apie tai, “kaip pasaulis veikia”.
Kol kas tik žmonės nešiojasi ant galvos neblogus pasaulio modelius, tačiau dėl priežasčių, kurias gali paskaityti čia http://goo.gl/BqiA9Z , ir kitų, kaip kad Deep Learning technologijų pažangos, panašu, kad tokie modeliai netolimoje ateityje neapsiribos žmonių galvomis.
Tad taip, tiek duomenų analizės, tiek teksto vertimo kol kas automatizuoti negalima, bet tai nereiškia, kad nenorėtume jų automatizuoti. Juk kur kas įdomiau priimti aukšto lygio sprendimus ir daryti aukšto lygio išvadas, nei užsiimti smulkemnomis.
*užsiimti smulkemnomis — na, turiu minty tuos minėtus 90% susijusių su duomenų paruošimu, ETL, etc. :). Kai kurios smulkmenos, atvirkščiai, juk, gali būti labai reikšmingos.
Mes kažkada svarstėme ar neverta būtų vieno tokio <90 proc. darbo automatizuoti ir atiduoti jo vykdymą 3sioms šalims (ten visai tokia nišinė telco rinka). Tas darbas yra pakrauti informaciją tokiu pusiau automatiniu interfeisu į DB.
Atsisakėme, nes darbuotojai kraudami tuos duomenis atlieka pirminę analizę, mato anomalijas ir tai jiems padeda daryti komercinius sprendimus, o be to kai patys tuos duomenis krauna, tai kontroliuoja procesą.
Šiuo komentaru norėjau pasakyti, jog dirbant tą <90 proc darbą jau daromos arba bent jau planuojamos strategijos likusiam 10 procentų.
@Skirmantas — vadinasi, tokį darbą galima būtų deleguoti patikimiems draugams, kuriems jis patinka :)
pasigendu AB testingo kuris manau daug ka sustato i savas vietas