Most small manufacturers can tell you what they produced last month. Considerably fewer can tell you why they did not produce more.
That gap is the whole opportunity in production monitoring, and it is frequently missed because monitoring gets specified as output measurement. Output is the easiest thing to count and the least useful thing to know, because it tells you the result without telling you the cause.
The number that changes decisions is not what was made. It is where the available hours went.
Output is a result; time is a cause
A shift has a fixed number of hours. Those hours are spent in a small number of states:
- Running and producing good units
- Running and producing units that will be rejected
- Stopped for a planned reason — changeover, maintenance, break
- Stopped for an unplanned reason — breakdown, no material, no operator, no order
- Running slower than the machine is capable of
Output only reflects the first. Everything actionable lives in the others, and a factory that measures only output is measuring the one category it cannot influence directly.
The practical version of this for a small manufacturer is not a formal efficiency metric. It is a simple question asked reliably: for every hour this line was not producing, why not?
Downtime attribution is the whole game
Most factories record downtime as an aggregate — the line was down four hours. That is a number nobody can act on.
Attribution means every stoppage has a cause recorded at the time, from a short fixed list that operators actually use. Fifteen categories will not be used consistently. Six will.
Something like: breakdown, changeover, no material, no operator, no order, quality stop. Crude, and sufficient. Once a month of data exists, the distribution is usually surprising — most factories discover that their largest loss is not the one they had been managing.
Why it must be recorded at the time
Downtime reconstructed at end of shift is a guess. The supervisor remembers the long stoppage and forgets the six short ones, and short frequent stoppages are commonly the largest cumulative loss precisely because nobody notices them individually.
Capture has to happen at the machine, in seconds, or it will not happen honestly. This is the same design constraint as a busy counter: if recording the awkward reality is slower than not recording it, the record will be optimistic. It is the principle behind how Truffaire builds software.
What to measure first
For a small manufacturer starting from nothing, in order:
Downtime with cause. As above. This is the single highest-value measurement and it requires no instrumentation — an operator, a screen, six buttons.
Actual versus planned output per shift. Not to judge people. To establish whether the plan is realistic, which is frequently the actual finding.
Rejects with a reason. Quantity alone tells you there is a problem. The reason tells you whose problem it is — material, machine, method or operator.
Changeover duration. In job-shop and short-run operations this is often the largest recoverable loss, and it is rarely measured because it is considered unavoidable.
Material consumed versus expected. Variance here indicates yield loss, theft, or a wrong standard — all worth knowing, all invisible otherwise.
Everything else can wait. A factory that reliably captures these five knows more than one with an expensive system nobody updates.
Sensors are not the starting point
The instinct is to instrument machines. Automated capture is genuinely better — it is objective, continuous and does not depend on anyone remembering.
But it answers that a machine stopped, not why. The cause still requires a human input, and the cause is the actionable part. A factory with automated stop detection and no attribution has precise measurement of an unexplained problem.
Start with manual attribution, prove people will use it, and instrument afterwards where the volume justifies it. Beginning with sensors frequently produces a dashboard of accurate numbers nobody acts on — the failure described in operational dashboards people actually use.
The part that gets built wrong
Production monitoring is often implemented as a supervisor's reporting tool. The data is entered for management, reviewed weekly, and delivers nothing to the people on the floor.
That arrangement decays. Operators recording data they never see feedback from will record it less carefully over time, and the numbers degrade in a way that is invisible until a decision is made on them.
The systems that hold up give something back at the floor level — a shift's progress against target, visible now, to the people who can change it. That is what makes the recording feel like part of the work rather than a report for someone else.
What we have seen
Production monitoring and factory operations management are among the ten systems we have delivered.
Two findings recur.
Small stops dominate. Factories manage the four-hour breakdown because it is memorable. The aggregate of twenty short stoppages usually exceeds it, and it is invisible without at-the-moment capture.
The plan is often the problem. When actual output is measured honestly against plan, the common discovery is not that the floor is underperforming — it is that the plan never accounted for changeover, material waits or realistic run rates. Which makes every downstream commitment optimistic.
Frequently asked questions
How small is too small for this?
If you have more than one machine or process step and you cannot account for where the day went, it applies. Scale determines the tooling, not whether the question matters — a whiteboard with honest attribution beats software nobody updates.
Do we need to integrate with the machines?
Not to start. Manual attribution captures the actionable part. Machine integration adds precision and removes dependence on memory, and it is worth doing once the categories are stable and used.
Will operators record downtime honestly?
They will if it is fast, if the categories match reality, and if it is not used punitively. The moment downtime recording becomes an instrument for blame, the data becomes fiction — and the fiction is worse than no data because decisions get made on it.
How does this relate to our stock system?
Directly. Production consumes material and produces finished goods, and both are stock movements. If production is tracked separately from inventory, the two will disagree — the same fragmentation described in what a business operating system actually is.
What about full ERP or MES?
Appropriate at scale and heavy for a small manufacturer. The failure mode is a comprehensive system where only the modules people were forced to use get maintained. Start narrow, prove usage, extend.
Where to start
Pick one line. For one month, record every stoppage with a cause from a list of six categories, captured at the machine when it happens.
At the end of the month, sort by total hours lost. Most manufacturers find the largest category is not the one they had been actively managing — and that single finding usually pays for the exercise before any software is purchased.
SPEXA covers production monitoring against the same record as stock and orders, so consumption and output are not a separate reconciliation. If you want a read on what to measure first, get in touch.