- Home
- Blog
- Shop Floor Execution
- What a Pause-with-Reason Record Is Worth in EDGEBI…
What a Pause-with-Reason Record Is Worth in EDGEBIC
Every time an operator pauses a job at the EDGEBIC by User Solutions kiosk, they record why, choosing from four categories: Machine, Material, Quality, or Waiting. That single tap is worth far more than it costs, because it turns a lost minute into a Pareto chart, a maintenance signal, and a fairer efficiency number. A pause reason code manufacturing teams record consistently is the raw material of continuous improvement. This article explains exactly what that one tap buys you.
Lost time is inevitable on a shop floor. Machines break, material runs out, quality holds happen, and operators wait. What is not inevitable is losing track of why. A pause with no reason is a hole in the record that no report can fill later. EDGEBIC closes that hole by making the reason mandatory and structured, and the payoff shows up in three places.
The Four Categories
When an operator taps Pause, the kiosk asks why with four category tiles: Machine, Material, Quality, and Waiting. The operator picks the category, then a specific reason within it (a coolant issue, a spindle problem, a missing part, a dimensional hold). The same four categories appear on the scrap reason picker, so a bad part is attributed the same way a stopped machine is.
This is not an arbitrary split. It is the industry-standard downtime taxonomy, and its power is that each category routes to a different owner:
| Category | Points to |
|---|---|
| Machine | Maintenance |
| Material | Lead or purchasing |
| Quality | Quality inspector |
| Waiting | Lead |
The categorization is the difference between a record that describes a problem and a record that dispatches a fix. To record a pause step by step, see how to pause a job with a reason code.
Worth One: The Reason Is Mandatory
The first thing the record is worth is that it exists at all. EDGEBIC requires a reason on Down, Idle, and Rework pauses, and on every scrap piece. The scrap reason is written in the same transaction as the count, so a scrap event with no reason cannot be saved.
That requirement is deliberate. A reason-less stop is an unattributable stop, and unattributable time cannot be improved because nobody knows what to fix. By making the reason mandatory at the moment work stops, when the operator still knows exactly what happened, EDGEBIC guarantees that every lost minute has a cause on record. There is no gap to reconstruct later from memory.
Worth Two: Lost Time Stays Out of Production Hours
The second thing the record is worth is fairness in the numbers. Paused, down, and idle time are recorded as non-productive and never flow into a job's production hours. Only run and rework time count as production.
This matters because it separates the operator's output from things outside their control. A coolant leak or a material wait does not drag down the run-hour figure that measures how much the machine produced. The lost time is still captured, with its reason, and it feeds downtime reporting, but it is kept out of the production number. Nobody's efficiency is judged on a breakdown they did not cause. This is the same separation you see on the shift handoff summary, where run, setup, and down hours are shown in separate buckets.
Worth Three: The Pareto Chart
The third and largest thing the record is worth accrues over time. One pause is an anecdote; a thousand pauses, each with a category and reason, is a Pareto chart. Because every stop is attributed to one of four categories and a specific reason, EDGEBIC can stack them into the classic 80-20 analysis that tells you where your lost time really goes.
This is where the four-category discipline pays off. Over a month you learn whether your downtime is mostly Machine (invest in maintenance), mostly Material (fix the supply flow), mostly Quality (address the process), or mostly Waiting (rebalance the crew). Each answer is a completely different action, and without the categories you would be guessing. This aggregate view is the foundation of machine downtime tracking that actually drives change.
A Worked Example
Tuesday, a mill operator running a job.
- 11:30. A coolant alarm. The operator taps Pause, picks Machine, then the coolant reason. The run punch closes and a down punch opens carrying that reason. The screen shows the pause is recorded.
- 12:10. The machine is back. The operator taps Resume. A fresh run punch opens. The 40-minute pause is recorded as non-productive.
Now trace the three worths through this one event. The reason was mandatory, so the coolant problem is on record rather than lost. The 40 minutes stayed out of the job's production hours, so the operator's output figure is not penalized for a coolant issue. And the pause landed under Machine with a coolant reason, so it feeds the Pareto chart and the shift handoff, where a second coolant pause that day would reveal a pattern.
Compare the same event with a generic, reason-less pause. The 40 minutes vanish into "the shift ran short." No maintenance ticket, no Pareto bar, no handoff warning. The difference between the two is one tap.
Why Accuracy Is the Whole Game
The record is only worth what its accuracy makes it. A broken spindle logged as Waiting looks like an idle operator, and the machine failure it really was never surfaces as a Machine problem. The Pareto chart then shows a Waiting bar that is a Machine bar in disguise, and the root cause stays buried. That is the one failure mode worth guarding against, and it is a habit problem, not a software one.
So the standard is simple: pick the honest category, every time. The four-way split only routes fixes correctly if the categories are true. An operator who reflexively taps Waiting for everything hands you a report that points nowhere. An operator who takes two seconds to pick the real cause hands you a report that pays for itself.
The Bottom Line
A pause-with-reason record costs one extra tap and buys three things: a guaranteed, attributable record of every stop; a fair production number that excludes time outside the operator's control; and, over time, a Pareto chart that tells you where to spend your improvement effort. That last one is where User Solutions customers have found decades of gains, from small job shops to the plants behind names like Cummins and BAE Systems. The tap is small; the return compounds.
See how these records fit the wider loop in closing the loop from shop floor to plan and the full shop floor execution guide. Explore the platform at EDGEBIC.
Expert Q&A: Deep Dive
Q: My operators used to just note downtime as 'machine problem.' How is the four-category split better?
A: The difference is where the record sends you. A generic 'machine problem' tells nobody what to do; the four-category split routes the fix. A Machine reason points maintenance at the machine, a Material reason points at purchasing or the lead, a Quality reason points at the inspector, and a Waiting reason points at the lead too. Over a month those categories stack into a Pareto chart, and you learn whether your lost time is mostly breakdowns, mostly material starvation, or mostly waiting, which is a completely different fix in each case.
Q: An operator tapped Waiting for what was actually a broken spindle. What is the cost of that mistake?
A: It sends maintenance nowhere. A broken spindle logged as Waiting looks like an idle operator in the reports, so the recurring machine failure never surfaces as a machine problem and never gets a maintenance ticket. The Pareto chart shows a Waiting bar that is really a Machine bar in disguise, and the root cause stays hidden. That is why honest reason selection matters: the record is only worth what its accuracy makes it, and a wrong category buries exactly the problem the record exists to reveal.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The Schedule Reconciliation Report in EDGEBIC, Explained
Eight parameter checks over two exception grids. See how EDGEBIC reconciles the plan against the plant and shows only the rows that disagree.
Why a Dependent-Parallel Child Is Exempt From the Over-Booked Check
Three synchronized drills book 24 hours on an 8 hour day. That is real plant behavior, not a capacity breach, and flagging it would make the whole check useless.
Confirming a Sub-Assembly Versus the End Product in EDGEBIC
One dialog, two mechanisms. See why confirming an end product reduces the build directly while confirming a sub-assembly works through ordinary stock netting.
