Why your production floor and your ERP tell different stories

The ERP records what was booked. The floor records what actually happened. In most manufacturing plants, closing that gap requires a morning stand-up, a clipboard, and a phone call to the supervisor. Here is what the gap costs, in decision lag, optimistic OEE, and schedules built on capacity assumptions that stopped being true years ago, and what a production board changes.

There is a number in your ERP that says how many units came off the line yesterday. There is a number on the floor, in the operator's shift log, or the supervisor's clipboard, or the quality hold bay, that says something different. If you ask the production manager and the operations director to each give you today's output figure, they will often give you two different answers with equal confidence.

This is not a technology failure. Both numbers are, in their own way, correct. The ERP records what was booked, finished goods receipts, work order completions, material issues. The floor records what actually happened, including the half-hour line stoppage that never made it into the system because the operator was busy getting the line running again, and the 14 units pulled for quality re-inspection that are still sitting in a hold location rather than counted against the order.

The gap between those two numbers is where production management lives. And in most manufacturing businesses we talk to, that gap is managed manually: a morning meeting, a shift handover sheet, a spreadsheet someone maintains, a phone call to the floor supervisor before the 9am stand-up.

What the manual loop costs

The stand-up is the most visible cost. Fifteen minutes of production leadership time, every morning, establishing the starting position, what did we actually make yesterday, where are we against target, what is on hold, what did we lose and why. In a 250-person plant with eight people in that room, that is two hours of senior time per day to answer questions that the data already knows.

That is the visible cost. The invisible costs are larger.

Decision lag. A line goes down at 10am. The downtime reason is logged by the operator, or it is not logged, because the operator is focused on getting the line back up. Either way, the maintenance coordinator does not see it aggregated until the afternoon report, or the morning stand-up the next day. A pattern, a specific machine failing on a specific shift, or a material quality issue causing intermittent stops, takes days or weeks to become visible in the aggregate data. By the time someone notices, it has run for long enough to affect a delivery commitment.

OEE reported, not real. Overall Equipment Effectiveness is the number every operations director wants. Most plants have it on a dashboard somewhere. Most of the time, it is calculated from the previous shift's data, using planned run time from the schedule and actual output from the ERP booking. What it does not include: unplanned downtime that was not logged, speed losses that show up as slightly low output rather than a discrete stoppage, quality losses that are in the hold bay rather than formally rejected. The number looks plausible. It is also consistently optimistic by five to fifteen percentage points, depending on how rigorously the plant logs.

Schedule assumptions that do not reflect actual capacity. The production scheduler is working from a capacity model that says a line runs at a certain rate per shift. That rate is derived from design capacity, adjusted downward for a utilisation assumption that was set when the plant was commissioned and has not been formally revisited since. If the actual average rate has drifted, because of product mix change, aging equipment, or a material specification that changed, the schedule is being built on a number that is no longer accurate. Orders get committed on the basis of that schedule. The shortfall shows up at despatch.

What the data actually looks like

Most plants have more data than they use. The ERP has work order completions, material issues, and finished goods receipts. The MES or SCADA system, if there is one, has machine signals: cycle counts, fault codes, speed data. The quality system has inspection results, hold records, and rejection reasons. The maintenance system has work orders, planned and unplanned, with downtime reason and duration.

The problem is that these systems do not talk to each other in any meaningful operational sense. The ERP does not know the machine is running slow. The maintenance system does not update the schedule. The quality hold bay is invisible to the throughput calculation until the units are formally dispositioned, which might be hours or days after they were pulled.

The result is that operational decisions, when to call in overtime, whether to expedite a material delivery, whether to resequence orders, whether to escalate a recurring fault, are made from a combination of yesterday's ERP report and whatever the supervisor said in the morning meeting. The data needed to make those decisions well exists. It just requires someone to manually assemble it from four systems before they can use it.

What a production board changes

We build boards that connect these sources into a single operational view, updated as frequently as the data allows, hourly from the ERP, near- real-time from machine signals where those are accessible, and daily from quality and maintenance systems where they are not.

The tiles we build most often for production ops:

Actual vs target output, by line and shift. Not the ERP booking at end of day, the running count through the shift, compared against the scheduled rate. If a line is running at 87% of target at 11am, the floor supervisor and the production manager see it at 11am, not the following morning. The gap between booked output and scheduled output is visible before it becomes a delivery problem.

Downtime by reason, accumulated in real time. Every stoppage logged, by the operator, the MES, or both, visible as it accumulates. The tile that turns a pattern into a fact: not "the line seems to go down a lot on night shift" but "unplanned downtime on Line 3 has averaged 47 minutes per shift over the last 14 nights, 34 of which is attributed to a single fault code." That is a maintenance conversation, not a production conversation. The board surfaces it early enough to have it.

Quality hold by order and SKU. Units currently in the hold bay, linked to the orders they were pulled from, with the hold reason and the time they have been waiting for disposition. The tile that connects the quality team's world to the production manager's world: this order is short by 22 units because 22 are in hold, and they have been there for six hours, and here is why.

Schedule attainment, week to date. Actual completions versus scheduled completions, by order, rolling forward through the week. Not the ERP's view of what is open, a direct comparison of what was planned and what has actually happened. The tile that answers "are we going to hit this week's dispatch targets?" with something other than a phone call to the floor supervisor.

WIP position by stage. Where material is in the process right now, in raw stores, at each production stage, in quality hold, in finished goods. Not a transaction history: a position. The question "where is that order?" answered from one screen rather than from a combination of ERP transactions and a walk around the warehouse.

What actually changes

The morning stand-up stops being an information-gathering exercise and starts being a decision-making one. The production manager walks in having already seen yesterday's output by line, the downtime summary, what is in hold, and where the week stands against target. The fifteen-minute information-gathering loop shrinks to five minutes of confirmation, and the remaining time is spent on the decisions only the team in that room can make.

The patterns that required weeks of manual data collection to spot become visible in days. A machine that is causing repeated short stoppages shows up in the downtime tile before it causes a delivery miss. A quality issue that is pulling 3% of a SKU into hold shows up in the quality hold tile before it affects the week's schedule attainment.

The schedule becomes more honest. When the board shows that a line's actual average throughput over the past four weeks is 91% of the planned rate, not because of exceptional events, but as a baseline, the production scheduler can update the capacity model. Orders get committed on the basis of what the plant can actually do, not what it was designed to do.

What we need to build it

The build depends on what data sources are accessible. The minimum viable version requires the ERP, work orders, completions, material movements, and either a daily export from the quality and maintenance systems or a manual entry process that feeds the board directly.

The most useful version adds machine-level data: either from a MES or SCADA system via API, or from a simpler source like operator-entered counts on a tablet at line-end. The gap between a board that shows output at end-of-shift and one that shows it in real time is significant for decision-making, but either version is better than the morning report.

The discovery call covers which systems are in place, what data they hold, and how it is currently accessed. We have built on SAP, Dynamics, Epicor, Exact, and bespoke manufacturing systems. The integration method varies; the board structure is usually similar.

Build time is seven days. If machine-level data integration is in scope, the discovery and data-mapping work takes longer, we flag that upfront rather than at day five.