8 Ways Planners Misread Manufacturing Reports (and the Fixes)

The most expensive reporting failures are not missing reports; they are correct numbers read the wrong way, then quoted in a meeting. A capacity figure taken from the approximate report, an OEE showing "n/a" mistaken for a bug, a percent complete that is capped by design. Each of these is EDGEBIC by User Solutions telling the exact truth about something other than what the reader assumed. Here are the eight that come up most, with the symptom, the cause, and the corrected reading.

If you have not met the catalog yet, start with the report overview; for the mechanics of filters and exports, the running and exporting guide covers them.

Mistake 1: Quoting the Approximate Capacity Report

Symptom. Two reports disagree about how loaded a work center is, sometimes by a factor of three.

Cause. Work Center Performance computes available hours as 24 hours times days times instances times efficiency. That formula deliberately ignores shift calendars, weekends, and holidays; it is a fast trend comparison, and the product documentation labels it an approximation. Work Center Utilization computes available hours from the real shift calendars and any per-day capacity overrides.

Fix. Make it a plant rule: capacity decisions use Work Center Utilization, full stop. Performance is for spotting a station whose trend is moving. The department-level version of the authoritative numbers is covered in department capacity analysis.

Mistake 2: Reading an "n/a" as a Broken Report

Symptom. The OEE report shows a Quality column full of "n/a" and no OEE percentage at all.

Cause. Quality is good pieces divided by good plus scrap plus rework, and those counts come from shop-floor kiosk punches. With no punches there is no quality figure, and since OEE multiplies Availability, Performance, and Quality, there is no OEE either. Printing 100% instead would be a fabrication that flatters every machine equally.

Fix. Read Availability and Performance meanwhile, which still compute. To get the full metric, start punching good, scrap, and rework at the kiosk. Two related traps live in the same report: a work center with its instance count left at zero is treated as one instance, and an efficiency factor of zero drives theoretical pieces to zero, which collapses Performance. Set both deliberately. The generic metric is explained in our OEE guide.

Mistake 3: Treating SPI 1.00 as "On Schedule"

Symptom. A job that has not started shows a Schedule Performance Index of exactly 1.00, and someone reports it as on plan.

Cause. SPI is earned value divided by planned value. When planned value is zero (nothing was scheduled to complete by the cut-off), the calculation returns 1.0 rather than dividing by zero.

Fix. Never read SPI without percent done beside it. An SPI of 1.00 with 0% done means "nothing to compare yet". The full arithmetic, including how SPI and CPI move in opposite directions on the same job, is in the on-time reports deep dive.

Mistake 4: Expecting a Job Without a Due Date to Appear as Late

Symptom. A job everyone knows is behind is absent from Late Jobs.

Cause. Late Jobs computes days late as scheduled end minus due date, and skips any job with no due date. Nothing minus nothing cannot be late.

Fix. Audit for orders with blank due dates as a standing data-quality check; they are invisible to every delivery report in the catalog, not just this one. If the due date exists and the job still does not appear, its plan currently beats the date, so look at the On-Time Delivery report's Forecast late rows instead.

Mistake 5: Reconciling Job Hours to the Sum of Station Hours

Symptom. Adding up a job's per-work-center hours produces more than the job's own total, and somebody starts hunting for double-counted rows.

Cause. Parallel work centers log the same wall-clock hours on every parallel machine, because both machines really are occupied. With the primary-hours-only policy enabled in Options, the job-grain reports (Job Progress, Earned Value, Sales Order Progress, Late Jobs, Job Audit, End-Product Actuals) count only the primary path, while per-work-center rows and cost stay full-effort by design.

Fix. Explain the rule once to whoever reconciles the two numbers, and pick which basis each report in your pack uses. A three-hour chain with a parallel sibling on every step is genuinely three job-hours and six machine-hours. Both figures are true.

Mistake 6: Reading a Capped Percentage as "No Overrun"

Symptom. A job that clearly overran shows 100% complete.

Cause. Percent complete in Earned Value is actual over budget, capped at 100. A job burning 110 hours against a 100-hour budget reads 100%.

Fix. Read the columns built for overrun: CPI below 1.0, estimate at completion above the budget, variance at completion negative. A 55-hour actual against a 50-hour budget gives CPI 0.91, EAC 55 hours, and VAC of minus 5. The same discipline applies on the Daily Production report, where adherence percentage is capped at 200: if a row is sitting at the cap, the real over-delivery is larger than it looks.

Mistake 7: Filtering the Grid and Quoting the Header

Symptom. A per-customer on-time percentage that does not match a manual count.

Cause. The header totals on the On-Time Delivery report are computed by the service before any grid-level filtering you apply. Grouping the grid by customer changes the rows you see, not the headline.

Fix. Use the Excel export for per-customer or per-product figures, and treat header numbers as whole-population figures. This is the same discipline that keeps hidden columns out of trouble: hidden columns are not exported at all, so unhide anything a downstream spreadsheet needs before you export.

Mistake 8: Reading a Blank Report as a Quiet Week

Symptom. Daily Production is empty for a week when the floor was busy, or Reschedule History has no rows for an event you remember.

Cause. Two different absences. Daily Production compares planned hours to actual hours, so with no logged hours there is nothing to show; work happening and work recorded are separate events. Reschedule History reads an audit trail that only contains runs made after audit logging shipped, so older history is genuinely not reconstructable.

Fix. For production reports, fix the logging habit rather than the report: log hours from the Gantt right-click or at the kiosk, and the same window populates immediately, since every report queries fresh with nothing cached. For the audit reports, accept the start date and rely on them going forward. When a reschedule surprises you and the trail is thin, the troubleshooting guide works the problem by symptom instead.

The Habit That Prevents All Eight

Every report in EDGEBIC carries a Column Details button, and every documented column explains itself: definition, formula, unit, and three worked example values showing a nominal, a good, and a bad reading. Most of the mistakes above are one click from being impossible, because the entry for SPI says what an SPI of 1.00 means and the entry for percent complete says it is capped. Building the habit of clicking Column Details before quoting a number is the single cheapest quality improvement available in the reporting layer. That mechanism is covered in how to use Column Details, and the terminology traps it prevents are in report terminology mistakes.

The second habit worth adopting: before escalating anything as a scheduler fault, run Scheduler Anomalies. Twenty-two automated checks across seven categories against the current plan usually explain the mystery, and the report is read-only, so running it mid-shift changes nothing.

For the system all of these reports observe, see the complete EDGEBIC guide, and for the metric definitions behind the acronyms, our manufacturing KPI guide. Want a second opinion on numbers you already have? Bring the report and your data to a demo and we will trace each figure to its formula.