Kjer sodelovanje pri podatkih ne uspe (in 4 nasveti za popravljanje)

Ponovno objavil Platon

Spremljevalci: 0

Kjer sodelovanje pri podatkih ne uspe (in 4 nasveti, kako to popraviti)
Slika creativeart na Freepiku

Podatkovne ekipe vedno bolj delujejo kot ekipe programskega inženiringa, ki za upravljanje svojega dela uporabljajo inženirska in razvojna orodja. Te segajo od sistemov za nadzor različic, kot je Github, do sprejemanja agilnih praks, kot sta Kanban in Scrum, in vključujejo slovesnosti, kot so vsakodnevno vstajanje, obveznosti v sprintu in predstavitve v sprintu. Na trg so prišle namenske rešitve (kot je dbt za podatkovno modeliranje, testiranje in integracijo), ki podpirajo miselnost programskega inženiringa. Te rešitve poganjajo velike ekipe za porazdeljene podatke, da opravljajo svoje najboljše delo.

Toda ko gre za sodelovanje med podatkovnimi skupinami in ostalim podjetjem, je še vedno veliko prostora za inovacije.

Tudi najbolj napredne organizacije, ki temeljijo na podatkih, se še vedno zanašajo na standardna orodja in prakse sodelovanja (npr. Slack, e-pošta ali redno načrtovani sestanki) za upravljanje komunikacije med svojimi podatkovnimi skupinami in poslovnimi deležniki. Konec koncev, zakaj pa ne? Ali ne bi morala podatkovna ekipa in njeni delovni tokovi spominjati na druge funkcije v organizaciji? Ta argument in vedenje delujeta, ko so interakcije razmeroma splošne narave. Toda v situacijah, kjer je timska dinamika bolj zapletena (in so podatki bolj osrednji za vsak pomemben pogovor in odločitev), je to zanašanje na generične rešitve nezadostno.

Ker postajajo podatki bolj osrednji za poslovne operacije, morajo člani podatkovne skupine pogosto nositi več klobukov. V nekaterih primerih morajo delovati kot vodje izdelkov z razumevanjem potreb poslovnih uporabnikov, da lahko razvijejo podatkovno platformo. V drugih primerih morajo obravnavati ad hoc zahteve kot podpora. V drugih situacijah morajo vključiti nove uporabnike in jim pomagati pri uporabi podatkovnih sredstev, ki so jim na voljo.

Splošna orodja za sodelovanje in tradicionalni pristopi k upravljanju dela se v teh scenarijih hitro pokvarijo. Skupine za izdelke in podporne ekipe imajo namensko izdelana orodja za upravljanje svojega dela. Ali podatkovne skupine ne potrebujejo tudi rešitve za najboljše upravljanje zahtev deležnikov? Ali orodja za upravljanje njihove podporne dokumentacije ali usposabljanje končnih uporabnikov? Najboljše podatkovne ekipe se pogosto znajdejo v težavah s tem delom svojega delovnega toka in na koncu sprejmejo rešitve, izdelane za druge (v tem primeru skupine za izdelke in podporo).

Ker je večina podatkovnega dela in interakcij notranjih, je ekipam lahko težko najti pravi način za delo s poslovnimi deležniki, ne da bi pri tem ustvarili zmedo in se soočili z nerodnostjo.

Če raziskujete težave pri sodelovanju med podatkovnimi skupinami in drugimi, boste zagotovo našli asimetrije informacij med ustvarjalci in uporabniki podatkovnih sredstev. Na eni strani imate graditelje podatkov s poglobljenim znanjem o osnovnih podatkih, o tem, kako z njimi manipulirati in jih analizirati ter kako jih kontekstualizirati v večjem obsegu podatkovnih sredstev. Po drugi strani pa imate uporabnike podatkov, ki so običajno strokovnjaki za področje z bogatim znanjem o samem poslu, kar je lahko ključnega pomena za zagotavljanje širšega konteksta, razumevanje podatkov in razvoj podatkovne platforme.

Vzemite na primer Jane. Pravkar se je pridružila podjetju s seznama Fortune 500 kot vodja prodaje in vodila porazdeljeno ekipo 15 prodajalcev, razpršenih po jugovzhodu. Drugi dan njene nove službe ji sodelavec posreduje e-poštno sporočilo z več povezavami do različnih virov: preglednica z informacijami o cevovodu, različna poročila v Salesforce in peščica nadzornih plošč o uspešnosti posameznika v rešitvi poslovnega bivanja podjetja. Po nekaj minutah gledanja podatkov ugotovi, da nima pojma, kaj v resnici gleda in kaj to pomeni. Pošlje sporočilo svojemu vodji prodajnih operacij in prosi za pomoč, ta pa prikliče njihovega partnerja v skupini za podatke, ki je zgradila večino teh virov. Podatkovni analitik prebere e-pošto, vzdihne in nato naslednjo uro porabi za pisanje odgovora. Ustvarijo vozovnico na svoji plošči JIRA za »ponovno oceno dokumentacije«.

Temeljni vzrok za tovrstne težave pri sodelovanju podatkov so asimetrije informacij med proizvajalci in potrošniki, zaradi česar so vsi razočarani in nezadovoljni.

Tragično je, da so ljudje, na katere ta dinamika najpogosteje vpliva, nižji zaposleni ali srednji menedžment na prvih črtah, ker imajo običajno manj moči v organizaciji in najmanj konteksta za razumevanje odločitev, ki se sprejemajo glede podatkov. Brez intenzivnega usposabljanja so ti zaposleni občutljivi na vrste komunikacijskih težav, ki so posledica asimetrije informacij. Prav tako so nagnjeni k temu, da postanejo žrtve »sindroma škripajočega kolesa«, kjer podatkovne ekipe seveda najglasneje slišijo glasove vodstvenih delavcev in članov višjega vodstva (zato imajo njihove zahteve in potrebe prednost pred zahtevami in potrebami drugih).

Da bi dobili boljšo donosnost naložbe iz ogromnih naložb v podatkovna orodja in ekipe, moramo napadeti te informacijske asimetrije v središču naših težav. Priti do ničle je morda ambiciozen cilj, vendar bi si morale podatkovne ekipe nenehno prizadevati zapolniti to vrzel s praksami, partnerstvi in orodji. S tem boste odpravili trenja, povečali preglednost in zaupanje ter vsem omogočili, da bolje izkoristijo ponudbo podatkov podjetja.

Tu so 4 proaktivni nasveti za vodje podatkov, ki želijo zmanjšati informacijske asimetrije in doseči boljše sodelovanje v svojih organizacijah:

Uskladite organizacijske in timske strukture s potrebami podjetja. To ne vključuje samo modelov poročanja, temveč tudi vloge in funkcije podatkovnih skupin. Začenjamo že opažati več objav za delovna mesta za vloge, kot sta »vodja podatkovnih izdelkov« ali »mojster podatkovnega scruma«. Te nove funkcije bodo podatkovnim ekipam pomagale obvladati izzive sodelovanja, ki so na koncu običajno povezani z ljudmi in procesi v primerjavi s temeljnimi tehnološkimi težavami.
Razmislite o naložbi v matrični model kjer so člani vaše ekipe – ali v nekaterih primerih celotne enote – usklajeni z določenimi poslovnimi enotami. To bo omogočilo uskladitev dolgoročnih podatkovnih pobud s takojšnjimi poslovnimi potrebami, spodbudilo izmenjavo znanja ter tesnejše sodelovanje med analitiki in tistimi, ki jih dnevno podpirajo.
Začnite z majhnim in gradite na svojem uspehu. The moč prvega vtisa ni mogoče preceniti. Začetno dojemanje podatkovne skupine je izjemno pomembno za to, kako bo njihovo delo sprejeto, zato vnaprej razmislite o tem, kako bo s ključnimi člani ekipe. Osredotočite se tako, da zgradite močne odnose z 1-2 ključnima prvakoma v organizaciji, ki lahko pomagata razširiti glas o tem, kako neverjetni ste. Razširite od tam.
Bodite pozorni na orodja za sodelovanje lahko uporabite v celotnem življenjskem ciklu vaših podatkovnih pobud in podatkovnih izdelkov. Na primer, pomislite, kako želite združiti svoje ljudi, procese in sisteme za vsako od spodnjih kategorij. Pogosto bo tisto, kar bo delovalo v eni kategoriji, v drugih popolnoma spodletelo:
- Sodelovanje znotraj podatkovne ekipe
- Generično sodelovanje z drugimi zaposlenimi zunaj vaše ekipe
- Ad hoc vprašanja ali zahteve za nove funkcije
- Stalna podpora za podatkovne izdelke
- Obseg novih podatkovnih pobud ali podatkovnih izdelkov
- Razvijanje vaše ponudbe podatkov na podlagi tega, kar je dragoceno za podjetje

Inovativne podatkovne ekipe se že selijo na najboljše prakse programskega inženiringa in ta trend se bo verjetno nadaljeval v prihodnjih letih. Ko razmišljate o vlaganju v podatkovno infrastrukturo za podporo prihodnje rasti, pomislite na orodja, ki podpirajo sodelovanje poslovnih partnerjev.

Nicholas Freund je izkušen izvršni direktor industrije SaaS z več kot desetletnimi izkušnjami pri vodenju zagonskih podjetij, osredotočenih na rast, ki jo vodi produkt. Kot ustanovitelj in izvršni direktor podjetja Workstream.io Nick vodi začetni tehnološki zagon, ki podatkovnim ekipam pomaga pri upravljanju kritičnih podatkovnih sredstev. Pred Workstreamom je bil Nick podpredsednik operacij za BetterCloud, neodvisnega prodajalca programske opreme, ki ponuja vodilno rešitev za upravljanje operacij SaaS. Prej je bil Nick na višjih finančnih položajih pri Tesli, medtem ko je pridobil MBA na Harvardu.