ERP og WMS

Hvorfor ERP- og WMS-integrasjoner feiler – masteroppgaven

To systemer som må snakke sammen, og et prosjekt som ofte ikke går som planlagt. Dette er masteroppgaven min fra 2025 – hva 22 fagfolk og fire konsulenter oppgir som årsakene til at ERP-WMS-integrasjoner feiler, hvilke tiltak de mener virker, og hvorfor det største tallet ikke er teknisk.

Tilbake til episoden Piltaster eller sveip

Dette går vi gjennom

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

Dette går vi gjennom (forts.)

Motsetningen i tallene
Det undersøkelsen ikke kan si

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

Forskjellen er omfang og oppløsning, ikke kvalitet. ERP-et vet at det ligger 400 av en vare på lager; WMS-et vet at de ligger på fire lokasjoner, hvilken som skal plukkes først, og hva som står i veien. Problemet oppstår der de overlapper: begge håndterer beholdning og ordre, men fra ulik vinkel. Går ikke dataene sømløst mellom dem, får du to sannheter om samme beholdning – og den ene styrer innkjøp mens den andre styrer plukking.

Hvordan jeg undersøkte det

Det største tallet er ikke teknisk

Dette er hovedfunnet, og det overrasket meg selv.

Hva respondentene oppgav som årsaker

Tekniske og prosessrelaterte årsaker ble spurt om i to separate flervalgsspørsmål til de samme 22 respondentene, så søylene er satt sammen her for å vise rangeringen – ikke som ett spørsmål. Poenget står likevel: den mest oppgitte årsaken til at en systemintegrasjon feiler, er at ingen hadde bestemt hvordan arbeidet skulle gå.

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.

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 %

Ingen svarte at forsinkelser ikke forekommer. Alle fire informantene i intervjuene hadde også opplevd det selv – noen ganger på grunn av tekniske problemer, andre ganger fordi prosessene ikke var avklart eller opplæringen ikke var gjort før go-live.

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

Involver sluttbrukerne tidlig – 77,3 %Det høyest rangerte tiltaket av alle. De som skal bruke systemet, vet hvordan arbeidet faktisk gjøres.
Grundig forarbeid – 72,7 %En ordentlig forstudie som fastslår kravene før prosjektet starter.
Omfattende pilottesting før go-live – 68,2 %I intervjuene ble det konkretisert: enhetstesting, systemtesting og integrasjonstesting, hver for seg.
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.
Middleware eller integrasjonsplattform – 40,9 %Et mellomlag mellom systemene, i stedet for å koble dem rett sammen.

Legg merke til at bare det siste punktet er teknologi. De fire første er arbeidsmåter. Alle fire informantene var dessuten innom det samme om opplæring: at den behandles som et punkt i prosjektplanen som skal krysses av, og ikke som noe som må vare.

En motsetning verdt å nevne

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

Det undersøkelsen ikke kan si

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

Fire forbehold

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

Tidspunktet er også et forbehold. Dataene ble samlet inn i en periode der mange virksomheter fortsatt håndterte ettervirkningene av pandemien og en rask digitalisering, og det kan ha påvirket hva respondentene så på som problemer. At funnene likevel stemmer med tidligere forskning, og at skjema og intervjuer peker på det samme, er det som gir dem vekt.

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.

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.

Hovedpunkter (forts.)

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.

Hovedpunkter (forts.)

Undersøkelsen har 22 svar og fire intervjuer. Det viser tendenser, ikke tall som kan generaliseres.

Spørsmål episoden svarer på

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?

Spørsmål episoden svarer på (forts.)

Hva er scope creep?
Hva er masterdata, og hvorfor velter det prosjekter?

Kilder

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.

Spørretimen

Les hele saken på