In most manufacturing companies, the ERP and the shop floor live in two different worlds. The system knows the work orders, item codes and book stock levels. The shop floor knows reality: how much actually came off the machine, who took a tool, which batch was scrapped. The link between them is a spreadsheet, a shift log or a supervisor who retypes everything in the evening. Integrating ERP with the shop floor is not about buying an “MES module”. It is about getting a single shop-floor event into the system without retyping. Below: where to start, what to calculate and what not to promise yourself at the outset.
One process first, not “the whole integration”
A “let’s integrate ERP with production” project has no end, because it has no beginning. The reverse order works: pick one flow in which someone currently retypes data by hand, and close it from the event on the shop floor to the entry in the ERP.
Good first candidates:
- Withdrawal of a tool or protective equipment from the tool crib. Today: a notebook or nothing. After: issued against a badge, the stock level in the ERP goes down by itself, the withdrawal has a name attached.
- Machine reporting (good parts, scrap, downtime). Today: a shift sheet retyped in the morning. After: a counter or panel by the machine, entry in the work order.
- Goods receipt into the warehouse. Today: the supplier’s delivery note, then a manual goods received note (PZ) in the system. After: scan, match to the order, PZ in one click.
The selection criterion is simple: the process must be painful (someone loses hours on it every week) and measurable (you can count how much retyping has disappeared).
What you need to know about your ERP before anyone starts coding
Integration starts with the question of how the ERP accepts data. There are three typical routes, and each has a different cost:
- The vendor’s API (REST, SOAP, sometimes a message queue). The cleanest route, but it is sometimes charged separately and does not always cover all documents.
- File import (CSV, XML) dropped into a folder or loaded in the system. Cheap and works almost everywhere, but without an immediate answer as to whether the entry succeeded.
- Direct writes to the database. The quickest to build and the riskiest: it bypasses the system’s validations and can stop working with an ERP update. The vendor usually prohibits it in the service agreement.
Before anyone quotes for the project, you need a written answer from the ERP vendor: by which route documents may be entered, what the API licence costs and who is responsible when an update changes the format. It is one conversation that saves months.
Dictionary: item codes, units, locations
The most common cause of a failed integration is not technical. It is about the dictionary. The ERP knows item code “RĘK-NITR-M-100”; on the shop floor the same thing is called “blue gloves”. The ERP counts in packs of a hundred; the machine issues by the pair. The ERP has one warehouse, “PROD”; the shop floor has twelve cabinets.
Before the integration, you need to settle:
- item code mapping: every item on the shop floor has exactly one ERP item code, with no “similar” ones,
- units and conversion factors: what the ERP counts in, what the shop floor issues in, who is responsible for the conversion factor,
- locations: whether the ERP is to see every cabinet, or one shop-floor warehouse with the breakdown kept on our side.
This is work for someone who knows production, not for a programmer. If this stage is skipped, the integration “works”, but stock levels drift apart and after six months nobody trusts it.
Who is the source of truth
For each field, you have to decide which system is right when the data differ. A typical, proven split:
- The ERP is the source of truth for item codes, prices, suppliers, work orders and book stock levels.
- The shop floor (app, dispensing machine, panel) is the source of truth for events: who, what, when, on which work order.
Events flow from the shop floor to the ERP; dictionaries flow from the ERP to the shop floor. Two-way editing of the same field in both systems is a recipe for conflicts that nobody will resolve.
What about what does not get through
An integration that stops production at the first error will be switched off within a week. You have to design up front what happens when the ERP does not respond or rejects a document:
- the shop-floor event is saved locally and waits in a queue, and the shop floor keeps working,
- once the connection is restored, the queue is sent automatically, in the same order,
- a document rejected by the ERP (e.g. a blocked item code) goes onto a list for manual resolution, with the reason, rather than silently disappearing.
The rule: no silent data loss. Better for the supervisor to see three items to clarify in the morning than to discover after a month that stock levels have been fiction for a week.
Checklist before you start
- one process chosen, with the name of the person who retypes the data today,
- a written answer from the ERP vendor: integration route, cost, responsibility in the event of an update,
- item code, unit and location mapping done with the people on the shop floor,
- a source of truth agreed for each field,
- a queue and a list of rejected documents designed,
- a measure of success: the number of retyped items before and after, counted by the same people.
This is how we run rollouts at ErgoFlow: first an audit of one process, then a pilot on one line or one tool crib, and only then expansion. In our setup, shop-floor events come from dispensing machines, custom applications and panels by the machines, and we describe connecting to ERP, MES and WMS on the Automation page.
This article is for information only. The costs and scope of integration depend on the ERP system and its licence; we give specific figures only after a process audit.
