The one rule for a useful report
Most shop floors do not lack reports. They have a folder of them, printed weekly, that nobody acts on. The problem is not quantity; it is that each report was built to display data rather than to answer a decision. A production report earns its place only when a specific person makes a specific choice because of it.
So the test for every KPI below is simple: what decision does this change? A live job-card status changes what a supervisor does in the next hour. A consumption-versus-BOM variance changes whether a costing is trusted. A rejection Pareto changes which problem an engineer opens first. Reports that fail this test are noise, however pretty the chart.
Live job-card status
The first question a plant manager asks every morning is the hardest to answer from paper: where is every open job right now? A job card is the shop-floor packet for a work order, and a live job-card status report shows each card's current position — which operation it is on, how much is complete, how much remains, and whether it is held for inspection or material.
The value is that it replaces floor-walking. Instead of a supervisor physically chasing jobs to build a mental picture, the position of every card is visible from the booking the operators already do as they complete operations. That is the difference between managing the floor and reacting to it. See the pillar guide on production management software for how the underlying work-order chain produces this view.
Work-order follow-up and ageing
Live status tells you where a job is; ageing tells you which jobs are in trouble. A work-order follow-up report lists open orders against their due dates and flags how long each has been open, so a planner can see at a glance which orders are late, which are at risk, and which are quietly stalled between operations.
Ageing matters because a late order is rarely late all at once — it drifts, one delayed operation at a time, and without an ageing view the slippage is invisible until the customer calls. A disciplined follow-up report turns a reactive scramble into a managed queue, and it draws directly on the work-order lifecycle states: draft, released, in-progress, completed, closed and short-closed.
| Report / KPI | The question it answers | Who acts on it |
|---|---|---|
| Live job-card status | Where is every job right now? | Shift supervisor |
| WO follow-up & ageing | Which orders are late or at risk? | Production planner |
| Consumption vs BOM | Are we over-consuming material? | Costing / stores |
| Process cost report | What does each operation really cost? | Costing / management |
| Rejection MIS | Where is quality being lost? | Quality engineer |
| Rework yield | How much do we salvage vs scrap? | Quality / management |
Consumption vs BOM variance
Of all the numbers on this list, consumption versus BOM is the one that most directly touches margin. It compares the material actually issued and consumed against a work order with the standard quantity the released Bill of Materials specified. Every unit of positive variance is material paid for with nothing to show for it.
A persistent over-consumption on a part is a diagnostic, not just a cost. It points to scrap that is not being captured, rejection that is quietly consuming replacement material, wrong issues that were never reversed, or a BOM that no longer matches how the part is really built. Because the variance is calculated against the released Bill of Materials, it also keeps the engineering definition honest — a BOM that never matches actual consumption is a BOM that needs an engineering change.
Process cost per operation
A work order's cost is not one number; it is the sum of what each operation on its route contributed. A process-cost report rolls resource and operation cost — from the standard times on the route sheet and the resources each operation consumes — into a cost per step, so management can see where the money actually goes down the route.
This matters most when quoting and when defending margin. If a job is unprofitable, the process-cost breakdown shows whether the loss sits in one expensive operation, in over-long actual times against standard, or in a work center that is simply mispriced. It is the operational half of the picture that BOM costing starts on the material side.
Tired of reports that nobody trusts?
See live job-card status, WO ageing, consumption vs BOM and rejection MIS built from your own bookings — reconciled to stock, in 30 minutes.
Rejection MIS and rework yield
The last pair of reports is where quality meets cost. A rejection MIS is only useful if it is built on rejection captured at source — good and reject WIP at each operation, and line rejection at part and child-part level booked against the work order — with every defect mapped to the work center that produced it. Built that way, it lets a plant Pareto its losses two ways: by defect type and by station. That is what turns "we reject too much" into "operation 30 on the second machine drives 40% of our reject cost."
Rework yield is the natural companion. Once rejected parts enter a controlled rework route, the yield report shows how much was salvaged back to finished goods versus how much was ultimately scrapped. A plant that reworks blindly assumes salvage succeeds; a plant that measures rework yield knows when the salvage effort itself is costing more than the material it recovers.
- Reject rate by defect — which failure mode costs the most.
- Reject rate by work center — which station is losing yield.
- Rework salvage vs scrap — whether the rework loop is worth running.
How Fast Production Software reports it
Fast Production Software produces every report above from the same linked chain the floor already runs, because each report is a view over documents that were captured during execution rather than a spreadsheet compiled after it.
Because production shares one stock ledger with Fast Inventory and Fast Quality and consumes the plan from Fast Planning, these reports reconcile to inventory and inspection rather than contradicting them — the defining advantage of reporting from one engine instead of four exported files.
Frequently asked questions
What are the most important production KPIs?
The KPIs that actually run a shop floor answer a specific management question each: live job-card status (where is every job right now), work-order ageing (which orders are late and by how much), consumption versus BOM (are we using more material than the standard), process cost per operation (what does each step really cost), rejection rate by defect and work center (where is quality lost), and rework yield (how much rejected material we salvage). A KPI that is not tied to a decision is just a number on a dashboard.
What is a daily production report?
A daily production report summarises a shift or day of shop-floor activity: quantity completed against plan per work order, good versus reject at each operation, material issued, finished goods transferred to stock, and any jobs held or short-closed. In a connected system it is a live roll-up of the process-status, WIP and finished-goods bookings the floor already made during the day, so it reconciles to stock rather than contradicting it.
What is consumption vs BOM and why does it matter?
Consumption versus BOM compares the material actually issued and consumed against a work order with the standard quantity the released Bill of Materials called for. A positive variance means the job burned more material than it should have — from scrap, rejection, wrong issue or an out-of-date BOM. It is one of the most direct margin signals a plant has, because every unit of over-consumption is money spent with no product to show for it.
How is rejection reported on the shop floor?
Meaningful rejection reporting captures rejects where they happen — good and reject WIP at each operation, and line rejection at part and child-part level booked against the work order — then maps each defect to the work center that produced it. A rejection MIS built on that data lets a plant Pareto its losses by defect type and by station, so it attacks the biggest recurring cause first instead of reacting to a single end-of-line total.
Do production reports need a separate BI tool?
Not to begin with. If work orders, material issue, WIP and finished-goods transfer are captured as linked documents on one engine, the core reports come straight out of that data. A separate BI or AI layer such as Dhruv AI adds cross-cutting dashboards and plain-English queries on top, but the operational reports that run the floor are a by-product of disciplined execution, not a second project.
