Building a Reason Code Catalog for Your Work Centers in EDGEBIC

EDGEBIC by User Solutions ships sixteen default reason codes organized into four categories, Machine, Material, Quality, and Waiting, and lets you add codes scoped to a single work center on top of them. That two-layer design is what lets a shop start capturing causes on day one and still end up with a paint booth list that mentions color changes and a heat treat list that does not.

A reason code is one tap on a touchscreen. It is also the entire difference between knowing you lost 1.25 hours and knowing why. This article is about building a catalog operators will use honestly, which is a design problem before it is a configuration one.

Where Reasons Are Required

The kiosk asks for a reason at specific, deliberate moments. It never asks casually.

The scrap case has an extra guarantee. The count and its reason are written together in one operation, so a scrap event with no cause cannot exist in the record. The reporting downstream, which is a Pareto view of causes, depends on that being airtight rather than mostly true. See good, scrap, and rework counts explained.

The Four Categories

The category layer exists so the operator's first tap is easy and the analyst's grouping is stable. Four tiles, one obvious choice each.

Machine. The equipment failed or needed unplanned attention. Spindle fault, coolant, hydraulics, controller. These escalate to maintenance.

Material. The work could not proceed because of what was, or was not, in front of the machine. Missing stock, wrong material, bad incoming part. These escalate to the lead or purchasing.

Quality. Something was out of specification, being checked, or held. Dimensional reject, inspection hold, first article. These escalate to the inspector.

Waiting. The machine and the material were fine and something else was not. No operator, waiting on a crane, waiting on a decision, waiting on the prior operation. These escalate to the lead.

That escalation column is the real design principle: a category is worth having when it sends the problem to a different person. If two categories always page the same person, you have one category wearing two hats.

Starting With the Defaults

The sixteen defaults are seeded automatically the first time the kiosk asks for a list and finds none. There is no setup task blocking your first shift, which matters when you are standing up terminals. See setting up the kiosk for your first shift.

The right first move is to leave them alone for a few weeks. Let the floor tap real reasons on real events, then look at what came back. Two patterns will show up quickly:

• A code that gets used constantly and is too vague. That is a candidate to split into two more specific codes, or to scope down to the work center where it actually fires.
• A code that never gets used at all. That is a candidate to retire, because every unused button makes the used ones slower to find.

Adding Work Center Specific Codes

A reason code can be scoped to a single work center. The kiosk at that work center shows the scoped codes together with the global defaults, so an operator there gets one combined list without the office having to duplicate the shared codes onto every machine.

Add them from the planner, on the work center's reason codes tab: pick the category the new code belongs to, give it a stable code key for reporting, a short operator-facing label, and a display position. The kiosk picks it up the next time it loads.

Practical guidance for the label: it is a button on a touchscreen next to a machine, read by someone who wants to get back to work. Short, concrete, and in the words the floor already uses. "Coolant" beats "Coolant delivery system fault." The stable code key underneath is what your reporting joins on, so it can be as formal as you like.

Retiring a code is a deactivation rather than a deletion. Historical punches keep pointing at the reason they actually carried, so last quarter's Pareto chart does not silently change shape because somebody tidied a list this morning.

What the Catalog Buys You

One tap at the machine turns into three things that would otherwise take a meeting.

A Pareto view of lost time. Down and idle hours grouped by reason, largest first. On most floors the top two causes account for the majority of unplanned loss, and they are rarely the two everyone assumed.

A fairer efficiency picture. Because setup, idle, and down time never enter productive hours, a machine that lost the morning to a coolant failure does not read as a slow operator. The loss is recorded against the machine, with its cause. See what a pause-with-reason record is worth.

Honest availability in OEE. The availability factor needs to know why a machine was not running, and reason codes are where that comes from. See how kiosk punches feed OEE.

A Worked Example

Paint Booth 2 keeps showing large unexplained down blocks tagged with a generic Machine code. The supervisor asks for a color-change code, scoped to that booth only, in the Machine category.

Two weeks later the booth's down time splits cleanly: about 60 percent color change, 25 percent gun maintenance, the rest scattered. The color-change portion is not a machine failure at all, it is a sequencing consequence, and it points straight at the changeover sequence rather than the equipment. That is a scheduling problem with a scheduling answer, and it was invisible while everything read as a single Machine code.

No other work center's terminal ever showed the new button.

The Bottom Line

Start with the sixteen defaults, watch what the floor actually taps, then add narrow work center specific codes where a real recurring cause deserves its own button. Keep each category short enough to scan, keep labels in floor language, and retire rather than delete. The catalog is small, but it is what turns lost time from an unexplained gap into a fixable line on a chart. Follow the rest of the loop in the shop floor execution guide, or see EDGEBIC.