Prioritering av maskinlæringstiltak: slik velger du riktig første use case

Hvorfor prioritering av maskinlæringstiltak er et eget problem

De fleste bedrifter som «vil bruke maskinlæring», har egentlig et helt annet spørsmål:

Hvilket konkret tiltak bør vi starte med – og hva bør vi si nei til?

Uten en strukturert prioritering ender mange med:

prosjekter som er teknisk imponerende, men svakt koblet til forretning
for mange parallelle initiativer og lite effekt i drift
at de mest modne, kjedelige – men lønnsomme – casene aldri blir valgt

Denne guiden dekker kun prioritering av use case:

hvordan du lager en kortliste over mulige maskinlæringstiltak
hvordan du rangerer dem etter gevinst, risiko og gjennomførbarhet
hvordan du tar en tydelig beslutning om hva som blir første pilot

Ingen algoritmer, ingen plattformvalg – kun beslutningsstøtte.

Steg 1: Lag en enkel bruttoliste over mulige use case

Start med å få alt ut på bordet, men på en strukturert måte.

1.1 Ram inn hvilke prosesser som er aktuelle

Begrens deg til 3–6 kjerneområder der maskinlæring ofte gir effekt:

Økonomi/fakturaflyt (tolking, konteringsforslag, betalingsrisiko)
Salg/CRM (leadscore, sannsynlighet for salg, neste beste tilbud)
Kundeservice (prioritering av saker, typeklassifisering, frafallsrisiko)
Drift/logistikk (etterspørselsprognoser, avviksdeteksjon, vedlikehold)

Alt utenfor disse kan noteres, men merkes som «senere».

1.2 Beskriv hvert forslag som én setning

For hvert foreslåtte use case, skriv:

Prosess: hvor i verdikjeden
Beslutning: hva modellen faktisk skal hjelpe med
Enhet: hva én rad vil være (kunde, faktura, sak, ordre)

Eksempler:

«Inngående faktura: modell som foreslår konto og prosjekt per faktura.»
«Abonnementskunder: modell som rangerer kunder etter sannsynlighet for å si opp innen 90 dager.»
«Supporthenvendelser: modell som gir prioritet (høy/middels/lav) per ny sak.»

Hvis du ikke klarer å skrive en énlinjer som dette, er caset for uklart til å vurderes.

Steg 2: Vurder forretningsverdi per case (uten teknologi)

Nå skal du grovsortere etter potensiell gevinst, uavhengig av algoritmer.

2.1 Tre spørsmål per use case

Gi en score fra 1–5 (1 = lav, 5 = høy):

Volum: hvor ofte tas denne beslutningen?
- 1 = sjelden (månedlig)
- 3 = ukentlig/daglig
- 5 = hundrevis/tusenvis av ganger per uke
Kost/konsekvens per beslutning: hvor mye betyr én feil eller én forbedring?
- 1 = nesten ingen økonomisk effekt
- 3 = merkbar, men ikke kritisk
- 5 = stor påvirkning på inntekt, kost eller risiko
Strategisk relevans: hvor tett ligger dette til dagens strategi?
- 1 = nice to have
- 3 = støtter viktige mål
- 5 = rett i kjernen (for eksempel lojalitet, margin, risiko)

Summer (maks 15). Alt under 7 kan normalt ut.

2.2 Fjern «lav-verdi»-kandidatene tidlig

Sorter listen etter sum. Dropp caser som:

har lav volumscore og lav konsekvensscore
ikke kan knyttes til et tydelig forretningsmål

Resultat: en kortliste på 5–10 caser.

Steg 3: Vurder datagrunnlag og modenhet per case

Selv et gull-case dør hvis dataene ikke finnes i praksis.

3.1 Minstesjekk for data

For hvert case på kortlisten, svar på fire ja/nei-spørsmål:

Finnes historiske data om beslutningen?
(f.eks. faktura med faktisk konto, kunder som faktisk sa opp/ikke sa opp)
Er dataene tilgjengelige i strukturerte systemer?
(ERP, CRM, fagsystem – ikke bare PDF og fritekst)
Vet vi hvem som eier dataene?
(navngitt fagansvarlig + systemeier)
Ser vi raskt minst 12 måneder med relevant historikk?
(eller tilsvarende antall hendelser)

Hvis du svarer «nei» på 2 eller flere, merk caset som ikke klart nå.

3.2 Grov score for datamodenhet

For de resterende casene, gi en score 1–5 på:

Datatilgjengelighet: hvor enkelt er det å hente ut et første datasett?
Datakvalitet (estimert): faglig vurdering – bruker dere dette til rapportering i dag?

Summér til en enkel «data-score» (2–10).

Steg 4: Estimer implementeringskompleksitet

Nå handler det om praktisk gjennomføring, ikke teori.

4.1 Tre praktiske dimensjoner

Gi 1–5 per case (1 = lav, 5 = høy – her er høy = vanskelig):

Integrasjonskompleksitet
- Hvor mange systemer må inn/ut?
- Holder det med batch mot ERP/CRM, eller kreves sanntid fra flere kilder?
Endring i arbeidsflate
- Enkle felter/etiketter i dagens skjermbilder (1–2)
- Nye skjermbilder, nye køer eller mange prosessendringer (4–5)
Regulatorisk/risikomessig kompleksitet
- Liten påvirkning på enkeltpersoner og lav beløpsrisiko (1–2)
- Berører kreditt, helse, personprofilering eller store beløp (4–5)

Summer til en kompleksitetsscore (3–15).

Lav score = enklere å gjennomføre.

Steg 5: Lag en enkel prioriteringsmatrise

Nå har du for hvert case:

Forretningsverdi (1–15)
Datascore (2–10)
Kompleksitet (3–15)

5.1 Konverter til tre nøkkeltall

Lag tre normaliserte skårer 1–10:

Business fit: basert på forretningsverdi (skalér 1–15 → 1–10)
Data readiness: direkte fra datascore (2–10)
Delivery risk: speilvend kompleksitet (lav kompleksitet = høy score)

5.2 Lag en «ICE»-lignende totalscore

For å komme til én prioritetsskår, kan du bruke:

Impact = Business fit
Confidence = Data readiness
Ease = Delivery risk

ICE-score = (Impact + Confidence + Ease) / 3.

Sorter casene etter ICE-score. De 1–3 øverste er kandidatene til første pilot.

Steg 6: Filtrer på risiko og «menneske-i-løkken»-krav

Før du velger vinneren, må du se på hva som kan gå galt.

6.1 Grov risikoklasse per case

Bruk tre nivåer:

Lav risiko: feil gir små beløp/tidsavvik, ikke personkritisk
Moderat risiko: merkbar økonomi/SLAs, men håndterbart
Høy risiko: store beløp, rettigheter, regulatorisk eksponering

Koble dette til automatjonsgrad i første runde:

Lav risiko → kan vurderes for delvis automasjon tidlig
Moderat risiko → start som tydelig beslutningsstøtte
Høy risiko → kun beslutningsstøtte + ekstra kontroll i piloten

6.2 Definer «menneske-i-løkken» per top-case

For de 1–3 beste casene, definer kort:

hvor mennesker alltid skal inn (terskler, beløpsgrenser, segmenter)
hvordan overstyring skal logges (årsakskoder)

Case som krever full automasjon fra dag én i høyrisikoområder bør skyves ut av første runde.

Steg 7: Ta beslutning om første pilot – og hva som parkeres

Til slutt må du lande på ett første case.

7.1 Beslutningskriterier for første pilot

Velg det caset som samlet sett har:

høy business fit
tilstrekkelig datagrunnlag nå
håndterbar kompleksitet (gjerne batch + enkle UI-endringer)
moderat eller lav risiko, eller tydelig menneske-i-løkken-ramme

7.2 Dokumenter eksplisitt hva som ikke velges nå

For de casene som tas ut:

skriv én setning «ikke nå fordi …» (mangler data, for kompleks integrasjon, for høy risiko)
eventuelt legg inn konkrete forutsetninger for å ta det opp igjen (ny datakilde, ferdig systembytte, bedre logging)

Dette reduserer støy internt og gir tydelig retning.

Steg 8: 30–60–90-dagers prioriteringsplan

Bruk denne planen for å gå fra liste til valgt pilot.

Dag 0–30: Innsamling og grovfilter

Samle inn forslag fra nøkkelområder (økonomi, salg/CRM, kundeservice, drift).
Skriv énlinjer per case (prosess, beslutning, én rad).
Score forretningsverdi på alle.
Fjern lav-verdi-caser.

Output: kortliste på 5–10 caser.

Dag 31–60: Data- og kompleksitetsvurdering

Gjør minstesjekk for data på hver kandidat.
Score datamodenhet og implementeringskompleksitet.
Beregn ICE-score (Impact/Business, Confidence/Data, Ease/Delivery).
Lag et første rangert forslag.

Output: 3 topp-caser med tallgrunnlag.

Dag 61–90: Risikoavklaring og valg av pilot

Gjør grov risikoklassifisering per topp-case.
Definer menneske-i-løkken og automatjonsgrad for hver.
Velg ett case som første pilot og ett som «reserve».
Dokumenter hva som ikke prioriteres nå – og hvorfor.

Output: beslutning om første pilot-case + enkel prioriteringslogg.

FAQ: Spørsmål om prioritering av maskinlæringstiltak

Hvordan unngår vi at «kjekt å ha»-case får forrang?

Krev at hvert forslag oppfyller tre ting før det vurderes:

klar énlinjer for beslutningen modellen skal støtte
anslått volum og konsekvens per beslutning
navngitt prosess- og dataeier

Forslag uten dette går ikke videre.

Bør vi velge det caset med høyest gevinst først?

Ikke nødvendigvis. Første pilot bør balansere:

høy nok gevinst til å være interessant
lav nok kompleksitet til å lykkes raskt

Ofte er et «middels stort» case med ryddige data og enkel integrasjon et bedre førstevalg enn et kjempestort, komplekst case.

Hva om vi har dårlig datakvalitet på alle caser?

Da er ikke første steg maskinlæring, men data- og prosessrydding. Bruk samme prioriteringslogikk til å velge hvor dere skal rydde data først (én prosess, én tabell, ett system).

Hvordan håndterer vi intern politikk og ulike agendaer?

Gjør prioriteringskriteriene eksplisitte og enkle:

forretningsverdi (volum, konsekvens, strategi)
dataklarhet
implementeringskompleksitet
risiko/automatjonsgrad

Del skåringen åpent. Da blir diskusjonen om tall og antakelser, ikke om hvem som «vinner».

Kan vi kjøre to piloter parallelt?

Kun hvis dere har:

egne team/eiereskap per case
kapasitet på data/integrasjon til å levere begge

For de fleste mellomstore bedrifter er det tryggere å lykkes med ett godt pilot-case før dere sprer ressursene tynt.

For en bredere innføring i maskinlæring – begreper, hovedtyper, vanlige metoder og hva som kreves teknisk – se pilarartikkelen vår om maskinlæring.