How to build a production statistics table: definitions, sources and cross-checks
How to build a production statistics table starts with knowing which table you are building. A ledger, a statistics table and an analysis are three different artefacts: the ledger says what happened, the statistics table says how much happened over a period, the analysis says why. Mix them and the sheets get wider while the conclusions management asked for never appear.
Separate the three tables first
A ledger is a stream: one fact per row, in time order, stable fields, no aggregation. Daily production reports, material issue records and put-away notes live here.
A statistics table is a cross-section: one metric per column, aggregated by day, week or month, with every figure traceable to rows in the ledger. Its purpose is to support management action — output trend, yield movement, share of downtime.
An analysis explains: comparison, decomposition, attribution. It is usually one-off; once the conclusion is drawn it does not need a daily refresh.
Decide which question the table answers before deciding which kind it is. Most plants can build tables; what they get wrong is using a ledger layout for statistics and a statistics layout for analysis, so none of the three layers works.
Define three things
Conflicting numbers almost always trace back here. For every metric, three sentences must exist:
- Definition — what is counted. Is "output" the reported completion, the put-away quantity, or both added together?
- Scope and calculation — does it include rework and trial production; is the defect rate divided by input or by inspected units?
- Source — which document, which system, which field, and who maintains it.
Put these into a metric dictionary on the first page of the table. New staff follow it, and definitions do not leave with the person who wrote them. iResearch's White Paper on Enterprise Data Governance in China 2024, published in July 2024, groups manufacturing problems into silos, inconsistent standards and poor quality; inconsistent standards sit in the middle because they are invisible and reproduce the discrepancy at every roll-up.
The minimum structure
A usable statistics table needs at least five things:
- Period — day, week or month with explicit start and end, never a relative word such as "this month" as the field value.
- Metric — one metric per row, not three in one row separated by headers.
- Value with unit — pieces, units, kilograms, hours, yuan.
- Source document — which documents this figure was aggregated from, traceable back.
- Owner — who is answerable for the number.
Simple as it looks, the last two are what most untrusted tables are missing. Without source and owner, a number is just a number: it cannot carry a decision and cannot be attributed when opinions differ.
Wording four common metrics
| Metric | Suggested definition | Common wrong version |
|---|---|---|
| Output | Reported completions in the period, attributed by order and operation | Using put-away as output, which trails the floor by one to two days |
| Yield | Good units divided by inspected units; re-inspected rework not counted as good in the period | Dividing by input, so reworked parts get counted twice |
| Labour hours | Direct production hours, excluding waiting for material, inspection and meetings | Including waiting time, which inflates labour cost and distorts efficiency |
| Downtime rate | Downtime divided by planned running time, reasons in fixed categories | Dividing by calendar time, so weekends count as available capacity |
The right-hand column is not hypothetical; these are the most frequent sources of month-end difference. Writing them into the dictionary removes a good share of reconciliation work.
Aggregate upwards, never allocate downwards
The correct order is to aggregate from documents upward, not to split a total downward. Documents are facts; totals are artefacts. Start from a total and force the detail to match, and discrepancies get spread evenly until nobody can see where they began.
So fix the smallest unit of fact — one job report, one material issue note, one put-away record — and aggregate those by order, operation and period. Write the aggregation rule as a formula rather than recalculating it by hand. A fixed rule can be repeated next month, which is what makes figures comparable.
Cross-check in two directions
A finished statistics table gets summed at least twice: across metrics to the row total, and across periods to the cumulative figure. Both balancing only proves the arithmetic, not the definitions.
Add a source spot-check: pick three days at random and trace every figure back to job reports, issue notes and put-away records. Coverage need not be complete, but it must include the number most often questioned. If the same class of metric fails every time, the problem is definition, not entry.
When a system is justified
Three signals: one person consolidates twice a month or more, each time for over half a day; one metric shows two values on two tables and both need explaining; definitions now have to be fixed per customer or per workshop. That is the point where a system pays for itself.
The national standard GB/T 39116-2020 places gap identification before solution planning, and the same order applies to statistics: find out whether you lack definitions, sources or tools, then spend. Fix definitions where definitions are missing; buy tools only where tools are missing.
If your table is on its third revision and every meeting still starts with aligning definitions, send us last month's version (contact) and we will show you which layer the gap is in. To have statistics land on one screen without manual consolidation, see the T001 manufacturing AI service centre.
In one line: write the metric dictionary before laying out the table. Without shared definitions, a prettier table produces longer arguments.
FAQ
- What is the difference between a statistics table and a ledger?
- A ledger records what happened, one fact per row, in time order. A statistics table answers what happened over a period, one metric per column. An analysis explains why. Mixing the three produces more numbers and fewer conclusions.
- How do I stop departments from reporting conflicting numbers?
- Define three things first: for each metric write one sentence covering scope, calculation, source document and owner. Without that, differences cannot be attributed — you cannot tell a different definition from a different extraction or a data entry error.
- Should output be counted at completion or at put-away?
- Both, separately. Output is normally counted at job reporting because it reflects shop-floor production; put-away reflects deliverable stock. Keep them in separate columns with their source documents named, so month-end discrepancies point to the right segment.
- How should a statistics table be checked?
- Reconcile in both directions: across metrics to the row total, and across periods to the cumulative figure. Then spot-check the source: pick three days at random and match the table against job reports, material issue notes and put-away records. Any mismatch is a definition or timing problem.