Fishbone / Ishikawa

An Ishikawa diagram is a single-page picture: the effect (the defined problem) at the head, the spine running left, and major-category bones branching off — Method, Machine, Material, Man, Measurement, Environment — with possible causes branching off each bone. The strength of the diagram is not the picture itself but the discipline of brainstorming exhaustively across every category before jumping to a hypothesis. Mature use puts the team in front of the diagram with the data (defect samples, batch records, photographs, complaint text) and works each bone to exhaustion before moving on. The output is not the diagram but the prioritised list of candidate causes that go forward to data-driven verification.

• Method — the process, the procedure, the SOP, the sequence, the operating parameters.
• Machine — equipment, tooling, fixtures, instrumentation, controls, software, utilities.
• Material — raw materials, components, packaging, consumables, supplier lot variability.
• Man (Person / People) — operator skill, training, fatigue, handoff, shift, communication.
• Measurement — sensor accuracy, gauge R&R, sampling, lab method, calibration.
• Environment (Mother nature / Milieu) — temperature, humidity, lighting, vibration, particulate, season.
• Management — sometimes added as 7th M for systemic causes (resourcing, priorities, governance).
• Money — sometimes added as 8th M when budget constraints drive the failure (deferred maintenance, deferred capex).

Service-industry adaptations replace Material / Machine with People / Process / Policy / Place / Promotion / Product (the 6 P's). The categorical scheme matters less than the discipline of working it exhaustively.

1. Define the effect precisely. 'Batch yield down' is too vague; 'API potency 92% on the last 6 batches when historical mean is 97%' is workable.
2. Assemble a cross-functional team — production, QA, engineering, supply, often supplier or customer representation.
3. Brainstorm every bone exhaustively — no idea is rejected at the brainstorm stage. Use sticky notes for divergence, then group at the end.
4. Sub-branch where appropriate — under Material > supplier lot, branch lot number, manufacture date, COA result, storage history.
5. Annotate each cause with the data needed to verify or disprove. The diagram is the brainstorm; verification is the rest of the investigation.
6. Prioritise — circle the 3-5 highest-likelihood causes; assign owners and verification methods.
7. Verify with data — every circled cause becomes a test (is the supplier lot different? is the operator different? is the parameter setpoint different?).
8. Conclude — confirmed cause(s) feed the CAPA / 8D D4 / Q9 risk assessment; disproved causes are documented and dismissed.

Fishbone is a divergent tool — it expands the universe of possible causes. 5 Whys is convergent — it drills from a symptom to a hypothesised root cause through repeated 'why'. Fault Tree Analysis is logical and quantitative — it tests how combinations of events lead to a top event. Pareto analysis is statistical — it ranks observed defect categories by frequency. Mature investigations chain the tools: Pareto identifies the dominant defect, fishbone brainstorms its possible causes, 5 Whys drills the most likely cause to its root, fault tree quantifies if the failure has system-safety implications. Using fishbone alone for a complex failure usually misses the systemic root; using 5 Whys alone often locks in on the first plausible answer and misses the actual cause.

1. Effect not precisely defined — diagram brainstorms 'quality problems', produces nothing actionable.
2. Brainstorm done by one person at a desk — the cross-functional perspective that makes the tool valuable never happens.
3. Sub-branches missing — major causes listed but not decomposed; nothing to verify.
4. Diagram used as the conclusion — investigation 'closed' with a fishbone in the file and no data-driven verification.
5. Causes confused with effects — 'high reject rate' listed as a cause of 'high reject rate', circular and useless.
6. Categories used as buckets rather than as prompts — every cause crammed into one M because nobody worked the others.
7. Fishbone for a recurring problem when the previous fishbone is in the file — same diagram, same conclusion, no learning.

• Deviation / NCR / CAPA / 8D investigation templates have a structured fishbone canvas built in — categories pre-populated, sub-branches expandable, every cause carries verification status and owner.
• Cross-functional invitees pulled from training-record-matched skill profiles — the brainstorm has the right voices at the table by default.
• Causes link to underlying data — supplier-lot causes pull the supplier's recent CoA, operator-shift causes pull the relevant batch executions, equipment causes pull the last maintenance and calibration records.
• Verification status (confirmed / disproved / pending) is enforced — closing the investigation requires every prioritised cause to have a status, not a guess.
• Confirmed causes feed the CAPA scope automatically; disproved causes are documented for the audit trail.
• Recurring-cause detection — if a fishbone is being run for a problem that's been seen before, the previous investigation's conclusions surface so the team starts from what was learnt last time.