ERP and WMS

Why ERP–WMS integrations fail – the master's thesis

Two systems that have to talk to each other, and a project that often does not go to plan. This is my master's thesis from 2025 – what 22 practitioners and four consultants report as the causes of ERP–WMS integration failure, which measures they think work, and why the biggest number is not a technical one.

Back to the episode Arrow keys or swipe

What this covers

What ERP and WMS are, and why they have to talk to each other
How the study was carried out
The technical reasons integrations fail
The biggest number is not a technical one
Delays – almost every project
What actually helps
Scope creep

What this covers (cont.)

A contradiction in the numbers
What the study cannot say

The two systems

The terms first, because they get mixed up.

One system for the business, one for the warehouse

ERP

Enterprise Resource Planning

Broad – finance, purchasing, sales, production, HR
Sees stock at an aggregated level
Used for planning and control
Acts as the core other systems connect to

WMS

Warehouse Management System

Narrow and detailed – the warehouse only
Locations, picking, packing, put-away
Real-time tracking, and links to automation
Does what the ERP has only basic functions for

The difference is scope and resolution, not quality. The ERP knows there are 400 units of an item in stock; the WMS knows they sit across four locations, which one to pick first, and what is in the way. The trouble starts where they overlap: both handle stock and orders, but from different angles. If the data does not flow cleanly between them you end up with two truths about the same stock – and one of them drives purchasing while the other drives picking.

How the study was done

The biggest number is not a technical one

This is the main finding, and it surprised me.

What the respondents reported as causes

Technical and process-related causes were asked about in two separate multiple-choice questions put to the same 22 respondents, so the bars are brought together here to show the ranking – not as one question. The point still holds: the most frequently reported cause of a system integration failing is that nobody had settled how the work should actually go.

Two systems cannot agree on a process that has not been decided.

How it showed up in the cases: several of the projects ran without a defined integration strategy. The consequence was not a missing document – it was that testing, training and change management were not prioritised, but handled along the way, as things caught fire. The projects ran from six months to a year, and many of the companies had limited internal IT capacity and depended on external consultants. Several had never done an integration like this before.

The technical side

That does not make the technology innocent. Three problems recurred, and they are connected.

The delays

Here the answers were strikingly consistent.

How often do the projects run late?

Answer	Share
Occasionally – 10–30% of projects	42.9%
Frequently – 30–50% of projects	38.1%
Rarely – around 10% of projects	9.5%
Very frequently – over 60% of projects	9.5%

Nobody answered that delays do not happen. All four interview informants had experienced them too – sometimes because of technical problems, sometimes because the processes had not been clarified or the training had not been done before go-live.

Scope creep – the project growing as it goes – was described as common, and as a direct cause of slippage.

Why it is worse here than elsewhere: when the scope changes in an integration project, it is not just one deliverable that changes. What was tested has to be tested again, the data that was mapped has to be mapped again, and the training that was planned now applies to a different system than the users will get. It is the same mechanism that made unclear scope the second most cited success factor in the study – 59.1 per cent pointed to a clear project scope and requirements.

What actually helps

This is the part I find most useful myself, because it is concrete.

The measures respondents rated highest

Involve end users early – 77.3%The highest rated measure of all. The people who will use the system know how the work is actually done.
Thorough pre-implementation analysis – 72.7%A proper pre-study that settles the requirements before the project starts.
Extensive pilot testing before go-live – 68.2%The interviews made it concrete: unit testing, system testing and integration testing, each in its own right.
Continuous training and support – 68.2%Not one session before go-live, but something that carries on once the system is live.
Middleware or an integration platform – 40.9%A layer between the systems, rather than wiring them straight together.

Note that only the last item is technology. The first four are ways of working. All four informants also touched on the same thing about training: that it gets treated as a line in the project plan to be ticked off, rather than as something that has to last.

A contradiction worth naming

The numbers are not entirely consistent, and that should be said out loud.

What the study cannot say

This is in the thesis, and it belongs here too.

Four reservations

22 responses is fewEnough to show tendencies in the field, not enough to generalise. A larger sample could have weighted things differently.
The ones with opinions answerAnyone with strong experiences, good or bad, is more willing to spend time on a questionnaire.
Four interviews give depth, not breadthOther industries or other countries might have pointed somewhere else.
All of it is self-reportedI observed no projects while they were running. These are practitioners' accounts of what happened.

The timing is a reservation too. The data was collected in a period when many companies were still dealing with the aftermath of the pandemic and a rapid push to digitalise, and that may have shaped what respondents saw as problems. That the findings nonetheless match earlier research, and that the questionnaire and the interviews point the same way, is what gives them weight.

What I take from it

That integration is an organisational problem dressed as a technical one. Middleware and standardised APIs solve real problems, but they do not solve two departments holding different views of how an order should be handled.

Key points

The most frequently reported cause of integration failure is not technical. Poorly defined business processes comes top at 76.2 per cent.
On the technical side data synchronisation leads at 71.4 per cent, followed by incompatible APIs at 66.7 per cent.
A lack of testing before go-live was reported by 66.7 per cent. The fault is then found in production.
Nine out of ten respondents reported delays in at least one project in ten.

Key points (cont.)

The most recommended measure was involving end users early – 77.3 per cent.
Training has to be a continuous process, not a box ticked before go-live.
Several projects ran without a defined integration strategy. Testing, training and change management were then handled as they came up.
Scope creep was described as common, and as a direct cause of delay.

Key points (cont.)

The study has 22 questionnaire responses and four interviews. It shows tendencies, not figures that can be generalised.

Questions this answers

What is the difference between an ERP system and a WMS?
Why do integrations between ERP and WMS fail?
What is the most common technical cause?
What is the most commonly reported cause overall?
How often do these projects run late?
Which measures do practitioners themselves rate highest?

Questions this answers (cont.)

What is scope creep?
What is master data, and why does it derail projects?

Sources

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?». Master's thesis LOG950, MSc in Logistics, Molde University College, 20 May 2025. Supervisor Terje Andersen.

Spørretimen

Read the whole thing at