Pareto Analysis for Lost Spindle Time (CNC Guide)

Pareto Analysis for Lost Spindle Time: Find the One Leak Worth Fixing First

Most CNC shops don’t lose spindle time because of one dramatic failure—they lose it through a rotating mix of “small” constraints that feel impossible to prioritize. One day it’s tooling, the next it’s waiting on a program, then it’s inspections, then it’s material. The result is predictable: lots of debate, scattered fixes, and a creeping sense that you need more machines to hit the schedule.

Pareto analysis is the anti-guessing tool for utilization. It forces a ranking: every minute of lost spindle time gets categorized, summed, and sorted so you can make a single “largest bar” decision—by shift, by machine group, or by cell—before chasing the long tail.

TL;DR — pareto analysis for lost spindle time

• Define “lost spindle time” consistently before you rank anything (same inclusions/exclusions across shifts).

• Start small: one machine group or one shift for one week beats a messy whole-shop rollup.

• Use 8–15 reason codes operators can select quickly; “Other” must be capped and reviewed.

• Pareto steps are simple: total minutes by category → sort → percent of total → cumulative percent.

• Treat the “80%” idea as a guideline; the real output is a single priority statement.

• Run Pareto by shift/machine/part family when patterns differ; averaging can hide the constraint.

• A good Pareto ends in an owner + 1-week countermeasure + a check that the top bar actually shrank.

Key takeaway

Pareto doesn’t “optimize” your whole shop— it creates operational visibility into where spindle time actually goes, then forces one decision on the biggest utilization leak. When ERP reporting and shift notes don’t match machine behavior, a consistent time base and usable reason codes let you rank losses by shift or cell and recover capacity before you consider more headcount or capital.

What ‘lost spindle time’ means (and what to exclude)

For Pareto to work, you need one clean question: “When the spindle isn’t cutting, where did that time go?” In operational terms, think of spindle-engaged (cutting) versus non-cutting time that prevents cutting. Lost spindle time is the non-cutting bucket you want to reduce because it represents recoverable capacity on equipment you already own.

Typical inclusions are the realities that show up between cycles: setups and changeovers, waiting on material, waiting on programs or approvals, program edits at the control, probing/first-article checks, inspection holds, tool issues (breakage, offsets, missing tools), minor stops, and “soft constraints” like waiting for a forklift or a supervisor decision. These are exactly the items that become arguments in a production meeting because everyone has a different anecdote—and because ERP time often reflects what was scheduled, not what the machine actually did.

Exclusions depend on your goal, but you need to decide them up front. Many shops exclude planned breaks, scheduled meetings, and planned maintenance (if they track those separately) so the Pareto focuses on controllable leakage rather than calendar reality. The key principle is consistency: if first shift excludes breaks but second shift lumps breaks into “idle,” your Pareto will “prove” the wrong story.

If you’re already capturing machine states, connect this definition to your existing machine utilization tracking software output: the Pareto layer sits on top of those lost-time categories to turn “a lot of idle” into “this is the biggest preventable reason for idle on this shift.”

The minimum data you need to run a Pareto this week

The fastest way to get value is to avoid “whole shop” scope at the start. Pick one: a machine group (for example, your VMCs), one cell (like a mill/turn cell), or one shift (often second shift if you suspect a gap). Run the window for one week so you have enough repetitions to see a pattern without turning it into a quarter-long data project.

On the data capture side, you have two workable options:

• Better: timestamped state changes (run/idle/down) with a reason selected for non-cutting periods, giving you near real-time truth that’s not reconstructed after the fact.

• Minimum viable: daily totals (minutes) per reason category per machine/shift, captured consistently at shift end and reviewed the next day.

Next is the taxonomy. Aim for 8–15 reason codes that an operator can choose in a few seconds—no scrolling through 40 options. Codes must be mutually understandable (no overlapping definitions like “waiting” vs “delay” vs “hold”) and operationally actionable. If you need a baseline on capturing losses without ERP guesswork, this is the same foundation used in machine downtime tracking: get the minutes into the right buckets first.

Finally, control “Other/Unknown.” Set a simple rule: if “Other” becomes one of the top bars, it’s not a finding—it’s a data problem. Cap it (for example, as a management expectation), review it daily for a week, and split it into 1–3 new codes that match what’s actually happening. This is how you prevent Pareto from becoming a formal-looking chart built on fuzzy labels.

How to do Pareto analysis for lost spindle time (step-by-step)

You can run this in Excel, Google Sheets, or directly from a shop-floor report. The mechanics are simple; the discipline is keeping the time base and reason codes consistent.

Step 1: List each lost-time category and the total lost minutes over your chosen window (one shift, one cell, one week—whatever scope you picked). Don’t mix categories from different definitions.

Step 2: Sort categories from highest to lowest minutes. This is where Pareto stops the arguing—your “largest bar” is visible.

Step 3: Calculate each category’s percent of total lost time:

category % = category minutes ÷ total lost minutes

Step 4: Calculate cumulative percent down the sorted list. This shows how many categories it takes to explain most of the lost time.

Step 5: Pick the cutoff—often the top 1–3 categories that approach roughly 80% of the lost time. Don’t treat 80/20 like a law of physics; the point is to identify a dominant leak, not to force the chart to match a textbook.

Step 6: Write the output as one sentence a supervisor can act on: “This week, the biggest utilization leak on second shift in the VMC group was waiting for program/approval.” That sentence becomes your meeting agenda item, not the chart itself.

Worked example: a Pareto that changes what you fix first

Below is a hypothetical example dataset: one week of categorized lost spindle time for a VMC group on second shift. The shop suspects the issue is “too many setups,” but the time categories tell a different story once they’re summed and ranked.

Lost-time category (2nd shift)	Minutes	% of lost time	Cumulative %
Waiting for program/approval	780	33%	33%
Setup / changeover	540	23%	56%
Tooling not ready / offsets	420	18%	74%
Waiting on material	240	10%	84%
Inspection / first-article hold	180	8%	92%
Minor stops / resets	120	5%	97%
Other / unknown	80	3%	100%

The dominant loss isn’t “setups” in general—it’s waiting for program/approval on second shift. That’s the required multi-shift scenario many shops recognize: first shift can get engineering/programming answers in the moment, while second shift stacks idle time around first-article signoff, program release, or a missing revision.

What not to do: launch five improvement projects because you now have five categories. That turns the Pareto into “peanut-buttering” effort across the week and makes it hard to verify what changed.

Translate the top bar into a 1-week countermeasure

Keep it tight:

• Owner: programming lead + second-shift supervisor.

• Experiment (1 week): release programs/tool lists for tomorrow’s second-shift jobs by end of first shift; establish a defined first-article approval window (e.g., during overlap or at a set time).

• Check: next week’s Pareto for second shift—did “waiting for program/approval” shrink, or did it simply get relabeled as “setup” or “other”?

If you’re using automated collection, near real-time review makes these experiments easier to manage because you’re not waiting for ERP reconciliation to learn what happened. This is where machine monitoring systems can help operational teams align on the same source of truth: what the machine actually did during the shift.

Another common case is the high-mix mill/turn cell where the team says “we’re getting interrupted all day.” A Pareto often shows the largest bar is not “interruptions” broadly, but tooling not ready/tool changes. That shifts the fix from chasing dozens of minor stops to implementing tool preset workflows, tighter kitting, and a standard “tool list ready” checkpoint before the job hits the machine.

Common pitfalls that make your Pareto lie

When a Pareto output doesn’t match shop-floor intuition, the problem is usually not the math—it’s the inputs or the resolution. These are the failure modes that quietly destroy credibility.

1) Garbage taxonomy (especially “Other”)

Too many codes, overlapping codes, or vague codes (“delay,” “issue,” “misc.”) cause operators to pick whatever is fastest. If “Other” becomes a top bar, treat it as a process issue: review “Other” entries daily for 3–5 days, then split it into the smallest set of codes that reflects reality. You’re not trying to create perfect accounting—you’re trying to preserve decision-making speed.

2) Mixing unlike work hides the constraint

If you combine unlike part families or machine types, you can average away the real bottleneck. Optional scenario: two similar VMCs can show different “largest bars” because they run different work. One may be dominated by workholding/setup (complex fixturing, frequent changeovers), while another is dominated by material wait (saw/receiving/kitting constraint). The fix isn’t “improve setups everywhere”—it’s to segment by machine and part family so you target the actual constraint area.

3) Time attribution errors in big “waiting” blocks

Long idle stretches often contain multiple causes (material arrives late, then a tool is missing, then a program revision is needed). If everything gets logged as “waiting,” you’ll over-invest in the wrong countermeasure. A practical rule: if an idle block is longer than a threshold (for example, 10–30 minutes), require a quick check-in—what is the primary constraint right now?

4) Gaming and selection bias

If the easiest code to select is “setup” or “maintenance,” it will become the biggest bar regardless of reality. Fix the system, not the people: simplify the code list, define each code with a one-line example, and build a daily habit where a supervisor samples a handful of entries and asks, “Does this code match what happened?”

5) Using averages only

A weekly average across all shifts can hide a second-shift release problem or a specific cell constraint. Pareto is most useful when it’s run at the resolution where decisions happen: by shift, by machine group, or by the constraint area that manages the work.

Turning the top Pareto bar into faster decisions (not a report)

The goal is not a prettier chart; it’s a tighter operating rhythm that recovers capacity before you add machines, overtime, or headcount. That only happens when the Pareto drives a decision cycle.

Set a simple cadence

Use two loops:

• Daily (10 minutes): check data quality. Is “Other” growing? Are reasons being selected consistently? Are there obvious mislabels?

• Weekly (production meeting): review the Pareto for the chosen scope and choose one priority category to attack next week.

Use a countermeasure format that prevents bureaucracy

A workable template is: one top category, one owner, one experiment, one verification metric. Keep the verification tied to the same time base you used in the Pareto (lost minutes in that category for that shift/cell), not an ERP completion code that updates after the fact.

If you want a diagnostic bridge between raw states and “what does this mean,” tools like an AI Production Assistant can help interpret patterns and standardize the weekly narrative (for example, whether “waiting on program” is concentrated around certain part families or certain approval steps). The point is faster alignment, not more dashboards.

Know when to segment the Pareto

Segment when the shop’s lived experience says “it depends.” Common triggers: second shift consistently underperforms first shift, one cell always claims they’re waiting, or one customer/part family seems to disrupt flow. Build separate Pareto views by shift, by machine group, or by part family so you don’t prescribe a global fix for a local constraint.

A simple 80/20 chart is the fastest way to end shop floor arguments. But to build an accurate chart, your software needs to capture the right inputs automatically. Learn exactly what goes into this process in our breakdown of machine downtime tracking and pareto analysis data.

Close the loop next week

The only question that matters after an experiment is whether the top bar shrank in the next window—or whether it migrated into another category because the team changed how they label time. That’s why daily data-quality review matters, and why Pareto is most powerful when paired with consistent shop-floor capture rather than ERP reconciliation alone.

If you’re considering more formal tracking, keep implementation practical: mixed fleets and multi-shift reality demand something that captures consistent reasons without turning into an IT project. Cost discussions should be framed around rollout scope (machines vs cells, shifts, and data review habits), not license math. You can see how packaging is typically structured on a pricing page—but the operational decision is whether you can sustain clean categories and weekly action.

Want to sanity-check your reason codes, your first Pareto, or whether you’re segmenting at the right level (shift vs cell vs part family)? schedule a demo and bring one week of categories. The fastest outcome is not software selection—it’s leaving with a clear “largest bar” and a one-week countermeasure you can verify.