# Fishbone Diagram

**URL:** https://kaizumi.com/dictionary/fishbone-diagram

**Description:** A fishbone diagram sorts the possible causes of one problem into groups. Six bones name about 31 causes. Two free tests cut them to 2.

**Japanese:** 特性要因図 (tokusei yōin zu) — "characteristic factor diagram"

**Category:** lean-tools

**Tags:** problem-solving, quality

## Drawing one | How to fill in a fishbone diagram

A fishbone diagram helps you list possible causes for a problem. It does not prove which cause is correct. The goal is simply to write down every condition that could create the defect before your team starts arguing about which one is responsible.

This tool is useful when a problem has many possible causes and no obvious explanation. For example, a defect rate went up last month, a customer queue keeps getting longer, or an error repeats every week. The diagram puts all the possibilities in front of the group so people do not just focus on the most popular opinion.

Here is a practical example. A distribution center ships the wrong item on `3.1` percent of its Zone B night orders. This started happening on `14 July`. Zone B ships `4,000` orders a week at night. That means `4,000 × 0.031 = 124` wrong shipments every week.

You write that specific problem statement in the head of the fish on the right side. The problem in the head needs to be clear and measurable. If you write "picking accuracy is bad," you have no clear direction to investigate. But "wrong item shipped on 3.1% of Zone B night orders since 14 July" tells you the exact place, shift, and date. You can test each of those details later.

The main horizontal line is the spine. It simply holds the diagram together. People sometimes argue about which line to draw first or what angle to use, but the layout does not change the facts.

The main bones coming off the spine are categories. They give your team areas to think about, such as equipment, steps in the process, or the work environment. A category is not a cause by itself. If a bone ends up empty, that just means the team did not list anything in that area.

The smaller branches off each bone, called twigs, are the actual causes you want to test. There is one important rule for these: **each twig must be a specific statement you can check and prove false.**

Phrase each twig so anyone on the team could go look at the work and verify it. "Training" is too vague to investigate. "New pickers work Zone B nights unsupervised in their first week" is a clear statement that someone can check tonight.

```kz-callout
tone: note
title: The twig test.
p: Write a twig, then ask what you would have to see for it to be false. "Night shift is careless" fails. Nothing you could observe would refute it. "The 12 July re-slot put lookalike SKUs into next-door bins" passes. Go and look at the bin map.
```

```kz-figure
id: parts
caption: **The worked case, part-drawn.** Three twigs hang off Method. You could go and disprove each one before lunch.
```

When a team works through six categories thoroughly, they usually come up with about `31` possible causes. For example: People `6`, Machine `4`, Method `7`, Material `5`, Measurement `5`, and Environment `4`. That is a typical result. But that list gives you `31` untested ideas, and a team usually only has the time and budget to investigate about three in detail. The next step is narrowing down the list.

If you want guidance on running the meeting itself, see the [manufacturing field guide](/guides/fishbone-diagram-in-manufacturing). It explains who should attend, how long to meet, and how to write down ideas without getting stuck in debate. The fishbone is one practical step in [root cause analysis](/dictionary/root-cause-analysis).

## Categories | Which fishbone categories should you use

Choose category names that make sense for the work you are analyzing. Teams commonly use four main sets of categories, but you can adjust them however you need.

| Set | The categories | The work it fits |
|---|---|---|
| 6M | Man, Machine, Method, Material, Measurement, Mother Nature | Physical work on an object: production, maintenance, warehousing |
| 8P | Product, Price, Place, Promotion, People, Process, Physical evidence, Performance | Commercial and service problems: churn, complaints, quoting errors |
| 4S | Surroundings, Suppliers, Systems, Skills, plus Safety when the defect can hurt somebody | Service delivery, field work, logistics |
| Care set | People, Process, Equipment, Environment, Materials, Policies | Hospitals, clinics, labs, and most office work |

Use three practical guidelines when setting up your categories:

1. **Pick categories where problems can actually happen in your process.** Do not worry about what other industries use.
2. **Remove categories that do not apply.** For example, an insurance claims team does not need "Mother Nature." If you keep an irrelevant category just to fill out the template, it stays blank and clutters the page.
3. **Add custom categories if needed.** You can add categories like Scheduling, Handover, or Regulations. The standard sets are just starting points.

Because you choose the categories based on the work, two different teams solving the same issue might use different bones and still get good results.

The categories you pick also direct where your team spends its time. If a hospital uses the 6M categories, a medication mistake usually gets filed under Man or Machine, which points at the person or the device. If the hospital uses the care set, that same mistake gets filed under Process or Policies, which points toward system fixes. The choice of categories shapes what your team investigates next.

The [healthcare guide](/guides/fishbone-analysis-in-healthcare) shows how this works in a hospital setting. A [restaurant kitchen](/guides/fishbone-diagram-in-a-restaurant) uses a different set suited to food service.

If you are not sure which set to use, pick the one with fewer categories. It is easy to add another bone later, but splitting a category after people have already written ten notes on it takes extra time.

In our Zone B warehouse example, we use the 6M set with two standard word updates: "People" instead of "Man," and "Environment" instead of "Mother Nature." These simple changes make the labels clearer without altering how you use the diagram.

## Narrowing | How to narrow a fishbone diagram

You can reduce `31` potential causes down to `2` using two simple, logical checks that cost nothing. The first check looks at where the problem happens, and the second check looks at when it started. Voting only tells you what people currently think, while these two checks rely on facts about the problem.

**Check one is contrast.** The defect only occurs under specific conditions. In our example, it happens in Zone B but not Zone A, and it happens on the night shift but not the day shift. If a condition exists on the day shift too, it cannot explain why the problem only happens at night. The day shift uses the same barcode scanners, the same storage racks, and the same training materials. That means you can cross off every cause related to those shared items. This single check eliminates `22` causes, leaving `9`.

**Check two is timing.** The defect began on `14 July`. A sudden increase on that date must come from something that changed right before it. When you look at the two weeks leading up to `14 July`, you find that `7` of the remaining `9` conditions had already been true for a year or longer. Since they were present long before the error rate went up, they cannot be the reason for the sudden change. Crossing them off leaves just `2` causes.

Set these two criteria before you review the diagram. If you make up criteria as you go, you risk keeping the causes you personally suspect and cutting the ones you dislike.

If both checks eliminate all of your causes, re-examine your problem definition. Either the defect is happening on the day shift without being reported, or it started earlier than `14 July`. Double-check the basic facts before continuing.

If the checks leave you with six or seven causes, make the problem definition more precise. For instance, looking specifically at "Zone B nights during a picker's first week" gives you a tighter focus and eliminates more items.

| Bone | Causes named | After the contrast test | After the timing test |
|---|---|---|---|
| People | 6 | 2 | 0 |
| Machine | 4 | 1 | 1 |
| Method | 7 | 3 | 1 |
| Material | 5 | 1 | 0 |
| Measurement | 5 | 1 | 0 |
| Environment | 4 | 1 | 0 |
| Running count | 31 | 9 | 2 |

The two surviving causes are:

- **Method.** On `12 July`, the warehouse reorganized the pick path. The new storage map placed `7` pairs of items that look almost identical into neighboring bins.
- **Machine.** On `8 July`, the scanner software was updated. It began confirming picks by scanning the case barcode instead of verifying the bin location.

```kz-figure
id: zone-b
caption: **Thirty-one ticks, two rings.** Every short tick is one cause the room named. The two ringed twigs are the only ones absent on day shift and newer than 14 July.
wide: true
```

```kz-callout
tone: warn
title: The People bone is where honest sessions go wrong.
p: Six of these `31` causes named a person. None of the six survived. Test every People twig with one question. Could a careful, trained person still produce this defect? If the answer is yes, the cause is not the person. It is whatever made the mistake possible, and it belongs on Method, Machine or Measurement.
```

Now you can gather data on the remaining causes without wasting time. Instead of testing `31` ideas, you only need to check `2`. You pull records for last week's `124` wrong shipments and check whether each error involved one of the `7` new lookalike pairs. It turns out that `96` of the `124` orders involved those items, which is `77` percent. Checking this takes a single morning. Investigating all `31` ideas would have taken a month.

In this case, neither change caused the defect by itself. Putting lookalike items side by side was manageable as long as the scanner forced pickers to confirm the bin location. Confirming by case barcode was manageable as long as lookalike items were stored far apart. But because both changes happened four days apart, they combined to remove the safeguard.

To fix the problem, the team separated the `7` item pairs and changed the scanner software back to bin-location confirmation. The error rate dropped to `0.4` percent. That means `0.4% × 4,000 = 16` wrong shipments a week, which is `108` fewer than the `124` they started with, or an `87` percent reduction.

You can create your own diagram with our online builder. It opens on a worked example, lets you rename or delete bones, and expands any cause into a [5 Whys](/dictionary/5-whys) chain. If your team prefers working on a whiteboard or projector, download the [PowerPoint template](/templates/kaizumi-fishbone-template.pptx).

<!--TOOL:fishbone-->

## Reading it | How to read a fishbone diagram

A completed fishbone tells you about the defect, but it also shows how your team approached the session. You can often spot issues with the team's approach just by looking at the layout of the chart.

```kz-figure
id: shapes
caption: **Four diagnoses, read from the shape alone.** You can make each call from across the room, before you read a single twig.
wide: true
```

Look at the overall distribution of causes first, then read the individual notes. The overall balance gives you immediate feedback on whether the session was effective.

| The shape | What it means | What to do |
|---|---|---|
| Every bone equally full | The head is too broad. You have drawn the causes of several problems at once. | Split the head into two or three specific gaps. Redraw the one that costs most. |
| One bone holds almost everything | Either the room already suspects the answer, or the set is wrong for your work. | If the room knows, stop drawing and run a why-chain down that bone. If it does not, change the set. |
| The People bone is the fullest | You are recording blame, not causes. The honest cause sits behind the person. | Re-file each People twig under the condition that made the error possible. |
| Bones one level deep, no twigs | The room named categories and stopped. Nothing on the page is testable. | Take one bone and force three twigs that each pass the disprove test. |
| One bone empty | Either that domain does not apply, or nobody in the room owns it. | Delete it, or invite the person who owns it and redraw. |

For example, if the Measurement bone is empty in a clinic, it rarely means the data collection is perfect. More often, it means no one from the laboratory was in the room. If a warehouse diagram has an empty Supplier bone, the team probably forgot to invite someone from purchasing.

An empty section usually points to a missing perspective in the meeting. You can fix that by inviting the right person before you begin collecting data.

Be cautious if a diagram has exactly one cause written neatly under every bone. That usually means a single person filled it out alone just to complete a form. In a real group session, ideas land unevenly across the categories. A completely uniform list across `31` causes is very rare in practice.

## Limits | What a fishbone diagram cannot do

A fishbone diagram cannot prove which cause is real, tell you which cause is largest, or show how two causes interact. The diagram structure simply does not record that information.

**It cannot prove a cause.** Every point on the diagram is a theory until you check it against real data. That is why the elimination tests are necessary. The diagram will naturally produce unhelpful ideas alongside useful ones, and you need other methods to separate them.

**It cannot rank causes.** Every branch looks the same size. The diagram cannot show you whether an item causes `77` percent of your errors or one in a thousand.

**It cannot show interactions.** The branches do not connect to one another. The format cannot show that two conditions must occur together to create the defect. In our Zone B example, both changes had to happen at the same time to cause the spike, but the drawing cannot show that link on its own. You have to explain that relationship separately.

| The job | The instrument |
|---|---|
| Decide which problem deserves a fishbone at all | A [Pareto chart](/dictionary/pareto-chart). Rank by frequency or cost first. [Chart it](/tools/pareto). |
| Tell a real signal from ordinary variation, before you investigate | A [control chart](/dictionary/control-chart). If the point sits inside the limits, there is no special cause to find. [Plot it](/tools/control-chart). |
| Go deep on one surviving cause | [5 Whys](/dictionary/5-whys), run once down each survivor. [Build the chain](/tools/5-whys). |
| Look ahead at failures that have not happened yet | An FMEA. It scores and ranks, which is what a fishbone will not do. [Score it](/tools/fmea). |
| Model causes that only produce the defect together | A fault tree. Its AND gate is the mark a fishbone is missing. |

To see how to choose the right method for different problems, look at our [5 Whys guide](/dictionary/5-whys). It has the full routing table, including the problems where a why-chain is also the wrong tool.

Filling out a fishbone diagram is only part of solving the issue. In an [A3 report](/dictionary/a3-problem-solving), it belongs in the analysis section. The practical fix you implement should usually be an error-prevention step, or [poka-yoke](/dictionary/poka-yoke). Changing the scanner software back is a reliable physical check, whereas reminding people to be careful rarely prevents future mistakes.

If you are running this process as a team workshop, it often fits inside a [kaizen event](/dictionary/kaizen-event). To see how to document the full project, check our [A3 guide](/guides/a3-problem-solving).

## Origin | Who invented the fishbone diagram

Kaoru Ishikawa developed this tool. He started using it at Kawasaki Steel in `1943` and refined it throughout the `1950s`. It reached English readers in his 1968 book, Guide to Quality Control, and is recognized as one of the [seven basic quality tools](/guides/six-sigma-tools).

The Japanese name is descriptive: 特性要因図 (tokusei yōin zu), which translates to characteristic factor diagram. The problem in the head is the characteristic, and the branches are the factors influencing it.

Ishikawa emphasized that the people doing the day-to-day work should be the ones drawing the diagram, in a quality circle. Frontline workers understand daily operational details that never appear in standard reports.

In the warehouse example, the computer inventory records showed that the storage locations were updated correctly on `12 July`. The system logs looked normal. But a night-shift picker noticed within a single shift that the two boxes looked nearly identical.

When a manager fills out a fishbone diagram alone, the chart only reflects one person's assumptions. When the whole team builds it together, the chart reflects what actually happens during the shift.

The terms fishbone diagram, [Ishikawa diagram](/dictionary/ishikawa-diagram), and cause-and-effect diagram all refer to the same method. You can use whichever name your workplace prefers.

```kz-qa
q: Is a fishbone diagram the same as an Ishikawa diagram?
a: Yes. One tool, three names. "Ishikawa diagram" credits Kaoru Ishikawa, who began using it in 1943 and published it in English in 1968. "Fishbone" describes the shape. "Cause-and-effect diagram" describes the purpose. The method does not change with the name.
q: What are the 6 Ms in a fishbone diagram?
a: Man (people, skills, staffing, fatigue), Machine (equipment, tooling, maintenance, calibration), Method (process steps, standard work, layout), Material (inputs, suppliers, incoming quality), Measurement (gauges, inspection, data definitions) and Mother Nature (temperature, humidity, lighting, workspace). They are a starting kit for physical work, not a rule. Delete any bone your work cannot fill, and add one it needs.
```

Source: https://kaizumi.com/dictionary/fishbone-diagram
Licence: free to quote and cite with attribution to Kaizumi.