Verdi
Emneknagger: #dataprodukter, #målbar dataverdi
Hvorfor dataprodukter faktisk 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.
Det klassiske mønsteret er kjent: 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.
Det er fristende å tenke at dette “bare” er litt ekstra SQL. 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
Hvis du kjenner igjen flere av disse, er dere sannsynligvis i dataprodukt-land (eller på vei dit):
- “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 også — 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.
- 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 ofte 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)
Under er 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 |
For å gjøre dette mer håndterlig, er det nyttig å skille mellom tre typer signaler:
- 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)
Du trenger ikke alle tre fra dag 1. Men hvis du aldri ser på run cost, blir porteføljen fort en samling “evighetsprosjekter”.
Slik måler dere uten å overdrive
En enkel praksis som ofte fungerer:
- Velg én verdihypotese per produkt (i klartekst, ikke konsulentsk).
- Velg 1–3 målepunkter som dere faktisk kan følge med på 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.)
Tommelfingerregel: 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.
- “Alle må ha SLO” fra dag 1: SLO uten responspraksis blir pynt.
- “Dette er for alle”: uklare kunder gir uklare prioriteringer, som gir utydelig produktflate, som gir kopier.
Hvis dere bare skal gjøre én ting: 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.
