Duomenys visur, derinimas niekur: kokie informacijos suvestinės klystu ir kodėl jums reikia duomenų produktų tvarkyklės

Per pastarąjį dešimtmetį įmonės išleido milijardus duomenų infrastruktūros. Petabaitų masto sandėliai. Realaus laiko vamzdynai. Mašinų mokymosi (ML) platformos.

Ir vis dėlto – paklauskite savo operacijų, kodėl praėjusią savaitę padidėjo „Churn“, ir greičiausiai gausite tris prieštaringas prietaisų skydelius. Paprašykite „Finance“ susitaikyti su priskyrimo sistemomis ir išgirsite: „Tai priklauso nuo to, ko klausiate“.

Pasaulyje, skęstančiame prietaisų skydeliuose, viena tiesa palaiko paviršių: duomenys nėra problema – produkto mąstymas yra.

Ramus „Duomenų kaip paslaugos“ žlugimas “

Ilgus metus duomenų komandos veikė kaip vidinės konsultacijos-reaktyvios, bilietų pagrindu sukurtos, „Hero“. Šis „Duomenų kaip paslaugos“ (DAAS) modelis buvo puikus, kai duomenų užklausos buvo mažos, o akcijų paketas buvo žemas. Tačiau kai įmonės tapo „pagrįstos duomenimis“, šis modelis suskilo pagal savo sėkmę.

Paimkite „Airbnb“. Prieš pradedant savo metrikos platformą, „Product“, „Finance“ ir „OPS“ komandos ištraukė savo metrikos versijas, tokias kaip:

• Naktys užsakė
• Aktyvus vartotojas
• Galimas sąrašas

Net paprastas KPI skyrėsi pagal filtrus, šaltinius ir kas klausė. Lyderystės apžvalgose skirtingos komandos pateikė skirtingus skaičius – dėl to buvo argumentai, dėl kurių metrika buvo „teisinga“, o ne kokių veiksmų imtis.

Tai nėra technologijos nesėkmės. Jie yra produktų nesėkmės.

Pasekmės

• Duomenų nepasitikėjimas: analitikai yra antra. Priimtuvų suvestinės atsisako.
• Žmonių maršrutizatoriai: Duomenų mokslininkai praleidžia daugiau laiko aiškindami neatitikimus, nei generuodami įžvalgas.
• Nereikalingi vamzdynai: inžinieriai atstato panašius duomenų rinkinius tarp komandų.
• Sprendimo vilkimas: vadovai atideda arba ignoruoja veiksmus dėl nenuoseklių įvesties.

Nes duomenų pasitikėjimas yra produkto problema, o ne techninė problema

Daugelis duomenų vadovų mano, kad turi duomenų kokybės problemą. Bet pažiūrėkite arčiau ir rasite duomenų patikėjimo problemą:

• Jūsų eksperimentų platforma sako, kad funkcija kenkia išlaikymui, tačiau produktų vadovai tuo netiki.
• OPS mato prietaisų skydelį, kuris prieštarauja jų gyvenimui.
• Dvi komandos naudoja tą patį metrinį pavadinimą, tačiau skirtinga logika.

Vamzdynai veikia. SQL yra patikimas. Bet niekas nepasitiki rezultatais.

Tai yra produkto gedimas, o ne inžinerija. Nes sistemos nebuvo sukurtos pritaikomumui, aiškinamumui ar sprendimų priėmimui.

Įveskite: „Data Product Manager“

Aukščiausiose įmonėse – „Data Product Manager“ (DPM). Skirtingai nuo generalinių PMS, DPM veikia per trapią, nematomą, kryžminę funkcinę reljefą. Jų darbas nėra gabenti prietaisų skydelius. Tai yra užtikrinti, kad tinkami žmonės tinkamu laiku galėtų priimti sprendimą.

Tačiau DPMS nesustokite su vamzdynų duomenimis į prietaisų skydelius ar kuravimo lenteles. Geriausi eina toliau: jie klausia: „Ar tai iš tikrųjų padeda kam nors geriau atlikti savo darbą?“ Jie apibūdina sėkmę ne pagal rezultatus, o rezultatus. Ar ne „Ar tai buvo išsiųsta?“ Bet „Ar tai iš esmės pagerino kažkieno darbo eigą ar sprendimų kokybę?“

Praktiškai tai reiškia:

• Ne tik apibrėžkite vartotojus; stebėkite juos. Paklauskite, kaip jie tiki, kad produktas veikia. Sėdėk šalia jų. Jūsų darbas nėra išsiųsti duomenų rinkinį – tai padaryti jūsų klientą efektyvesnį. Tai reiškia giliai suprasti, kaip produktas patenka į realaus pasaulio darbo kontekstą.
• Savo kanoninę metriką ir traktuokite jas kaip su API-versijomis, dokumentais patvirtintais, valdomais-ir užtikrinkite, kad jie būtų susieti su tokiais sprendimais, kaip 10 mln.
• Sukurkite vidines sąsajas, tokias kaip funkcijų parduotuvės ir „Clean Room API“ – ne kaip infrastruktūra, o kaip realūs produktai su sutartimis, SLA, vartotojais ir grįžtamojo ryšio kilpomis.
• Pasakykite „ne“ projektams, kurie jaučiasi sudėtingesni, bet nesvarbu. Duomenų dujotiekis, kurio nė viena komanda nenaudoja, yra techninė skola, o ne pažanga.
• Patirties dizainas. Daugelis duomenų produktų nepavyksta ne nuo blogo modeliavimo, o iš trapių sistemų: dokumentų neturinčių logikos, dribsnių vamzdynų, šešėlių nuosavybės. Sukurkite darant prielaidą, kad jūsų būsimas aš ar pakaitalas jums padėkos.
• Išspręskite horizontaliai. Skirtingai nuo domeno specifinių PMS, DPM turi nuolat atitolinti. Vienos komandos gyvenimo vertės (LTV) logika yra kitos komandos biudžeto įvestis. Iš pažiūros nedidelis metrikos atnaujinimas gali turėti antrosios eilės pasekmes rinkodaros, finansų ir operacijų pasekmėms. Vadovavimas tuo sudėtingumu yra darbas.

Bendrovėse DPM tyliai iš naujo apibrėžia, kaip sukuriamos, valdomos ir priimamos vidinės duomenų sistemos. Jų nėra valyti duomenis. Jie ten, kad organizacijos vėl tuo patikėtų.

Kodėl tai užtruko

Ilgus metus klaidingai veikėme progresui. Duomenų inžinieriai pastatė vamzdynus. Mokslininkai pastatė modelius. Analitikai pastatė prietaisų skydelius. Tačiau niekas neklausė: „Ar ši įžvalga iš tikrųjų pakeis verslo sprendimą?“ Arba dar blogiau: mes paklausėme, bet niekam nepriklausė atsakymas.

Nes dabar vykdomieji sprendimai yra susiję su duomenimis

Šiandienos įmonėje beveik kiekvienas pagrindinis sprendimas – biudžeto poslinkiai, nauji paleidimai, ORG restruktūrizavimas – pirmiausia praeina per duomenų sluoksnį. Bet šie sluoksniai dažnai nebenaudojami:

• Paskutinį ketvirtį naudojama metrinė versija pasikeitė, tačiau niekas nežino, kada ir kodėl.
• Eksperimentų logika skiriasi įvairiose komandose.
• Priskyrimo modeliai prieštarauja vienas kitam, kiekvienas su tikėtina logika.

DPMS neturi sprendimo – jiems priklauso sąsaja, dėl kurios sprendimas yra įskaitomas.

DPM užtikrina, kad metrika būtų aiškinama, prielaidos yra skaidrios, o įrankiai yra suderinti su realiomis darbo eigomis. Be jų sprendimo paralyžius tampa norma.

Kodėl šis vaidmuo įsibėgės AI epochoje

AI nepakeis DPMS. Tai padarys juos būtinus:

• 80% AI projekto pastangų vis dar atitenka duomenų parengimui („ForRester“).
• Kaip didelių kalbos modelių (LLMS) skalė, šiukšlių sąnaudų sąnaudų kaina. PG neištaiso blogų duomenų – jis juos sustiprina.
• Reguliavimo slėgis (ES AI įstatymas, Kalifornijos vartotojų privatumo įstatymas) skatina organizacijas, kad galėtų gydyti vidines duomenų sistemas gaminio griežtumu.

DPM nėra eismo koordinatoriai. Jie yra pasitikėjimo, aiškinamumo ir atsakingų AI pagrindų architektai.

Taigi, kas dabar?

Jei esate CPO, CTO ar duomenų vadovas, paklauskite:

• Kas turi duomenų sistemas, kurios galioja mūsų didžiausius sprendimus?
• Ar mūsų vidinės API ir metrikos yra versijos, aptinkamos ir valdomos?
• Ar mes žinome, kurie duomenų produktai yra priimti – ir kurie tyliai pakenkia pasitikėjimui?

Jei negalite aiškiai atsakyti, jums nereikia daugiau informacijos suvestinių.

Jums reikia duomenų produktų vadovo.

„SeoJoon OH“ yra „Uber“ duomenų produktų vadovas.