Every manufacturing client I work with in the ₹50–500 crore revenue band arrives with the same symptom. The ERP knows what was ordered, what was invoiced, and what was dispatched. The shopfloor knows what was actually made, how long it took, and where it stalled. The two systems disagree, and the CFO and the plant head argue about inventory every month.
The fix is not another ERP. The fix is building a thin, deliberate layer that captures shopfloor reality and flows it into the system of record without asking operators to double-key data. This post walks through the playbook I use when a mid-market manufacturer asks me to make the shopfloor-to-ERP loop actually work.
Start by deciding what “shopfloor data” you actually need
The biggest mistake I see is teams trying to instrument everything before they have decided what decisions the data will drive. An MES demo is intoxicating — live OEE dashboards, every machine blinking with real-time status, a heatmap of bottlenecks. None of that is useful if your monthly close still takes nine days because production confirmations are handwritten on a traveller card.
Before we touch a sensor or a barcode scanner, I force the team to list the decisions the data must support. For most mid-market plants, the list is surprisingly short:
- Daily: is this shift on plan? Which order slipped, and why?
- Weekly: is my WIP aging anywhere? Where are my scrap and rework hotspots?
- Monthly: is my standard cost still real? What changed in my yield, uptime, and labour minutes per unit?
If a data point does not feed one of those decisions, we do not capture it in phase one. That discipline compresses the scope to three or four shopfloor events worth instrumenting: job start, quantity produced (with reject/rework split), downtime with reason code, and job close. Four events. Everything else is phase two.
Match the capture method to the operator, not the vendor
Once the events are agreed, the next question is how to capture them. This is where vendors show up with a laminated product map and the buying team loses the thread. The right capture method depends almost entirely on who is doing the capturing and what the shopfloor physically looks like.
The three patterns that actually work
- Ruggedized tablet at each workstation, backed by a lightweight web app. Best when operators are literate, the workstations are discrete, and Wi-Fi is reliable. Capture cost is low, operator training is half a day, and the app can enforce validations (you cannot close a job with zero reject count unless you explicitly click “no rejects”).
- Barcode / QR scans on the job traveller. Best when job travellers are already a disciplined artefact and operators prefer scanning over tapping. Works in dirtier environments where tablets die. Pair it with a fixed-position scanner rather than handhelds when you can.
- PLC/machine-level integration via OPC UA or MQTT. Best when uptime and cycle time dominate the decisions and the machines are modern enough to expose the data. This is the only method where “real-time” is genuinely real-time. It is also the most expensive to install and maintain, so I reserve it for the two or three bottleneck machines, not the whole plant.
In most SME plants the right answer is a blend: tablets at assembly and packing stations, scans on the job card, and PLC hooks on the two machines that actually gate throughput. Anyone who sells you one method for the whole plant is selling their product, not your process.
Land the data in ERP without turning ERP into a warehouse
The second trap is dumping every shopfloor event directly into ERP tables. ERPs are transactional systems tuned for financial truth, not time-series sensor data. If you push thousand-row-per-hour machine events into your ERP production table, your month-end close will slow down and your IT team will quietly start deleting history.
The pattern I recommend is a thin operational data store between the shopfloor and the ERP:
- Shopfloor events land in a lightweight store — PostgreSQL, a low-code platform’s data table, or even a well-designed Google Sheet for a single-plant proof of concept.
- Scheduled jobs aggregate raw events into ERP-shaped transactions: one production confirmation per job, one consumption posting per BOM line, one downtime summary per shift.
- The ERP ingests those aggregates via its normal posting APIs. The raw event history stays in the operational store for analytics and audits.
This separation is boring and it works. It keeps the ERP clean, keeps analytics fast, and — critically — means you can switch ERPs in five years without re-engineering the shopfloor layer.
Sequence the rollout so the plant sees value inside ninety days
A shopfloor digitization project that does not show something useful on a dashboard within the first quarter will lose the plant head’s support before it is finished. I sequence these rollouts in three ninety-day arcs:
- First 90 days — one line, one shift, one dashboard. Pick the most observable production line. Instrument job start / qty / reject / downtime / job close. Build a single shift-end dashboard the supervisor actually uses during the morning meeting. Do not touch ERP yet.
- Next 90 days — ERP confirmations and daily close. Wire the aggregated events into ERP production confirmations. Replace the handwritten traveller card with a printed summary from the system. Move daily production close from “tomorrow morning” to “before the supervisor leaves.”
- Final 90 days — scale and analytics. Roll the pattern across the remaining lines. Layer on weekly WIP aging, scrap/rework hotspots, and first-pass yield trends. Only now discuss whether you need a full MES.
That third stage is where most clients discover they do not, in fact, need a full MES. They need the disciplined basics to work.
Where I fit in
I usually come in at the start of this arc as a system audit engagement — three to four weeks to diagnose what data the shopfloor is already producing (most plants produce far more than they realize), what the ERP actually expects, and where the friction lives. From there, teams typically move into a process digitization engagement to build the capture layer and the ERP integration without buying a full MES on day one.
If this describes your plant — ERP and shopfloor disagreeing, month-end arguments about inventory, a vendor shortlist that feels too big to evaluate — let’s talk about it. The hardest part of this work is deciding what not to build. Getting that right in the first ninety days pays for the next three years.