ForretningsutviklingHafsteinn Runarsson · AI Konsulent01 Sept 2026 · 12 min

Datadrevet forretningsutvikling: 6 praktiske trinn

Datadrevet forretningsutvikling betyr å bruke relevante data til å velge hvilke problemer virksomheten bør løse, teste mulige tiltak og lære av resultatene. Målet er ikke mer rapportering. Målet er bedre beslutninger og konkrete endringer i produkter, tjenester, prosesser eller forretningsmodeller.

En enkel arbeidsmåte er å:

1. definere målet og beslutningen
2. finne dataene som faktisk trengs
3. etablere et pålitelig utgangspunkt
4. teste ett avgrenset tiltak
5. måle effekt og uønskede konsekvenser
6. justere, skalere eller stoppe

Denne guiden viser hvordan du gjør det i praksis, hvordan en datastrategi støtter arbeidet, og hvor analyse, integrasjoner, automatisering og AI passer inn. Hvis dataarbeidet er del av en større endring, kan du også lese vår praktiske guide til digital transformasjon.

Hva er datadrevet forretningsutvikling?

Datadrevet forretningsutvikling er en arbeidsform der data brukes aktivt til å forstå behov, prioritere muligheter og forbedre produkter, tjenester, prosesser eller forretningsmodeller. Data gir ikke fasiten alene. De gjør antakelser synlige og gir teamet et bedre grunnlag for å velge hva som skal testes.

Arbeidsformen består av tre deler:

• Forretningsforståelse: Hvilket problem er viktig nok til å løse?
• Datagrunnlag: Hvilke observasjoner kan bekrefte eller avkrefte antakelsen?
• Gjennomføring: Hvordan gjøres innsikten om til en endring i produktet eller arbeidsflyten?

Rapportering forteller ofte hva som har skjedd. Datadrevet forretningsutvikling bruker den kunnskapen til å bestemme hva virksomheten skal prøve videre. Forskjellen ligger i handlingen.

Start med beslutningen, ikke verktøyet

Et godt datainitiativ har én tydelig beslutning som mottaker. Hvis ingen kan si hva de vil gjøre annerledes når analysen er ferdig, er oppgaven for uklar.

Avklar disse spørsmålene før dere henter flere data:

• Hvem skal ta beslutningen?
• Hvor ofte tas den?
• Hvilke alternativer velger personen mellom?
• Hva er konsekvensen av et dårlig valg?
• Hvilken ny informasjon kan realistisk endre valget?

Et salgsteam kan for eksempel trenge å velge hvilke henvendelser som skal følges opp først. Et produktteam kan trenge å velge hvilket steg i registreringen som bør forbedres. En driftsleder kan trenge å se hvilke avvik som krever handling i dag. Hvert tilfelle krever forskjellige data, selv om alle ønsker «bedre innsikt».

Gjør datastrategien konkret

En datastrategi er nyttig når den kobler forretningsmål til beslutninger, datakilder, ansvar og en prioritert leveranseplan. En lang teknologiplan uten navngitte brukere og beslutninger blir fort løsrevet fra driften.

En kort datastrategi bør svare på fem ting:

1. Hvilke forretningsmål skal dataarbeidet støtte?
2. Hvilke beslutninger eller arbeidsflyter skal forbedres først?
3. Hvilke data trengs, og hvor pålitelige er de i dag?
4. Hvem eier definisjoner, tilgang, kvalitet og bruk?
5. Hvilke initiativer skal testes nå, senere eller ikke i det hele tatt?

Prioriter initiativene etter nytte, gjennomførbarhet, datatilgang og risiko. Da blir strategien en rekkefølge av valg, ikke en ønskeliste over plattformer og verktøy. For initiativer som skal bli et AI-produkt, bør datastrategien henge sammen med en produktstrategi for AI-produkter.

Vurder modenhet per brukstilfelle

Virksomheten trenger ikke være «datamoden» overalt før den kan begynne. Vurder modenheten for den konkrete beslutningen dere vil forbedre:

• Beskrivende: Teamet kan se hva som har skjedd, men dataene brukes mest i rapporter.
• Beslutningsstøttende: Dataene har felles definisjoner og brukes fast når en navngitt person velger neste handling.
• Operasjonell: Innsikten er integrert i produktet eller arbeidsflyten, med tydelige regler for tilgang, avvik og menneskelig kontroll.

Denne inndelingen gjør neste investering lettere å velge. Et team på første nivå trenger ofte bedre definisjoner og en fast beslutningsrytme før det trenger en ny dataplattform.

Seks trinn fra data til tiltak

En datadrevet prosess bør være kort nok til at teamet lærer før forutsetningene endrer seg. Del arbeidet i seks trinn med en tydelig leveranse fra hvert trinn.

1. Definer forretningsmålet

Beskriv ønsket endring uten å velge løsning på forhånd. «Redusere tiden fra henvendelse til første kvalifiserte oppfølging» er mer nyttig enn «bygge et AI-system for salg». Den første formuleringen åpner for flere mulige tiltak.

Knytt målet til en navngitt eier. Uten en eier blir målet lett et analyseprosjekt ved siden av den daglige driften.

2. Skriv ned antakelsen

En testbar antakelse forklarer hvilken endring dere tror vil påvirke målet, og hvorfor. Den kan skrives slik:

Hvis vi gjør [endring] for [målgruppe eller prosess], forventer vi [observerbar effekt], fordi [begrunnelse].

Formuleringen tvinger teamet til å skille mellom det dere vet, og det dere antar.

3. Kartlegg nødvendige data

Bruk minst mulig data som kan belyse antakelsen. Det kan være hendelser fra et digitalt produkt, statusendringer i et CRM-system, behandlingstid i en arbeidsflyt eller kvalitative tilbakemeldinger fra kunder og ansatte.

Dokumenter hvor dataene kommer fra, hvem som eier dem, hvordan de oppdateres og hvilke mangler som er kjent. Et lite datasett med tydelig betydning er mer anvendelig enn mange felt ingen stoler på.

4. Etabler et utgangspunkt

Mål dagens situasjon før dere endrer noe. Utgangspunktet gjør det mulig å skille en faktisk endring fra en god magefølelse. Det synliggjør også om målingen er stabil nok til å brukes.

Velg både et resultatmål og ett eller flere kontrollmål. Hvis målet er kortere behandlingstid, kan kvalitet, feilrate eller kundeklager være kontrollmål som hindrer at teamet optimaliserer for fart alene.

5. Test den enkleste brukbare løsningen

Den første løsningen skal teste antakelsen, ikke representere sluttproduktet. Det kan være en ny prioriteringsregel, en manuell ukentlig gjennomgang, et enkelt dashboard, en integrasjon eller en liten prototype. AI er aktuelt når oppgaven faktisk krever mønstergjenkjenning, språkbehandling eller fleksibel automatisering.

Legg testen inn i arbeidsflyten der beslutningen tas. En analyse som leveres i en presentasjon, men ikke er tilgjengelig når valget gjøres, får liten praktisk verdi. En avgrenset test kan senere inngå i en større prosess for digital produktutvikling fra idé til lansering.

6. Evaluer og velg neste handling

Sammenlign resultatet med utgangspunktet og kontrollmålene. Vurder også datakvalitet, brukernes faktiske adferd og kostnaden ved å drifte løsningen.

Avslutt med ett av tre valg:

• Skaler: Testen viser ønsket retning, og løsningen tåler mer bruk.
• Juster: Antakelsen kan fortsatt være riktig, men løsning eller datagrunnlag må endres.
• Stopp: Effekten er for svak, risikoen er for høy eller problemet var mindre viktig enn antatt.

Å stoppe en svak idé tidlig er også et godt resultat. Teamet har lært uten å binde seg til en stor investering.

Bygg et datagrunnlag folk kan bruke

Et brukbart datagrunnlag er forståelig, tilgjengelig og stabilt nok for beslutningen det skal støtte. Perfekte data finnes sjelden. Kravene bør stå i forhold til konsekvensen av beslutningen.

Sjekk fem forhold:

• Betydning: Tolker alle et felt eller en hendelse på samme måte?
• Fullstendighet: Mangler bestemte kunder, perioder eller steg systematisk?
• Aktualitet: Oppdateres dataene raskt nok for beslutningen?
• Sporbarhet: Kan teamet finne kilden og forstå endringer i definisjonen?
• Tilgang: Har de rette personene tilgang uten å spre data unødvendig?

Gi kritiske datasett en eier. Eieren trenger ikke produsere alle dataene, men må kunne godkjenne definisjoner, håndtere avvik og varsle når en kilde endres.

Datastyring må følge beslutningen

Datastyring bør beskrive hvem som kan bruke dataene, hva de betyr og hvordan feil håndteres. Begynn med dataene som inngår i den prioriterte beslutningen, i stedet for å forsøke å etablere regler for alt samtidig.

For hvert kritisk datasett bør teamet registrere:

• eier og teknisk kilde
• definisjon av sentrale felt og hendelser
• hvem som har tilgang, og hvorfor
• forventet oppdateringsfrekvens
• kjente mangler og rutine for avvik
• hva som skjer når kilden eller definisjonen endres

Dette gir et praktisk grunnlag for datastyring uten at arbeidet blir et separat dokumentasjonsprosjekt. Når data skal deles mellom virksomheter eller systemer, peker Digdir på felles standarder, tillitsmekanismer, styringsmodeller og semantisk interoperabilitet som sentrale deler av arbeidet.

Personvern må avklares før innsamling

Personopplysninger kan ikke samles inn bare fordi de kan bli nyttige senere. Datatilsynet forklarer at virksomheten må identifisere et behandlingsgrunnlag før opplysningene hentes inn. Avklar formål, tilgang, lagringstid og sletting sammen med ansvarlige for personvern og sikkerhet.

Dataminimering gjør også analysen enklere. Færre, tydelig definerte felt reduserer både risiko og opprydding.

Velg teknisk nivå etter behovet

Riktig arkitektur er den enkleste løsningen som gir pålitelige data når beslutningen tas. Ikke alle initiativer trenger en ny dataplattform, og ikke alle kan drives forsvarlig fra et regneark.

Velg nivå ut fra oppgaven:

• Manuell analyse: Passer for en avgrenset test med få datakilder og lav beslutningsfrekvens.
• Rapport eller dashboard: Passer når flere trenger samme definisjoner og en fast oversikt.
• Integrasjon i arbeidsflyten: Passer når innsikten må være tilgjengelig i CRM-systemet, produktet eller driftssystemet der handlingen skjer.
• Felles dataplattform: Passer når flere brukstilfeller trenger de samme kildene, historikken og tilgangsreglene.
• AI-løsning: Passer når oppgaven krever behandling av språk, dokumenter, bilder eller mønstre som faste regler håndterer dårlig.

Skisser dataflyten før dere bygger. Vis kildene, transformasjonene, definisjonene, tilgangene og stedet der en bruker tar beslutningen. Da blir avhengigheter og svake punkter synlige tidlig.

Organiser arbeidet rundt ett felles mål

Datadrevet forretningsutvikling fungerer best når forretning, data og gjennomføring møtes i samme arbeidsflyt. En overleveringskjede mellom bestiller, analytiker og utvikler skaper lett tap av kontekst.

Et lite tverrfaglig team bør dekke disse ansvarene:

• en forretningseier som prioriterer problemet
• en person som forstår datakildene og analysen
• en person som kan endre produktet, integrasjonen eller prosessen
• brukere fra arbeidsflyten som kan prøve løsningen og forklare avvik

Teamet trenger en fast rytme for å se på data, beslutte neste test og følge opp kontrollmål. Et dashboard uten en slik beslutningsrytme blir fort en skjerm få åpner.

Innføring er en del av leveransen

En løsning skaper først verdi når noen bruker den til å handle annerledes. Planlegg derfor innføring samtidig som analyse og utvikling.

Avklar:

• hvilken rolle som får ny informasjon eller et nytt ansvar
• hva brukeren skal gjøre når signalet er tydelig, uklart eller feil
• hvordan tilbakemeldinger og avvik registreres
• hvem som følger opp bruken etter lansering
• hvilke gamle rapporter eller manuelle steg som kan fjernes

Brukerne bør delta i testen. De kjenner unntakene i arbeidsflyten og kan forklare hvorfor et tilsynelatende godt signal ikke alltid bør styre handlingen.

Bruk AI der oppgaven krever det

AI er et virkemiddel i datadrevet forretningsutvikling, ikke en strategi i seg selv. Velg AI når egenskapene passer problemet bedre enn faste regler, søk eller tradisjonell programvare.

Aktuelle oppgaver kan være å:

• sammenfatte store mengder tekst for menneskelig vurdering
• foreslå kategorier eller prioriteringer basert på kjente eksempler
• hente strukturert informasjon ut av dokumenter
• finne relevant kontekst på tvers av godkjente kilder
• automatisere et avgrenset steg med tydelige kontrollpunkter

Definer hva systemet kan gjøre, hvilke data det kan bruke og når et menneske skal kontrollere resultatet. NISTs rammeverk for risikostyring av AI er laget for frivillig bruk og for å innarbeide pålitelighet i design, utvikling, bruk og evaluering av AI-systemer. Vår guide til human-in-the-loop AI viser hvordan kontrollpunkter kan plasseres i arbeidsflyten.

Test også feiltilfeller. En løsning som gir et godt svar i en demo, men mangler håndtering av usikkerhet, tilgang og avvik, er ikke klar for en viktig arbeidsflyt. Les mer om hvordan du kan teste programvare og AI-systemer før løsningen får større ansvar.

Velg brukstilfeller med kort vei til handling

De beste første initiativene har en tydelig bruker, en gjentakende beslutning og data som allerede finnes. Da kan virksomheten teste arbeidsformen uten å starte med en omfattende plattformendring.

Eksempler kan være:

• Kundeoppfølging: samle signaler fra henvendelser og CRM-status for å prioritere neste handling
• Produktutvikling: kombinere brukshendelser og tilbakemeldinger for å velge hvilket friksjonspunkt teamet skal undersøke
• Drift: synliggjøre avvik og gi ansvarlig person riktig kontekst før oppfølging
• Kunnskapsarbeid: finne og sammenfatte relevant informasjon fra godkjente dokumenter
• Nye tjenester: teste om eksisterende data kan inngå i en ny digital arbeidsflyt eller et nytt produkt

Prioriter etter forventet nytte, gjennomførbarhet, datatilgang og risiko. Den mest avanserte ideen er sjelden det beste stedet å begynne.

Lag en enkel business case

En business case for datadrevet forretningsutvikling bør sammenligne forventet nytte med kostnad, risiko og alternativet om å fortsette som i dag. Bruk et intervall når effekten er usikker, og skriv ned hvilke antakelser som driver regnestykket.

Vurder disse postene:

• hvor ofte beslutningen tas
• hvor mange saker, kunder eller ansatte som berøres
• dagens tidsbruk, feil eller tapte muligheter
• kostnaden ved utvikling, datatilgang, lisenser og drift
• kostnaden ved menneskelig kontroll og avvikshåndtering
• hvor raskt testen kan gi et troverdig svar

En lovende business case er fortsatt en antakelse. Bruk utgangspunktet og testen til å erstatte antakelser med observerte resultater før dere skalerer.

Unngå de vanligste feilene

De fleste svake datainitiativer mangler koblingen mellom innsikt og handling. Disse feilene bør oppdages tidlig:

• Teknologi først: Teamet velger plattform før problem og beslutning er definert.
• For stort omfang: Flere avdelinger, datakilder og mål legges inn i samme første leveranse.
• Uklare begreper: Team tolker «aktiv kunde», «kvalifisert henvendelse» eller «fullført sak» forskjellig.
• Ingen arbeidsflyt: Innsikten presenteres, men ingen har ansvar for å handle på den.
• Bare ett måltall: Et lokalt mål forbedres mens kvalitet, risiko eller kundeopplevelse svekkes.
• Skalering før læring: Infrastruktur bygges for stort volum før teamet vet om tiltaket er nyttig.
• Manglende innføring: Løsningen er ferdig, men roller, rutiner og gamle arbeidsmåter er uendret.

En kort problemdefinisjon, en måleplan og en navngitt eier fanger opp mye av dette før utviklingen starter.

Slik velger du første initiativ

Det første initiativet bør være viktig nok til å få oppmerksomhet, men lite nok til at virksomheten kan lære og endre kurs. Bruk denne sjekklisten:

1. Beslutningen tas ofte nok til at en forbedring kan observeres.
2. En navngitt person eier målet og kan endre arbeidsflyten.
3. De viktigste dataene finnes allerede eller kan samles inn på en forsvarlig måte.
4. Teamet kan beskrive dagens utgangspunkt.
5. Testen kan avgrenses til én målgruppe, prosess eller del av produktet.
6. Resultatmål og kontrollmål er avtalt før testen starter.
7. Det finnes en plan for drift, tilgang og avvik hvis testen skal skaleres.

Hvis flere punkter mangler, bør teamet redusere omfanget eller gjøre en kort kartlegging først.

Hva er forskjellen på datadrevet forretningsutvikling og business intelligence?

Business intelligence samler og presenterer data for rapportering og analyse. Datadrevet forretningsutvikling bruker denne innsikten til å prioritere, teste og endre produkter, tjenester, prosesser eller forretningsmodeller. BI kan være en del av datagrunnlaget, men arbeidsformen krever også eierskap og gjennomføring.

Må vi ha AI for å jobbe datadrevet?

Nei. Mange gode initiativer bruker enkle regler, analyser, integrasjoner eller manuelle tester. AI er relevant når problemet krever behandling av ustrukturert informasjon, mønstergjenkjenning eller fleksibel automatisering. Verktøyet bør velges etter oppgaven.

Trenger vi en dataplattform før vi kan begynne?

Nei. Begynn med beslutningen og de kildene som er nødvendige for å teste den. En felles dataplattform blir aktuell når flere brukstilfeller trenger de samme dataene, historikken, kvalitetskontrollene og tilgangsreglene. En avgrenset test kan ofte gjennomføres enklere.

Hvor mye data trenger vi for å begynne?

Dere trenger nok data til å beskrive utgangspunktet og teste en konkret antakelse. Kvalitet og relevans er viktigere enn størrelsen alene. Start med de kildene som ligger nærmest beslutningen, og dokumenter mangler i stedet for å skjule dem.

Hvordan velger vi riktig KPI?

Velg et mål som endres når brukeren eller arbeidsflyten faktisk blir bedre. Suppler det med kontrollmål for kvalitet, risiko eller kundeopplevelse. KPI-en må ha en tydelig definisjon, datakilde, eier og målefrekvens før testen starter.

Når bør vi hente ekstern hjelp?

Ekstern hjelp kan være nyttig når virksomheten mangler kapasitet til å koble forretningsmål, data og produksjonsutvikling i ett team, eller når en prototype må gjøres om til en robust arbeidsflyt. Avklar mål, omfang, tilgang, ansvar og overlevering før arbeidet starter.

Gjør én datamulighet konkret

Velg én beslutning, prosess eller tjeneste som bør bli mer datadrevet. Beskriv dagens utgangspunkt og hva dere vil gjøre annerledes før dere velger verktøy. Hvis dere trenger hjelp til å avgrense og gjennomføre arbeidet, kan dere lese om Daias tjenester eller starte en samtale.