# Systemutvikling og integrasjoner: når bør bedriften bygge noe eget?

> Når lønner det seg å bygge eget system eller koble sammen verktøyene dere har? Se beslutningsmatrise, CRM-eksempel og krav til en stabil integrasjon.

Av Media Access. Publisert: 2026-09-06. Oppdatert: 2026-09-06.

Original: [Systemutvikling og integrasjoner: når bør bedriften bygge noe eget?](https://mediaaccess.no/aktuelt/systemutvikling-og-integrasjoner/)

Behovet for systemutvikling viser seg ofte som en arbeidsoppgave noen gjentar hver dag: kopiere en forespørsel til CRM, sjekke en ordre i flere systemer eller rette feil i et regneark. Før dere bygger noe nytt, bør dere finne ut hvorfor oppgaven finnes.

En forbedring kan være bedre oppsett av et eksisterende verktøy, en integrasjon mellom to systemer eller en skreddersydd løsning. Denne guiden gir deg et grunnlag for å velge, avgrense en første leveranse og stille konkrete spørsmål til et utviklingsbyrå.

## Dette får du svar på

- Kartlegg arbeidsflyten og unntakene før dere velger teknologi.
- Sammenlign standardløsning, integrasjon og egen utvikling på samme oppgave.
- Bestill feilhåndtering, eierskap og overvåking som en del av løsningen.

## Start med én arbeidsflyt

Velg en oppgave som både forekommer ofte og har et tydelig sluttpunkt. Beskriv hvem som gjør hva, hvilke opplysninger som brukes, og hvor informasjonen kommer fra. Noter også venting og manuelle kontroller. Et skjema på nettsiden er bare starten dersom en ansatt fortsatt må kopiere alt videre før noen kan svare kunden.

Tell forekomsten i en representativ periode. Mål hvor lang tid de ulike stegene tar, og noter hvilke feil som krever ekstra arbeid. Ikke regn all tid som en mulig besparelse; noen vurderinger må fortsatt gjøres av et menneske.

Ta med unntakene: en eksisterende kunde sender en ny forespørsel, et felt mangler, eller en ordre endres etter registrering. Disse situasjonene avgjør ofte hvor enkel løsningen egentlig kan bli.

## Velg mellom konfigurering, integrasjon og utvikling

Undersøk først om systemene dere allerede betaler for, kan løse oppgaven. Deretter vurderer dere om en ferdig kobling eller en avgrenset integrasjon er tilstrekkelig. Egen systemutvikling er mest interessant når en viktig arbeidsflyt ikke dekkes på en fornuftig måte av alternativene.

Be om en demonstrasjon av samme oppgave i hvert alternativ. En funksjonsliste kan skjule forskjellen mellom at noe er mulig og at ansatte faktisk får gjort det uten omveier. Vurder også hvordan løsningen kan endres og hvem som skal holde den i gang.

Beslutningsmatrise for en konkret arbeidsoppgave

| Alternativ | Passer når | Undersøk |
| --- | --- | --- |
| Konfigurere eksisterende verktøy | Behovet allerede dekkes av tilgjengelige funksjoner. | Tilganger, arbeidsflyt, opplæring og begrensninger. |
| Kjøpe standardløsning | Oppgaven er vanlig og produktet dekker viktige krav. | Abonnement, eksport, integrasjoner og leverandøravhengighet. |
| Koble sammen systemer | Verktøyene fungerer, men data flyttes manuelt. | API-tilgang, felt, feilretting og ansvar for koblingen. |
| Bygge en egen løsning | Arbeidsflyten har særskilte krav med tydelig verdi. | Utvikling, drift, dokumentasjon og langsiktig eierskap. |

## Eksempel: fra kontaktskjema til CRM

Tenk deg en bedrift som mottar tilbudsforespørsler via nettsiden. En integrasjon kan overføre nødvendige opplysninger til CRM, opprette en salgsoppgave og varsle riktig team. Dette er et illustrerende løsningsforslag, ikke en beskrivelse av en bestemt kundeleveranse.

Start med å bestemme hvilket system som eier hvilke data. Kontaktinformasjonen kan komme fra skjemaet, mens kundestatus skal vedlikeholdes i CRM. En ny innsending bør ikke overskrive selgerens vurdering uten at det er en bevisst regel.

Skillet mellom kontakt og forespørsel er viktig. Samme person kan sende to reelle henvendelser om forskjellige behov. En løsning som fjerner alt med samme e-postadresse som duplikat, kan derfor miste informasjon.

Forslag til felter og regler i en CRM-flyt

| Opplysning | Formål | Regel som må avklares |
| --- | --- | --- |
| Kontaktinformasjon | Gjøre det mulig å svare. | Hvilke felter trengs, og hvordan valideres de? |
| Tjeneste eller behov | Fordele forespørselen. | Hvem mottar hver type henvendelse? |
| Innsendings-ID | Skille hendelser og spore behandling. | Samme innsending skal ikke opprette oppgaven på nytt. |
| Kildeside | Forstå hva kunden tok kontakt om. | Overfør avtalt sideinformasjon, uten unødvendige fritekstdata. |
| Kundestatus | Styre oppfølging i salget. | Hvilket system og hvilken rolle kan endre status? |

## Bestill hva som skjer når noe feiler

En integrasjon må kunne håndtere at et mottakersystem ikke svarer, at tilganger utløper, eller at en melding blir sendt flere ganger. Avtal hvilke feil som skal prøves igjen, hvor de vises, og hvem som varsles. En e-post som bare sier «feil» gir dårlig grunnlag for oppfølging.

AWS beskriver idempotens som et prinsipp som lar en gjentatt forespørsel få samme effekt som én behandling. For en CRM-flyt kan en unik innsendings-ID brukes til å unngå at et nytt leveringsforsøk lager den samme salgsoppgaven flere ganger.

Stripe er et konkret eksempel på en leverandør som dokumenterer både dupliserte webhook-hendelser og at hendelser ikke garanteres levert i rekkefølge. Poenget ved innkjøp er å be utvikleren kontrollere den faktiske dokumentasjonen for hvert system dere skal koble til.

Kilde: [AWS Well-Architected: Make mutating operations idempotent](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_idempotent.html)

Kilde: [Stripe: webhook-levering og håndtering av duplikater](https://docs.stripe.com/webhooks)

## Lag en liten første leveranse med tydelig test

Avgrens første versjon til én flyt som gir verdi alene. For eksempel kan dere overføre forespørsler og opprette oppgaver før dere bygger automatisk tilbudsproduksjon. Det gjør det lettere å kontrollere datakvalitet og få tilbakemelding fra dem som skal bruke systemet.

Test med avtalte testdata, og dokumenter forventet resultat. En vellykket normalinnsending er bare ett scenario. Kontroller også gjentatt levering, manglende informasjon, midlertidig feil og en eksisterende kontakt med et nytt behov.

Før dere øker bruken, bør noen kunne finne igjen en konkret test fra start til slutt. Bruk en referanse som kan spores mellom systemene, og unngå å lagre mer personinformasjon i logger enn dere trenger for å forstå feilen.

- Normal flyt oppretter riktig informasjon hos riktig mottaker.
- Gjentatt levering av samme hendelse gir ikke en ekstra oppgave.
- En feil blir synlig og har en navngitt ansvarlig.
- En ny forespørsel fra eksisterende kontakt blir bevart.
- Tilganger og dokumentasjon kan overleveres til bedriften.

## Avklar hvem som eier løsningen etterpå

Et prosjekt er ikke ferdig planlagt før drift og endringer har en eier. Avklar hvor løsningen kjører, hvem som betaler for nødvendige tjenester, hvem som kan endre tilganger, og hvordan dere får hjelp hvis data slutter å flyte.

Be også om en enkel oversikt over systemer, koblinger og forutsetninger. Når et CRM bytter et feltnavn eller en leverandør endrer et grensesnitt, bør det være mulig å finne ut hva som kan påvirkes. God dokumentasjon gjør videreutvikling lettere å bestille og reduserer avhengigheten av én person.

## Spørsmål og svar

### Hva er forskjellen på systemutvikling og en integrasjon?

Systemutvikling lager eller endrer funksjonalitet i en programvareløsning. En integrasjon kobler sammen systemer slik at de kan utveksle informasjon eller utløse handlinger. Et prosjekt kan inneholde begge deler.

### Kan vi integrere nettsiden med CRM-systemet vi har?

Det må undersøkes mot det konkrete systemet, abonnementet og tilgjengelige grensesnitt. Beskriv hvilke opplysninger som skal overføres, hvilken vei de skal gå og hva som skal skje etter mottak.

### Hvordan vurderer vi om automatisering er verdt investeringen?

Kartlegg dagens tidsbruk, feil og forsinkelser. Sammenlign dette med etablering, drift og forventet vedlikehold. Ta også hensyn til om ansatte faktisk kan bruke tiden på andre verdifulle oppgaver.

## Kilder og videre lesning

- [AWS Well-Architected: Make mutating operations idempotent](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_idempotent.html)
- [Stripe: webhook-levering og håndtering av duplikater](https://docs.stripe.com/webhooks)

## Les videre

- [Webutvikling for bedrifter: fra behov til en nettside som fungerer](https://mediaaccess.no/aktuelt/webutvikling-for-bedrifter/index.md)
- [Hva koster en nettside? Slik vurderer du pris og totalkostnad](https://mediaaccess.no/aktuelt/hva-koster-en-nettside/index.md)
- [Slik bygger du en landingsside for relevante henvendelser](https://mediaaccess.no/aktuelt/landingsside-som-gir-henvendelser/index.md)

[Diskuter integrasjoner og utviklingsbehov](https://mediaaccess.no/kontakt/)