Manufacturing Case Study: Reducing Machine Downtime

When machine downtime spikes unexpectedly, it’s tempting to assume a mechanical failure. But the truth is, recurring stoppages rarely stem from a single broken part. In my 20 years of leading RCA efforts in industrial settings, I’ve seen dozens of cases where the real problem wasn’t the motor, but the process around it.

Let me be direct: the first step is never replacing a bearing. It’s identifying the actual trigger—what’s truly causing the spike in stoppages? This chapter walks through a real industrial fishbone example from a high-precision machining facility, where we identified and resolved a root cause that had eluded maintenance teams for months.

You’ll see how a structured Fishbone diagram, grounded in evidence and team collaboration, transformed a reactive maintenance problem into a proactive improvement initiative. This is a quality control case study grounded in real data, showing not just how to diagnose, but how to fix and sustain results.

By the end, you’ll have a repeatable template for tackling machine downtime root cause issues in any manufacturing environment—no guesswork, just methodical, evidence-based problem solving.

Defining the Problem: Beyond the Obvious

At first glance, the problem seemed clear: a critical CNC machine was experiencing 30% more downtime than average. The maintenance team had logged 22 unplanned stoppages in a single month. The immediate reaction was to inspect the spindle, cooling system, and motor.

But after three weeks of part replacements with little improvement, I stepped in. The team needed an objective way to break out of the “fix and forget” cycle.

We began by writing a precise problem statement on the Fishbone diagram’s head:

“Unplanned downtime for CNC Machine #4 increased by 30% over the past 30 days, averaging 1.8 hours per incident.”

This wasn’t just a symptom—it was a measurable, auditable event. We could now investigate systematically, not emotionally.

Next, we selected the 6M framework for manufacturing:

• Manpower
• Machinery
• Methods
• Materials
• Measurement
• Medium (environment)

This framework gave us a structured lens to avoid missing systemic contributors.

Building the Fishbone: The Brainstorming Process

On a whiteboard, we drew the backbone and labeled the six categories. I facilitated the session with one rule: no judgment, only facts. If someone said, “The operator is careless,” I asked, “What do you see that makes you think so?”

We quickly began populating branches with potential causes. For example, under Manpower, we listed:

• Shift changes with only 15 minutes handover
• Operator training completed 6 weeks prior
• Two operators covering 3 machines

Under Machinery, we noted:

• Spindle vibration above threshold (data from last 2 weeks)
• Oil pump pressure below spec on 3 occasions
• Filter replaced every 6 months, not per schedule

But here’s what most teams miss: we didn’t stop at listing causes. We asked, “What evidence supports this?”

For the oil pump concern, we pulled real-time PLC logs and confirmed the pressure dropped below 35 psi during 80% of the downtime events. That wasn’t speculation—it was data.

We repeated this for every cause: verify or discard. The result? A refined Fishbone with only validated causes.

Key Insight: Not All Causes Are Equal

After validation, we had 17 causes. The next step was to group them by impact and likelihood. We used a simple 2×2 matrix:

Cause	Impact	Frequency
Filter not changed per schedule	High	High
Spindle vibration above spec	High	Medium
Operator handover time < 15 minutes	Medium	High

Now we could see the pattern: the filter issue had the highest combined score. But why did it keep being missed?

We dug deeper. The filter wasn’t on a maintenance schedule—it was tagged “after 100 hours” in the system. But the machine had been running 120 hours per week. The filter should have been replaced every 1.5 weeks. It hadn’t been changed in over 8 weeks.

This wasn’t a maintenance failure. It was a process gap.

Root Cause and Corrective Action

The true root cause? There was no automated alert for filter replacement based on runtime, and no accountability for tracking it.

That was the moment we shifted from fixing the machine to fixing the system.

We didn’t just replace the filter. We redesigned the workflow:

1. Added a runtime counter on the PLC that triggered a maintenance alert at 75 hours.
2. Assigned a single technician to oversee all filter changes per shift.
3. Created a digital log in the CMMS system that required signature confirmation.
4. Introduced a 30-minute pre-shift checklist with filter status verification.

Within two weeks, unplanned downtime dropped by 28%. After one month, it was down 41%—and the trend continued.

This wasn’t a fix. It was a transformation.

And it all started with asking: “What evidence proves this cause?”

Why This Works: The Power of Systematic RCA

Most teams stop at the first visible cause. But real improvement comes from tracing the chain—because the machine didn’t fail. The system did.

Here’s what makes this manufacturing RCA example powerful:

• It wasn’t about blaming the operator or the maintenance team.
• It used a standardized Fishbone template to avoid blind spots.
• It relied on real data, not anecdotes.
• It turned a reactive fix into a proactive process.

When you treat machine downtime root cause as a system issue, not a mechanical one, you’re not just repairing a machine—you’re improving the entire production environment.

This is the essence of a true quality control case study: not just solving the problem, but learning how to prevent it from happening again.

Frequently Asked Questions

How do I know when to use a Fishbone diagram instead of 5 Whys?

Use the Fishbone when multiple factors contribute to a problem. For example, machine downtime often involves people, processes, materials, and equipment. The 5 Whys is better for simple, linear issues—like a sensor failure.

For complex situations, combine both: use Fishbone to map all potential causes, then apply 5 Whys to each to dig deeper.

What if the root cause isn’t in the Fishbone?

It’s rare, but it happens. If you’ve thoroughly validated all causes and still can’t find the root, ask: “What data are we missing?”

Check logs, shift reports, and machine diagnostics. Sometimes the answer is in a timestamp or a sequence of events that wasn’t captured in the initial brainstorm.

How long does an RCA session take?

A well-facilitated session should take 60–90 minutes. If it goes longer, you’re likely including people who aren’t directly involved or getting stuck on symptoms.

Stick to 3–5 core team members: one facilitator, one recorder, and 2–3 subject matter experts (e.g., maintenance, production, engineering).

How do I ensure corrective actions are sustainable?

Use a SMART CAPA framework:

• Specific: “Replace filter every 75 hours”
• Measurable: “Track using CMMS log”
• Achievable: “One technician can handle all machines”
• Relevant: “Reduces unplanned downtime”
• Timely: “Complete by next cycle”

Assign ownership and verify results within 14 days.

Is this process applicable to other industries?

Yes. This exact method was applied in a hospital to reduce patient transport delays, and in a warehouse to minimize conveyor breakdowns.

The Fishbone structure adapts. The key is to customize the categories—e.g., 4S (Safety, Standardization, Self-maintenance, Sort) for service environments.

Every time you use the Fishbone correctly, you’re not just solving a problem. You’re building a culture of inquiry.