The machine that stops most is rarely the one holding the line back.

On a coupled line, most recorded downtime is consequence rather than cause. This guide sets out how to tell the two apart, and how to confirm which machine is the constraint before time and money are spent on it.

  • Five-step method

Why the most-stopped machine is usually not the constraint.

The palletiser stops because the labeller slowed, and the palletiser logs the downtime. It reaches the top of the Pareto, gets the engineering attention, and the labeller carries on doing it, which is why the same machine keeps appearing on the list after being fixed.

A ranking built from each machine’s own log measures which machines suffered stops, not which machine caused them. On a line where machines are coupled by short buffers, one stop shows up several times, and the machine that started it may record the least.

Stopped, starved and blocked.

A machine waiting for product and a machine that has failed are both idle, and most reporting records them identically. One is a maintenance problem and the other is a balancing problem, and treating the second as the first is expensive. Four states are enough to tell them apart.

  • Running

    Producing, at whatever rate. The only state in which the machine adds output.

  • Stopped

    Idle for a reason of its own: a fault, a changeover, an adjustment. This is the state that has a cause on this machine.

  • Starved

    Ready to run, with nothing to work on, because the machine before it is not delivering. The cause is upstream.

  • Blocked

    Ready to run, with nowhere to put its output, because the machine after it is not taking it. The cause is downstream.

Why a line average hides it.

Take the mean across six machines and a genuinely limiting one is diluted by five that are running well. The line figure moves smoothly, looks manageable, and points at nothing in particular.

The line’s output is set by its constraint, not by its average. A line figure is still worth reporting; it simply needs the constraint’s own figure beside it.

A method in five steps.

Each step uses what the one before it established. The order matters: confirming a suspect before the states have been recorded only confirms the suspicion.

  1. 01

    Draw the line in order

    Write down which machine feeds which, with the buffers between them and how much each can hold. This is engineering knowledge, held once, and every later step is read against it.

  2. 02

    Record each machine’s states over time

    For each machine, a timeline of running, stopped, starved and blocked, read from its own controller where possible, with a reason for each stop it caused itself. A week covering the usual product mix is a better sample than one bad day.

  3. 03

    Find the machine that is rarely starved or blocked

    The constraint is the machine that is almost always either working or stopped for its own reasons. Machines upstream of it spend time blocked; machines downstream spend time starved; the queue in front of it is usually the longest.

  4. 04

    Confirm it by changing it

    Protect or speed up the suspected constraint, for example by covering its breaks, and watch the line’s output. If output rises, it is the constraint. If output does not move, the constraint is elsewhere and the change only moved where material waits.

  5. 05

    Measure the constraint on its own terms

    Give the limiting machine its own figures rather than averaging it into the line’s. When it stops for a reason that is not technical (no material, no operator, no order), record that as its own category rather than as general downtime.

What the data has to hold.

The method needs two things the usual reports lack: each machine’s own timeline, and the difference between a stop a machine caused and one it suffered. AFNOR NF E60-182 calls these own stops and induced stops.

The order of the line stays an input from the people who know it. Data shows when each machine stopped and why; reading which stop came first, against the drawing from step one, is still an engineering judgement.

Terms this guide uses.

Each one is defined in full in the glossary, with the terms around it.

  • Bottleneck

    The bottleneck is the resource whose capacity limits the output of the whole line.

  • Stop reason

    A stop reason is the cause recorded against a period when a machine was not producing, chosen from a list the plant maintains.

  • Work in progress

    Work in progress is material that has entered production and not yet been finished: parts between operations, in buffers or waiting for a resource.

  • Takt time

    Takt time is the available production time divided by the customer demand over the same period.

  • Ideal cycle time

    The ideal cycle time is the shortest time in which a machine can produce one unit of a given product under good conditions.

  • Micro-stop

    A micro-stop is a stop short enough that it is cleared on the spot and rarely recorded by hand: a jam, a misfeed, a sensor that needs a reset.

  • OEE

    Overall Equipment Effectiveness is the share of planned production time that produced good parts at full speed.

Frequently asked questions.

At any moment one resource limits output, but which one can change with the product mix, the shift or a recurring fault. A constraint that moves is usually a sign that two machines are close in capacity, and both need watching.

Plan the change before it reaches the line.

Request a demo and an engineer looks at how your production runs today, shows how the software would fit around it, and where a pilot on one line would start.

How the demo works
  1. 01Pick a time

    Choose a slot in the calendar, and note what you make and what reads your machines today.

  2. 02Screen shared with an engineer

    A video call with someone who builds the software, in English or French.

  3. 03What would connect

    For each machine, its path: native (OPC UA, MQTT or HTTP push), through a gateway, or nothing to build.