Ishikawa diagram in OSH

The Ishikawa diagram, also called a cause-and-effect diagram or fishbone diagram, organizes potential causes of a problem into categories. In occupational health and safety (OSH), it helps explore technical and organizational factors, but the hypotheses it presents must be tested before being presented as conclusions.

In short

Ishikawa organizes hypotheses about the causes of a problem. The diagram facilitates exploring different dimensions of the work, without proving on its own that a cause was involved in the incident.

Content
  1. What it is and what it is used for
  2. Choose a specific effect
  3. Select useful categories for OSH
  4. Gather hypotheses and prepare for their testing
  5. Practical example
  6. Relationship with other methods
  7. Turning the findings into prevention
  8. Limits and common mistakes
  9. Related concepts
  10. On the blog
  11. References

AZ Dictionary →

What it is and what it is used for

The Ishikawa diagram represents a problem at the end of a main axis and distributes its potential causes along branches. The categories allow for the examination of different dimensions without losing sight of the effect being analyzed. Its shape resembles a fishbone, hence one of its common names. It is a tool for organizing reasoning, not a causal proof.

In occupational safety and health, it can be used when investigating an accident, a recurring deviation, or a control difficulty. For example, it allows for the organization of hypotheses about why spills occur in an area or why a measure is not maintained. Its contribution lies in making visible questions that might not arise if the team focused from the outset on a single explanation.

Choose a specific effect

The problem identified at the head of the diagram must be specific and understandable to the entire team. “Many accidents” encompasses situations that can have very different mechanisms. A formulation such as “spills during transfer at the mixing station” allows for a more focused investigation, provided that the period, operations, and conditions included in the analysis are clearly defined.

It is also important to distinguish between investigating a specific event and studying a pattern. In the first case, hypotheses must be tested against what actually happened. In the second, it will be necessary to determine whether a proposed cause explains several cases or only one. Combining these two objectives can transform an isolated observation into a general conclusion that the data does not support.

Select useful categories for OSH

Traditional categories relate to people, methods, equipment, materials, measurement, and environment, but they can be adapted to the work being analyzed. In occupational safety and health (OSH), it is useful to make the organizational structure visible: planning, purchasing, maintenance, supervision, and coordination. There is no technical obligation to maintain a fixed number of categories if other terms help to better understand the issue.

The people category should examine skills, information, communication, and task requirements, avoiding becoming a list of personal shortcomings. Similarly, the equipment category should consider design, suitability, and maintenance, not just breakdowns. The classification helps to identify potential areas; it doesn’t force you to find a cause in every one or artificially distribute the conclusions.

Gather hypotheses and prepare for their testing

A session can begin with proposals from those who perform, maintain, supervise, and evaluate the work. The facilitator should keep a variety of questions open and prevent one opinion from overshadowing others. Each proposal should be phrased concretely enough to allow for further investigation. If an idea touches on multiple categories, preserving its meaning is more important than debating which category it belongs to.

Next, the verification process is prepared: what evidence is needed, where it can be obtained, and who will review it. For example, “the filling rate exceeds the container’s capacity” can be verified using technical information and controlled observation of the operation. “People are rushing” requires specifying when, why, and with what effects; without this detail, it is not a usable explanation for deciding on measures.

Practical example

In a hypothetical example, a team studies splashing during container filling. They note potential nozzle and regulation problems in the equipment section; viscosity changes in the materials section; differences in container position in the methods section; and variations in purchased sizes in the organization section. All these notes are considered initial hypotheses, not proven causes.

The review confirms that some newer containers have a smaller opening and that the nozzle used was not adapted to the change. It finds no evidence of the alleged viscosity variation. The team retains the supported findings, discards those that do not explain the cases, and leaves open those requiring further information. Actions focus on equipment compatibility and reviewing supply changes.

Relationship with other methods

The five whys method can delve deeper into a branch of the diagram. Once the facts of an accident have been verified, the cause tree can help to illustrate their relationships. The tools are complementary if the distinction between proposing an explanation, testing it, and drawing a conclusion about the event is respected.

The classification of causes can also be used to analyze trends among completed investigations. In this application, the categories must be stable and have clear coding criteria. It is not advisable to mix pending hypotheses with confirmed causes in the same statistics, because this would end up measuring what the team most often imagines rather than what they actually find.

Turning the findings into prevention

Corrective measures are defined based on confirmed factors and a technical evaluation of the solutions. In the example, adapting the nozzle without reviewing future purchases could resolve the current issue but allow the same problem to recur. Therefore, it is important to consider both the physical correction and the process that authorized the change of containers.

Each decision must be linked to a responsible party, a timeframe, and a method for verifying the outcome. A controlled trial may be necessary before implementing a solution generally. The absence of further splashing during a few operations does not, in itself, demonstrate that all conditions have been resolved; the suitability of the design and the conditions of use must also be verified.

Limits and common mistakes

The main mistake is presenting the diagram as if all its branches were proven causes. Another is measuring the quality of the analysis by the number of ideas, even if many are vague or repetitive. The session can also be biased if it is limited to people unfamiliar with the actual work or if the problem is framed in a way that already assigns responsibility to someone.

Ishikawa does not estimate probabilities nor does it replace technical research, measurement, or documentary verification. Its usefulness depends on the quality of the questions asked and the subsequent work done. A simple diagram, accompanied by evidence and clear decisions, offers more preventive value than a highly detailed chart that is filed away without distinguishing what has been confirmed and what remains a possibility.

Related concepts

On the blog

References

  1. American Society for Quality. Fishbone: cause-and-effect diagram. Revision 2024. Official source
  2. National Institute for Occupational Safety and Health. NTP 924: Causes of accidents: classification and coding. 2011. Official source
  3. Occupational Safety and Health Administration. Incident Investigation. Official source

Editorial information

Publication date: October 10, 2026.

Editorial Manager: Sabentis Editorial Team.

Author: Pablo Rodríguez LinkedIn

Executive Vice President of the ORP International Foundation and Chief Financial Officer of Sabentis.

Request a Demo

Discover all that Sabentis can do for your organization.

Try Sabentis

request a demo
stars 5
GetApp Software Advice Capterra