Stopped again, reason: jammed
The flow-wrapper stops. The operator clears it, restarts, stops again ten minutes later. At some point someone writes on the clipboard: 11.20 to 11.35, jammed. The shift report says line 2 had a poor morning. The engineering manager hears about it on Thursday.
Every factory has the same few causes eating time: film splices, labeller faults, waiting for ingredients, waiting for a clean-down to be signed off, short crew. Without a record anyone can analyse, the loudest problem gets fixed, not the biggest.
Why downtime stays on paper
Operators are busy, clipboards are there, and nobody has a reason to fill them in carefully because nobody reads them. Reasons are free text, small stops are not written down at all, and the paper goes into a folder after the shift.
- Stop reasons are written in each operator's own words.
- Short stops of a minute or two are not recorded.
- Times are rounded or filled in at the end of the shift.
- Stops are not linked to the product running at the time.
- Engineering and production keep separate records of the same stop.
What you cannot see
Which cause costs most time on each line. Whether a problem follows a particular product, film or shift. Whether the fix engineering made last month actually worked. Without that, spending on spares, upgrades or training is based on impressions, and OEE figures are more hope than measurement.
The downtime logging we build
- A tablet screen at each line shows the current product from the schedule and a start and stop button.
- When the line stops, the operator picks a reason from a short list your team defines for that line, with the option of a note or a photo.
- Where the line's machines can provide a running signal, through a PLC connection or a simple sensor, stops are timed automatically and the operator only adds the reason.
- Stops that need engineering can raise a job to the engineering team from the same screen.
- Reports show downtime by line, reason, product and shift, with trends, and a Pareto chart of the causes that take most time.
- Line leaders see a live view of their line, and managers see the whole factory.
| Captured | How |
|---|---|
| Stop start and end | Machine signal or button |
| Reason | Picked from your list |
| Product running | From the production schedule |
| Notes and photos | Optional, on the tablet |
| Engineering job | Raised from the stop |
What the numbers let you do
Engineering can see which faults cost most time and focus there. Production managers can compare shifts fairly. Changes can be judged by what happened afterwards. And the daily production meeting can look at the same record instead of arguing about whose memory is right.
Operators tend to take the record more seriously once they see it being used. When the reason they picked on Tuesday turns up in Thursday's meeting and a fix follows, the list gets filled in properly, and the free text notes start to carry useful detail about what actually happened at the machine.
It helps with capacity decisions too. Before buying another line or adding a shift, you can see how much time the existing lines lose, and whether recovering some of it is the cheaper route.
Is your downtime record like this?
- Stops are written on a clipboard at the line.
- Reasons are free text that nobody can summarise.
- Short stops are never recorded.
- Engineering and production disagree about what stopped the line.
- Your OEE figure is estimated.