Downtime management: recording stoppages in a way that leads to action

The losses that never get recorded are usually the largest

Long stoppages get recorded because they are impossible to ignore. Short ones do not: the brief jam, the adjustment, the wait for material, the pause while an operator fetches something. Individually they fall below whatever threshold the plant records and collectively they often exceed the breakdowns everybody discusses. Establishing their scale usually requires a period of direct observation or interval counting rather than the existing reporting, and the result is frequently uncomfortable. Until this gap is measured, improvement effort concentrates on the visible failures while the larger loss continues unexamined.

Reason codes designed for the person entering them

A code list that is long, ambiguous or organised for the convenience of analysts will be used badly, with most events landing in a general category. Keep the list short enough to be remembered, make the categories mutually exclusive in a way an operator recognises, and review how the codes are actually being used rather than assuming the definitions hold. Where a catch-all category dominates, that is a design fault in the list rather than carelessness on the floor. Adding a free-text note alongside the code preserves the detail the categories cannot carry.

Attribution arguments and how to settle them

When a line stops because material arrived late, is that a production loss, a supply loss or a planning loss? Departments argue because the answer affects how they are judged. Settle it with a rule rather than case by case: attribute to the function that could most directly have prevented it, record the immediate trigger separately from the underlying cause, and accept that some events will be attributed imperfectly. What must be avoided is the alternative, where each function maintains its own version and the leadership meeting spends its time reconciling numbers instead of deciding what to fix.

Separating planned from unplanned without hiding either

Planned stoppages such as changeovers, cleaning, scheduled maintenance and trials are legitimate uses of time, and mixing them with failures makes both harder to manage. Report them separately, but do report them, because a plant that excludes all planned time from its loss analysis can be losing a very large share of its capacity to activities nobody has examined. The useful question about planned downtime is different: not why did it happen, but does it need to take this long and does it need to happen this often.

From a downtime report to something actually being fixed

Ranking causes by total time lost on the resource that limits the plant produces a short list, and the discipline is to work the top of that list to a conclusion rather than distributing effort across everything. Each item needs an owner, a diagnosis that goes beyond the reason code, and a check that the loss actually reduced afterwards. Reports that circulate without this loop train people to view downtime recording as an administrative burden, which then degrades the data quality and removes the basis for any future analysis.

Frequently asked questions

Should downtime be measured on every machine or only on some?

Measure everywhere output is genuinely lost to the plant, which usually means the constraint and the resources that feed it. Recording stoppages on machines with plenty of spare capacity generates data that leads nowhere, since time lost there costs nothing unless it starves something downstream. Narrowing the scope also improves quality, because the effort of accurate capture is concentrated where someone will actually use the result.

How do we get honest downtime reporting from the floor?

Make the reaction to a reported loss consistently useful rather than punitive, keep the recording effort small, and visibly act on the resulting list. Where reporting a stoppage produces a question about who was at fault, the reasons quickly become vague and uniform. Supervisors set this by example: if they routinely recode uncomfortable events or lean on operators about the figures, the data becomes an account of what is acceptable to report.

Is a downtime target a good idea?

Targets on a measure that people self-report tend to improve the reporting rather than the process. If a target is used, pair it with independent verification such as recorded machine running time or output counts, and target a specific loss category with an owner rather than the total. Improvement conversations built around the ranked cause list generally produce more than a plant-level percentage that everyone has an interest in flattering.