Hvorfor ERP- og WMS-integrasjoner feiler – masteroppgaven

Våren 2025 leverte jeg masteroppgave i logistikk ved Høgskolen i Molde. Temaet var systemintegrasjon, og spørsmålet var praktisk: hvorfor går det så ofte galt når et ERP-system og et lagerstyringssystem skal snakke sammen – og hva gjør de som får det til?

Veileder var Terje Andersen. Oppgaven er skrevet på engelsk, og denne episoden er gjennomgangen av hva undersøkelsen faktisk viste.

De to systemene

Begrepene først, for de blandes ofte.

Ett system for virksomheten, ett for lageret

ERP

Enterprise Resource Planning

• Bredt – økonomi, innkjøp, salg, produksjon, personal
• Ser beholdningen på et samlet nivå
• Brukes til planlegging og styring
• Fungerer som kjernen andre systemer kobles til

WMS

Warehouse Management System

• Smalt og detaljert – bare lageret
• Lokasjoner, plukk, pakking, plassering
• Sporing i sanntid, og kobling mot automasjon
• Gjør det ERP-et bare har grunnfunksjoner for

Hvordan jeg undersøkte det

Undersøkelsen kombinerte to kilder. Et digitalt spørreskjema gikk ut gjennom LinkedIn og fagmiljøer for folk som jobber med ERP og WMS, og ga 22 svar. Deretter gjorde jeg fire semistrukturerte intervjuer med en ERP-konsulent, en WMS-konsulent, en løsningsarkitekt og en prosjektleder. Dataene ble samlet inn mellom mars og mai 2025.

Respondentene var erfarne: 45,5 prosent hadde seks til ti år bak seg, 18,2 prosent over ti år. De fleste hadde bakgrunn fra logistikk og lager, men også fra distribusjon, industri, næringsmiddel og varehandel – flere fra mer enn én bransje.

Skjemaet ga bredden. Intervjuene ga dybden, og forklarte hva tallene betydde i praksis.

Det største tallet er ikke teknisk

Dette er hovedfunnet, og det overrasket meg selv.

Hva respondentene oppgav som årsaker

Det er verdt å stoppe ved det. Dette kalles et integrasjonsprosjekt, og diskusjonen handler om API-er og datamodeller. Men det respondentene oftest pekte på, var at forretningsprosessene ikke var definert godt nok før man begynte å koble systemer sammen.

To systemer kan ikke enes om en prosess som ikke er bestemt.

Slik det viste seg i casene: flere av prosjektene ble gjennomført uten en definert integrasjonsstrategi. Konsekvensen var ikke at strategien manglet på papiret – den var at testing, opplæring og endringsledelse ikke ble prioritert, men løst underveis, etter hvert som det brant. Prosjektene varte fra et halvt til ett år, og mange av virksomhetene hadde liten intern IT-kapasitet og var avhengige av eksterne konsulenter. Flere hadde heller ikke gjort en slik integrasjon før.

Det tekniske

Det betyr ikke at teknikken var uskyldig. Tre problemer gikk igjen, og de henger sammen.

Datasynkronisering var den mest oppgitte tekniske årsaken. Uten oppdatering i sanntid blir beholdningstallene feil, ordrebehandlingen treg, og noen må rette opp manuelt – som er nettopp det integrasjonen skulle fjerne.

Inkompatible API-er ble trukket fram særlig der ERP og WMS kom fra ulike leverandører. Manglende standardisering, feil i datautvekslingen, og mer kompleksitet enn prosjektet var planlagt for.

Masterdata ble i intervjuene beskrevet som en grunnleggende årsak – ikke en feil i seg selv, men grunnen til at andre feil oppstår. Er produkt- og kundedataene ufullstendige eller inkonsistente, gjør lageret feil operasjoner, eller ingen.

I tillegg nevnte respondentene versjonsavvik mellom systemene, håndtering av restordrer, transaksjoner som forsvinner, og sikkerhetshull i datautvekslingen.

Forsinkelsene

Her var svarene påfallende samstemte.

Hvor ofte blir prosjektene forsinket?

Svar	Andel
Av og til – 10–30 % av prosjektene	42,9 %
Ofte – 30–50 % av prosjektene	38,1 %
Sjelden – rundt 10 % av prosjektene	9,5 %
Svært ofte – over 60 % av prosjektene	9,5 %

Og én forklaring kom uoppfordret fra flere av informantene:

Scope creep – at omfanget vokser underveis – ble beskrevet som vanlig, og som en direkte årsak til at prosjektene skled.

Hvorfor det er verre her enn ellers: når omfanget endres i et integrasjonsprosjekt, endres ikke bare en leveranse. Det som var testet, må testes igjen, dataene som var kartlagt, må kartlegges igjen, og opplæringen som var planlagt, gjelder nå et annet system enn det brukerne skal få. Det er samme mekanisme som gjør uklart omfang til det nest mest oppgitte suksesskriteriet i undersøkelsen – 59,1 prosent pekte på tydelig definert omfang og kravspesifikasjon.

Hva som faktisk hjelper

Dette er den delen jeg selv synes er mest nyttig, fordi den er konkret.

Tiltakene respondentene mente virket best

1. Involver sluttbrukerne tidlig – 77,3 %Det høyest rangerte tiltaket av alle. De som skal bruke systemet, vet hvordan arbeidet faktisk gjøres.
2. Grundig forarbeid – 72,7 %En ordentlig forstudie som fastslår kravene før prosjektet starter.
3. Omfattende pilottesting før go-live – 68,2 %I intervjuene ble det konkretisert: enhetstesting, systemtesting og integrasjonstesting, hver for seg.
4. Løpende opplæring og støtte – 68,2 %Ikke en økt før go-live, men noe som fortsetter etter at systemet er i drift.
5. Middleware eller integrasjonsplattform – 40,9 %Et mellomlag mellom systemene, i stedet for å koble dem rett sammen.

På spørsmål om hva som er avgjørende for å lykkes, kom et erfarent innføringsteam høyest med 63,6 prosent, tydelig omfang på 59,1 prosent, og dokumenterte, standardiserte integrasjonsprosesser på 40,9 prosent.

En motsetning verdt å nevne

Tallene er ikke helt samstemte, og det bør sies høyt.

I spørreskjemaet var sterk ledelsesstøtte det lavest rangerte suksesskriteriet – bare 18,2 prosent pekte på det. I intervjuene ble manglende engasjement fra ledelsen trukket fram som en reell årsak til svak gjennomføringskraft.

Jeg har ikke grunnlag for å si hvilken av dem som er riktig. En mulig forklaring er at ledelsesstøtte er lett å undervurdere når man krysser av i et skjema, og lett å se når man forteller om et prosjekt som gikk galt. Men det er en tolkning, ikke et funn.

Det undersøkelsen ikke kan si

Dette står i oppgaven, og det hører med her også.

Fire forbehold

1. 22 svar er fåNok til å vise tendenser i feltet, ikke nok til å generalisere. Et større utvalg kunne gitt andre vektinger.
2. De med meninger svarerDen som har sterke erfaringer, godt eller dårlig, er mer villig til å bruke tid på et skjema.
3. Fire intervjuer gir dybde, ikke breddeAndre bransjer eller andre land kunne pekt på noe annet.
4. Alt er selvrapportertJeg observerte ingen prosjekter mens de pågikk. Det er fagfolks beskrivelser av hva som skjedde.

Det jeg tar med meg

At integrasjon er et organisatorisk problem forkledd som et teknisk. Middleware og standardiserte API-er løser reelle problemer, men de løser ikke at to avdelinger har ulik oppfatning av hvordan en ordre skal behandles.

Og at rekkefølgen betyr noe. Nesten alle tiltakene respondentene mente virket, måtte settes i gang før prosjektet startet – forstudien, kravene, brukerne, teststrategien. Det er vanskelig å hente inn igjen et prosjekt som begynte uten dem.

Oppgaven er en undersøkelse av hva fagfolk i feltet oppgir, ikke en måling av prosjekter. Bedrifter, informanter og alt som kunne identifisere deltakerne er anonymisert i oppgaven. Innholdet er generell informasjon, ikke en anbefaling for et konkret prosjekt.

Hovedtemaer

• Hva ERP og WMS er, og hvorfor de må snakke sammen
• Hvordan undersøkelsen ble gjort
• De tekniske årsakene til at integrasjoner feiler
• Det største tallet er ikke teknisk
• Forsinkelser – nesten alle prosjekter
• Hva som faktisk hjelper
• Scope creep
• Motsetningen i tallene
• Det undersøkelsen ikke kan si

Spørsmål episoden besvarer

• Hva er forskjellen på et ERP-system og et WMS?
• Hvorfor feiler integrasjoner mellom ERP og WMS?
• Hva er den vanligste tekniske årsaken?
• Hva er den vanligste årsaken totalt?
• Hvor ofte blir slike prosjekter forsinket?
• Hva mener fagfolk selv er de mest effektive tiltakene?
• Hva er scope creep?
• Hva er masterdata, og hvorfor velter det prosjekter?

Hovedpunkter

• Den mest oppgitte årsaken til at integrasjoner feiler er ikke teknisk. Dårlig definerte forretningsprosesser står øverst med 76,2 prosent.
• På teknisk side topper datasynkronisering med 71,4 prosent, fulgt av inkompatible API-er med 66,7 prosent.
• Manglende testing før go-live ble oppgitt av 66,7 prosent. Feilen oppdages da i produksjon.
• Ni av ti respondenter rapporterte forsinkelser i minst hvert tiende prosjekt.
• Det mest anbefalte tiltaket var å involvere sluttbrukerne tidlig – 77,3 prosent.
• Opplæring må være en løpende prosess, ikke et punkt som krysses av før go-live.
• Flere prosjekter ble gjennomført uten en definert integrasjonsstrategi. Testing, opplæring og endringsledelse ble da løst underveis.
• Scope creep ble beskrevet som vanlig, og som en direkte årsak til forsinkelser.
• Undersøkelsen har 22 svar og fire intervjuer. Det viser tendenser, ikke tall som kan generaliseres.

Kilder og referanser

• Jan Sindre Heltne – «Which technical and process related factors contribute to failures in ERP-WMS integrations, and what strategies can be used to mitigate them?». Masteroppgave LOG950, Master of Science in Logistics, Høgskolen i Molde, 20. mai 2025. Veileder Terje Andersen. På engelsk.