Production Monitoring and OEE: How to Measure Shop Floor Performance

The most argued-about question in a manufacturing business is this: "how much does that machine actually run?"

The production manager says "close to full capacity". The shift supervisor says "something always comes up in the mornings". Accounting looks at cost per unit and says "there is a loss here". All three are right, because none of them is measuring the same thing.

A production monitoring system ends that argument. What it does is not magic: it turns what happens on the floor into a single record. OEE is that record reduced to a single number.

What does a production monitoring system do?

In practice it has three layers:

1. The signal layer. It automatically collects whether the machine is running and how many units it has produced. On newer machines that information already sits in the controller. On older machines a counter, a relay or a simple sensor does the same job — machine age is far less of an obstacle than most people assume.

2. The operator layer. When a machine stops, only a person can say why. Tooling change, waiting for material, breakdown, break? That input comes from a terminal on the floor, a tablet, or a simple barcode list.

3. The context layer. Which work order, which product and which shift the stoppage belongs to. Without it the data can say "the machine stopped" but not "which job lost us money".

Put the three together and you can state this sentence for the first time: "Last month we had 62 hours of unplanned downtime; 28 hours were tooling changes and 19 hours were waiting for material." From that moment the discussion moves from opinion to measurement.

What is OEE and how is it calculated?

OEE (Overall Equipment Effectiveness) is the product of three components:

OEE = Availability × Performance × Quality

• Availability: how much of the planned time the machine actually ran. Breakdowns, tooling changes and material waits reduce it.
• Performance: how fast it produced compared with its design speed while running. Slow cycles and micro-stops show up here.
• Quality: how many of the units produced came out right the first time. Scrap and rework reduce it.

An illustrative calculation:

• Planned shift time 480 minutes, unplanned downtime 60 minutes → 420 minutes running. Availability = 420 / 480 = 87.5%
• Ideal cycle time 30 seconds, 700 units produced → theoretically 350 minutes of work. Performance = 350 / 420 = 83.3%
• 21 of the 700 units are scrap → Quality = 679 / 700 = 97%
• OEE = 0.875 × 0.833 × 0.97 ≈ 70.7%

The value of that number is not in itself but in its components. A manager who sees 70.7% says "bad"; a manager who reads the components says "our real loss is speed" and fixes the right thing.

Is the "85% world class" target realistic?

The 85% threshold often cited in OEE literature comes from Seiichi Nakajima, the originator of Total Productive Maintenance, and is used as a world-class benchmark by the Japan Institute of Plant Maintenance. The component targets behind it are: 90% availability, 95% performance and 99.9% quality — multiplied together, roughly 85%.

Two things are worth knowing before adopting it as a target. First, the achievable level differs by production type: a continuous line and a line that changes tooling five times a day cannot be judged on the same scale. Second, and more importantly, your own baseline is more valuable than any benchmark. Whatever number comes out of the first month, the real question is what it looks like three months later.

In our experience the most common result of a first measurement is this: the number comes out lower than everyone expected. That is not bad news; it is the sign of standing on real ground for the first time.

How should downtime reasons be coded?

This is where the success of the system is decided, and it is usually the least considered part. Three rules:

Keep the list short. Eight to twelve reasons are enough. Nobody reads a list of thirty; the operator picks the top option and your data is ruined.

Use the operator's language. Not "feed-related line interruption" but "waited for material". The code list is written on the floor, not in the office.

Watch the "other" share. If more than 10% of stoppages are marked "other", the list is wrong. That ratio is the fastest indicator of data quality; for the wider frame see why data quality matters.

Also define planned stoppages up front: breaks, planned maintenance, shift handover. Whether they are included in availability is a matter of choice — but it must be a written choice. Otherwise nobody will know what the numbers measure two months later.

Where do you start?

Connecting the whole plant at once is the most expensive and slowest route. The sequence that works:

1. Pick the bottleneck. Start measuring at whichever machine sets the pace of the line. Raising OEE on a non-bottleneck machine only grows work in progress — a trap we also covered in inventory management for SMEs.
2. Run a two-to-four-week pilot. One machine, one code list, a simple screen. The goal is real data, not a perfect system.
3. Read the pilot result with the team. The first meeting should be spent fixing the code list, not defending the numbers.
4. Then expand. Second machine, second shift, then the line. The code list settles a little more at each step.

Who sees the data and how often should also be settled up front: an end-of-shift board on the floor, a weekly downtime breakdown for the production manager, a monthly trend for management. For how to build those screens see designing an effective dashboard, and for choosing what to track, choosing the right KPIs.

Three mistakes that make OEE meaningless

1. Turning it into a performance scorecard. If operators get questioned whenever OEE drops, next month the data improves — reality does not. A downtime record is a map of where the problem is, not an instrument of blame. When that trust disappears, the system collapses.

2. Optimising a single machine. A plant's output is the speed of its slowest link. Efficiency won on the wrong machine usually comes back as a pile of work in progress.

3. Separating measurement from action. A setup that produces reports and changes nothing becomes a screen nobody opens within a few months. Every measurement cycle should end with one correction decision — ideally aimed at the largest downtime category.

On eliminating repetitive manual steps, business process automation and RPA may also help.

How do you fund the investment?

A production monitoring system is one of the easiest investments to justify under digital transformation support programmes: the downtime and scrap figures you measure are exactly the baseline an application file needs. We covered the open call period and the steps that strengthen a file in planning a software investment with SME grants.

If you are curious what such a setup looks like, take a look at our production data reporting system project.

Conclusion: the record first, the number second

OEE is a diagnostic tool, not a target. Its value lies in showing which of the three components is dragging you down. And no calculation can be better than the quality of the record coming off the floor — which is why most of the investment goes not into the screen, but into recording stoppages correctly.

If you would like us to build a setup that measures downtime on your line, work out how to collect data from your existing machines, or design your OEE dashboard, get in touch; to see how we work, take a look at our services.