How Downtime Reason Codes Build the Maintenance Case

Maintenance money usually goes to whoever asks most persistently, because nobody can say which machine actually costs the most: downtime reason codes replace that with a ranked list of causes and the hours behind each one. EDGEBIC by User Solutions collects those codes where the loss happens, at the kiosk, as a required answer when an operator pauses a job into Down or Idle. The outcome is not better record keeping. It is that a maintenance request stops being a complaint and becomes a comparison between a repair cost and recovered hours.

This post covers the maintenance-spend outcome. It sits under the EDGEBIC results guide. For designing the code list itself, see building a reason code catalog.

The Budget Meeting Without Data

Three supervisors want money. The first has a grinder that trips out and has tripped out for two years. The second has a press with a leaking cylinder. The third has an older lathe everyone dislikes.

Each request is a story, each story is true, and there is no way to rank them. So the budget goes to the most senior voice, or to the machine that failed most recently, or to the one whose failure was most visible. None of those correlate with hours lost.

The uncomfortable part is that the plant already paid for the answer. Every one of those failures cost real production time. It just was not recorded in a form anyone could add up.

Where the Code Gets Captured

The kiosk asks for a reason at specific, deliberate moments and never casually:

That restraint matters. Operators stop answering honestly the moment a system asks them to categorize normal work, so the prompt appears only when something went wrong. One tap, at the machine, at the moment it happened, which is the only time anyone remembers the actual cause.

Sixteen default codes ship across four categories, and the categories are built on one design rule: a category is worth having when it sends the problem to a different person.

• Machine. Spindle fault, coolant, hydraulics, controller. Escalates to maintenance.
• Material. Missing stock, wrong material, bad incoming part. Escalates to the lead or purchasing.
• Quality. Dimensional reject, inspection hold, first article. Escalates to the inspector.
• Waiting. No operator, waiting on a crane, waiting on a decision, waiting on the prior operation. Escalates to the lead.

On top of those you add codes scoped to a single work center, which is what makes the list describe your plant rather than a generic one.

Turning Taps Into a Case

A quarter of coded pauses on one station might look like this:

Two findings fall out immediately, and only one of them is a maintenance finding.

The spindle fault is 22.5 hours on one station in one quarter, roughly 90 hours a year. That is a specific recurring failure, not general age, and it is now priceable: compare the repair against 90 hours.

The 12 hours waiting on the prior operation is not a maintenance problem at all. It is a scheduling one, and it would have been invisible in a downtime total that only said "this station lost 55 hours." Sorting by cause routes each problem to the person who can fix it, which was the design intent of the categories in the first place.

Why the Constraint Multiplies the Number

Ninety hours on an ordinary station is ninety hours of that station. Ninety hours on the constraint is ninety hours of plant output, because the constraint sets the pace of everything downstream of it.

That is the argument that moves a maintenance request from the cost line to the throughput line, and it is why the constraint station deserves its own reading of the downtime list before any other station gets one. See production bottleneck identification for identifying which station that is, and how protecting the constraint lifts plant output for the throughput case.

Planned Downtime Is a Separate Conversation

Coded pauses capture unplanned loss. Planned maintenance is modeled ahead of time as downtime events, which remove hours from a station's capacity so the schedule never books a job into a window the machine will not be available. The kiosk also carries a preventive maintenance due banner where it lands, so the reminder reaches the person at the machine rather than an inbox.

The two halves work together. Coded pauses tell you which failure to attack; planned downtime is how the fix gets into the schedule without wrecking the promise dates around it. See EDGEBIC downtime events explained and how planned downtime modeling keeps the schedule honest.

The Limits

Codes record what an operator selected. This is capture at the kiosk, not machine sensing. A fault that nobody paused for leaves no record, and a pause coded quickly under pressure may be coded roughly. The data is honest about what was entered.

One dominant generic code means the catalog is wrong, not the operators. If most taps land on the same broad code, either the real cause has no code or two codes look alike on the touchscreen and one is nearer the thumb. Fix the list, not the people.

Hours lost are not directly hours recoverable. Eliminating a 90 hour fault does not always add 90 hours of output, because a station that was not the constraint may have had slack anyway. The number is an upper bound on the gain, and it is still the best number in the room.

Availability is only part of the picture. OEE combines availability, performance, and quality, and availability is actual hours over shift-available hours. A machine that runs all its hours slowly is not a downtime problem. See machine downtime tracking for the wider metric set.

Reports are point-in-time. When a downtime figure justifies a spend, export it into the request so the decision keeps its arithmetic. Tomorrow's picture will differ, and next quarter nobody will remember what the number was when the case was made.

Want to see what your own lost hours would rank as? Bring a quarter of shop floor data to a demo and we will sort your downtime by cause.