Dataforberedelse for maskinlæring: praktisk guide for norske bedrifter

Hvorfor egen guide for dataforberedelse?

De fleste maskinlæringsprosjekter stopper ikke i algoritmen, men i dataene:

feil felter trekkes ut fra ERP/CRM
datasettet blandes uten å skille mellom historikk og nåværende praksis
det finnes ingen enkel måte å gjenskape datasettet på senere

Denne artikkelen handler kun om én smal del av maskinlæring:

Hvordan du forbereder et konkret datasett i en norsk bedrift slik at det kan brukes trygt og effektivt til å trene den første maskinlæringsmodellen.

Ingen algoritmer, ingen plattformvalg – kun praktiske steg fra rådata til treningssett.

1. Start i prosessen: hva skal datasettet faktisk svare på?

Før du åpner et verktøy, må du låse to ting skriftlig.

1.1 Formuler ett konkret spørsmål

Eksempler:

«Kan vi forutsi hvilke kunder som sannsynligvis sier opp innen 90 dager?»
«Kan vi gi forslag til kontering på inngående faktura basert på historikk?»
«Kan vi rangere nye leads etter sannsynlighet for kjøp innen 30 dager?»

Skriv dette i én setning og få enighet mellom fag og data/IT. Uten enighet om spørsmålet får du et ubrukelig datasett.

1.2 Definer hva én rad i datasettet skal være

Én rad må være én beslutningsenhet – det modellen skal vurdere.

Eksempler:

Frafallsmodell: én rad = én kunde (per dato eller per måned)
Konteringsforslag: én rad = én fakturalinje eller én faktura
Leadscore: én rad = ett lead i CRM

Skriv eksplisitt: «I dette datasettet er én rad = …». Alt videre bygger på dette.

2. Velg kilder og felter – minst mulig, men nok

Nå skal du velge hvilke systemer og felter som faktisk skal inn i første versjon.

2.1 Kartlegg kildesystemer for dette ene spørsmålet

Typiske kilder i norske virksomheter:

ERP/økonomisystem (faktura, betaling, produkter, leverandører)
CRM (leads, aktiviteter, tilbud, status)
Fagsystem (bransjespesifikke hendelser, bruk, sensordata)
Kundeserviceverktøy (saker, kategorier, responstider)

Lag en kort liste:

System
Tabell/rapport
Eiere (fag + teknisk)

Hvis du har mer enn 3–4 hovedkilder i første versjon, er prosjektet sannsynligvis for bredt.

2.2 Velg felter du faktisk trenger for første modell

Del felter i tre kategorier:

Identifikatorer
- kundenummer, fakturanummer, lead-ID, sak-ID
- brukes til kobling og sporbarhet – ikke som features direkte
Kandidat-features (faktiske forklaringsvariabler)
Eksempler:
- kunde: antall kjøp, total omsetning siste 12 mnd, produktmiks, antall klager
- faktura: beløp, MVA-kode, leverandør, prosjektnummer, betalingsbetingelser
- lead: kanal, bransje, størrelse, antall interaksjoner, tid siden første kontakt
Fasit/label
- frafall: sa_opp_innen_90_dager (ja/nei)
- kontering: faktisk konto/prosjekt brukt
- lead: kjøpt_innen_30_dager (ja/nei)

Første versjon bør ha heller for få enn for mange kandidat-features. Du kan alltid legge til flere senere.

3. Lag datasettet én gang – på en måte du kan gjenta

Et datasett du ikke kan gjenskape, er verdiløst når du skal forklare modellen senere.

3.1 Skriv eksplisitt uttrekket som logikk

Beskriv uttrekket slik at en annen kan gjenta det:

periode: f.eks. «fakturaer med bokføringsdato fra 01.01.2022 til 31.12.2024»
filtre: «kun kunder i Norge», «ekskluder interne kunder», «kun statuser X og Y»
koblinger:
- faktura.kundenr = kunde.kundenr
- lead.account_id = account.id

Om dette gjøres i SQL, ETL-verktøy eller rapportmodul er mindre viktig – men logikken må være lagret og versjonert.

3.2 Skille mellom historikk og nåværende praksis

Unngå å blande helt ulike perioder ukritisk.

Eksempler på perioder som bør markeres eller vurderes separat:

større prisendringer, fusjoner, bytte av system
pandemiperioder, streik, ekstraordinære kampanjer

Praktisk grep:

legg inn en enkel «periode»-kolonne (f.eks. før_systembytte, etter_systembytte)
vurder å trene første modell kun på den mest relevante perioden

4. Ryddedata – minimumskrav før du går videre

Nå har du et råuttrekk. Før du tenker «modell», bør du gjøre noen enkle, men systematiske sjekker.

4.1 Finn og håndter åpenbare feil

Typiske feil å lete etter:

negative beløp som egentlig skulle vært kreditnota, men ikke er merket
faktura med bokføringsdato i fremtiden
kunder uten kundenummer eller landkode
lead uten opprettelsesdato

Ta stilling til:

skal raden fjernes?
skal verdien settes til tom/manglende?
skal det lages en egen kategori («ukjent», «annet»)?

Beslutningene må skrives ned – ikke bare gjøres i hodet.

4.2 Behandle manglende verdier bevisst

Identifiser felter med høy andel manglende:

< 5 % manglende: ofte trygt å imputere (f.eks. 0, median eller egen kategori)
5–30 %: vurder om feltet er viktig nok til å beholde – eller skal droppes
30 %: ofte bedre å droppe feltet i første versjon

Ikke la verktøyet velge standard-imputering uten at du vet hva det gjør.

4.3 Normaliser kategorier som brukes på tvers

Typiske problemområder:

land («Norge», «NO», «NOR»)
produktkoder som har fått nye navn
kundetyper («SMB», «SMÅ», «Small» osv.)

Lag små oppslagslister (mapping-tabeller) der det trengs, og bruk dem både i datasettet og i operativ rapportering.

5. Lag fasitkolonnen riktig – den er kjernen

Feil definert fasit gir feil modell uansett hvor «avansert» algoritmen er.

5.1 Eksempel: kundefrafall

Definer først:

hva betyr «sluttet som kunde» i deres forretning?
- ingen fakturert omsetning på 6 måneder?
- aktivt oppsigelsesbrev?
hvilken observasjonsperiode skal brukes?
- kunder aktive per 31.12.2023
- se om de sluttet innen 90/180/365 dager etter dette

Bygg fasit slik:

én rad per kunde ved startdato
label = 1 hvis kunden sluttet innen valgt horisont
label = 0 ellers

Unngå å blande periode for input og periode for fasit i samme tidsvindu.

5.2 Eksempel: konteringsforslag på faktura

én rad = én faktura eller én fakturalinje
fasit = faktisk konto (og evt. prosjekt) brukt ved bokføring
ekskluder faktura som senere er korrigert på en måte som ikke gjenspeiler normal praksis

6. Splitt datasettet for trening og testing – uten å jukse med tid

En vanlig feil er å blande gamle og nye rader tilfeldig. For bedriftsdata er det ofte feil.

6.1 Bruk tidsbasert splitt når det finnes tidsdimensjon

Praktisk mønster:

treningssett: første 70–80 % av perioden (f.eks. 2022–2023)
testsett: siste 20–30 % (f.eks. 2024)

Fordel:

du ligner mer på virkeligheten (du trener på historikk og tester på nyere data)

6.2 Når tilfeldig splitt kan forsvares

hvis datasettet ikke har tydelig tidsdimensjon
hvis det er svært stabilt over tid

Selv da bør du vurdere å holde unna en nyere periode som ekstra sanity-sjekk.

7. Dokumenter datasettet enkelt, men ordentlig

Du trenger ikke en tung datakatalog, men du trenger minimum dokumentasjon for dette datasettet.

7.1 Minimumsinnhold i en datasettbeskrivelse

Det bør finnes ett dokument (wiki, Markdown-fil eller lignende) som inneholder:

formål: hvilket spørsmål datasettet skal besvare
definisjon av én rad
periode og filtre brukt i uttrekk
kildesystemer og tabeller/rapporter
liste over felter med:
- navn i datasettet
- kort beskrivelse
- kildefelt (system.tabell.felt)
- hvordan manglende verdier er håndtert
definisjon av fasit/label
dato for generering + hvem som gjorde det

Dette er grunnlaget både for modellforklaring og for revisjon senere.

8. Minimum governance rundt datasettet

Selv i en liten pilot trenger du enkel styring for å unngå kaos senere.

8.1 Eier og tilgang

Avklar:

fageier: hvem eier prosessen og godkjenner bruken av data
dataeier: hvem har ansvar for kilden(e)
hvem har lov til å endre uttrekkslogikken

Sørg for at datasettet lagres på et sted med tilgangsstyring – ikke i en tilfeldig lokal mappe.

8.2 GDPR og dataminimering

Hvis datasettet inneholder personopplysninger:

dokumenter behandlingsgrunnlag (avtale, berettiget interesse, samtykke)
fjern felter som ikke trengs for formålet
vurder pseudonymisering (for eksempel hash av kundenummer i analyseversjonen)
sørg for logging/sporbarhet på hvem som har tilgang

Se Datatilsynet for detaljerte krav.

9. 30–60–90-dagers plan for dataforberedelse til én modell

Denne planen er laget for ett use case og ett datasett.

Dag 0–30: Avklare problem og hente første råuttrekk

Spikre problemformulering og én rad-definisjon
Velg kildesystemer og felter i samarbeid mellom fag og data/IT
Beskriv uttrekkslogikk (periode, filtre, koblinger)
Hent første råuttrekk og lagre det med versjon og dato

Output: rådatasett + enkel beskrivelse.

Dag 31–60: Rydding, fasit og datasplitt

Rydd åpenbare feil og manglende verdier etter klare regler
Normaliser kategorier som brukes på tvers
Bygg fasit/label kolonne med eksplisitt definisjon
Splitt data i trenings- og testsett uten å bryte tidslogikk
Dokumenter datasettet (felter, kilder, regler)

Output: klart trenings- og testsett + dokumentasjon.

Dag 61–90: Datakvalitetssjekk og forankring

Gå gjennom datasettet med fageiere – ser tallene riktige ut?
Sjekk enkle fordelinger per segment (kunder, produkter, perioder)
Avklar eventuelle GDPR-spørsmål og juster felter ved behov
Frys første datasettversjon som grunnlag for de første modellene

Output: godkjent datasett som kan brukes til å bygge de første modellene.

FAQ: Spørsmål om dataforberedelse for maskinlæring

Hvorfor kan vi ikke bare ta et eksport fra ERP/CRM og begynne å trene modell?

Fordi en enkel eksport sjelden har tydelig definert fasit, periode, filtrering og håndtering av manglende verdier. Uten dette får du en modell som er vanskelig å forklare, gjenskape og forbedre.

Hvor mye tid bør vi sette av til dataforberedelse i første prosjekt?

I mange bedrifter går flertallet av timene i første prosjekt til dataarbeid. Det er normalt at 60–80 % av innsatsen i starten er knyttet til data, ikke modellering.

Hva gjør vi hvis viktige felter har veldig mye manglende data?

Du har tre valg:

forbedre registreringspraksis og vente
bruke enklere modeller og færre felter i første versjon
begrense bruken til segmenter der dataene er bedre

Å tvinge inn svake felter med tung imputering i første versjon gir sjelden god effekt.

Bør vi rense bort alle «rare» perioder, for eksempel pandemi eller streik?

Ikke nødvendigvis. Men du bør merke disse periodene tydelig, og vurdere:

å trene modellen uten dem i første omgang
å bruke dem i egne tester («hvordan oppfører modellen seg under stress?»)

Hvordan vet vi at datasettet er «bra nok» til å starte modellering?

Typiske tegn:

fageier kjenner seg igjen i fordelinger og tall i et utvalg
det finnes en ryddig og konsistent fasitkolonne
manglende verdier og åpenbare feil er håndtert etter dokumenterte regler

Da er det som regel mer nyttig å komme i gang med enkel modellering enn å perfeksjonere datasettet ytterligere.