A Diagram Is Not an Analysis

The fishbone, or Ishikawa diagram, is a tool for widening a search. It arranges candidate causes around a single effect so that a team stops arguing about the first idea somebody said out loud. On its own it proves nothing. A diagram with forty causes and no data is a list of opinions drawn neatly.

Start With a Measurable Effect

The head of the fish must be a specific, measurable failure, not a category. "Slider binds" is better than "quality problem". Better still is a statement with a condition and a magnitude: slider binding on size five auto-lock sliders, occurring on approximately one piece in four hundred, concentrated in the first two hours after a mold change.

A precise effect statement does half the analytical work, because it already excludes causes that could not produce that pattern. If the failure is concentrated after a mold change, causes related to raw material lots become less likely and causes related to setup become more likely.

The Six Branches

The conventional branches are man, machine, material, method, measurement and environment. For zipper failures, each has a recognisable set of candidates:

  • Man: setup sequence skipped, incorrect gauge used, new operator on a complex assembly station, shift handover without status transfer.
  • Machine: mold wear, ejector pin wear, stamping tool clearance drift, plating bath agitation, assembly track misalignment, feeder vibration.
  • Material: tape shrinkage variation between lots, yarn count deviation, slider spring hardness, plating chemical concentration, lubricant inconsistency.
  • Method: torque or force specification missing, first piece approval bypassed, repair method that reintroduces the fault, packing sequence that damages teeth.
  • Measurement: gauge out of calibration, wrong limit sample, inspector classification drift, measurement taken at the wrong point on the tape.
  • Environment: humidity affecting tape dimensional stability, temperature affecting plating adhesion, lighting that hides shade differences, dust in the assembly area.

Add a seventh branch when it earns its place. Management or system causes, such as an incentive that rewards volume over first pass yield, often explain why a known method was skipped. Putting that cause in a branch of its own prevents it from being hidden under man.

Building It With a Team

Run the session in two phases. In the first, ask for causes silently and in writing, one per card, for a fixed period. Silent generation prevents the senior person in the room from setting the direction. In the second, read the cards aloud without commentary and place them on branches, merging duplicates.

Keep the group small enough that everyone speaks and broad enough that all six branches are represented. A fishbone built by one engineer at a desk reproduces that engineer's assumptions, which is precisely the failure the tool is meant to avoid.

Verifying Candidates

Convert each plausible cause into a test. The test can be a physical trial, a data query, or a comparison between affected and unaffected production. Three forms cover most cases:

  1. Stratify existing data: compare defect rate by machine, by shift, by material lot, by tool age. A cause that should produce a difference and does not is weakened immediately.
  2. Run a controlled change: alter one factor, hold the rest, and measure. This is the strongest evidence and the slowest to obtain.
  3. Reproduce the failure deliberately: force the suspected condition and confirm the failure appears, then remove it and confirm it disappears.

Record the result beside each cause: supported, contradicted or untested. Publishing the contradicted ones is as important as publishing the supported ones, because it stops the same hypothesis from returning at the next meeting.

Ranking the Survivors

After verification, rank by expected contribution rather than by opinion. A simple and defensible score multiplies three factors: how often the cause occurs, how severe the resulting failure is, and how easily it escapes detection. Rank the product and address the top two or three. Anything beyond that will not receive real resources.

Where quantitative data exists, use it directly: compare the defect rate in the presence and absence of the cause and estimate the share of defects attributable to it. A cause present in eighty percent of failures and twenty percent of successes is a strong signal; a cause present equally in both is noise.

Turning the Top Cause Into an Action

A fishbone ends where a five-why begins. Take the highest-ranked verified cause and ask why it exists, then why that condition exists, until the answer is a system or a design decision that can be changed. The chain should terminate in something actionable, not in a person's name.

If the top cause is mold wear causing tooth pitch drift, the chain might run: why tooth pitch drift, because the mold cavity is worn, because the service interval is set by calendar rather than by shot count, because nobody tracks cumulative shots by cavity. The action is then a counter and a wear limit, which is testable and permanent.

Where the Tool Fits in the Wider System

The fishbone is an input to root cause analysis, not a replacement for it, and its output should feed directly into an 8D or a similar corrective action structure. It is also useful preventively: run it on a failure mode that has not yet occurred in volume, using the failure mode analysis as the source of candidate causes.

YCC runs fishbone sessions at the process step where the defect was created rather than at the step where it was found, and requires every branch to be populated before the session closes. An empty branch is usually not evidence that the branch is irrelevant; it is evidence that nobody from that function was in the room.

Failure Modes of the Technique

  • An effect statement too vague to test, which lets every cause remain plausible.
  • Causes recorded as solutions, such as "needs better training", which end the analysis prematurely.
  • No verification step, so the diagram ranks opinions by volume of voice.
  • Only one function represented, which leaves whole branches unexplored.
  • No follow-through into a corrective action with an owner and a date.

Each of these is avoidable with a written agenda: define the effect, populate silently, verify with data, rank, convert to action, assign. The diagram is only the second step in that list, and it is the cheapest one.