Kaoru Ishikawa brought together a set of simple tools that, in his view, are enough to solve a large share of the quality problems met in daily work. Known today as the seven basic quality tools, they require no complex software: only a clear question, reliable data and a team that learns to read them.
Why these tools?
Ishikawa wanted quality methods to move out of specialists’ offices and into the hands of front-line staff. He therefore chose tools that can be learned quickly and applied with pen and paper or a simple spreadsheet. They all share one idea: decisions should rest on facts rather than impressions, and the team should see the problem clearly before proposing solutions.
The seven tools and the question each one answers
- Check sheet: a simple table for collecting data where it occurs, such as the type of error, how often it happens and when. It answers the question: what is happening, and how often? The better it is designed, the less effort recording takes and the more reliable the data.
- Pareto chart: bars sorted in descending order that show the most frequent or most costly causes, with a cumulative curve. It rests on a rule of thumb known as the 80/20 rule: a small number of causes usually explains most of the effects, what Joseph Juran called the "vital few".
- Cause-and-effect (fishbone) diagram: organizes the possible causes of a problem into categories and answers the question: what might lie behind this result? It is a tool for structuring group thinking, not for proving causes.
- Histogram: bars showing how the values of a single variable, such as waiting times, are distributed, revealing their centre, spread and shape. Two peaks, for instance, may indicate that the data come from two different sources.
- Scatter diagram: points that reveal a possible relationship between two variables, such as the number of open counters and waiting time. An apparent correlation, however, does not necessarily mean cause and effect.
- Control chart: developed by Walter Shewhart, it follows a process over time between control limits calculated from the process’s own data. It thus separates the ordinary variation inherent in every process from shifts with a special cause that deserve investigation.
- Stratification: splits data by source, period, team or type of service to reveal patterns that aggregated figures hide.
Some references replace stratification with the flowchart, which maps the steps of the work in sequence and helps locate where a problem arises. Both lists are in common use; what matters is using the tools methodically.
Three complementary functions
The tools can be grouped by their role in the analysis:
- Collecting and organizing data: check sheet and stratification.
- Understanding the problem and setting priorities: Pareto chart, histogram and scatter diagram.
- Searching for causes and monitoring the process: fishbone diagram and control chart.
Not every project needs all seven tools: the question being asked determines the tool. Their use often follows the stages of the PDCA cycle, with data collected and analysed during planning, and the effect of solutions tracked on a control chart during checking.
Worked example: a municipal service desk
The manager of a document-issuing desk at a municipality notices growing dissatisfaction among citizens. Rather than relying on impressions, the team designs a check sheet on which staff record, for two weeks, the reason for each complaint: long waits, missing documents in the file, errors in the document issued, or unclear information.
The team ranks the results in a Pareto chart and finds that long waits and missing documents account for most complaints. It then stratifies the waiting data by day and hour, and sees that the peak is concentrated in the first hours at the start of the week. A histogram of waiting times shows two peaks which, on checking, turn out to come from two counters each working in its own way.
The team analyses the causes of waiting with a fishbone diagram and chooses simple solutions: a list of required documents posted at the entrance, a common working method for both counters, and extra staff at peak hours. It then tracks the average daily wait on a control chart to make sure the improvement is real and stable, not just a passing fluctuation.
How to start
- Frame a clear, specific question, for example: which errors occur most often in the files received?
- Define the data needed, who collects them, where and when, then design a simple check sheet.
- Test the sheet for a few days and adjust it before rolling it out.
- Choose the tool that fits the question, not the familiar one.
- Present the results visually and discuss them with the people involved.
- Turn conclusions into actions and track their effect with the same data.
Common mistakes
- Collecting lots of data with no question to guide it.
- Confusing control limits with specification limits or targets.
- Treating a correlation in a scatter diagram as proof of causation.
- Building a Pareto chart on frequency alone when the cost or severity of some causes matters more.
- Stopping at the chart, with no discussion or decision.
- Treating every small fluctuation in the figures as a special problem that calls for action.
The value of these tools is not in their charts, but in getting the team to speak the language of data.
