How to Tell When a Crewing Standard Is Wrong: Demonstrated Performance vs. the Number in Your ERP

A line beats its crewing standard while the plant still pays overtime to run it. That single pattern points to one place: the standard, not the crew. Most plants treat the number in the ERP as a fixed fact, something set once during an implementation project and left alone unless someone complains. In practice, that number is a starting assumption about how many people a line needs and how much it should produce per hour. Demonstrated performance, what the crew actually runs shift after shift, is the real answer. When those two numbers disagree, the practical question for a Controller is not who is wrong on the floor. It's which number the plant should be scheduling and paying against.

This matters because crewing standards drive staffing plans, labor budgets, and the overtime a plant approves every week. A standard that's a few years stale doesn't just create a reporting nuisance. It can hide a genuine, recoverable cost on the highest-volume lines in the plant, the ones running every shift, every week, all year. Getting the standard right, and getting it corrected the right way, is a Controller decision, not a floor argument.

When Demonstrated Performance Beats a Crewing Standard

A crewing standard lives in the ERP as an operation standard tied to a resource, a work center or a line, not to any individual person. That distinction is easy to miss and it explains a lot of confusing efficiency data. One user working through this exact issue on an Epicor forum summed up the mechanics plainly: the crux of the issue is that the operation standard is per resource not per person. When a crew reports quantity against that shared standard, individual efficiency numbers can look wrong even when the crew is performing exactly as expected, because the math splits credit across people in a way that doesn't match how the work actually got done.

Demonstrated performance is different. It's the actual, sustained output a crew produces on a specific line, run after run, shift after shift. Many plants are still scheduling against a standard set years before the current product mix, tooling, or crew existed. When the ERP standard assumes a line runs at one rate and the line has reliably run at a lower or higher rate for a long stretch, every plan built on the old number starts wrong before the shift begins. Turning that raw production history into a defensible number is exactly what manufacturing analytics is for: it's what shows a Controller the line's real, sustained rate instead of the rate someone assumed years ago. The crew then gets blamed for a gap that the standard created, not a gap they created.

That's the core comparison a Controller needs to make: not this crew against that crew, but the number in the ERP against what the line has actually demonstrated it can do.

Confirming the Standard Is Structurally Wrong, Not Mix Driven

Before changing anything, confirm the gap is structural. A single strong shift, a favorable product mix, or a lucky batch of easy-to-run SKUs can make a line look like it's beating standard when the real explanation is temporary. The check is straightforward: does the gap hold across multiple runs, multiple shifts, and multiple SKUs on the same line, or does it only show up under one specific condition? If a crew of eleven consistently outperforms a fourteen-person standard on Tuesdays running the high-volume SKU but not on Fridays running a low-volume specialty item, that's a mix effect, not a standard error. The standard may still be correct for the harder mix and simply generous for the easy one.

A second check is whether the reported numbers are trustworthy in the first place. Crews sometimes normalize their own reporting by manually splitting a shared job's quantity across each person before entering it into the system, which smooths out individual efficiency figures but can mask what's really happening at the crew level. Whether burden hours get split or duplicated across a crew also depends on a configuration setting most plants never revisit, so it's worth confirming the resource group setup before concluding the standard itself is the problem.

The last check is the one plants skip most often: has anyone actually looked? Standards drift quietly. Wisys, a manufacturing analytics resource, put it directly: if actual hours consistently exceed plan but no one catches it during execution, the underlying standard never gets questioned. The organization just absorbs the variance as noise, quarter after quarter, until it's large enough to matter and nobody remembers why the number was set where it was. If the gap holds across runs, shifts, and SKUs, and the reporting mechanics check out, the standard is the structural problem.

The Dollar Cost of a Stale Crewing Standard on High-Runner Lines

Here's what a stale standard costs when it sits on a high-runner line, the kind that runs every shift and carries the plant's volume. Say three high-runner lines are each staffed to a fourteen-person crewing standard in the ERP, but demonstrated performance on all three has held steady at eleven people for months. That's three extra people scheduled per line, per shift, across lines that never stop running. Multiply that gap across every shift in a year and the total overstaffing cost on those three lines alone lands at roughly $350,000 a year, spread quietly across payroll rather than showing up as a single flagged line-item anywhere.

That number is large because labor is a large share of total production cost to begin with. Wisys notes that labor typically runs 30 to 50 percent of total production cost in manufacturing, so a staffing gap that looks modest on any single shift compounds fast once it repeats across a full year of shifts on lines that run constantly. A few extra people per shift never get costed out on their own; the spend just disappears into total plant labor.

That's the trap with stale crewing standards on high-runner lines specifically. The cost doesn't announce itself. It never shows up as a single variance a Controller can point to in a monthly close. It only becomes visible once someone totals the gap between the ERP standard and demonstrated performance across every high-runner line and turns that gap into dollars.

Overtime as a Signal the Standard Is Wrong

Here's the pattern worth watching for specifically: a line beats its own crewing standard on output, and the plant is still paying overtime to staff it. That combination is the clearest available signal that the standard, not the crew, is the source of the error. If the crew were actually understaffed relative to real demand, output would lag, not beat, the standard. Beating the standard while still absorbing overtime means the standard is asking for more people than the line has ever needed to hit its numbers.

Most plants treat overtime on a line like that as an unavoidable cost of doing business, something absorbed every period without much scrutiny because the line is hitting its numbers anyway. Once a Controller sees that the standard itself is off, that overtime stops being unavoidable and becomes a controllable decision. The plant can correct the standard, adjust the scheduled crew size to match demonstrated performance, and recover the overtime spend that the old number had been quietly generating.

The risk in reading this pattern as a people problem instead of a standards problem is that the same overtime recurs every cycle. A line running over standard can trace back to several different causes: a training issue, a tooling problem, a scheduling inefficiency, or a material delay on a specific run. Without a clear read on which cause is actually in play, a Controller is guessing, and operational reporting with drilldowns is what turns that guess into a specific, traceable cause instead of a hunch. Beating standard while paying overtime, held consistently across shifts, points at the standard itself, not at any one of those one-off causes.

When the Standard Is Actually Right

Not every gap between plan and actual means the standard is wrong. A work center running well over standard on a given run could be a training issue with a newer crew member, a tooling problem slowing the line down, a scheduling inefficiency that put the wrong sequence of jobs on the line, or a material delay that stalled output through no fault of the standard or the crew. Each of those causes needs a different fix: retraining, maintenance, resequencing, or a supplier conversation, not a rewritten crewing standard. None of them means the crewing number in the ERP needs to change, and treating them as if they do just swaps one wrong number for another. The kind of production planning and scheduling that keeps plan and actuals tied together shift by shift is what makes it possible to tell these causes apart before one gets mistaken for a stale standard.

The discipline here is not correcting a standard off a single anomalous shift or an unverified cause. A bad week caused by a tooling failure looks identical, on the surface, to a genuinely stale standard, if all a Controller has is one week of data. The same check from earlier applies in reverse: confirm the cause before touching the number. What real time production monitoring adds here is the ability to catch a one-time cause while it's still happening on the floor, rather than reconstructing it from an end-of-shift report days later. If the variance traces back to a fixable, one-time event rather than a sustained pattern across multiple runs and shifts, the standard was never the problem, and changing it would just introduce a new error in the other direction.

Pushing an Approved Change Back to the ERP

Once demonstrated performance is confirmed as a structural gap rather than mix, noise, or a one-time cause, the correction has a specific path. The gap between the ERP standard and demonstrated performance gets surfaced in dollars, not just units or hours, so the Controller is looking at what the stale number is actually costing the plant on an annualized basis. That's the number that turns a floor observation into a finance decision, and it's the same gap that the promise of the ERP was supposed to close automatically but usually leaves for Finance to reconcile by hand.

From there, the Controller reviews the recommended standard and approves the change. This is a recommendation, not an automatic override: a platform like Jetson can recommend the corrected crewing standard based on demonstrated performance, but it does not set the schedule or push a change through on its own. The Controller retains approval authority over any change to the number the plant schedules and pays against.

Once approved, the corrected standard gets pushed back into the ERP, so future plans schedule against demonstrated performance instead of the old, stale number. That closes the loop: the ERP stops generating staffing plans built on a number that hasn't matched the floor in years, and every future schedule reflects production planning and scheduling that's tied to what the line actually does rather than what a stale standard assumed. The Controller has a documented, approved basis for the change rather than an informal adjustment nobody can trace back to a decision. The next time a high-runner line beats its standard while paying overtime, that's the moment to run this same check again.

‍