You know the line can do more. The nameplate on the case packer says a certain number of cases a minute, the filler upstream is rated higher still, and yet at the end of the shift the count comes up short again. Not dramatically short, just enough that you're running Saturdays to make the number, or fielding the question of whether it's time to quote a second line. Before anyone signs off on new steel, it's worth asking where the missing hours actually went, because on most high-speed packaging and converting lines a good share of the capacity you're chasing is already inside the equipment you own. You just can't see it from the daily production report.
The trouble is that the report averages everything into one flat number, and a flat number hides exactly the losses you can do something about. A line that spends its day dying in three-second increments and a line that took one long unplanned outage can post the same shift total. They are different problems with different fixes, and only one of them is worth a capital request.
What OEE is actually telling you
Overall Equipment Effectiveness (OEE) is the standard yardstick for this, and it's a good one as long as you build it honestly. It's three factors multiplied together: availability, the share of scheduled time the line was genuinely running; performance, how close it ran to its rated speed while it was running; and quality, the fraction of what it made that you could actually ship. Multiply the three and you get a single percentage.
The multiplication is where people get surprised. A line at ninety percent availability, ninety percent performance, and ninety-five percent quality is not sitting in the ninety-something range. It works out to around seventy-seven percent, and that gap between the three headline numbers and the product of them is usually the first thing a plant learns when the measurement is done properly. The second is where the losses actually sit. Most teams assume the problem is availability, the big visible stoppages, because those are the ones that get shouted about across the floor. The loss that most often gets missed is performance: the line technically running, counter ticking over, but at a cadence below what it's rated for. That one never trips a downtime alarm, so it never lands on anyone's desk, and on plenty of lines it turns out to be a bigger number than anyone expected.
Count the whole changeover, not just the swap
Changeover, the move from one product or format to the next, is the loss you have the most direct control over, because it happens on a schedule you set rather than at random. It's also the one most often measured wrong. A lot of plants clock changeover from last good case of the old run to first attempt on the new one, then quietly leave out the twenty minutes of speed-up, jam-clearing, and reject-sorting before the line settles into a clean rhythm. That ramp is changeover too. If you're not counting it, you're understating the loss and overstating how well the swap went.
The useful lens is separating the work that must happen while the line is stopped from the work that could happen while it's still running the previous job. Staging the next format's change parts at the machine, pre-kitting tooling, prepping the recipe on the human-machine interface (HMI) so the operator isn't keying setpoints during the stop: none of that needs the line down, yet on plenty of lines all of it happens during the stop because that's how the routine grew up. Pulling that preparation forward is usually the best return you'll get for the money, since it costs you controls work and floor discipline rather than a new machine. Whether it's your single biggest lever depends on your loss profile, which is the whole reason to measure before you conclude.
Micro-stops hide inside your definition of "running"
Micro-stops are the short stalls, a few seconds each, where the line faults and recovers before anyone can walk over to it: a carton that didn't square up in the magazine, a photo-eye that saw a shadow that wasn't there. Individually they're nothing. Across a shift they can quietly eat an hour, and because each one is shorter than the threshold your controls use to log a real stoppage, they frequently don't show up in the downtime data at all. In a clean Six Big Losses breakdown they don't even count as availability loss; they surface as reduced throughput, which puts them in the performance bucket alongside plain speed loss. The line reports itself as running. The counter disagrees.
Catching them is a measurement problem first. Downtime thresholds on real lines usually sit somewhere in the two-to-five-minute range for the availability bucket, which is precisely why sub-minute stalls hide: they fall under the floor. If you want to see a three-second stall you have to drop into territory where you're arguing about what even counts as stopped versus a normal index dwell, then capture every event at that resolution and tag it by cause. That's first-out fault logic and state capture at scan rate, buffered on the programmable logic controller (PLC) and offloaded, not a one-line setpoint change, but it's routine controls work. Do it and two or three fault causes usually account for most of the micro-stop time. Once they're ranked you know where to point a mechanic, or a bit of logic, instead of guessing.
Jam recovery: the sequence matters more than the sensor
When a jam does happen, how the line comes back matters as much as how often it jams. A well-built recovery routine knows what's upstream and downstream of the fault, holds the infeed so product doesn't keep piling into a blockage, and brings the line back up in an order that doesn't immediately cause the next jam. A poorly sequenced one dumps everything to a hard stop, throws a generic alarm, and leaves the operator to clear product by hand and restart into a half-full machine that faults again within a minute. The mechanical jam might take ten seconds to clear; the badly handled recovery costs several times that, every time, and it trains operators to run the line slow on purpose because slow feels safer than fighting restarts.
Holding the infeed only works if there's somewhere for the product to go. That's the part people skip: you can hold back the flow just long enough for accumulation upstream to absorb it, and if the line isn't balanced or the buffer isn't sized for it, all you've done is move the blockage up the line and starve yourself on the restart. Sequencing and interlocks are necessary; the accumulation to back them up is what makes them work. The fix here usually lives in the recovery logic and the line balancing rather than in the sensor that caught the jam, which is why adding a more sensitive detector to a line that recovers badly just gives you more well-detected stoppages.
What this looks like on a real plant
A cartoning line running single-serve product, a few years back: the crew was convinced the machine was worn out and wanted it replaced, and the shift numbers backed them up, roughly. OEE was sitting around sixty percent and everyone assumed the losses were downtime. When we actually instrumented it, availability was fine and quality was fine. Almost all of the loss was performance, and most of that was micro-stops that never logged. The cartoner was faulting on mis-set cartons a couple of times a minute, each stall three or four seconds, none long enough to register as a stoppage. The operators had done the sensible thing and dialed the line speed down so the fault rate felt manageable, which meant the machine spent its day running well below rate while appearing to run continuously.
Two things closed most of the gap and took OEE into the mid-seventies. We dropped the event-logging resolution so the stalls became visible and rankable, and the ranking pointed straight at the carton magazine: a vacuum pickup that had lost performance as the cup aged, and a magazine guide sitting out of adjustment. Then we rebuilt the recovery sequence so a mis-feed held the infeed and cleared cleanly instead of dumping to a full stop. With the fault rate down, the operators trusted the line enough to run it near rate again, and there was no new cartoner. The honest footnote is that the pickup and the guide were mechanical problems, and no amount of logic would have fixed either. The controls work made them visible and cheap to find. It didn't replace the wrench.
Where software stops
Software has a ceiling, and it's worth being blunt about that. Sometimes the real answer on a packaging line is a worn timing screw, a chute with the wrong geometry, a misfeeding hopper, or a format part that's simply past its life, and the most useful thing good measurement does is tell you that quickly instead of sending you chasing a cleverer loop that was never going to help. Tuned recovery logic and honest OEE data will find you real hours on most lines. They won't conjure capacity out of hardware that's genuinely worn out, and it's worth being suspicious of anyone who says they will.
Start with measurement you trust. Count the ramp in your changeovers, log the stalls that are currently too short to see, and separate performance loss from availability loss so you know which problem you actually have. If you'd like a second set of eyes on where a line's hidden hours are going before you commit to new equipment, get in touch and we can talk it through.