OEE Calculation Example for a CNC Aerospace Shift

OEE Calculation Example for a CNC Aerospace Shift

If your ERP says a work order “ran all day,” but you still shipped fewer parts than the traveler implied, you don’t have a reporting problem—you have a visibility problem. On a high-mix aerospace job, the lost time usually isn’t one dramatic breakdown. It’s first-article approval waiting, tool touch-offs, chip-clearing pauses, an inspection queue, and small cycle-time creep that no one writes down consistently.

This OEE calculation example walks through one CNC machine on one shift using realistic inputs and “messy” constraints. The point isn’t to produce a score for a meeting. It’s to turn the shift into a loss map you can act on today—then repeat across machines and shifts without relying on end-of-week spreadsheets.

TL;DR — OEE calculation example

• You only need five inputs: planned production time, downtime, ideal cycle time, total count, good count.

• Availability is driven by stopped time inside the planned window (including “ready but waiting” decisions you define).

• Performance exposes speed loss from micro-stops and cycle-time drift even when the machine “ran.”

• Quality separates output loss (scrap/rework) from time loss; both matter operationally.

• First-article and inspection holds can dominate the shift if you don’t classify them consistently.

• Two shifts can run the same job and still show different Availability and Performance due to short stops and support readiness.

• The most useful next step is identifying which component moved and what to verify on the floor within 24 hours.

Key takeaway OEE is most valuable when you treat it as a breakdown of where time and output were lost—not a number to defend. When your ERP “run time” doesn’t match actual machine behavior, the gap usually comes from waiting, short stops, and approval/inspection constraints that vary by shift. Calculate OEE from trustworthy inputs, then use the component losses to recover capacity before you consider adding machines or overtime.

The aerospace shop-floor setup: one machine, one shift, real constraints

Scenario: a 5-axis mill is running a tight-tolerance aluminum aerospace bracket in a small lot. The traveler includes documentation, first-article inspection (FAI) expectations, and an in-process inspection gate before parts can move to the next operation. This is typical high-mix work: programs get tweaked, offsets get touched, and inspection can become a pacing constraint even when the machine is physically capable of cutting.

Time window: one day shift. For this example, we’ll use planned production time as “the portion of the shift intended for this machine to produce parts,” excluding the formal lunch break. (You can choose other rules in your shop; the key is that you apply them consistently across machines and shifts.)

Real losses we will account for in the math:

• Setup and probing activity that occurs inside the planned window

• First-article approval and an inspection queue hold (machine ready, paperwork/inspection not ready)

• Tool changes and offset adjustments (some logged as stops, some showing up as slower cycles)

• One unplanned stop (alarm/chip issue) that halts production

Goal: compute OEE for this machine/shift, then identify the biggest utilization leakage—the losses that quietly consume capacity and make the schedule feel “tight” even when you’re staffed and the machine is available.

OEE inputs you actually need (and where shops mis-measure them)

For a usable OEE calculation, keep it simple. You need five inputs, and you need to trust them:

• Planned Production Time (PPT): minutes you intended the machine to produce during the window

• Downtime: minutes the machine was not running inside PPT (by your rule set)

• Ideal Cycle Time: the best-known, repeatable cycle time for this operation (not the quote)

• Total Count: all parts produced (including scrap/rework pieces, depending on how you count attempts)

• Good Count: parts that met requirements and can move forward (including “accepted after rework” only if that’s your rule)

Downtime boundaries matter, especially in aerospace. In this example, we’ll count “machine ready but waiting on inspection sign-off” as downtime because the spindle is not producing within the planned window. That choice exposes the operational constraint (inspection capacity) rather than hiding it in a paperwork bucket. Another shop might exclude that time from PPT if inspection is considered outside the machine’s responsibility—but then you must apply that logic every day, on every shift, or comparisons will mislead you.

Common mis-measurement traps that make OEE useless:

• Planned time vs scheduled time: counting meetings, training, or “no operator assigned” as machine opportunity can distort Availability and create arguments instead of decisions.

• Counting “waiting” as running: if an operator marks “in process” while the machine is stopped for a cart, tool, or inspection, your ERP will look fine while the floor loses hours.

• Ideal cycle time from quotes: quoting assumptions include buffers; OEE needs a best-known achievable cycle for the operation under stable conditions.

• No reason-coded stops: without consistent stop reasons, you can compute OEE but you can’t move fast on what caused the loss. This is where disciplined machine downtime tracking becomes the difference between a KPI and a daily management tool.

The practical aim is decision speed: when the shift ends, you should be able to say, “We lost time to inspection queue and short tool-related pauses,” and validate it quickly—without rebuilding the day from memory.

OEE calculation example (with numbers): Availability × Performance × Quality

Here’s a single-machine, single-shift example with internally consistent numbers. Assume an 8-hour shift with a 30-minute lunch excluded from planned time.

Input	Value	What it represents on the floor
Planned Production Time (PPT)	450 minutes	480 minutes scheduled minus 30-minute lunch
Downtime (within PPT)	95 minutes	Setup/probe (30), first-article/inspection hold (40), chip/alarm stop (25)
Ideal Cycle Time	6.0 minutes/part	Best-known stable run for this op, excluding unusual interruptions
Total Count	50 parts	Total pieces completed through the cycle during the shift
Good Count	48 parts	2 parts scrapped/rejected for nonconformance

Step 1: Availability

Run Time = Planned Production Time − Downtime = 450 − 95 = 355 minutes

Availability = Run Time / Planned Production Time = 355 / 450 = 0.789 (78.9%)

Note what’s inside that 95 minutes: this is where aerospace realities show up. The machine is mechanically fine, but first-article approval and inspection queue time can still consume planned production minutes if the process gate isn’t ready.

Step 2: Performance

Performance compares how fast you ran while you were running.

Ideal Time to Produce = Ideal Cycle Time × Total Count = 6.0 × 50 = 300 minutes

Performance = Ideal Time to Produce / Run Time = 300 / 355 = 0.845 (84.5%)

Where does Performance loss come from in a CNC cell? Often it’s cycle creep plus small interruptions that don’t get recorded as formal downtime: extra tool touch-offs, chip clearing, program edits between parts, and longer-than-expected in-cycle probing. Those add minutes without necessarily triggering a “stop” entry—one reason many shops move toward near-real-time capture with machine monitoring systems to keep inputs trustworthy.

Step 3: Quality

Quality = Good Count / Total Count = 48 / 50 = 0.960 (96.0%)

In aerospace work, Quality loss can include scrap and also rework loops (documentation, MRB dispositions, re-inspection). For this example, we’ll keep it clean: two parts are rejected and don’t count as good output for the shift.

Step 4: OEE

OEE = Availability × Performance × Quality

OEE = 0.789 × 0.845 × 0.960 = 0.640 → 64.0% (rounded)

This number is only meaningful because every input ties back to an observable event: time lost to inspection/approval gates, time lost to a true stop, speed loss while “running,” and yield loss from rejects.

Read the result like a loss map (not a score): where the hours went

Now use the components to locate the leakage:

• Availability loss (downtime-driven): 95 minutes of planned time had the spindle stopped. In this example, the biggest single bucket is first-article + inspection hold (40 minutes). That’s not a maintenance issue; it’s a flow constraint.

• Performance loss (speed-driven): you had 355 minutes running time, but only 300 minutes were “ideal.” The difference (55 minutes) is where micro-stops and cycle-time variance hide. This is why OEE can reveal gaps between ERP-reported “in process” and actual machine behavior.

• Quality loss (output-driven): 2 rejected parts consume material, inspection effort, and often extra machine time elsewhere—plus they reduce the good output you thought you were buying with that shift.

Dominant loss to investigate first: the inspection/first-article gate, because it directly removed productive minutes and can repeat across many jobs. On the floor, the 24-hour actions are straightforward:

• Ask: “When the machine was ready, what exactly were we waiting on—inspector availability, CMM program, paperwork packet, calibration status, or a queue rule?”

• Verify the stop reason codes reflect reality (avoid a generic “down” bucket that can’t be acted on).

• Compare cycle logs or part-to-part times to the best-known run: where did cycle time stretch—probing, chip evacuation, tool changes, or feed adjustments?

Weekly averages tend to bury the issue. A week can look “fine” while the shop keeps bleeding 5–15 minute waits and short stops that add up across a 20–50 machine fleet. That’s why many teams pair OEE with daily utilization review using machine utilization tracking software: the goal is to see recurring loss patterns while you can still change tomorrow’s plan.

Mid-shift diagnostic (practical, not theoretical): if your team debates whether the problem is “maintenance” or “people,” the OEE breakdown forces a clearer question—did we lose time because we were stopped, because we ran slower than expected, or because parts didn’t pass? That decision filter prevents you from chasing the wrong fix.

Mini-variation: how one inspection hold or cycle-time drift changes OEE

To make OEE useful in daily management, you need to understand sensitivity: which component moved, and what that implies operationally. Below are two mini-variations based on the same shift.

Scenario A (inspection hold): add a 45-minute inspection queue delay

Keep counts and ideal cycle the same, but downtime increases by 45 minutes because the machine finishes the first piece and then sits while inspection sign-off is delayed (FAI/verification gate). New downtime = 95 + 45 = 140 minutes. Run Time = 450 − 140 = 310 minutes.

• Availability = 310 / 450 = 0.689

• Performance = (6.0 × 50) / 310 = 300 / 310 = 0.968

• Quality = 48 / 50 = 0.960

• OEE = 0.689 × 0.968 × 0.960 = 0.640 (about 64.0%)

Notice what happened: OEE barely changed because Performance improved (less running time to produce the same count makes the speed ratio look better). This is exactly why consistent definitions matter. If inspection holds are frequent, you can’t rely on OEE alone as a “score” without also looking at the loss buckets. Operationally, you would still treat this as a capacity problem—your machine is waiting, even if the math offset looks neutral.

Scenario B (cycle-time drift): cycle increases by 8% from tool wear/chip control

Now keep downtime as original (95 minutes), but actual running is slower due to chip management and conservative feed adjustments late in the shift. Instead of needing 355 minutes to make 50 pieces at the observed pace, suppose Run Time becomes 379 minutes (24 minutes slower overall). Availability changes because Run Time increased: Downtime would then be 450 − 379 = 71 minutes (fewer recorded stops), but Performance will drop.

• Availability = 379 / 450 = 0.842

• Performance = 300 / 379 = 0.792

• Quality = 0.960

• OEE = 0.842 × 0.792 × 0.960 = 0.640 (about 64.0%)

Again, the OEE can land in a similar range while the reality changes drastically. Managerial takeaway: don’t “manage the final OEE.” Manage the component that moved. If Performance dropped, look at tool life practices, chip control, probing inflation, and whether short pauses are being captured as downtime or just stretching cycles.

This is where near-real-time interpretation helps: not a dashboard for its own sake, but a faster path from raw signals to “what changed today?” Some teams use an assistant layer to summarize anomalies and recurring stop patterns (see AI Production Assistant) so supervisors aren’t manually reconciling notes across shifts.

Make the calculation repeatable across 10–50 machines and multiple shifts

A single worked example is helpful, but the real value comes when you can repeat it across a mixed fleet and multiple shifts without debates over definitions.

Standardize the rules that drive the inputs. Decide (and document) what counts as planned production time, what gets tagged as downtime, and how you treat inspection holds. Then standardize reason codes so “waiting on inspection,” “waiting on setup cart,” and “tool touch-off” don’t all collapse into “misc.” The objective is operational visibility: when you see a loss bucket grow, you can assign it to the right owner quickly.

Make shifts comparable on purpose. Required scenario: Shift A runs steady cycle times with few micro-stops; Shift B runs the same work order but has more short pauses—tool touch-offs, chip management, and waiting on a setup cart. In OEE terms, Shift B often shows lower Performance (cycle stretching) and/or lower Availability (more recorded short stops), even though the job, program, and print are identical. That’s not an argument about effort; it’s a signal about support readiness, standards, and how work is staged.

Use a daily cadence, not month-end reporting. A practical rhythm is a short daily review of top losses by machine and shift. You’re not hunting perfection—you’re preventing small, repeated losses from becoming the default. OEE supports that by separating “stopped,” “slow,” and “bad output,” which makes the next question obvious.

Reduce manual input wherever possible. Manual spreadsheets can work for one machine, one week—until you scale to 20–50 machines and the data stops being trustworthy. The more your calculation depends on someone remembering stop times and counts at the end of the shift, the slower your decisions get. That’s why many shops treat monitoring and tracking as a capacity recovery tool: first eliminate hidden time loss, then decide whether you truly need more equipment.

If you’re considering making this repeatable with software, frame the cost conversation around implementation reality and operational discipline rather than sticker price. Ask what it takes to get trustworthy downtime reasons, consistent planned-time rules, and shift-to-shift comparability. For a practical sense of packaging and rollout expectations, you can review pricing—but the real “cost” is usually whether the data is credible enough to make same-day decisions.

If you want to pressure-test your own OEE inputs (planned time rules, downtime boundaries, ideal cycle source) against what your machines actually did, we can walk through one of your machines and one shift exactly like the example above. Use schedule a demo to run a diagnostic review focused on where time is leaking and how to capture cleaner inputs across shifts.