ERP/MRP shop-floor data collection: the hidden network requirements
ERP/MRP-driven shop-floor data collection fails most often because the underlying LAN/WLAN is treated like office connectivity: designed for coverage and basic access rather than reliability, segmentation, and performance under load and movement.
TL;DR (what to do first)
- Treat shop-floor connectivity as production infrastructure (availability and change control matter)
- Define success in operational terms (downtime, scan success rate, latency tolerance, safety constraints)
- Segment IT/OT and third-party access so faults and threats don’t spread laterally
- Validate with real operational routes and workflows (not only static tests)
The trigger pattern we see
A common sequence:
- An ERP/MRP programme expands from offices into the shop floor (or across multiple sites).
- Data collection grows quickly: mobile devices, printers, machine data, quality systems, cameras, engineering laptops.
- The network “mostly works” — until it doesn’t. The cracks show up as intermittent faults that are hard to reproduce.
From an Ops perspective, this looks like: missed scans, delays, workarounds, and time lost. From an IT perspective, it looks like: escalating tickets, finger-pointing between Wi‑Fi/app/vendor teams, and no single source of truth.
Why “office-grade” networking breaks on the shop floor
Shop-floor data collection raises the bar in four ways:
1) Reliability beats raw speed
A fast network that fails intermittently is worse than a slower one that behaves predictably. Operational systems depend on consistency.
2) Movement changes everything
Roaming, handoff, reflections, metal, and occlusion create a different RF reality. Coverage maps aren’t the same as performance in motion.
3) IT/OT boundaries become real
Once ERP/MRP touches OT-adjacent systems, segmentation and controlled flows become mandatory — for security, resilience, and troubleshooting.
4) Visibility becomes a prerequisite
If you can’t see what’s happening end-to-end, faults will be blamed on “the system” and trust will erode.
A practical first-week diagnostic checklist
[ ] List the operational workflows that must not fail (pick/scan/print, line-side updates, quality checks, maintenance access).
[ ] Identify where movement is involved (routes, choke points, high-bay aisles, cranes, vehicles).
[ ] Confirm what must be segmented (OT systems, vendors, tenants, guest, engineering).
[ ] Check for single points of failure (core/distribution, controllers, uplinks, power).
[ ] Validate with real routes and peak conditions (don’t rely only on static signal checks).
Common pitfalls
- Designing for “coverage” rather than operational performance
- Treating Wi‑Fi issues as “application issues” without correlating roaming/interference behaviour
- Leaving east‑west access open because “it’s on the internal network”
- Making changes without before/after validation evidence
FAQ (AEO)
Do we need to replace everything to make shop-floor data reliable?
Not always. Often the fastest gains come from measurement, targeted remediation, and prioritising change by operational impact.
Is this mainly a Wi‑Fi problem?
Sometimes, but the root cause is usually end-to-end: RF design, client behaviour, VLAN/policy, upstream capacity, and resilience.
What should we ask suppliers to prove?
Ask for evidence tied to your workflows: performance in motion, segmentation design, resilience behaviour, and before/after validation.
How do we avoid over-engineering?
Start with use cases and acceptance criteria, then build only the layers required to meet them reliably.
Next step
For an overview of the architecture patterns behind this, see: Connected Factory.
If you want to sanity-check readiness for your ERP/MRP shop-floor rollout, email solutions@oxspring.com with subject “ERP shop floor” and include your site type, critical workflows, and where issues are showing up.
