Hjem / sArtikkel / Slik kartlegger du behovene før du velger programvare

Slik kartlegger du behovene før du velger programvare

18, mars, 2026

Slik kartlegger du behovene før du velger programvare handler mest om å unngå dyre bomkjøp. Når behovene er uklare, ender dere ofte med “riktig” løsning på papiret. Men feil i hverdagen. God behovskartlegging gjør det enklere å sammenligne leverandører, sette realistisk budsjett og planlegge innføring uten å miste fart.

Innholdsfortegnelse

Vil du se hele kjøpsløpet fra kravliste til TCO og evaluering, kan du bruke pillar-guiden som støtte: Hvordan velge riktig programvare for virksomheten (SMB): steg-for-steg kjøpsguide.

> CTA (maler): Samle dette i én “nedlastbar” pakke internt (Word/Google Docs + Excel/Sheets): sjekkliste, kravmatrise, scoringsmatrise og PoC-plan. Da kan du gjenbruke det neste gang.

Når er kartleggingen ferdig nok? (definer suksessmål)

Kartleggingen er “ferdig nok” når dere kan:

  • beskrive hvem som har behovet og hvorfor
  • formulere 10–30 tydelige må-krav (Must) som skiller gode kandidater fra resten
  • bli enige om prioritering og beslutningskriterier
  • lage en shortlist (typisk 3–5 leverandører) som dere faktisk kan teste i demo/PoC
  • knytte valget til 3–6 KPIer/effektmål (for eksempel tidsbesparelse, færre feil, bedre datakvalitet)

Hvis dere fortsatt diskuterer “hva vi egentlig trenger”, er dere ikke klare for RFP/RFQ eller PoC.

Oversikt: prosess fra behov til shortlist (og pilot)

Bruk dette som sjekkliste for rekkefølge:

  • Forberedelse: mandat, scope, roller, interessenter
  • Innsikt: intervjuer, observasjon, survey, workshop, dataanalyse
  • As-is / To-be: prosesser, dataflyt, systemlandskap, smertepunkter
  • Kravspesifikasjon: funksjonelle + ikke-funksjonelle krav
  • Prioritering: MoSCoW + enkel RICE/vekting
  • Scoring og shortlist: krav → evalueringskriterier → poeng og vekter
  • Budsjett og TCO: hva koster det faktisk over 3–5 år
  • Sikkerhet/GDPR: DPA, datalagring, tilgang, logging
  • Integrasjoner: API, SSO, nøkkelsystemer (ERP/CRM/kalender)
  • PoC/pilot: testscenarier, suksesskriterier, evaluering
  • Leverandørvurdering: SLA, lock-in, referanser, supportmodell
  • Implementering og adopsjon: opplæring, endringsledelse, måling

Forberedelse: mandat, roller og interessentkart

Start med et kort prosjektmandat (1 side). Det holder ofte.

Mandatet bør avklare:

  • mål: hva skal bli bedre, og for hvem?
  • scope: hva er med nå, hva er uttrykkelig ikke med?
  • tidsramme: når må dere beslutte, og når må dere være i drift?
  • beslutningsmyndighet: hvem bestemmer ved uenighet?

Interessentkart (stakeholders) som faktisk fungerer

Involver tidlig, men ikke “alle i alle møter”. Lag et interessentkart og avtal nivå av involvering.

Typiske roller:

  • Prosesseier/fagansvarlig: eier behovet og gevinstene
  • Sluttbrukere/superbrukere: kjenner hverdagsflyten og irritasjonen
  • IT/arkitektur: drift, integrasjoner, autentisering, standarder
  • Sikkerhet/personvern: risiko, GDPR, databehandleravtale (DPA)
  • Økonomi/innkjøp: budsjett, TCO, kontrakt, betalingsmodell
  • Ledelse: prioritering, endringstrykk, forankring

En enkel RACI kan hjelpe (Responsible, Accountable, Consulted, Informed).

Innsiktsarbeid: metoder og praktisk gjennomføring

Målet er å få frem både uttalte behov (det folk sier) og faktiske behov (det dere ser i praksis).

Intervjuer: få frem friksjon og unntak

Gjør 6–12 korte intervjuer (30–45 min). Ta med både “power users” og de som sliter.

Spørsmål du kan kopiere:

  • Hvilke oppgaver tar mest tid i dag, og hvorfor?
  • Hvor oppstår feil, dobbeltregistrering eller misforståelser?
  • Hvilke unntak håndterer dere ofte (som dagens løsning ikke støtter)?
  • Hva må fungere på mobil / ute i felt?
  • Hvilke rapporter eller data trenger dere for å styre bedre?
  • Hvis systemet er nede i 2 timer: hva er konsekvensen?
  • Hvilke andre systemer må dere jobbe i parallelt?

Tips: Be informanten vise skjermen og en ekte oppgave. Da blir behovene konkrete.

Observasjon: se hva som faktisk skjer

Bruk 1–2 timer “skygge” i prosessen (f.eks. planlegging, godkjenning, endring). Noter:

  • antall klikk/overganger
  • manuelle mellomlag (Excel, e-post, lapper)
  • ventetid og “avbrudd” i flyten

Spørreundersøkelse: bredde på smertepunkter

En survey er nyttig for å bekrefte om det dere hører i intervjuer gjelder flere.

Hold det kort (5–10 spørsmål). Eksempler:

  • Hvor ofte opplever du X? (aldri–ofte)
  • Hva er topp 3 irritasjonsmomenter?
  • Hvilke enheter bruker du (PC/mobil/nettbrett)?
  • Hvor trygg er du på datakvaliteten (1–5)?

Workshops: bli enige om begreper og prioritering

Bruk workshop når dere må samle flere perspektiver raskt.

Forslag til agenda (90 min):

  • 10 min: mål og scope
  • 20 min: “as-is” smertepunkter (post-its)
  • 20 min: “to-be” mål og prinsipper
  • 30 min: første runde MoSCoW på krav
  • 10 min: neste steg og eierskap

Dataanalyse: mål før dere mener

Hvis dere har logger eller tall, bruk dem:

  • antall saker/avvik per måned
  • antall manuelle rettinger
  • responstid i prosess (fra opprettet til ferdig)
  • kostnader knyttet til feil, overtid, svinn

Dokumentere dagens løsning (as-is) og ønsket tilstand (to-be)

Dette trinnet gjør kravene mer realistiske. Det er også her integrasjonsbehov og datakvalitet ofte dukker opp.

As-is/to-be i et enkelt diagram

As-is (i dag)

  • Bruker registrerer → Excel → e-post til leder → godkjenning → manuelt inn i system A → rapport i system B

To-be (ønsket)

  • Bruker registrerer i løsning → automatisk godkjenning/flyt → data synk til system A/B → rapporter i samme løsning eller BI

Du trenger ikke fancy verktøy. En side med bokser og piler holder, så lenge dere er enige.

Kartlegg systemlandskap og data

Lag en liste over:

  • hvilke systemer som er kilde (master) for ansatte, kunder, produkter
  • hvilke systemer som bare “kopierer” data
  • hvilke integrasjoner som finnes i dag (og hvordan de fungerer: API, fil, manuell)

Lage kravspesifikasjon: funksjonelle og ikke-funksjonelle krav

En god kravspesifikasjon gjør demoer og tilbud sammenlignbare. Den bør være tydelig, testbar og prioritert.

Forskjellen på funksjonelle og ikke-funksjonelle krav

  • Funksjonelle krav: hva systemet skal gjøre (arbeidsflyt, funksjoner, rapporter)
  • Ikke-funksjonelle krav: hvordan det skal fungere (ytelse, sikkerhet, skalerbarhet, tilgjengelighet, etterlevelse)

Begge deler må med, ellers velger dere ofte en løsning som “har alt”. Men ikke tåler drift, volum eller krav til personvern.

Mal: kravmatrise (kan kopieres til Excel/Sheets)

ID Kravtype Krav (testbar formulering) Prioritet (MoSCoW) Begrunnelse/nytte Målemetode Kommentar
F-01 Funksjonelt Systemet skal støtte godkjenning i to trinn (leder + økonomi) Must Reduserer feilutbetaling Demo + testscenario Gjelder alle avdelinger
NF-01 Ikke-funksjonelt Oppetid skal være minst X per måned, ekskl. planlagt vedlikehold Must Kritisk for drift SLA + rapport Avklar hva som måles
INT-01 Integrasjon Løsningen skal kunne integrere med SSO (SAML/OAuth) Should Mindre friksjon og bedre sikkerhet Dokumentasjon + test IT eier

Unngå “brukervennlig” som krav. Skriv heller: “Ny bruker skal kunne utføre oppgave X uten opplæring, innen Y minutter” (og test i PoC).

Eksempler på krav du ofte bør ha med

Ikke-funksjonelt (drift/ytelse):

  • ytelse: responstid for nøkkelfunksjoner ved normalt volum
  • skalerbarhet: antall brukere/enheter/avdelinger over tid
  • tilgjengelighet: oppetid, vedlikeholdsvinduer
  • logging og sporbarhet: hvem gjorde hva, når (audit trail)

Sikkerhet og personvern (GDPR):

  • rollebasert tilgang (minste privilegium)
  • MFA/SSO støtte
  • datalagring og sikkerhetskopi
  • støtte for innsyn/sletting/retensjon (der det er relevant)

Integrasjoner og API:

  • standard API-endepunkter for les/skriv av nøkkeldata
  • eksportmuligheter (format, frekvens)
  • hendelser/webhooks ved endringer (om nødvendig)

Prioritering av krav: MoSCoW, MVP, RICE og vekting

Prioritering er ofte den vanskeligste delen. Men uten prioritering blir alt Must, og da hjelper ikke kravlisten.

MoSCoW (enkelt og effektivt)

  • Must: uten dette er løsningen uaktuell
  • Should: viktig, men kan fases inn senere
  • Could: “nice to have”
  • Won’t (nå): bevisst utsatt

Knyt Must til risiko/konsekvens: driftstans, lovkrav, sikkerhet, store kostnader.

RICE (for å rangere Should/Could)

RICE = Reach, Impact, Confidence, Effort Gi hver faktor en enkel skala (1–5). Høy score = høy verdi per innsats.

Eksempel:

  • Reach: hvor mange brukere/prosesser påvirkes?
  • Impact: hvor stor effekt?
  • Confidence: hvor sikre er dere (basert på innsikt)?
  • Effort: hvor tungt er det å innføre?

Dette gir dere et tydeligere “MVP” (minimumsløsning) som kan tas i bruk raskt.

Scoringsmodell og kortlisting av leverandører

Når kravene er klare, må dere gjøre dem om til en objektiv evaluering. Det hindrer at “beste demo” vinner.

Mal: scoringsmatrise (eksempel)

Skala: 0–5 (0 = støttes ikke, 3 = støttes med tilpasning, 5 = støttes standard)

Kategori Vekt (%) Leverandør A Leverandør B Leverandør C Hvordan måles
Must-krav (funksjonelt) 35 Demo/PoC
Ikke-funksjonelle krav (SLA/ytelse) 15 SLA + dokumentasjon
Sikkerhet/GDPR (DPA, tilgang, logging) 15 Sikkerhetssvar
Integrasjoner/API/SSO 15 Teknisk workshop
TCO (3–5 år) 15 Kostmodell
Leverandør (referanser, support, stabilitet) 5 Referansesjekk

Viktig: Must-krav bør ha “knockout”. Hvis en leverandør ikke oppfyller et Must (uten uakseptabel workaround), bør de ut.

Budsjett og TCO: hva regnes med?

TCO (Total Cost of Ownership) er ofte der prosjekter sprekker. Ikke fordi lisensen er dyr. Men fordi integrasjoner, opplæring og endring blir undervurdert.

TCO-sjekkliste (3–5 år)

Direkte kostnader:

  • lisens/abonnement (per bruker, per modul, per transaksjon)
  • oppstart/onboarding
  • supportavtale (hva er inkludert?)

Indirekte kostnader:

  • integrasjoner (utvikling, test, drift)
  • datamigrering og datavask
  • tilpasninger/konfigurasjon
  • intern tid (fag, IT, superbrukere)
  • opplæring og oppfølging
  • endringsledelse og intern kommunikasjon

En enkel tommelfingerregel er å budsjettere for mer enn lisensen. Men eksakt forhold varierer. Derfor bør dere be leverandører beskrive hva som er inkludert og hva som faktureres ekstra.

Sikkerhet, personvern og samsvar (GDPR, DPA og relevante krav)

Hvis løsningen behandler personopplysninger, må GDPR være en del av behovskartleggingen – ikke et vedlegg til slutt.

Spørsmål du kan sende leverandør (kopierbar liste)

  • Hvor lagres data (land/region), og kan vi velge lokasjon?
  • Hvem er behandlingsansvarlig og databehandler i dette oppsettet?
  • Tilbyr dere databehandleravtale (DPA), og hva er standardvilkårene?
  • Hvordan håndteres tilgangsstyring (roller), MFA og SSO?
  • Har dere logger/audit trail, og hvor lenge lagres de?
  • Hvordan håndteres sikkerhetskopi og gjenoppretting (RPO/RTO)?
  • Hvordan støttes innsyn, retting og sletting (der det er aktuelt)?
  • Hvordan varsles vi ved avvik/sikkerhetsbrudd?

For inspirasjon til strukturert kartlegging i offentlig/regelstyrt kontekst kan du se Digdir sitt steg om å kartlegge: Steg 3: Kartlegge | Digdir.

Integrasjoner og tekniske forutsetninger

Integrasjoner avgjør ofte både kostnad, tidsplan og brukeropplevelse.

Lag et integrasjonskart (minimum)

Liste opp:

  • systemer som må integreres (ERP, CRM, lønn, ID/AD, kalender)
  • dataobjekter (ansatt, avdeling, kunde, prosjekt, vakt, timeføring)
  • retning (én vei / to vei)
  • frekvens (sanntid, hver time, daglig)
  • metode (API, fil, iPaaS, manuell)

Autentisering: SSO som standardkrav for mange

Mange virksomheter ønsker SSO for å redusere passordkaos og øke sikkerhet.

  • SAML eller OAuth/OIDC (avhengig av løsning)
  • støtte for gruppe-/rolle-mapping fra katalog
  • krav til MFA via virksomhetens løsning

Når og hvordan kjøre PoC / pilot

En PoC (Proof of Concept) bør redusere risiko. Ikke være en “mini-implementering” som tar tre måneder.

Når PoC er spesielt nyttig

  • dere er usikre på integrasjoner (API/SSO/dataflyt)
  • dere har krevende arbeidsflyt med unntak
  • brukervennlighet i praksis er kritisk (mange brukere, høy turnover)
  • ikke-funksjonelle krav er stramme (oppetid, logging, volum)

PoC-oppsett (enkelt, men stramt)

  • varighet: 2–4 uker
  • scope: 3–5 testscenarier (ikke “alt”)
  • data: bruk realistiske testdata (anonymisert ved behov)
  • suksesskriterier: konkrete og målbare
  • evalueringsskjema: samme spørsmål til alle leverandører

Eksempel på testscenarier:

  • Opprette → godkjenne → endre → rapportere (full flyt)
  • Integrasjon: synk av ansatte/avdelinger + SSO innlogging
  • Avvik/unntak: “bytte vakt”, “retroaktiv korrigering”, “manglende data”

Leverandørrisiko, SLA og kontraktsvilkår å sjekke

Leverandørvalg er mer enn funksjoner. Det handler om hvordan dere blir fulgt opp i 3–5 år.

Sjekkpunkter:

  • SLA: oppetid, responstid, supporttider, eskalering
  • oppsigelse: bindingstid, oppsigelsesfrist, prisjustering
  • dataeierskap: kan dere eksportere alt, i hvilket format?
  • vendor lock-in: proprietære formater, uvanlige integrasjonsmetoder, høye uttrekkskostnader
  • referanser: snakk med kunder som ligner dere (bransje, størrelse, kompleksitet)

En nyttig sjekkliste for leverandørvurdering (generelt) finner du her: 6 ting å tenke på når du velger IT-leverandør | Advania.

Implementering, opplæring og brukeradopsjon

Behovskartleggingen bør ende i en plan for adopsjon. Ellers velger dere løsning uten å sikre effekt.

Det du bør avklare før valg:

  • hvem er superbrukere, og hvor mye tid får de?
  • opplæringsplan: korte moduler + praksisoppgaver
  • støtte i oppstart: “kontortid”, chat, intern FAQ
  • KPIer for adopsjon: innlogginger, gjennomførte prosesser, færre manuelle steg

Eksempler på KPIer/effektmål:

  • redusert tid per sak/prosess (minutter)
  • færre feil/avvik per måned
  • høyere andel oppgaver løst i systemet (ikke e-post/Excel)
  • kortere ledetid (fra opprettet til ferdig)

Kort case: kartlegge behov for et rostering-/planleggingsverktøy

En mellomstor virksomhet med skiftarbeid skal bytte planleggingsverktøy. Dagens situasjon: vaktplan i Excel, bytte av vakter på SMS, godkjenning på e-post og rapportering manuelt til lønn.

Innsikt (2 uker):

  • 8 intervjuer (ledere, planleggere, ansatte, lønn)
  • 2 observasjoner (planlegging + endringshåndtering)
  • kort survey til 60 ansatte (irritasjon, mobilbehov, bytte av vakter)
  • data: antall endringer per måned og tidsbruk per endring

As-is → to-be:

  • to-be krever mobiltilgang for ansatte, tydelig godkjenning og sporbarhet, samt eksport til lønn.

Krav (utdrag, 8 stk):

  • Must: ansatte skal kunne foreslå vaktswap i app, med godkjenning
  • Must: støtte for rollebasert tilgang (ansatt/leder/planlegger)
  • Must: eksport til lønn i avtalt format eller via API
  • Should: integrasjon med Outlook-kalender for ledere
  • Must: audit trail på endringer i plan
  • Must: oppetid/SLA som matcher drift (særlig i helg)
  • Should: rapporter for fravær og bemanningsdekning
  • Could: automatiske forslag basert på kompetanse

Prioritering og shortlist:

  • MoSCoW ga 5 Must, 2 Should, 1 Could.
  • Scoringmatrise (vekter på Must, integrasjon, TCO og brukervennlighet) ga shortlist på 3 leverandører.
  • PoC testet 4 scenarier: opprett plan, endre, swap, eksport til lønn. Én leverandør falt ut pga. manglende swap-flyt uten tung tilpasning.

For flere eksempler på vurderinger i planleggingsverktøy kan denne være nyttig som inspirasjon: En praktisk guide til planleggingsprogramvare | Teamdeck.

Nødvendige artefakter du bør laste ned eller lage

Du trenger ikke mer enn dette for å komme fra innsikt til shortlist:

  • Sjekkliste for behovskartlegging (stegene i denne artikkelen)
  • Intervjuguide (10–12 standardspørsmål)
  • As-is/to-be-ark (1 side diagram + notater)
  • Kravmatrise (funksjonelle + ikke-funksjonelle + integrasjon)
  • Prioriteringsark (MoSCoW + RICE-kolonner)
  • Scoringsmatrise (kriterier, vekter, poeng, kommentar)
  • PoC-mal (scenarier, testdata, suksesskriterier, evaluering)
  • TCO-ark (3–5 år, kostnadsposter, antakelser)

Hvis dere vil ha en mer formalisert tilnærming til behovsidentifisering kan KS sin beskrivelse være nyttig som metode-støtte: Steg 2 – Identifisere behov | KS.

Oppsummering: hva gjør du denne uken?

  • Avklar mandat, scope og beslutningsmodell (1 side).
  • Lag interessentkart og book 6–8 intervjuer.
  • Dokumenter as-is/to-be på én side, inkludert systemer og data.
  • Start kravmatrise med 10 Must + 10 Should (inkl. sikkerhet, GDPR, integrasjoner).
  • Lag en enkel scoringsmatrise og bestem vekter før dere ser demo.

Vanlige spørsmål

Hvordan involvere og prioritere interessenter uten å skape beslutningsvegring?

Hold to spor: et lite beslutningsteam (3–5 personer) og en bredere referansegruppe. Bruk faste beslutningspunkter og tidsbokser. La ikke alle mene alt hele tiden.

Hva er forskjellen mellom funksjonelle og ikke-funksjonelle krav, og hvordan dokumentere begge?

Funksjonelle krav beskriver oppgaver og flyt. Ikke-funksjonelle krav beskriver drift, ytelse, sikkerhet og etterlevelse. Dokumenter begge i samme kravmatrise, med testmetode (demo, dokumentasjon, PoC).

Hvordan beregne realistisk budsjett og TCO for en ny programvareløsning?

Ta med lisens, oppstart, integrasjon, migrering, intern tid, opplæring og løpende support. Sett TCO over 3–5 år. Og dokumenter antakelser (antall brukere, volum, integrasjoner).

Når er det nødvendig med en PoC eller pilot, og hvordan setter man den opp?

PoC er nyttig ved integrasjonsrisiko, kompleks arbeidsflyt eller strenge ikke-funksjonelle krav. Sett 2–4 uker, 3–5 scenarier, tydelige suksesskriterier og samme evalueringsskjema for alle.

Hva bør man kreve av leverandør med hensyn til sikkerhet og GDPR?

Be om DPA, datalagringssted, tilgangsstyring, logging/audit trail, backup/gjenoppretting og rutiner for avvik. Avklar også roller for behandlingsansvarlig/databehandler.

SaaS eller on-premises, hvordan velge riktig driftsmodell?

Se på krav til kontroll, integrasjoner, intern driftsevne, sikkerhetskrav og hvor raskt dere må i gang. SaaS gir ofte raskere oppstart, mens on-prem kan gi mer kontroll, men krever mer drift.

Hvordan evaluere integrasjonsbehov og eksisterende systemlandskap?

Lag en oversikt over kildesystemer og dataobjekter. Og beskriv retning, frekvens og metode for hver integrasjon. Ta en teknisk workshop med leverandør tidlig.

Hva er tegn på leverandørrisiko og hvordan unngå vendor lock-in?

Røde flagg er vanskelig dataeksport, proprietære formater, uklare priser på uttrekk/avslutning og avhengighet av leverandørkonsulenter for små endringer. Krev eksportmuligheter, tydelig kontrakt og dokumenterte API-er.

Hvordan måle suksess etter implementering (KPIer og ROI)?

Mål både adopsjon (bruk, fullførte prosesser) og effekt (tid, feil, kvalitet). Sett baseline før innføring. Og mål på nytt etter 1, 3 og 6 måneder.

Hvor detaljert må kravspesifikasjonen være før man inviterer til tilbud (RFP)?

Den må være detaljert nok til at leverandører kan prise likt og dere kan sammenligne. Start med Must/Should, testbar formulering og tydelig scope. Detaljer som “Could” kan ofte tas senere.

Konklusjon

God behovskartlegging er det som gjør programvarevalg håndterbart. Du trenger ikke perfekte dokumenter. Du trenger tydelige interessenter, konkrete krav (inkludert sikkerhet, GDPR og integrasjoner), prioritering og en scoringsmodell som gir en shortlist dere tør å teste.

Når dere har dette på plass, blir resten av kjøpsprosessen enklere å styre. Og sjansen for at løsningen faktisk blir brukt øker kraftig.

Merket:
Jonas Hansen

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *