OEE How to Calculate (CNC Job Shop Step-by-Step)

OEE How to Calculate (CNC Job Shop Step-by-Step)

Most “OEE” numbers in CNC job shops aren’t wrong because the formula is complicated—they’re wrong because the inputs don’t match what actually happened on the floor. If your ERP says the work order is on track, but the pacer machines felt starved, interrupted, or stuck waiting on inspection, your OEE math will drift unless you lock down the same time window, loss categories, and count rules every shift.

This guide stays calculation-first: you’ll set a repeatable measurement boundary, build a simple time model that survives real CNC conditions (setups, first-article approvals, rework loops, mixed runs), and run a worked example you can replicate in a spreadsheet.

TL;DR — OEE how to calculate

• Pick one measurement window (per machine, per shift is usually most actionable) before using any formulas.

• Define “Scheduled/Planned Production Time” and keep the same exclusions across shifts.

• Availability depends on planned vs unplanned classification; standardize ambiguous items (first-article, inspection hold, program edits).

• Performance only works in high-mix when Ideal Cycle Time is defined per part + operation + machine (or weighted for the shift mix).

• Quality must be counted at the operation’s output; don’t retroactively distort earlier ops when a later op scraps a part.

• Avoid averaging OEE across machines/ops; if you aggregate, weight by run time (or planned production time).

• Use the result to locate utilization leakage (Availability vs Performance vs Quality) before assuming you need more machines.

Key takeaway OEE becomes comparable and actionable only when you standardize the time window, loss buckets, and “good vs total” counting rules across shifts and across operations. That consistency closes the gap between ERP-reported progress and actual machine behavior, making hidden idle patterns and capacity loss visible without changing the math.

Start with the only decision that matters: what time window are you measuring?

Before Availability/Performance/Quality, choose the unit of analysis you’ll live with operationally. For CNC job shops, the most actionable choice is usually machine-level OEE per shift. It aligns with how problems show up: one shift waits on first-article longer, another has more tool-related interruptions, or a specific machine spends more time in short idle states between small runs.

Next, pick which “time” you mean and stick to it:

• Calendar time: 24/7 window. Useful for facility-level thinking, but it punishes you for hours you never intended to run.

• Staffed time: when an operator is assigned (or the cell is staffed). Better for multi-shift comparison, but still needs clear exclusions.

• Scheduled production time: the portion of the shift you expected to produce (after planned exclusions like breaks). This is the most common denominator for Availability in day-to-day shop math.

Rule for comparing shifts: comparisons only mean something if the same window and the same exclusions are used. If Shift A counts “first-article waiting on QC” as unplanned downtime and Shift B treats it as planned, you’ll “discover” a shift gap that is really a definition gap—fix the model before you fix the people.

Build your time model: Planned vs unplanned losses (with CNC examples)

OEE lives or dies on your time model. The goal isn’t perfect detail on day one; it’s repeatable buckets that match what supervisors and operators can apply consistently across machines and shifts. If you’re capturing this manually today, keep it simple enough to survive a clipboard and still be useful.

Common planned time exclusions (removed from the Availability denominator if you choose scheduled production time):

• Breaks and lunch

• Planned meetings / shift start-up routines (if you choose to exclude them)

• Planned maintenance windows (only if actually scheduled and broadly honored)

• Training blocks (if scheduled in advance)

Common unplanned losses (reduce Run Time and therefore Availability):

• Waiting on material, pallets/fixtures, or missing tools

• Tool breakage, offsets chasing, unexpected chatter/surface finish issues

• Program prove-out overruns and re-runs beyond what you planned

• Inspection hold / waiting on QC when it wasn’t built into the schedule

The hard part is ambiguous events. Decide once, document it, and apply it everywhere:

• First-article approval: If your schedule assumes first-article and QC response time, treat it as planned. If it’s unpredictable and regularly stalls machines, treat it as unplanned. Either is acceptable—inconsistency is the problem.

• Warmup: If it’s a standard routine at shift start, decide whether it’s planned exclusion or part of scheduled time. Use the same rule for both shifts.

• CAM/program edits at the control: If edits are expected during prove-out for new work, you might exclude a standard allowance as planned; overruns beyond that fall into unplanned.

Practical tip: if a supervisor can’t code it consistently, it doesn’t belong as a separate bucket yet. Start with fewer categories, then split them only when the data is stable enough to trust across shifts.

If you’re moving from manual logs to more automated capture later, this time model becomes the bridge between raw machine states and actionable downtime classification. For context on how shops turn interruptions into visibility, see machine downtime tracking.

Calculate Availability (step-by-step) without hiding the real loss

Availability answers: “Of the time we intended to run, how much time did the machine actually run?” Use the denominator you chose in your window definition.

Availability = Run Time / Planned Production Time

Step-by-step:

• Start with your time window (example: one 8–12 hour shift).

• Subtract planned exclusions (breaks, planned meeting, etc.) to get Planned Production Time.

• Sum unplanned downtime events within the window (waiting, tool issues, inspection holds—per your definitions).

• Run Time = Planned Production Time − Unplanned Downtime.

Micro-stops matter when they accumulate. A string of 2–5 minute pauses for chip clearing, tool offsets, or waiting for a cart can be “invisible” in ERP updates but very visible in shift-level Availability if you capture it consistently.

Multi-shift rule (required if you want a real comparison): the same planned exclusions and the same definitions for ambiguous events must apply to all shifts. This shows up immediately in the common scenario where two shifts run the same vertical mill cell and one “looks worse.” If Shift A logs first-article/QC wait as unplanned and Shift B treats it as planned (or ignores it), you haven’t found a performance problem—you’ve found a measurement mismatch. Standardize the category first, then compare.

Operationally, low Availability points you toward the floor questions: Are machines waiting on material/fixtures? Is inspection response time unpredictable? Is prove-out spilling into production? The “next step” is investigation by loss bucket, not a new KPI.

Calculate Performance in a high-mix shop: pick the right Ideal Cycle Time

Performance answers: “When the machine was running, did it run at the expected pace?” The trap in high-mix CNC is using one “standard cycle” for a machine and calling it Performance. In reality, cycle expectations change by part, operation, and sometimes even by fixture or tool strategy.

Performance = (Ideal Cycle Time × Total Count) / Run Time

Definitions you must lock down:

• Ideal Cycle Time: set this per part number + operation + machine. “Op 20 on Machine VMC-3” gets its own ideal, even if the same part runs elsewhere.

• Total Count: define whether it includes rejects/rework attempts. Most shops use total produced at that operation (good + reject) so Performance reflects pace, while Quality handles yield.

Changeovers and small runs are common on high-mix days. Keep the logic clean: Performance is not a setup metric. Setup time is handled in Availability (as planned or unplanned, depending on whether it’s excluded from the denominator). If you bury setup inside Performance by inflating Run Time to include it while still using a machining cycle as the ideal, the result becomes hard to interpret and inconsistent across shifts.

If you ran multiple part numbers in one shift, use a weighted ideal cycle time approach:

• Compute “Ideal Time” as the sum of (Ideal Cycle Time for each part/op × its count).

• Then Performance = Total Ideal Time / Run Time.

This is where manual methods start to strain: once you’re mixing jobs, micro-stops, and multiple ops, it’s easy for “ideal” to become a guess. If you want background on turning run/idle signals into consistent utilization math, see machine utilization tracking software and how shops typically evolve from spreadsheets to scalable capture.

Calculate Quality in multi-process routing: where ‘good’ is counted changes everything

Quality answers: “Of what this machine/operation produced, how much met requirements at that step?” In multi-operation routing, the biggest error is counting “good” only at final inspection and back-applying it to every prior operation. That makes earlier machines look worse (or better) for problems that happened later.

Quality = Good Count / Total Count

Practical rules for CNC routing:

• Count Good at the operation’s output (e.g., Op 10 good parts leaving the saw/lathe/mill), not at shipment.

• Handle rework explicitly: decide whether “reworked and passed” is counted as good for that operation’s Quality, and keep that rule consistent. Many shops track rework as its own count for decisions, even if Quality math stays Good/Total.

• Avoid double-counting across ops: a part can be acceptable after Op 10 and then scrapped at Op 30. Don’t retroactively reduce Op 10’s good count because of a downstream scrap event.

Required scenario: imagine a part with three operations across different machines, with WIP handoffs and a rework loop. If you use final shipped quantity as “Good” for every machine, you will inflate or deflate OEE in meaningless ways. Instead, set Good/Total per operation (what that machine produced), and set Ideal Cycle Time per operation as well. That keeps each machine’s OEE tied to its actual behavior rather than to downstream inspection or assembly outcomes.

Worked example: full OEE calculation for one CNC machine on one shift

The numbers below are illustrative. Use them as a template for your own shift log or spreadsheet.

Item	Illustrative Value	Notes (Definitions)
Time window	10 hours (one shift)	Machine-level, shift-level
Planned exclusions	0.5 hours	Breaks (excluded from denominator)
Planned Production Time	9.5 hours	$10 - 0.5$
Unplanned downtime events (sum)	1.25 hours	Material wait, tool issue, inspection hold (per your rules)
Run Time	8.25 hours	$9.5 - 1.25$
Total Count	44 parts	Good + reject at this operation
Good Count	42 parts	Accepted at this operation’s output
Ideal Cycle Time	10 minutes/part	For this part + operation + machine (illustrative)

1) Availability

• Availability = Run Time / Planned Production Time

• = 8.25 / 9.5 = 0.868 (86.8% as a computed example)

2) Performance

• Ideal Time = Ideal Cycle Time × Total Count

• = 10 minutes × 44 = 440 minutes = 7.33 hours

• Performance = Ideal Time / Run Time = 7.33 / 8.25 = 0.889

3) Quality

• Quality = Good Count / Total Count = 42 / 44 = 0.955

4) OEE

• OEE = Availability × Performance × Quality

• = 0.868 × 0.889 × 0.955 ≈ 0.736 (73.6% as a computed example)

Sensitivity check (definition change): suppose 0.25 hours of the “inspection hold” was treated as a planned exclusion instead of unplanned downtime. Then Planned Production Time becomes 9.25 hours and Unplanned Downtime becomes 1.0 hour, leaving Run Time still 8.25 hours. Availability becomes 8.25/9.25 (higher), even though the machine behavior did not change. That’s why definition standardization must come before shift-to-shift conclusions.

What to do next (questions, not tactics): If Availability is leaking, which downtime bucket dominates and on which shift? If Performance is low, are you mixing the wrong ideals across part/ops? If Quality is low, is the loss truly happening at this machine’s output or downstream?

Mid-article diagnostic: if your team can’t produce this same table reliably for two machines and two shifts without arguing about definitions, that’s the signal to simplify buckets and tighten rules—then consider whether manual capture is scaling. Background on approaches (without turning this into a product discussion) is covered in machine monitoring systems.

Multi-process reality check: how to calculate OEE across multiple operations (without averaging nonsense)

In job shops, “the part” isn’t one process—it’s a routing with handoffs, queues, and sometimes rework loops. The safe rule is: calculate OEE per machine (or per operation) first. Only aggregate after you decide how to weight it.

Why simple averaging is misleading: a machine that ran for most of the shift and a machine that ran briefly should not contribute equally to an “average OEE.” Averaging hides where time is actually being consumed.

Simple aggregation method (time-weighted):

• Compute OEE for each machine/operation in the group for the same window.

• Choose a weight (commonly Run Time or Planned Production Time) for that same window.

• Time-weighted OEE = Sum(OEE_i × Weight_i) / Sum(Weight_i).

Required scenario (high-mix day): frequent changeovers and small runs can make Availability swing depending on whether setup is included in scheduled production time or excluded as planned. If you schedule the shift assuming setups will happen, include them in Planned Production Time and record setup-related overruns as unplanned loss. If you exclude setups as planned, be honest that you are measuring “machining-only OEE,” and don’t use it to claim you have more capacity than the schedule can actually deliver.

Required scenario (three-operation routing with WIP and rework): calculate each operation’s OEE with its own Ideal Cycle Time and its own Good/Total at that step. If Op 20 reworks parts and Op 30 scraps some, don’t “smear” those outcomes backwards onto Op 10’s Quality. You’ll end up chasing the wrong machine for a downstream issue.

When OEE may be the wrong summary for a specific question: if you’re managing a clear constraint, you might focus more on adherence to the constraint schedule and uninterrupted run time. Still, having consistent OEE inputs (time window, downtime definitions, op-level counts) keeps shift reviews grounded in what the equipment actually did.

As you move from manual math toward daily visibility, the challenge becomes interpretation as much as calculation—especially when you have dozens of small interruptions and mixed routings. Tools like an AI Production Assistant can help translate raw events into consistent questions for the next shift, but the foundation is still the definitions and the spreadsheet-ready arithmetic you built above.

If you’re evaluating whether to keep this manual or make it scalable, focus on implementation realities: mixed fleets, minimal IT friction, and getting trustworthy shift-level outputs. You can see typical rollout and packaging options on the pricing page (no math changes—just how you capture and standardize the inputs).

If you want to sanity-check your current OEE definitions (especially shift-to-shift consistency and multi-op counting) against a real shop-floor workflow, schedule a demo. Bring one machine, one shift, and a week of downtime notes—we’ll map your time buckets and count rules so the calculation stays trustworthy before you scale it across 20–50 machines.