Duomenų valdysena – terminas, kurį IT sluoksniuose girdi vis dažniau, tačiau retai kas moka aiškiai paaiškinti, kas tai per gyvūnas. Vieni įsivaizduoja begalines Excel lenteles su duomenų savininkų sąrašais, kiti – brangius įrankius su gražiais dashboard’ais, treti apskritai galvoja, kad tai tik GDPR atitikties reikalas. Iš tikrųjų duomenų valdysena yra kur kas platesnė sąvoka, ir jei organizacija ja rimtai nesirūpina, anksčiau ar vėliau atsiduria situacijoje, kai niekas negali pasakyti, kuris skaičius teisingas – tas, kuris finansų ataskaitoje, ar tas, kuris rodomas BI įrankyje.
Kas iš tikrųjų yra duomenų valdysena
Paprastai tariant, duomenų valdysena – tai taisyklių, procesų ir atsakomybių rinkinys, apibrėžiantis, kaip organizacija tvarko savo duomenis nuo jų sukūrimo iki ištrynimo. Tai ne technologija, o organizacinis sluoksnis virš technologijos. Galima turėti geriausią duomenų platformą pasaulyje – Snowflake, Databricks, kad ir ką – bet jei niekas nežino, kas yra atsakingas už kliento adreso lauko tikslumą, jokia platforma nepadės.
Praktiškai tai reiškia atsakymus į gana banalius, bet nepaprastai svarbius klausimus: kas gali keisti šį lauką duomenų bazėje? Kas patvirtina naują duomenų šaltinį prieš jį prijungiant prie duomenų sandėlio? Kur galima rasti informaciją, ką iš tikrųjų reiškia stulpelis status_code ir kodėl jame yra reikšmė „7”, kurios niekas nebeprisimena, iš kur atsirado.
Kodėl apie tai staiga visi pradėjo kalbėti
Duomenų valdysena nėra naujiena – banke ar draudimo bendrovėje apie tai kalbama jau dešimtmetį. Bet paskutiniais metais tema išpopuliarėjo dėl kelių priežasčių vienu metu. Pirma, reguliavimas – GDPR, o dabar ir AI Act – verčia įmones tiksliai žinoti, kokius asmens duomenis jos turi, kur jie saugomi ir kas prie jų prieina. Antra, dirbtinis intelektas. Norint apmokyti modelį ar paleisti generatyvinį AI produktą, reikia švarių, gerai aprašytų duomenų, o ne chaoso, kuris kaupėsi dešimtmetį per įvairius ETL procesus.
Trečia priežastis – savitarnos analitika (self-service BI). Kai kiekvienas rinkodaros ar pardavimų analitikas gali pats susikurti ataskaitą Power BI ar Tableau, atsiranda rizika, kad penki žmonės sukurs penkis skirtingus „klientų skaičiaus” apibrėžimus. Be aiškios valdysenos toks laisvumas greitai virsta chaosu, kur niekas nebepasitiki skaičiais, ir susirinkimai virsta ginčais, kieno duomenys teisingi, o ne diskusija apie verslo sprendimus.
Kas iš tikrųjų dirba su duomenų valdysena
Čia dažnai kyla nesusipratimų. Duomenų valdysena nėra vien IT skyriaus reikalas – jei taip manysi, projektas žlugs per pusmetį. Reikalingas trikampis:
- Duomenų savininkas (data owner) – dažniausiai verslo atstovas, kuris atsako už konkrečios srities duomenis (pvz., klientų duomenų savininkas gali būti pardavimų vadovas).
- Duomenų prižiūrėtojas (data steward) – žmogus, kuris kasdien rūpinasi duomenų kokybe, aprašymais, standartais. Dažnai tai analitikas ar srities ekspertas, ne programuotojas.
- Duomenų inžinierius / IT komanda – įgyvendina technines priemones: prieigos kontrolę, kokybės patikras, katalogavimo įrankius.
Be šio trikampio valdysena virsta popierizmu – parašytas dokumentas, kurio niekas neskaito. Gera praktika – sukurti nedidelį duomenų valdysenos komitetą, kuris susitinka reguliariai (ne kas savaitę, bet, tarkim, kartą per mėnesį) ir sprendžia realius klausimus: naujo šaltinio prijungimą, prieigos konfliktus, kokybės problemas.
Metaduomenys, katalogai ir kur dingsta duomenų kilmė
Vienas didžiausių organizacijų skausmų – niekas nežino, iš kur duomuo atsirado ir per kokias transformacijas jis praėjo. Čia į pagalbą ateina duomenų kilmės sekimas (data lineage) ir metaduomenų valdymas. Įsivaizduok situaciją: BI ataskaitoje rodomas pajamų skaičius, jis neatitinka apskaitos sistemos. Be lineage įrankio ieškoti priežasties tenka rankiniu būdu peržiūrint SQL užklausas, ETL kodą, galbūt ir Python skriptus, kuriuos kažkas parašė prieš trejus metus ir jau seniai pamiršo.
Duomenų katalogas (data catalog) šioje vietoje veikia kaip savotiška duomenų „Google paieška” organizacijos viduje – jame galima rasti, kokios lentelės egzistuoja, ką reiškia stulpeliai, kas yra atsakingas, kokia paskutinio atnaujinimo data. Rinkoje yra rimtų sprendimų – Collibra, Alation, Microsoft Purview, atviro kodo variantas – DataHub ar OpenMetadata. Pastarieji ypač patrauklūs mažesnėms komandoms, nes nereikia mokėti didelių licencijų, tačiau reikalauja daugiau technikos darbo diegiant ir palaikant.
Kokybė – ten, kur viskas dažniausiai ir sugriūna
Galima turėti gražiausią katalogą ir aiškiausias politikas, bet jei pati duomenų kokybė prasta, visa tai neturi prasmės. Kokybės problemos dažniausiai kyla iš labai proziškų dalykų: dubliuoti įrašai, tušti laukai, neatitinkantys formatai (vienas sistema saugo datą kaip DD.MM.YYYY, kita – kaip YYYY-MM-DD), arba tiesiog pasenusi informacija.
Praktiškai verta įdiegti automatines kokybės patikras – pvz., naudojant Great Expectations, dbt tests ar Soda. Šie įrankiai leidžia apibrėžti taisykles (pvz., „el. pašto laukas negali būti tuščias”, „užsakymo suma negali būti neigiama”) ir automatiškai gauti perspėjimą, jei duomenys neatitinka lūkesčių dar prieš patenkant į ataskaitas. Tai kur kas geriau, nei sužinoti apie problemą iš įsiutusio finansų direktoriaus po ketvirčio uždarymo.
Klaidos, kurias organizacijos kartoja vėl ir vėl
Pastebėjau, kad daugelis diegimų žlunga dėl panašių priežasčių. Pirma – pradedama nuo įrankio, o ne nuo procesų. Perkamas brangus platforma, bet niekas nesusėdo aptarti, kas iš tikrųjų yra atsakingas už duomenis. Rezultatas – brangus įrankis dulka, o duomenys tvarkomi kaip ir anksčiau.
Antra klaida – bandymas apimti viską iš karto. Duomenų valdysena visai organizacijai per vieną projektą – garantuotas nesėkmės receptas. Geriau pradėti nuo vienos srities, pvz., klientų duomenų arba finansinės atskaitomybės, parodyti apčiuopiamą rezultatą, o tada plėstis toliau.
Trečia – valdysena suvokiama kaip vienkartinis projektas, o ne nuolatinis procesas. Duomenų aplinka kinta – atsiranda nauji šaltiniai, keičiasi verslo taisyklės, senos sistemos migruoja į naujas. Jei valdysenos procesas nėra įtrauktas į kasdienį darbą (pvz., į CI/CD procesą, kai kuriamas naujas duomenų pipeline), jis greitai pasensta ir tampa nebeaktualus.
Vietoj išvadų – kelios praktinės gairės, kaip pradėti neišprotėjus
Jei skaitai šį straipsnį, nes tavo organizacijoje ką tik nuskambėjo žodžiai „reikia susitvarkyti duomenis”, štai keletas dalykų, kuriuos verta padaryti pirmiausia, prieš perkant bet kokį įrankį:
- Susirašyk, kokius duomenų šaltinius turi organizacija ir kas juos realiai naudoja. Dažnai paaiškėja, kad pusė sistemų jau seniai niekam nebereikalingos.
- Paskirk atsakingus žmones konkrečioms sritims – net jei tai pradžioje tik neformalus susitarimas, ne oficiali pareigybė.
- Pradėk nuo vieno skausmingiausio atvejo – to, kur ginčai dėl skaičių vyksta dažniausiai. Išsprendus jį, žmonės patys pamatys naudą ir bus lengviau plėsti iniciatyvą.
- Neinvestuok į brangų įrankį, kol neturi bent minimalaus proceso. Net paprasta bendra Confluence lentelė su duomenų aprašymais yra geriau nei brangus, bet tuščias katalogas.
- Įdiek bent kelias automatines kokybės patikras svarbiausiems duomenų srautams – tai duoda greičiausią naudą už mažiausią pastangą.
- Nepamiršk, kad valdysena – tai kultūra, ne dokumentas. Jei žmonės nesupranta, kodėl tai svarbu, jokia politika nepadės.
Galiausiai verta prisiminti – duomenų valdysena nėra biurokratinė našta, kurią IT skyrius primeta verslui. Tai investicija, kuri atsiperka tuo momentu, kai reikia greitai priimti sprendimą, ir visi vadovai žiūri į tą patį skaičių, nesiginčydami, kuris šaltinis teisingas. O tokių momentų, ypač kai kalbama apie AI projektus ar reguliavimo patikras, netrūksta nei vienai organizacijai.
