The first mistake comes before any why: a poorly defined effect. “We have quality problems”, for example, gives nobody anything to work with. The effect has to be measurable (which defect, on which line, how much, since when), because the whole diagram will be checked against it.
The first round almost always produces vague labels: “old mould”, “bad material”. They sound like causes, but they can’t be verified. The fix is to go down to the machine or to the data and rewrite the sticky note with something verifiable, whether it’s what was seen or what the process sheet says. A note that can’t be confirmed or ruled out is no use for asking the next why.
Something similar happens with blame. “Careless operators” or “the technician didn’t connect it” show up, sometimes far down the diagram, when the group thought it had moved past that stage. There is a simple test: if the problem would still be there with a different person, the cause isn’t the person. The note is rewritten as observable behaviour or as a failure of the system (the task has no owner, nobody teaches another way to react).
Some ideas are true but answer a different question. “Parts aren’t inspected” explains why the defect reaches the customer, not why it happens. It isn’t thrown away. It goes to “awaiting decision”, because it deserves its own analysis. Mixing it in with the rest contaminates the diagram. Generic notes that overlap with another branch (“lack of maintenance”) are simply removed, and whatever truth they held ends up surfacing further down in concrete terms.
The most frequent mistake, and the hardest to spot, is in the arrows. A note can be well written and hang from the wrong place. This happens in two ways. The first is placing two causes side by side as siblings when they are really parent and child: raising the pressure doesn’t sit next to “high pressure”, it explains it, so it has to drop a level. The second is grouping by topic instead of by causality. The dryer gets placed under “material” because everything about material seems to belong together, but it doesn’t explain why the flow index varies between batches. It explains the damp material, which is in another branch and two levels further down. When this comes to light, the diagram isn’t corrected by adding things. It’s corrected by moving them.
Links go missing too. Going from “the plan counts hours, not cycles” to “wear on the mould” seems reasonable until you read it slowly: counting hours doesn’t wear anything. The intermediate step is missing (the mould exceeds its planned cycles without inspection). Once it’s inserted, everything hanging below it drops a level.
The tool for catching both misplaced arrows and gaps is to read each branch aloud, bottom-up, joining the notes with “therefore”. If any sentence grates, there’s a problem there.
Another mistake is stopping too early, at the technical cause: the dryer’s heating element is broken. That gets fixed by replacing the element, and the next breakdown will go unnoticed again. You keep asking until you reach something that depends on how the work is organised (failures on auxiliary equipment aren’t logged in the maintenance management system) and that allows a concrete action with an owner. That’s where you stop, and not before. This is why the long branches need five or six levels while others close at three. There’s no need to even them out.
Personally, I prefer the tear drop format to the fishbone or Ishikawa diagram, and many of the mistakes above explain why. The fishbone starts from fixed categories (machine, method, material, manpower, environment, measurement), and that pushes people towards exactly the grouping by topic described above. The dryer would end up on the “machine” or the “material” bone, and its link to the damp material, which is what matters, would stay hidden. The “manpower” category is also an open invitation to write down culprits. In the tear drop there are no predefined boxes: each note hangs from the note it explains, and the structure comes from causal relationships, not from a classification.
The other reason is depth. Fishbone diagrams tend to end up wide and flat, with many causes on the first or second level and few chains going further. Part of the reason is that the small bones have almost no room. In the tear drop the levels are visible. You can see at a glance which branch has stopped short, and the space grows downwards precisely where more causes appear. With sticky notes, moving an idea to another level or another arrow takes seconds, and reading bottom-up with “therefore” works because each chain is a single continuous line. I don’t discard the Ishikawa categories. When a group gets stuck in the first round, going through them helps ideas come out. I use them as a checklist, not as the structure of the diagram.
None of this becomes visible unless you accept that the diagram isn’t drawn in one go. What comes out in the first half hour is a draft, and the tear drop shape emerges only after rewriting, moving and removing notes several times.
Visitas: 3