"It was a bad shift"
The weekly production meeting looks at output. One folder-gluer was well below its usual output. The shift note says "feeder problems, waiting for board, long make-ready". Which of those mattered most, and are they new or the same as last month? Nobody knows, so the meeting ends with a general agreement to try harder.
Meanwhile maintenance is convinced most of the lost time is make-ready, and production is convinced it is breakdowns.
Stops are recorded late and in free text
Short stops happen constantly on packaging lines, and longer ones a few times a shift. Operators are busy fixing the problem, not writing it down. Anything recorded is written at the end of the shift, in free text that cannot be added up. Machine counters show output but not the reasons for stops.
- Stops are written up at the end of the shift, from memory.
- Free text reasons cannot be totalled.
- Short stops are not recorded at all.
- Waiting time is blamed on the machine rather than on materials or planning.
- Maintenance and production have different versions of events.
What guessing costs
Without reliable downtime data, improvement effort goes to whatever feels worst, not what costs most. Maintenance budgets and machine replacement decisions are argued on opinion. Planning uses optimistic run speeds and misses dates. And the plant cannot show whether changes, such as a new make-ready routine, actually worked.
Downtime also hides in plain sight. A folder-gluer that stops for two minutes thirty times a shift looks busy to anyone walking past, yet those stops can add up to more lost time than the breakdown everyone talks about.
Maintenance planning suffers in the same way. Without a record of which faults recur on which machines, planned maintenance is scheduled by the calendar rather than by the machine's actual history, and the same breakdown can return month after month.
Downtime logging we build
- Stops are detected automatically where the machine provides a running signal or counter, or started by the operator with a tap on a screen at the machine.
- When a stop ends, the operator picks a reason from a short list you define: make-ready, waiting for board, waiting for tooling, jam, breakdown, quality check, no operator, and so on, with an optional note.
- Short stops are recorded automatically and can be categorised in groups at the end of a run, so operators are not interrupted constantly.
- Breakdowns create a maintenance request with the machine and reason, so maintenance history and downtime are linked.
- Reports show lost time by reason, machine, shift and product, and trends over weeks.
- The planner's run speeds can be compared with real speeds to improve scheduling.
| Question | Answer now | Answer with logging |
|---|---|---|
| What stopped us most this week? | Opinion | Lost time by reason |
| Is make-ready getting better? | Unknown | Trend by machine |
| How often are we waiting for board? | Blamed on the machine | Recorded as its own reason |
| Which breakdowns repeat? | Maintenance memory | Linked to maintenance history |
| Are run speeds realistic? | Planner's assumption | Actual speeds by product |
Improving what actually costs you
The weekly meeting starts with a chart rather than an argument. Improvement effort goes to the causes that cost the most time. Maintenance and production share one record. Planning uses realistic speeds. And when a change is made, you can see whether it helped.
Is downtime a matter of opinion?
- Downtime is recorded in shift notes.
- Short stops are not recorded.
- You could not say which cause cost the most time last month.
- Maintenance and production disagree about causes.
- Planned run speeds are rarely achieved.