Hjem / sArtikkel / Bygg eller kjøp automatisering? Slik velger du riktig tilnærming for din SMB

Bygg eller kjøp automatisering? Slik velger du riktig tilnærming for din SMB

Automatisering handler sjelden om «ny teknologi». Det handler om mindre manuelt arbeid, færre feil, raskere leveranser og bedre kapasitet uten å ansette like mange. Spørsmålet er bare hvordan dere kommer dit: skal dere bygge en egen løsning, kjøpe en ferdig løsning, eller gjøre en hybrid?

Kontor1 - Bygg eller kjøp automatisering? Slik velger du riktig tilnærming for din SMB
Innholdsfortegnelse

Her er tre raske tommelfingerregler før vi går i detalj:

  1. Hvis dere trenger verdi på under 3 måneder → kjøp (eller hybrid).
  2. Hvis prosessen er en tydelig konkurransefordel og må være unik → bygg (eller hybrid).
  3. Hvis dere mangler kapasitet til drift/vedlikehold → kjøp (SaaS) eller managed service.

Vil dere se hele prosessen for å lykkes med automatisering (trinn, eksempler og pris/ROI)? Se pillar-artikkelen: Automatisering i små bedrifter: 6 trinn, konkrete eksempler og priseksempler.

Kort oversikt over alternativene: bygg, kjøp og hybrid

Bygg (custom) Dere utvikler selv, eller med et konsulenthus, en skreddersydd automatisering. Det kan være alt fra en integrasjon mellom ERP og CRM til en full arbeidsflyt med godkjenning, logging og rapportering.

Kjøp (off-the-shelf) Dere kjøper et produkt, ofte som SaaS (skybasert abonnement). Typisk CRM-automatisering, marketing automation, fakturahåndtering, helpdesk, integrasjonsverktøy (iPaaS) eller RPA-verktøy.

Hybrid Dere kombinerer en kjøpt plattform (for eksempel CRM/ERP/marketing automation) med egne tilpasninger, integrasjoner og regler. I praksis er dette ofte mest realistisk for SMB: dere kjøper «motoren». Og bygger «koblingene» og spesiallogikken.

Sammenligning: bygg vs. kjøp (TCO, tid, kompetanse, drift, SLA, lock-in)

Tabellen under er ment som en rask beslutningsstøtte. Tall varierer mye, så fokuset er på hva som typisk driver kostnad og risiko.

Tema Bygg selv (custom) Kjøp (SaaS/standard)
Startkostnad Ofte høyere (analyse, utvikling, test) Ofte lavere (oppsett/onboarding)
Løpende kostnad (TCO) Drift, feilretting, videreutvikling, hosting Lisens + ev. support + integrasjoner
Tid til verdi Typisk 3–9+ måneder for MVP/1. versjon Typisk 4–12 uker til første effekt
Kompetansebehov Utvikling, test, DevOps/drift, sikkerhet Prosesseier + admin/konfig + integrasjonskompetanse
Vedlikehold Dere eier det (og må vedlikeholde) Leverandør oppdaterer, men dere må følge endringer
SLA/oppsetid Dere må etablere det selv (eller kjøpe drift) Ofte SLA inkludert (varierer)
Tilpasning Maks kontroll, kan støtte «rare» prosesser Tilpasning innenfor rammer/konfig, ellers dyrt
Leverandørlåsning Lavere hvis dere bygger på åpne standarder Kan bli høy (data, workflow, integrasjoner)
Sikkerhet/GDPR Fullt ansvar for design og drift Delt ansvar: dere er behandlingsansvarlig, leverandør databehandler

Beslutningsramme: sjekkliste + enkelt beslutningstre

Sjekkliste med terskler (praktisk)

Svar ja/nei:

  • Må dere være live innen 12 uker? Ja → kjøp/hybrid
  • Har dere unik forretningslogikk som standardverktøy ikke støtter uten «workarounds»? Ja → bygg/hybrid
  • Har dere intern utviklingskapasitet (eller budsjett til å kjøpe den) i minst 6–12 måneder? Nei → kjøp
  • Er prosessen tungt regulert (persondata, helse, finans) eller krever streng datalokasjon? Ofte → bygg/hybrid (men kjøp kan fungere med riktig leverandør)
  • Er integrasjoner den største jobben (ERP/CRM/regnskap), ikke selve skjermen? Ofte → hybrid (kjøp kjerne + bygg integrasjoner)
  • Er volumet lavt/moderat og behovet er «best practice»? Ja → kjøp

Et enkelt beslutningstre (tekst-flow)

  • Start: Hva er viktigst nå?
  • Rask effekt og lav risiko → Kjøp
  • Unik logikk/kundereise som skiller dere → Bygg eller hybrid
  • Deretter: Hvor sitter kompleksiteten?
  • I prosess + skjema → Kjøp passer ofte
  • I integrasjoner + datakvalitet → Hybrid passer ofte
  • Til slutt: Hvem skal drifte?
  • Ikke dere → Kjøp/managed service
  • Dere har kapasitet → Bygg kan være riktig

Typiske SMB-use cases og hva som ofte passer best

Faktura og bilag (regnskap, godkjenning, OCR)

  • Typisk tilnærming: Kjøp eller hybrid
  • Hvorfor: Mange prosesser er standardiserte (mottak, attestasjon, kontering, arkiv).
  • Hybrid når: dere må koble mot flere systemer (prosjekt, ordre, lager) eller har egne godkjenningsregler.
  • Merk: For regnskapsnære prosesser er datakvalitet og kontroll viktig. Se også et norsk perspektiv på automatisering i økonomi hos Mediabooster (ekstern): KI i regnskap og økonomi.

Marketing automation (leads, e-postløp, SMS, scoring)

  • Typisk tilnærming: Kjøp
  • Hvorfor: Verktøyene er laget for dette, og verdien kommer raskt hvis dere har orden på samtykker og segmenter.
  • Fallgruve: Skjulte kostnader i form av innhold, oppsett, datavask og integrasjon mot CRM.

CRM-workflows (oppfølging, pipeline, kundedata)

  • Typisk tilnærming: Kjøp eller hybrid
  • Hvorfor: Standard CRM har ofte automatisering for oppgaver, varsler, ruting og enkle godkjenninger.
  • Hybrid når: dere må koble CRM tett mot ERP/regnskap, eller trenger spesielle regler per kundetype/avtale.

Ordre- og lagerflyt (ordre → plukk → faktura → frakt)

  • Typisk tilnærming: Hybrid eller bygg
  • Hvorfor: Her kommer ofte «spesialregler» (retur, del-leveranser, prosjekt, B2B-priser). Standard kan bli for stivt.
  • Praktisk: Kjøp et ERP/WMS som dekker 80 %, og bygg integrasjoner og unntakslogikk.

Kundeservice (sakshåndtering, chatbot/selvbetjening, ruting)

  • Typisk tilnærming: Kjøp
  • Hvorfor: Ticketing og ruting er modne kategorier, og SLA/oppetid betyr mye.
  • Hybrid når: dere trenger kobling til ordrestatus, reklamasjonssystem eller kundeportal.

Hvordan beregne TCO og ROI (med et enkelt regneeksempel)

TCO (total eierkostnad) blir feil hvis dere bare ser på lisens eller utviklingspris. Ta med:

  • Oppstart: kartlegging, oppsett/utvikling, integrasjoner, test, opplæring
  • Løpende: lisens, drift/hosting, support, videreutvikling, sikkerhetsarbeid, intern tid
  • Skjult/indirekte: datavask, endringsledelse, prosess-eierskap, leverandørstyring

Mini-eksempel (konservative antakelser)

Antakelser:

  • 2 ansatte bruker 5 timer per uke hver på manuelle steg som kan automatiseres (totalt 10 t/uke)
  • Intern timekost (fullt belastet) settes til 800 kr/time (for å ha et rundt, forsiktig estimat)
  • Forventet effekt etter stabilisering: 70 % av tiden spares
  • Kjøpt løsning: oppstart 60 000 kr (oppsett + enkel integrasjon) + lisens 4 000 kr/mnd

Beregning:

  • Årlig tidsbruk i dag: 10 t/uke × 48 uker = 480 t/år
  • Potensiell spart tid: 480 t × 70 % = 336 t/år
  • Verdi av spart tid: 336 t × 800 kr = 268 800 kr/år
  • Kostnad år 1: 60 000 + (4 000 × 12) = 108 000 kr
  • Payback: 108 000 / (268 800 / 12) ≈ 4,8 måneder

Dette er ikke «fasit». Men modellen tvinger dere til å være tydelige på hva som faktisk spares. Og hva dere betaler for drift, lisens og endringer.

KPI-er dere bør måle i en pilot:

  • Tid per sak/ordre/faktura (før/etter)
  • Feilrate og rework
  • Gjennomløpstid (lead time)
  • Brukeradopsjon (hvor ofte folk går rundt systemet)

Tekniske og juridiske vurderinger (integrasjon, dataeierskap, GDPR, sikkerhet)

Integrasjon: ERP, CRM og regnskap avgjør ofte valget

Spør tidlig:

  • Finnes det API (og er det godt nok dokumentert)?
  • Har leverandøren ferdige koblinger mot deres systemer?
  • Hvem eier feilsøking når noe stopper: leverandør, integratør eller dere?

Typiske integrasjoner i norsk SMB:

  • Regnskap/faktura, CRM, nettbutikk, lager, lønn/HR, e-signering, kundeservice.

GDPR og datalagring (norsk kontekst)

Som SMB er dere ofte presset på tid og folk, men ansvaret for persondata forsvinner ikke.

Sjekk spesielt:

  • Dataråderett: kan dere eksportere alle data ved avslutning?
  • Databehandleravtale (DPA): på plass før produksjon
  • Datalokasjon: hvor lagres data (EU/EØS eller utenfor)? Hva betyr det for deres risikovurdering?
  • Sikkerhetsnivå: kryptering, tilgangsstyring, logging, rollebaserte rettigheter
  • Standarder: Har leverandøren relevante revisjoner/rammeverk (for eksempel ISO 27001, hvis aktuelt for dere)

For en enkel definisjon av SMB-begrepet og norsk næringskontekst kan NHO være nyttig (ekstern): Små og mellomstore bedrifter (SMB).

Operasjonell drift og kompetanse: hvem gjør hva etter lansering

Automatisering som «bare virker» er sjelden gratis. Det må eies.

Hvis dere bygger:

  • Roller dere trenger (minst deltid): prosesseier, utvikler(e), test/QA, drift/DevOps, sikkerhetsansvarlig
  • Dere må planlegge for feil, oppdateringer, endringer i API-er og nye behov

Hvis dere kjøper:

  • Dere trenger fortsatt prosesseier og systemansvarlig (admin)
  • Leverandøren tar ofte plattformdrift, men dere eier: konfigurasjon, brukeropplæring, datakvalitet og integrasjoner

Managed service kan være aktuelt hvis dere vil kjøpe drift/forvaltning som en tjeneste. Da betaler dere mer, men slipper mye koordinering internt.

Risikoer og mitigering: leverandørlåsning, teknisk gjeld, kontinuitet

Leverandørlåsning (vendor lock-in)

Kontor2 - Bygg eller kjøp automatisering? Slik velger du riktig tilnærming for din SMB
  • Risiko: dere bygger prosessene «inni» et verktøy som blir dyrt å bytte
  • Tiltak:
  • krev dataeksport og tydelige vilkår for uttrekk
  • bruk åpne standarder og API-er der mulig
  • dokumenter prosesser utenfor leverandørens grensesnitt (slik at dere kan flytte)

Teknisk gjeld (særlig ved bygg eller for mye tilpasning)

  • Risiko: hver endring blir dyr og treg
  • Tiltak:
  • hold første leveranse liten (pilot/MVP)
  • bygg modulært (integrasjoner som kan byttes)
  • sett av fast tid/budsjett til vedlikehold

Kontinuitet

  • Risiko: automatiseringen stopper, og produksjonen stopper med den
  • Tiltak:
  • avklar manuelle nødprosedyrer
  • still krav til backup, logging, overvåkning og varsling
  • avklar SLA og responstid (kjøp) eller vakt/beredskap (bygg)

Implementasjonsroadmap (pilot → utrulling → oppfølging)

Typiske tidsbilder for SMB (grovt):

  • Kjøpt løsning: 4–12 uker til første effekt
  • Egenutviklet MVP: 3–9+ måneder

Faser:

  • Pilot (2–6 uker): én prosess, tydelige KPI-er, ekte data, begrenset brukergruppe
  • Utrulling (4–12 uker): flere team, mer integrasjon, opplæring, rutiner
  • Oppfølging (løpende): overvåkning, forbedringer, kvartalsvis «ROI-sjekk»

Endringsledelse i praksis:

  • utnevn en prosesseier
  • hold opplæring kort og konkret
  • mål faktisk bruk (ikke bare at funksjonen finnes)

Hva du spør leverandører/utviklingsteamet om (RFP-sjekkliste + pilot-KPIer)

RFP-sjekkliste (kortversjon)

  • Hvilke integrasjoner støttes (ERP/CRM/regnskap), og hva krever de?
  • Hva er SLA (oppetid, responstid, supportvinduer)?
  • Hvor lagres data, og hvordan håndteres underleverandører (GDPR/DPA)?
  • Hvordan håndteres tilgangsstyring, logging og revisjonsspor?
  • Hva koster tillegg: brukere, miljøer, API-kall, supportnivå, onboarding?
  • Hvordan ser en exit ut (dataeksport, format, kostnad, tid)?

Pilot-KPIer

  • Tid spart per enhet (sak/ordre/faktura)
  • Feilrate og antall manuelle unntak
  • Gjennomløpstid
  • Brukertilfredshet (enkelt: 1–5)
  • Kostnad per transaksjon før/etter

Oppsummering: når bør dere kjøpe, bygge eller velge hybrid?

Kjøp når:

  • dere trenger rask effekt (uker, ikke måneder)
  • prosessen er standard og «best practice» finnes i markedet
  • dere vil ha SLA, oppdateringer og mindre driftsansvar

Bygg når:

  • prosessen er en kjerne i konkurransefortrinnet deres
  • dere har klare krav som standardverktøy ikke dekker uten omveier
  • dere kan ta ansvar for sikkerhet, drift og videreutvikling

Hybrid når:

  • dere trenger standard plattform, men med flere integrasjoner og noe unik logikk
  • dere vil minimere lock-in ved å eie integrasjonslaget og dataflyten

Neste steg som ofte fungerer:

  • Start med en 1-sides sjekkliste og en enkel ROI-mal (setup + lisens + spart tid).
  • Be om en 30-minutters pilotvurdering fra leverandør eller integratør, og krev en plan med KPI-er før dere signerer.
  • Definer hva som er «godt nok» for en pilot, og bestem på forhånd hva som gir grønt lys for utrulling.

FAQ

Er det billigere å kjøpe enn å bygge for en SMB?

Ofte ja på kort sikt, fordi dere slipper utvikling og får raskere tid til verdi. Over tid kan kjøp bli dyrt hvis lisens, tillegg og tilpasninger vokser. Derfor må dere regne TCO, ikke bare startpris.

Hvordan regner jeg ut TCO for en automatiseringsløsning?

Ta med oppstart (kartlegging, oppsett/utvikling, integrasjon, opplæring) og løpende kostnader (lisens, drift, support, videreutvikling). Legg også inn intern tidsbruk til forvaltning og datakvalitet.

Hvor lang tid tar det å implementere kjøpt løsning kontra egenutviklet?

En kjøpt løsning gir ofte effekt på 4–12 uker. En egenutviklet MVP tar ofte 3–9+ måneder, avhengig av integrasjoner og testbehov.

Hvilke sikkerhets- og personvernansvar har jeg ved kjøp av SaaS?

Dere er normalt behandlingsansvarlig og må sikre lovlig grunnlag, databehandleravtale, tilgangsstyring og rutiner. Leverandøren er databehandler og skal dokumentere sikkerhetstiltak, underleverandører og hvor data lagres.

Hvordan unngår jeg leverandørlåsning?

Krev dataeksport i et brukbart format, avklar exit-prosess i kontrakt. Og unngå å bygge all logikk «inne i» verktøyet hvis dere planlegger å bytte. Eie integrasjonslaget der det er mulig.

Hvilke interne ferdigheter trenger vi for å bygge og drifte egen automatisering?

Minst: prosesseier, utviklingskompetanse, test/QA og noen som tar driftsansvar (overvåkning, feilretting, sikkerhet). Uten dette blir «bygg» fort dyrere enn planlagt.

Når er hybrid (kjøp + tilpasning) best?

Når dere vil ha en standard plattform raskt, men må koble mot flere systemer og har noen få regler som er spesielle for dere. Hybrid gir ofte best balanse mellom tid, kontroll og risiko.

Hvordan tester vi verdi før full utrulling (pilot/MVP)?

Velg én avgrenset prosess med tydelige KPI-er (tid, feilrate, gjennomløpstid). Bruk ekte data. Kjør pilot i noen uker. Bestem på forhånd hva som er «suksess».

Merket:

Legg igjen en kommentar

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