Food manufacturing OEE and SCADA integration. Getting a number the GM trusts.

OEE in one paragraph.

When was the last time the OEE figure on the plant dashboard changed a decision?

OEE is Availability times Performance times Quality. Each component is a fraction between zero and one. Availability is the fraction of planned production time the line was actually running. Performance is the fraction of ideal cycle speed the line achieved when it was running. Quality is the fraction of output that passed first time. The three numbers multiply. A plant that hits 90% on each of the three components has an OEE of 73%, not 90%. That is the part of the formula most plant managers learn about three weeks after the dashboard goes live.

The metric is useful because it consolidates three different kinds of loss into one number. The losses are independent: a line can run all shift (high availability) at half speed (low performance) producing perfect product (high quality). OEE catches the combined effect, which is what the GM is paying for.

The 85% trap.

Seiichi Nakajima proposed the 85% world-class figure in his 1984 book on total productive maintenance. The numbers behind it are deliberate: 90% Availability, 95% Performance, 99% Quality. Multiply them and the result is 84.6%, rounded to 85. The benchmark has stuck for forty years because it remains demanding without being arithmetically impossible.

What the benchmark does not say is how broadly it applies. Industry data, surveyed across more than fifty countries, places the global average for discrete manufacturing between 55% and 65%. Roughly 6% of plants reach 85% or higher. High-volume, repetitive lines — automotive assembly, FMCG packaging, single-SKU canning — can realistically chase 85%. High-changeover lines, complex setups, and precision-critical products (aerospace, pharmaceuticals, multi-SKU bakery, fresh pasta) typically consider 70-75% to be world-class for their context.

Australian food manufacturing follows the pattern. A single-line UHT plant running one SKU around the clock has a structural shot at 85%. A bakery running ten SKUs per shift with three allergen-segregation changeovers does not, even on a best-managed day. Targeting 85% on the bakery is targeting the wrong number. A plant manager who pursues a benchmark structurally out of reach for the line they actually run produces stress, not improvement.

The benchmark is useful as a directional anchor, not as a universal target. Each line needs its own world-class number, set by the structural characteristics of what it makes.

Where to actually capture the three numbers.

The arithmetic is simple. The data capture is where projects fail.

Availability — from the line state.

The line's state machine in the PLC is the source. "Running" is a state. "Stopped — planned" and "Stopped — unplanned" are different states. The SCADA logs state transitions with timestamps. Availability is total Running time divided by total Planned Production time. The data lives in the PLC. The job of the SCADA is to log it cleanly and the job of the database is to aggregate it. Most projects fail not at the logging but at the state-machine definition: a line whose PLC code does not distinguish planned from unplanned stops cannot produce a clean Availability number, period.

Performance — from the count and the ideal cycle.

Total Count is the actual output for the period. Ideal Cycle Time is the design speed of the line in seconds per piece, set by the OEM specification or by an agreed plant standard. Performance is (Ideal Cycle Time × Total Count) divided by Running Time. The data comes from the line's piece counter (a photoeye, a conveyor encoder, the fill or capper count) and the running-time accumulator. The trap is the Ideal Cycle Time: if it is set to "what the line did on its best day" rather than "what the line is designed to do," Performance is structurally optimistic.

Quality — from the reject count.

Quality is Good Count divided by Total Count. Good Count is Total Count minus rejects, minus rework. The reject count comes from the line itself (a vision-rejected can, a metal-detector-rejected pack) or from downstream QA (a held batch, a customer return). The Quality number gets contentious because plants disagree about whether rework counts as a quality loss or a productivity loss. Pick one definition and apply it consistently.

Micro-stop classification — the decision that breaks dashboards.

A micro-stop is a short line stoppage, typically defined as anything under a threshold (commonly 30 seconds to 5 minutes). Below the threshold, the stoppage is too short to investigate individually. Above the threshold, it is logged as a downtime event with a reason code.

The threshold matters because micro-stops accumulate. A line with thirty 90-second micro-stops per shift is losing 45 minutes of running time, but if the threshold is 5 minutes, every one of those stops disappears into the Performance number rather than the Availability number. The Availability looks great. The Performance looks bad. The plant manager spends three months trying to fix a Performance problem that is actually a hundred small Availability problems.

The plants that get real value from OEE do three things differently on micro-stop classification:

• Set the threshold deliberately, not by default. 30 seconds catches everything; 5 minutes hides the chronic small problems. The right threshold depends on the line's design cycle time and the typical fault distribution. A canning line at 1,200 cpm needs a tighter threshold than a slow batch mixer.
• Track micro-stop frequency, not just micro-stop duration. Frequency tells you whether the line has a structural problem. Duration tells you how bad each instance is. Both matter.
• Build a reason-code dictionary that operators can use without coaching. A reason-code list with 40 options gets compliance for 20 minutes and "Other" for the rest of the shift. Eight to twelve well-chosen options, each meaningful in the line's context, gets honest data.

Planned versus unplanned downtime — the boundary plants get wrong.

Planned downtime is outside the OEE calculation. Unplanned downtime drags the Availability number down. Where the boundary sits is therefore the most consequential single configuration decision in the SCADA OEE setup.

The honest definitions:

• Planned downtime is anything the plant scheduled in advance and the customer was not promised production through. Changeovers, scheduled CIP, planned maintenance, no-demand idle time, shift breaks if the line shuts during breaks.
• Unplanned downtime is anything else. A jam, a fault, a missing material, a supply-side shortage that should have been forecast, a quality hold.

The reason plants get this wrong is local optimisation. The plant manager whose bonus depends on OEE has an incentive to classify ambiguous events as "planned." A material shortage caused by a late supplier becomes "planned demand idle." A long cleaning event that was supposed to take 30 minutes and took 90 becomes "planned CIP." Each individual reclassification is defensible. Cumulatively they make the Availability number a fiction.

The fix is governance, not technology. A written policy that defines the planned-versus-unplanned boundary, a quarterly audit by someone outside the line management chain, and a public reporting layer that prevents quiet reclassification after the fact. A plant whose OEE figure does not survive a finance-team audit is a plant whose OEE figure does not survive any other audit either.

Building an OEE the GM actually trusts.

The path from a fresh SCADA install to an OEE figure the GM reads at a board meeting is not technical. The technical part is mostly solved by Ignition, AVEVA, FactoryTalk View SE, and the open-source data stack any of them can sit on top of. What separates a trusted OEE from a decorative one is the policy work that surrounds it.

The five things that consistently work:

• One owner. A single named person responsible for the OEE definition, the line state-machine, the micro-stop threshold, the planned-downtime policy, and the reporting layer. Not a committee. The owner can be a plant engineer, a production manager, or a continuous-improvement lead. They cannot be everyone.
• Written policies that an auditor could verify. Micro-stop threshold, planned-downtime boundary, Ideal Cycle Time per SKU, reject classification rules. Documented, dated, version-controlled. Reviewed annually.
• A standing data-quality check. A weekly or fortnightly review that compares the SCADA-derived OEE against a manual sample of the same shift, performed by someone other than the OEE owner. Drift between the two numbers is the early warning.
• Three-number reporting, not one. Show A, P, and Q separately, with the OEE figure as the multiplied result. The plant manager can debate which leg is weak. The dashboard that shows only the headline number invites disbelief.
• A target appropriate to the line. Not 85% on every line. A line-specific target derived from the line's structural characteristics, set by the OEE owner, agreed by the GM, and reviewed once a year.

The plants that have done this work do not talk about OEE anymore. They talk about specific Availability losses, specific Performance losses, and specific Quality losses, with the OEE figure as the audit-trail summary at the end of the conversation. That is what a trusted number looks like in practice.

Common questions.

Sources and further reading.

Industry and standards references for the benchmark and methodology claims above. Retrieved 18 May 2026.

• Lean Production. OEE — Overall Equipment Effectiveness. leanproduction.com
• Nakajima, Seiichi. Introduction to TPM: Total Productive Maintenance, 1984. (Original source for the 85% world-class benchmark.)
• Evocon. World-Class OEE: Industry Benchmarks from More Than 50 Countries. evocon.com
• OEE.com. World-Class OEE: Set Targets To Drive Improvement. oee.com

This article sits under the Food & Beverage Automation guide. For the batch-control side that feeds OEE on recipe-driven lines, see the ISA-88 article. For the SCADA-platform decision that often sits underneath an OEE rollout, see the Ignition vs Wonderware spoke.