Verdi: hvorfor dataprodukter er verdt bryet
Emneknagger: #dataprodukter, #målbar dataverdi
Hvorfor dataprodukter er verdt bryet – og hvordan du måler effekten.
Hvorfor skal du bry deg om dataprodukter?
Fordi alternativet blir dyrt i tid, friksjon og risiko.
Mønsteret gjentar seg: Team A leverer “noe data”, Team B kopierer og tilpasser (for å være trygg), Team C bygger videre på kopien. Resultatet er fragmentering: flere varianter av “samme sannhet”, mer run cost, flere avstemminger og lavere tillit.
I praksis blir det fort et systemproblem:
- Ulike definisjoner lever side om side, uten at noen vet hvilken som er “offisiell”.
- Endring blir farlig, fordi ingen har oversikt over hvem som bruker hva.
- Feil blir stille, fordi avvik oppdages i etterkant (ofte i et møte, ikke i pipeline).
- Gjenbruk skjer ikke, fordi tryggeste strategi blir å lage sin egen kopi.
Dataprodukter er ikke en magisk løsning. Men de gir dere et verktøy for å gjøre noen få leveranser stabile nok til at andre tør å bygge på dem, og for å gjøre kost/nytte synlig nok til at dere kan prioritere.
Tegn på at dere trenger “produkt” og ikke flere tabeller
Kjenner dere igjen flere av disse?
- “Hvor kommer tallet fra?” tar lengre tid enn å ta beslutningen.
- To dashboards viser ulike svar på samme spørsmål.
- Folk sier “vi tør ikke bruke den tabellen” (og lager en kopi).
- Små endringer i upstream skaper store ringvirkninger downstream.
- Dere har ting dere aldri tør å slette, fordi konsekvensen er ukjent.
Når kostnader er målbare, bør verdi også være det
Hvert dataprodukt har konkrete kostnader: compute, lagring, drift, forvaltning, support og videreutvikling. Da er det rimelig å være konkret på verdi, uten å overkomplisere.
Et praktisk grep er å snakke om cost to serve på en enkel måte. Ikke for å “chargebacke” alt, men for å unngå at produkter lever evig på autopilot:
- Teknisk drift: kjøring, lagring, observability, incident-håndtering.
- Koordineringskost: avstemming av begreper, avklaringer, møter, “kan du forklare denne joinen?”.
- Endringskostnad: breaking changes, migreringer, parallelle grensesnitt, opprydding. Les mer om hva dette koster i praksis i kapittel 8 om endring og utfasing.
- Risiko-kost: feil beslutninger, compliance-brudd, tap av tillit (som gjør at folk slutter å gjenbruke).
Når dere ikke gjør verdi eksplisitt, får dere en av to uheldige effekter:
- Alt får leve (fordi “kanskje noen trenger det”), eller
- Alt måles og blir støy (queries, antall tabeller, “populæritet”), og dere ender med å optimalisere for feil ting.
Målet er ikke et perfekt business case. Målet er et godt nok beslutningsgrunnlag for prioritering og porteføljestyring.
Konkrete verdihypoteser og målepunkter (eksempler)
Eksempler på verdihypoteser som er enkle å forklare, og målepunkter som kan brukes uten å bygge et datavarehus for å måle datavarehuset.
| Dataprodukt | Verdihypotese | Målepunkter (1–3) |
|---|---|---|
| Forecast/features for planlegging | Bedre planlegging ved at flere bygger på samme features/modeloutput over tid | Planavvik • andel beslutninger som bruker produktet • tid brukt på avklaringer |
| Ordre/ordrelinjer (hendelseslogikk) | Mindre avstemming ved én statusmodell og én tidslogikk | avvikssaker • tid til periodesteng • antall duplikatvarianter |
| Metrikk-lag (KPI) | Konsistente KPI-er på tvers av rapporter og team | KPI-konflikter • adopsjon i rapporter • tid fra endring til oppdatert forbruk |
| Kunde 360 – Core | Mer konsistent kundebilde og mindre feilbruk | tid til kundeoppslag • avvik i kundetall • antall konsumentmiljøer |
| Samtykkegrunnlag | Lavere compliance-risiko og færre kampanjefeil | avvik/klager • tid fra samtykke til effekt • andel kampanjer som bruker grunnlaget |
| Produktkatalog for analyse | Bedre sortiments- og prisbeslutninger | coverage på nøkkelattributter • antall lokale mappinger • tid brukt på datavask |
Kunde 360 – Core er det samme eksempelet vi brukte i business canvas og MVDP. Målepunktene her henger direkte sammen med verdihypotesen i canvasen.
Tre typer signaler er verdt å skille:
- Adopsjon (bruk): hvem bruker produktet, og i hvilke flater? (konsumentmiljøer, dashboards, jobs, API-klienter)
- Effekt (nytte): hva blir bedre når produktet brukes? (tid spart, færre avvik, høyere treffsikkerhet)
- Driftskost (run cost): hva koster det å holde løftet? (incident-rate, compute, support-tid)
Dere trenger ikke alle tre fra dag 1. Men hvis dere aldri ser på run cost, blir porteføljen fort en samling “evighetsprosjekter”.
Slik måler dere uten å overdrive
- Velg én verdihypotese per produkt (i klartekst, ikke konsulentsk).
- Velg 1–3 målepunkter som dere kan følge månedlig.
- Knytt målingen til en beslutning: “Hvis X skjer, gjør vi Y.” (Eksempel: hvis adopsjon er lav over 90 dager, vurder nedgradering til komponent eller juster produktflaten.)
Målepunkter som endrer seg sakte er fine, så lenge de endrer seg i riktig retning når dere gjør tiltak.
Vanlige feller
- “Antall queries” som verdi: høy query-rate kan bety verdi, eller bare dårlig modellering og manglende semantisk lag.
- “Antall tabeller” som fremdrift: mer motorrom er ikke det samme som mer gjenbruk.
- Verdi uten kobling til beslutning: dere måler månedlig, men ingenting endrer seg basert på det dere ser. Da er målingen pynt.
- “Dette er for alle”: uklare kunder gir uklare prioriteringer, som gir utydelig produktflate, som gir kopier.
Gjør verdihypotesen tydelig nok til at dere kan si nei til ting som ikke hjelper kunden, og ja til det som gjør produktet mer gjenbrukbart over tid.
Neste spørsmål er: hvordan deler dere produktet uten at konsumentene lager sine egne kopier? Se kapittel 5 om grensesnitt og datakontrakter.
