关于 fishbone-analysis
用于质量问题根因调查的鱼骨图分析技能,面向需要系统梳理潜在原因的跨职能团队。它要求覆盖 6M 类别、依据证据评估原因,并将已确认或可能的原因交由 5-Why 深入验证。
主要功能
- 01按 6M 类别梳理原因
- 02先发散再评估原因
- 03按证据标记原因状态
- 04与现有 PFMEA 交叉检查
- 05将候选原因转入 5-Why
- 06检查相似产品和流程的横向部署
适用场景
- 01开展 8D D4 头脑风暴
- 02启动 CAPA 根因调查
- 03分析存在多个潜在因素的缺陷
- 04确认根因后检查相似流程
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ rbraga01/ quality-engineering-skills --skill fishbone-analysis安装后在 Claude Code 中输入/fishbone-analysis确认已加载。
附带文件references/6m-category-guide.md
详细介绍
鱼骨图(石川图)分析
适用场景
在开展 5-Why 之前,使用鱼骨图分析头脑风暴,列出质量问题的所有可能原因。它能避免视野狭窄,确保不遗漏任何原因类别。对于有多个潜在影响因素的复杂缺陷,这种方法尤其有价值。
典型用途:8D D4 头脑风暴会议、CAPA 根本原因调查、初步问题分析。
前提条件
- 已通过 Is/Is-Not 或 5W2H 明确定义问题
- 跨职能团队(至少包括质量、生产和工程人员)
- 能够接触发生缺陷的流程、机器或产品
鱼骨图必备检查清单
☐ 开始前已定义并就问题陈述达成一致——问题陈述中不得包含原因描述
☐ 已涵盖全部 6M 类别——每个 M 至少有一项,若某类别不适用,须记录理由
☐ 先完成头脑风暴,再进行评估或排除——生成原因时不得进行评估
☐ 使用客观证据将每项原因归类为已确认、可能或不太可能——不得仅凭主观意见
☐ 已确认 = 有数据或实物证据支持;可能 = 合乎逻辑,符合 Is/Is-Not,但尚未确认;不太可能 = 与数据矛盾
☐ 在继续进行 5-Why 之前,已将已确认和可能的原因与现有 PFMEA 失效原因条目交叉核对
☐ 每项已确认或可能的原因均分别进入独立的 5-Why 链
☐ 确认根本原因后:进行横向展开检查——类似零件、流程或产品系列中是否可能存在相同原因?
6M 框架
鱼骨图的六根主骨。**必须涵盖全部六项。**如果某一类别确实不适用,请记录:“经团队系统审查后,该类别未发现原因——不适用,因为[理由]。”
1. 人(人为因素)
要询问的问题:
- 执行任务的操作员是否经过培训并具备相应资质?
- 能力是否有记录且仍然有效?
- 操作员是否遵循了正确的作业指导书?
- 疲劳、换班或分心是否可能造成影响?
- 该任务在人体工程学方面是否存在困难或容易出错?
- 所有班次都发现了相同缺陷,还是仅在某个班次发现?(仅单个班次出现 → 与操作员有关)
2. 机器(设备)
要询问的问题:
- 机器是否经过校准?上次校准是什么时候?是否仍在校准周期内?
- 是否按计划进行了预防性维护?
- 是否存在已知偏差(振动、磨损、温度漂移)?
- 机器能力如何(Cp、Cpk)?是否能够满足该特性的要求?
- 工装是否磨损或损坏?
- 夹具或工装是否正常运行?
3. 方法(流程)
要询问的问题:
- 该工序是否有书面的作业指导书?
- 作业指导书是否为最新版本,且是否放置在工作站?
- 是否规定并控制了工艺参数(温度、压力、速度、扭矩)?
- 控制计划中是否包含该工序步骤?
- 流程顺序是否正确?
- 不同班次或操作员采用的方法是否不同?
4. 材料(输入材料)
要询问的问题:
- 缺陷是否与某个特定来料批次或供应商批次相关?
- 材料是否符合规格要求(合格证、来料检验)?
- 材料是否按要求储存(温度、湿度、先进先出)?
- 材料是否可追溯到来源?
- 供应商最近是否有任何变更(次级供应商、流程、地点)?
5. 测量(测量系统)
要询问的问题:
- 测量系统是否具备能力(是否已进行 MSA / Gauge R&R)?
- 量具是否经过校准且仍在校准周期内?
- 测量方法是否标准化(使用相同夹具、采用相同的操作员测量手法)?
- 测量误差是否可能掩盖缺陷(误判为可接受)?
- 不同操作员的测量结果是否具有重复性?
6. 环境 / 自然因素
要提出的问题:
- 缺陷是否与环境温度或湿度相关?
- 附近是否存在振动源或污染源?
- 光线是否足以进行目视检查?
- 是否存在季节性规律?
- 洁净室或 ESD 环境是否符合要求?
工作流
步骤 1 — 绘制图表
在鱼头(右侧)标出问题(结果)。画出主干。添加六条主骨,并标注 6M 类别。
步骤 2 — 与团队一起头脑风暴
针对每个 M 类别,提出问题:“[M] 中哪些因素可能导致[问题]?”
记录所有想法,不做评判——先追求数量,再进行评估。**头脑风暴期间不要评估或舍弃任何想法。**至少安排 30–60 分钟。时间紧迫是漏掉原因的最常见因素。
将每个原因作为相关 M 类别的一条分支骨添加进去。分支骨还可以继续延伸(探究原因的原因)。
步骤 3 — 评估并确定优先级
将每个原因标记为:
- 已确认(有数据或直接物证支持——而非意见)
- 可能(逻辑上合理,符合“是/否”模式,但尚无数据证实)
- 不太可能(与数据或“是/否”模式相矛盾)
舍弃不太可能的原因。调查已确认和可能的原因。没有客观证据(测量数据、实物演示、复现测试或直接记录审查),不得将原因归类为已确认。
步骤 4 — 与 PFMEA 交叉核查
继续进行 5 Why 分析之前,将已确认和可能的原因与现有 PFMEA 交叉核查:
- 此失效原因是否已记录在 PFMEA 中?如果是,原有的检测或预防控制措施是否应当能够防止此缺陷?
- 如果 PFMEA 未记录此原因,请标记出来——确认根本原因后必须更新 PFMEA。
步骤 5 — 衔接 5 Why
对于每个已确认或可能的原因,执行 5 Why 链式分析,以找出系统性根本原因。
鱼骨图用于识别候选原因。5 Why 用于验证并深入分析这些原因。
确认根本原因后:评估类似零件、工序或产品系列中是否可能存在同样的原因。如适用,请记录横向展开措施。
输出格式
将鱼骨图记录为表格(比图表更便于纳入报告):
| M 类别 | 可能原因 | 证据 / 状态 | 是否继续进行 5 Why? |
|---|---|---|---|
| 人员 | 操作员未经培训 | 缺少操作员 12 的培训记录 | 是 |
| 设备 | 夹具磨损 | 测得磨损量为 0.3mm——限值为 0.1mm | 是 |
| 方法 | 无应急作业指导 | 已审查作业指导书——确认缺失 | 是 |
| 材料 | 批次差异 | 未发现与批次的关联 | 否 |
| 测量 | 量具重复性 | GR&R = 8%——可接受 | 否 |
| 环境 | 温度 | 控制在 22°C ± 2°C——稳定 | 否 |
表格中必须包含全部 6M 类别。如果经过系统化头脑风暴后某个类别没有任何条目,请记录:“经过团队系统审查,此类别未发现任何原因。”
常见错误
- 在时间紧迫的情况下进行头脑风暴——容易漏掉原因;至少安排 30–60 分钟
- 止步于第一层原因——“设备未校准”是一个原因,但还应添加分支骨:为什么没有校准?
- 未使用数据进行确认或排除——每个原因都必须通过客观证据验证,而不能只是列出来
- 把鱼骨图当作根本原因——鱼骨图用于找出候选原因;5 Why 用于找出根本原因
- 跳过类别——如果某个类别留空且没有说明,分析就不完整,可能会漏掉真正的原因
- 根据团队意见将原因归类为已确认——已确认必须有证据;没有证据时,应归类为可能并制定验证计划
输出格式
每次开始使用时,都要询问用户:
“您希望以哪种格式接收输出? A — 结构化 Markdown(包含格式化表格和章节,可直接复制) B — 纯表格(简化结构,适用于 Excel 或 Word) C — 叙述式报告(流畅行文,适用于正式文档或电子邮件)
默认:A。”
根据用户选择的格式调整所有输出章节。如果平台或会话上下文已指定格式偏好,则跳过此问题。
更新日志
| 版本 | 日期 | 作者 | 更改 |
|---|---|---|---|
| 1.0 | 2026-06-01 | @RBraga01 | 首次发布 |
| 1.1 | 2026-06-04 | @migmcc | 完善 6M 类别,添加验证标准和 5-Why 集成 |