Machine Utilization in High Mix Low Volume

Machine Utilization in High Mix Low Volume: Stop Chasing Benchmarks

If your ERP says you’re “at capacity” but the floor still feels like it’s waiting on something, the problem often isn’t effort—it’s measurement. In high mix low volume (HMLV) CNC shops, a single utilization target borrowed from repetitive manufacturing tends to create two bad outcomes: teams start arguing about numbers, and leaders make decisions off a picture of the shop that’s smoother than reality.

The goal isn’t to find the “right” universal utilization percentage. The goal is to build a credible, apples-to-apples baseline by machine type and shift—one that separates necessary HMLV work (setup, prove-out, first article) from true utilization leakage (waiting, blocked handoffs, avoidable downtime) so you can recover capacity before you buy more machines.

TL;DR — machine utilization in high mix low volume

• HMLV “benchmarks” break because changeovers and variable routings are the system, not exceptions.

• Split non-cutting time into planned (setup/prove/first article) vs. leakage (waiting/blocked/avoidable downtime).

• Baseline by machine class and by shift; roll-ups hide where time is actually going.

• Use a 2–4 week window and annotate abnormal events so the baseline reflects normal mix volatility.

• Report a distribution (median + range) rather than one “target” that invites gaming.

• Daily improvement comes from short reason codes on idle/blocked states and faster shift-level decisions.

• Set goals in recovered minutes per shift (by leakage bucket), not a borrowed utilization %.

Key takeaway In HMLV, “low utilization” can be the cost of doing the right work (setup, prove-out, first-article discipline), while “high utilization” can hide starvation and wrong-priority running. A useful baseline separates planned non-cutting from true leakage and shows differences by machine type and shift so leaders can remove waiting/blocked time and tighten daily decisions.

Why utilization benchmarks break in high mix low volume shops

Most utilization “targets” assume repeatability: long runs, stable routings, predictable staffing, and a steady drumbeat of similar parts. HMLV job shops don’t operate that way. Your constraint shifts with the mix: one day it’s a 5-axis with long setups, the next it’s turning capacity because a part family suddenly pulls ahead, and by Friday it’s inspection or programming approvals.

In this environment, setup, prove-out, first-article checks, and inspection loops aren’t “exceptions” to be minimized at all costs—they are the system that prevents scrap, rework, and missed deliveries. Treating all non-cutting time as failure pushes teams to cut corners, hide time, or mis-code jobs so the KPI looks better than the flow actually is.

A single-number utilization view also hides whether losses are structural (mix-driven and planned) or avoidable (leakage). Two shops can show the same “utilization” while one is setup-heavy by design and the other is bleeding time to waiting on material, queued inspection, missing tools, and unclear priorities.

Finally, ERP and end-of-shift reporting tend to smooth reality. Operators round. Supervisors interpret. Short stops disappear. Waiting states get collapsed into “setup” or “running” so the record stays simple. If you’re trying to recover capacity, those small gaps and handoffs are where the minutes live. For a broader overview of why tracking matters (without turning this into a math exercise), see machine utilization tracking software.

The real question: what kind of ‘non-cutting’ time is unavoidable vs. leaking?

To make utilization meaningful in HMLV, separate non-cutting time into two buckets with different management responses:

• Planned non-cutting (structural): setup, tool touch-offs, proving programs, first-article processes, fixture swaps, in-process checks that prevent downstream problems.

• Unplanned losses (leakage): waiting/starved, blocked, avoidable downtime—time that should have been preventable through coordination, readiness, and faster decisions.

Leakage is where capacity is hiding. Common HMLV leakage buckets include waiting on material, tooling, program approval, inspection availability, fixture readiness, traveler clarification, and operator availability (especially when one person is pulled to “babysit” a pacer machine). These are not solved by yelling “hit 85%.” They’re solved by naming the state, assigning an owner, and tightening the handoff.

This is also why “utilization = spindle on” can mislead in job shops. Setup quality determines flow. A careful prove-out that prevents a crash or scrap run can look like “bad utilization” if you lump it into downtime. The operational question is: did planned non-cutting time enable the right work to run cleanly later, and did leakage steal time that should have been available?

When you do want more detail on capturing waiting, blocked, and downtime states with less interpretation, this relates closely to machine downtime tracking—not as a maintenance story, but as a way to expose coordination losses.

A baselining method that works in HMLV (without gaming the numbers)

A credible baseline is less about formulas and more about discipline: consistent definitions, consistent capture, and enough time to represent your normal volatility.

Step 1: Lock in time-state definitions (and make them shift-proof)

Start with a small set of states you can apply consistently: run, setup, idle/starved, blocked, and down. The value is not having 40 categories—it’s that first shift and second shift classify the same situation the same way. If you rely on manual end-of-shift notes alone, you’ll get drift (different supervisors, different interpretations). Automation is the scalable evolution here: capture machine states automatically where possible, then validate with spot checks and short reason codes.

Step 2: Baseline by machine category, not “the whole shop”

Separate baselines for 3-axis mills, 5-axis mills, turning, mill-turn, grinders—whatever categories reflect different constraints and setup profiles. HMLV variability hits each class differently. Aggregating early creates a comfortable average that hides which workcenter is starved, which is blocked by inspection, and which is spending planned time proving new programs.

Step 3: Capture at the machine level first; roll up later

Begin with machine-by-machine time breakdowns so you can see patterns: a single “pacer” that blocks handoffs, a cell that spends time waiting on inspection, or a high-changeover machine where setup variance is driving schedule chaos. Once you trust the machine-level story, then roll up by cell, shift, and machine class.

Step 4: Use a 2–4 week window and annotate abnormal events

A single week can be distorted by a large rush job, a key operator out, a machine issue, or a material shortage. Use a 2–4 week baseline window to include normal mix variability, and annotate abnormalities so they don’t become “the baseline.” This prevents the common trap where leaders overreact to an outlier week and push the shop into unstable behavior.

Step 5: Report a distribution, not a single target

In HMLV, the honest answer to “what should utilization be?” is usually a range by machine class and shift. Report median and range (or a simple band like “typical week” vs. “heavy changeover week”) so you can compare apples-to-apples. This is how you improve without gaming: you’re not chasing a universal number; you’re tightening your own variability and reducing leakage.

If you’re evaluating how to capture these states reliably across a mixed fleet (including older controls), the practical implementation discussion lives in machine monitoring systems.

Worked example: two shifts, one ‘utilization’ number, opposite realities

Here’s a hypothetical example from a multi-shift CNC cell to show why rolled-up utilization pushes the wrong actions. Assume a 5-axis mill with two shifts and a single “utilization” number reported weekly.

Rolled up, you might conclude: “Second shift is more utilized; first shift is the problem.” But the shop reality can be the opposite.

In this scenario, first shift looks ‘low’ because it carries heavy setups and prove-outs—dialing in new work, validating first articles, and staging fixtures so the cell can run stable later. That time is planned non-cutting and may be exactly what prevents scrap and rework.

Meanwhile, second shift looks ‘high’ on run time but is frequently starved of the right tools, programs, or priority jobs. So it runs what’s available—often lower-priority work—because decision-making and handoffs lag behind the schedule. That’s not a utilization win; it’s a priority-control problem.

The operational actions that follow are specific:

• Pre-stage tooling/fixtures for second shift before 1st shift ends (reduce starvation).

• Set a program release cutoff time so second shift isn’t waiting on approvals.

• Tighten inspection handoffs so first-article and in-process checks don’t become “blocked” overnight.

• Sequence setups to protect the pacer machine, not to maximize a daily utilization score.

What’s killing utilization here is decision latency: the delay between when the shop needs a decision (what runs next, what gets kitted, what gets approved) and when the decision arrives. In multi-shift shops, that latency often shows up as second-shift starvation and first-shift firefighting.

Mid-shop diagnostic to run this week: pick one pacer machine and audit 10–30 minutes at each shift transition. If the machine is waiting, write down the specific reason. If you can’t name it quickly, your measurement system is too vague to drive action.

What to measure daily to improve utilization in HMLV (without turning it into OEE theatre)

Once you have a baseline, the win is a simple daily cadence that turns time-state data into decisions. Keep it operational: fewer charts, more action.

1) Review top leakage states daily (with short reason codes)

In a high-mix scheduling day, several machines can show “idle,” but the root causes differ—and the actions differ. One machine is waiting on inspection; another is waiting on material; a third is waiting on program approval; a fourth is idle because the operator was pulled to another machine. A single benchmark target can’t fix that. A short list of reason codes can: it tells you whether to expedite inspection, kit material, release programs earlier, or adjust staffing/coverage across a cell.

2) Track changeover frequency and setup variance by part family

In HMLV, setups are planned—but setup variance is where schedules fall apart. Track how often changeovers happen and how setup time ranges by part family. This stabilizes planning assumptions without pretending you can eliminate changeovers entirely. It also helps you decide where standard work, better kitting, or fixture strategy will actually pay back in recovered minutes.

3) Measure handoff gaps as utilization multipliers

Many “machine” losses are really handoff losses: programming approvals that miss shift start, inspection queues that block first-article release, material that isn’t kitted to the point of use, or tooling that’s in a crib when it should be at the cell. These gaps multiply across shifts. If you can shorten the approval/kit/inspect loop, you often recover usable capacity without capital expenditure.

4) Use shift-start readiness checks

A practical daily control: at shift start, verify programs, tools, fixtures, and material are staged for the first planned jobs on each pacer machine. When this is missing, you’ll see it later as “idle/starved,” but by then you’ve already lost the best hours of the shift.

5) Set goals in leakage minutes, not a universal %

Instead of telling teams to “hit a utilization number,” set improvement goals like: reduce waiting on inspection by X minutes per shift (hypothetical), reduce program-approval delays, or reduce tool-search time. This keeps incentives aligned with flow and prevents OEE-style theatre where the metric improves but delivery performance doesn’t.

If you need help interpreting patterns (especially across shifts and mixed machine types), an assistant that summarizes time-state drivers can speed up daily decision-making. See the AI Production Assistant for an example of how shops turn raw states into a concise operational narrative.

Common measurement traps in HMLV utilization (and the rule to prevent each one)

Most utilization programs fail because the measurement becomes untrusted or incentives get misaligned. Use a simple “trap → rule” approach to keep the baseline credible.

Trap: counting setup as “bad” time

Rule: classify planned non-cutting separately and trend it. In a new part family introduction week, utilization often drops because planned learning curve work increases: prove-outs, first articles, offset refinement, fixture adjustments. Treating that as “failure” leads to the wrong corrective action (rushing, skipping checks, or blaming the wrong shift). Instead, separate necessary learning from avoidable downtime. If the machine is blocked waiting on inspection or approvals during that week, that’s leakage; if it’s in planned prove-out, that’s structural and should be improved differently (standardization, better pre-work, better documentation).

Trap: relying on operator-entered end-of-shift reporting

Rule: capture time states automatically where possible; verify with spot checks. Manual methods can work for a small pilot, but as you scale across 20–50 machines and multiple shifts, “best effort” reporting becomes inconsistent. Automatic state capture reduces interpretation and makes shift-to-shift comparisons fairer—especially for short stops and waiting states that rarely make it into the ERP cleanly.

Trap: aggregating across dissimilar machines

Rule: baseline per machine class and constraint. A turning center with short cycles and frequent checks behaves differently than a 5-axis with long setups and complex prove-outs. Combining them produces a number that looks neat and leads nowhere.

Trap: ignoring micro-stops and short waits

Rule: set a minimum event threshold, but audit the “hidden” time weekly. If you only look at major downtime, you miss the small delays: looking for gauges, waiting for a first-article signoff, walking for tools, waiting for material moved from receiving. Those add up, especially on second shift when fewer support roles are present.

Trap: benchmarking against other shops

Rule: benchmark against your own baseline by mix and shift. Your “right” utilization is the one that reflects your quoting strategy, part complexity, staffing model, and changeover realities. Build a baseline you trust, then recover leakage minutes before you consider adding headcount or another machine.

Implementation note (cost framing without sticker numbers): the practical questions are usually coverage across legacy and modern machines, how quickly you can install without corporate IT friction, and what you need to maintain data trust across shifts. If you’re at the point of scoping rollout, review pricing to understand packaging and what typically drives cost (machine count, level of tracking, and support).

If you want to pressure-test your baseline approach against your actual shift patterns—especially the gap between ERP-reported hours and real machine behavior—the fastest next step is a short diagnostic walkthrough. schedule a demo and come prepared with: one pacer machine, one recent “rough” week, and the top three reasons you think machines go idle. We’ll focus on definitions, leakage buckets, and what you can fix before you spend on more capacity.