Å velge ny programvare handler sjelden bare om funksjoner. Det handler om flyt i hverdagen, færre manuelle rutiner og lavere risiko. Feil valg kan gi dyre integrasjoner, misfornøyde brukere og en migrering som aldri blir helt ferdig. Riktig valg gir derimot bedre kontroll, bedre data og mer tid til kjerneoppgaver.
Innholdsfortegnelse
- Trinn 1, Kartlegg behovene: kravspesifikasjon på én side
- Trinn 2, Prioriter beslutningskriterier (i riktig rekkefølge)
- Regnskapssystem vs ERP-system vs CRM vs BI: hva trenger du?
- Regnskapssystem
- ERP-system
- CRM
- BI / rapportering
- Skybasert vs lokal løsning, hvilke konsekvenser har valget?
- Hvordan beregne kostnad: enkel TCO-modell
- Sjekkliste for integrasjoner og API
- Sikkerhet og samsvar i Norge (GDPR)
- Vendor-evaluering: spørsmål, referanser og SLA
- Pilot, demo og migrering: praktisk testplan
- Endringsledelse, opplæring og måling av suksess
- Rask sjekkliste: hva du må ha på plass før du signerer
- Konkrete next steps: 6–12 ukers beslutningsløp (timeline og ansvar)
- Konklusjon
- Vanlige spørsmål (FAQ)
- Hvordan starter vi prosessen med å velge riktig programvare?
- Hva koster et typisk regnskapssystem eller ERP i praksis (TCO)?
- Skal vi velge skybasert eller lokal løsning?
- Hvor lenge tar en implementering og migrering?
- Hvordan sikrer vi at systemet integreres med eksisterende verktøy (API/integrasjoner)?
- Hva må et regnskapssystem støtte for å fungere i Norge?
- Hvordan unngår vi vendor lock-in?
- Hva slags support og SLA bør vi kreve?
- Hvordan måler vi ROI og effekt etter implementering?
- Kan vi prøve systemet før kjøp – og hva bør vi teste?
Nedenfor får du en praktisk prosess du kan følge i dialog med leverandører – med kravmal, TCO-modell, spørsmål og en plan for demo, pilot og migrering.
Trinn 1, Kartlegg behovene: kravspesifikasjon på én side
Start med å bli enige internt om hva dere faktisk skal løse. Hold det kort. Én side er ofte nok for å komme i gang og lage en fornuftig shortlist. Vil du gå dypere i forarbeidet, se Slik kartlegger du behovene før du velger programvare.
Kopiérbar kravmal (1 side)
- Mål (1–3 stk): Hva skal bli bedre? (f.eks. raskere fakturering, bedre lagerkontroll, mer salgsoppfølging)
- Omfang: Hvilke avdelinger/prosesser er med nå – og hva kommer senere?
- Brukertyper: Antall brukere, roller (økonomi, salg, prosjekt, lager), eksterne (revisor, regnskapsfører)
- Må-krav (ikke-forhandlingsbart):
- Regulatorisk: MVA-rapportering, EHF, ev. a-melding hvis lønn er i scope
- Tilgangsstyring: roller, godkjenning, sporbarhet
- Rapportering: standardrapporter + eksport til BI ved behov
- Bør-krav (prioritert): automasjon, attestering, mobil, prosjekt, time, lager, etc.
- Integrasjoner: kasse, nettbutikk, bank, lønn, CRM, BI (hva, hvorfor, hvor ofte)
- Data og migrering: hvilke historiske data må med (bilag, kunder, varer, ordre, timer)
- Sikkerhet/GDPR: persondata, databehandleravtale, logging, MFA
- Tidslinje: når må dette være i drift, og når kan dere bytte
Praktisk tips: Be hver avdeling beskrive 3–5 “daglige scenarier” (f.eks. “kreditnota + ny faktura”, “ordre til lager og faktura”, “månedsavslutning”). Det er disse som avslører om programvaren passer.
Trinn 2, Prioriter beslutningskriterier (i riktig rekkefølge)
For å unngå å velge på magefølelse, bruk en fast prioritering. Denne rekkefølgen fungerer ofte for SMB:
- Funksjonalitet og prosess-støtte: dekker systemet det dere må få gjort?
- Integrasjoner / API: hvor mye må bygges, og hvor robust er det over tid?
- Brukervennlighet (UX): hvor raskt kommer folk i gang, og hvor mange “omveier” blir det?
- Sikkerhet og samsvar (GDPR): tilgang, logging, databehandleravtale, revisjonsspor
- Skalerbarhet: flere brukere, flere transaksjoner, nye moduler, flere selskaper
- Leverandørstøtte / SLA: oppetid, responstid, onboarding, kompetanse
- Total kostnad (TCO): alt dere faktisk betaler og bruker av tid, ikke bare lisens
Poenget er enkelt: Et “billig” system blir dyrt hvis integrasjoner og drift spiser opp gevinsten.
Regnskapssystem vs ERP-system vs CRM vs BI: hva trenger du?
Mange ender opp med å blande kategorier. Bruk dette som en rask avklaring:
Regnskapssystem
Typisk for små og mellomstore virksomheter. Fokus på faktura, bokføring, MVA, betaling, bilagsflyt og ofte lønn/prosjekt som moduler. Eksempler i markedet inkluderer Visma eAccounting og Tripletex (sjekk selv hva som inngår og hvilke integrasjoner som finnes).
Når det er riktig: Når hovedbehovet er økonomiflyt, rapportering og etterlevelse. Og prosessene ellers er relativt standard.
ERP-system
Mer helhetlig styring av økonomi, innkjøp, lager, logistikk, produksjon og ofte prosjekt. Større påvirkning på prosesser og mer krevende implementering.
Når det er riktig: Når dere har lager/produksjon, mange varelinjer, komplekse innkjøp eller behov for felles masterdata på tvers av avdelinger.
CRM
System for salg og kundedialog. Verdien kommer ofte først når CRM er koblet til økonomi, markedsføring og kundeservice.
Når det er riktig: Når dere mister oppfølging, har lange salgsprosesser, eller trenger struktur på pipeline og aktiviteter.
BI / rapportering
Brukes for innsikt og styring på tvers av systemer. Hvis ledelsen etterspør “én sannhet”, er BI ofte nøkkelen. Et vanlig verktøy er Microsoft Power BI.
Når det er riktig: Når dere har flere datakilder og trenger gode dashboards og analyse, uten å bytte kjernesystem først.
Skybasert vs lokal løsning, hvilke konsekvenser har valget?
Valget påvirker både kostnad, drift og risiko. Vil du ha en mer detaljert vurdering, se Skybasert eller lokalt installert programvare, hva passer din virksomhet?.
Skybasert (cloud) passer ofte når:
- dere vil ha rask oppstart og automatiske oppdateringer
- dere har begrensede IT-ressurser internt
- dere vil betale som abonnement og skalere opp/ned
Lokalt installert (on-prem) kan passe når:
- dere har spesielle krav til nettverk/tilgjengelighet eller integrasjoner i lokalt miljø
- dere har tung tilpasning og egen driftsmodell (ofte større virksomheter)
- dere kan ta ansvar for patching, backup og drift
Viktig avklaring: Sky betyr ikke “mindre sikkert”. Men dere må kreve dokumentasjon på tilgangskontroll, logging, kryptering og databehandleravtale.
Hvordan beregne kostnad: enkel TCO-modell
Pris per bruker per måned er bare én linje. Be om et estimat for total cost of ownership for 3 år, og legg inn egne interne timer. For en mer komplett mal, bruk Hvordan beregne TCO: fra lisens til drift og opplæring.
Enkel TCO-tabell (kopiér til regneark)
| Kostnadselement | Hva du bør ta med | Engang / Årlig |
|---|---|---|
| Lisens/abonnement | brukere, moduler, transaksjoner, selskaper | Årlig |
| Implementering | oppsett, konfig, prosjektledelse | Engang |
| Integrasjoner | etablering, testing, overvåking, endringer | Begge |
| Migrering | eksport/import, datavask, validering | Engang |
| Opplæring | kurs, superbrukere, intern tid | Engang + løpende |
| Drift/forvaltning | admin, tilgangsstyring, rapportvedlikehold | Årlig |
| Tillegg | add-ons, ekstra lagring, supportnivå | Årlig |
| Risiko/avbrudd | nedetid, feil i overgang, dobbel drift | Engang |
Enkel ROI-tanke: Sett opp 3–5 målbare gevinster (timer spart, færre feil, raskere fakturering, bedre lagerpresisjon) og vurder når de realistisk slår inn (typisk etter stabil drift, ikke første uke).
Sjekkliste for integrasjoner og API
Integrasjoner avgjør om systemet blir et “nav” eller bare enda et verktøy.
Vanlige integrasjoner i norske virksomheter
- Bank/betaling, faktura/EHF
- Nettbutikk og kasse (POS)
- Lønn/HR
- CRM/marketing
- BI (f.eks. Power BI)
- Dokumenthåndtering og signering
Sjekk dette med IT/leverandør
- Finnes det API-dokumentasjon som er åpen og oppdatert?
- Støttes webhooks/hendelser, eller må alt hentes periodisk (batch)?
- Hvordan løses autentisering (f.eks. OAuth) og rettigheter per integrasjon?
- Er det rate limits, ekstra kostnader eller begrensninger per transaksjon?
- Hvordan håndteres datamapping (kunder, produkter, kontoplan, MVA-koder)?
- Finnes det testmiljø/sandbox?
- Hvem eier integrasjonen ved feil: dere, partner eller leverandør?
Trenger du en mer teknisk sjekkliste, er det smart å lage en egen integrasjonslogg som del av piloten.
Sikkerhet og samsvar i Norge (GDPR)
Dette bør dere kreve svar på før pilot, ikke etter signering.
Minimum å sjekke
- Databehandleravtale (DPA) og tydelig rollefordeling
- Tilgangsstyring (roller, minst mulig tilgang, MFA der det er relevant)
- Logging og revisjonsspor (hvem gjorde hva, og når)
- Kryptering i transitt og lagring (be om hvordan det er løst)
- Backup og gjenoppretting (RPO/RTO: hvor mye kan dere tape, hvor raskt er dere oppe igjen?)
- Underleverandører og hvor data behandles (viktig for risikovurdering)
Har dere bransjekrav (helse, finans, offentlig), må dette inn i må-krav tidlig.
Vendor-evaluering: spørsmål, referanser og SLA
Bruk disse spørsmålene i demo- og tilbudsfasen. Be om skriftlige svar.
Spør leverandøren om
- SLA og oppetid: Hva garanteres, og hva er kompensasjonen ved brudd?
- Support: åpningstider, responstid per alvorlighetsgrad, norsk support, onboarding
- Veikart: hva kommer de neste 12–18 månedene som påvirker dere?
- Prisstruktur: hva koster moduler, integrasjoner, ekstra miljø, rapportpakker, konsulenttimer?
- Vendor lock-in / exit: hvordan får dere eksportert data i et lesbart format ved bytte?
- Eierskap til data: tydelige vilkår for datauttrekk og sletting
- Referanser: be om 2–3 kunder som ligner dere (størrelse/bransje), og spør konkret om innføring og support
Sjekk internt
- Hvem eier prosessen (produktansvarlig) etter go-live?
- Hvem tar beslutninger ved avvik i prosjektet?
Pilot, demo og migrering: praktisk testplan
En demo viser hva som er mulig. En pilot viser hva som faktisk fungerer hos dere.
Forslag til pilotoppsett (2–4 uker)
- Velg 5–10 brukere og 3–5 kritiske scenarier
- Bruk et lite, men ekte datasett (noen kunder, produkter, bilag, ordre)
- Definer akseptkriterier før dere starter:
- tidsbruk per prosess (før/etter)
- feilrate/avvik
- integrasjon fungerer stabilt (f.eks. ordre → faktura)
- rapporter stemmer mot gamle tall
Migrering: sjekkpunkter
- Avklar hva som må med: masterdata + nødvendig historikk
- Kjør testmigrering tidlig (ikke vent til siste uke)
- Gjør datavask: duplikater, ugyldige felt, gamle MVA-koder
- Planlegg fallback: hva gjør dere hvis noe feiler ved overgang?
- Vurder “dobbel drift” i en kort periode ved høy risiko
Endringsledelse, opplæring og måling av suksess
Mange prosjekter feiler på adopsjon, ikke teknologi.
Tiltak som ofte virker
- Utnevn superbrukere per avdeling
- Lag korte rutiner: “slik gjør vi det her” (1 side per prosess)
- Gi opplæring tett på arbeidshverdagen (ikke bare kurs én dag)
- Mål etter 30/60/90 dager:
- andel som bruker systemet riktig (f.eks. bilagsflyt)
- tid brukt på månedsavslutning
- antall manuelle korrigeringer
Rask sjekkliste: hva du må ha på plass før du signerer
- Kravlisten er godkjent av økonomi, drift og IT
- TCO for 3 år er sammenlignet på samme måte for alle kandidater
- Integrasjoner er avklart (hvem bygger, hvem drifter, hva koster endringer)
- SLA, supportnivå og eskalering er avtalt skriftlig
- Plan for migrering og testmigrering er beskrevet
- Exit-strategi er tydelig (datauttrekk, format, kostnad, tidslinje)
- Opplæringsplan og intern eier etter go-live er definert
Konkrete next steps: 6–12 ukers beslutningsløp (timeline og ansvar)
- Uke 1–2: Krav (1 side), scenarier, interessenter, budsjett-ramme
- Uke 3: Shortlist 3–5 leverandører + innhent skriftlige svar på må-krav
- Uke 4–5: Demo med demo-sjekkliste + referansesamtaler
- Uke 6–8: Pilot/prøveperiode med akseptkriterier og testdata
- Uke 9: TCO-sammenligning + risikovurdering (integrasjon, migrering, drift)
- Uke 10–12: Kontrakt/SLA, implementeringsplan, oppstart
CTA (praktisk): Start med å kopiere kravmalen over til et dokument og be leverandørene svare punktvis. Deretter avtaler du demo og pilot med samme scenarier for alle.
Konklusjon
Hvordan velge riktig programvare for virksomheten blir mye enklere når du låser prosessen: krav først, integrasjoner og sikkerhet tidlig. Og TCO før du lar deg styre av “pris per bruker”. Bruk pilot med egne data, krev skriftlige svar på SLA og exit. Og planlegg migrering som et eget delprosjekt. Da får dere en løsning som faktisk blir brukt – og som tåler vekst.
Vanlige spørsmål (FAQ)
Hvordan starter vi prosessen med å velge riktig programvare?
Start med en kort kravspesifikasjon (mål, må-krav, integrasjoner, tidslinje). Lag så en shortlist og test med demo/pilot basert på deres egne scenarier.
Hva koster et typisk regnskapssystem eller ERP i praksis (TCO)?
Det varierer mye. Poenget er å sammenligne likt: lisens + implementering + integrasjoner + opplæring + drift + tillegg. Be om 3-årig estimat og legg inn interne timer.
Skal vi velge skybasert eller lokal løsning?
Sky passer ofte SMB som vil ha rask oppstart og mindre drift. Lokal løsning kan passe der dere har spesielle krav og en tydelig driftsmodell internt. Sikkerhet må dokumenteres uansett.
Hvor lenge tar en implementering og migrering?
Fra noen uker til flere måneder, avhengig av kompleksitet, datakvalitet og antall integrasjoner. Testmigrering tidlig reduserer risiko og forsinkelser.
Hvordan sikrer vi at systemet integreres med eksisterende verktøy (API/integrasjoner)?
Krev API-dokumentasjon, testmiljø og en konkret integrasjonsplan. Avklar også hvem som har ansvar ved feil og ved endringer i API.
Hva må et regnskapssystem støtte for å fungere i Norge?
For de fleste er dette sentralt: MVA-rapportering, EHF for faktura der det er relevant. Og a-melding hvis lønn er en del av løsningen. Få det inn som må-krav og be om skriftlig bekreftelse.
Hvordan unngår vi vendor lock-in?
Sørg for kontraktsfestet exit: datauttrekk i lesbart format, tidslinje, kostnader og hva som skjer ved oppsigelse. Vurder også integrasjoner som ikke er “låst” til én partner.
Hva slags support og SLA bør vi kreve?
Krev definert oppetid, responstid per alvorlighetsgrad, eskalering. Og tydelige vilkår for vedlikeholdsvinduer. Be også om å se hvordan de håndterer hendelser i praksis.
Hvordan måler vi ROI og effekt etter implementering?
Sett 3–5 KPIer før oppstart (tidsbruk, feil, gjennomløp, rapporteringstid). Mål etter 30/60/90 dager og juster rutiner/opplæring basert på funn.
Kan vi prøve systemet før kjøp – og hva bør vi teste?
Ja, be om prøveperiode eller pilot. Test kritiske scenarier med egne data, minst én integrasjon og et mini-oppsett for rapportering.
