The short answer
A downtime list works when an operator can pick from it in a few seconds with gloves on. Keep it short, split planned from unplanned, and let machines fill in what they can.
Why long lists fail
Many plants start with a downtime list of dozens of reasons, built in a workshop where everyone wanted their own problem to be visible. On the floor, the list becomes a wall of buttons. Operators pick the first one that looks right, or the one at the top, and the report fills up with "Other". After a month the supervisor stops trusting it.
The cause is not lazy operators. A reason list is a form, and forms that are slow to fill are filled badly. The test for each reason is simple: would two operators, standing at the same stopped machine, pick the same one?
Start from decisions, not from causes
Ask what someone would do differently if they saw a reason in the report. If the answer is nothing, merge it with another. A useful reason points at an owner: maintenance, materials, quality, planning, the operator. You do not need a reason for every possible fault. You need enough to send the report to the right person on Monday.
The app ships with a default reason set. Treat it as a starting point: shorten it and rename it for your plant, using the words your operators already say. If the floor says "jam", the button should say Jam.
Split planned from unplanned
The most useful division is between stops you chose and stops you suffered. Changeovers, cleaning, scheduled maintenance and breaks are planned. Breakdowns, waiting for material and quality holds are unplanned. Mix them and a good changeover looks like a failure; separate them and you can ask two different questions.
Planned
Stops you chose
- Changeover and cleaning
- Scheduled maintenance
- Breaks and shift handover
Unplanned
Stops that cost you output
- Breakdown and jams
- Waiting for material
- Quality hold
Planned time is managed by scheduling, and the plan can be improved. Unplanned time is managed by maintenance and supply, and the reasons point to who should act.
Let the machine pick when it can
Every reason an operator does not have to pick is one that cannot be picked wrongly. When the MESFlow Machine Gateway reads a machine, you can map a machine status to a downtime reason. When the machine stops, the running operation is paused with that reason and the machine's own timestamp. For stops that are ambiguous, a supervisor is offered the pause to accept. When the machine runs again, the operation resumes.
This changes the operator's job. Instead of remembering to log every stop, they are only asked about the ones the machine cannot explain.
A worked example of a short list
Imagine a packing line with six reasons: Changeover, Cleaning, Maintenance planned, Breakdown, Waiting for material, Quality hold. Changeover, Cleaning and Maintenance planned are planned. The other three are unplanned. Six buttons, two groups, and every one has an owner. Everything else the operator can write off as the nearest of the six, and if the report shows a reason that is far too popular, you split it then, not before.
This is an illustration of the shape, not the contents of the default reason set. Start from your own stops.
Pausing with a reason
On the app, an operator pauses an operation and picks a downtime reason. That is the whole action. It is stored on the device first, so it works with the network down, and it is sent to Business Central with the time it really happened. The pause and the reason are on the operation log, ready to be read.
Keep the number of taps low. A pause that takes two taps will be logged. A pause that needs a menu, a sub-menu and a text note will be skipped, and the stop will be discovered later as a gap in the run.
Reading the report
Two printable reports show the result: the downtime report and the machine activity report. Read the downtime report by reason first, then by machine. If one machine dominates one reason, that is a job for maintenance. If one reason is spread across every machine, it is a process or supply problem. Then compare with the machine activity report to see how the machine's time was spent.
On the role center, the Needs Attention list puts the items that need a person in front of the supervisor, and the cues show running and paused operations. Lists drill down to the order, item, machine or ticket behind each number, so a number is never a dead end.
A monthly habit
Review the list once a month with the people who use it. Retire reasons nobody picked. Split any reason that has become a dumping ground. Rename anything an operator has started calling something else. A reason list is never finished, and the point is to keep it short enough to be used.
In Business Central
The features involved are the downtime reasons, the mapping from machine status to reason, the pause with a reason on the operation, the offer of a pause to a supervisor, the operation log, the downtime report, the machine activity report, and the role center with its cues and Needs Attention list.
Limits
The default reason set is a starting point, not a standard, and you should edit it for your plant. Machine-triggered pauses depend on machine drivers, and five of them are commissioned per site and have not yet run on a real device, so test on your equipment first. The desktop app is unpackaged and unsigned, with no installer yet. The apps are in English only.
Keep reading
For how a stopped machine reaches the list, read from PLC to production order. For the questions to ask a vendor about downtime, see 17 scenes for a Business Central plant.
See it on your plant
Bring your current list. Book the downtime demo scenario and we will shorten it with you, map a machine status to a reason, and show the downtime report that results.