一、根因分析的最大误区：把"可能的原因"当"结论"
场景你一定不陌生：
一个产线停机的质量事故，你带着团队开了两小时的脑暴会。鱼骨图画得密密麻麻，5M1E 每个分支下都挂满了可能原因——
"设备老化？有可能。" "操作工没培训到位？也有可能。" "原材料批次有问题？不排除。"
会议结束，你发现你有了 15 条"可能的原因"，但没有一条能告诉你：到底应该先查哪一个？
这就是根因分析最常见的困境——穷举了可能性，但没有建立逻辑推理链条。
鱼骨图擅长发散，但它的弱点是：所有原因看起来"平级"的，你不知道哪个原因最致命，也不知道原因之间是否存在组合关系。
这时候你需要的是另一种工具：故障树分析（FTA，Fault Tree Analysis）。
二、故障树和鱼骨图的本质区别
| 维度 | 鱼骨图（Ishikawa） | 故障树（FTA） |
|---|---|---|
| 分析方向 | 从结果发散找原因 | 从顶事件向下逐层分解 |
| 原因关系 | 所有原因平行 | 用 AND/OR 逻辑门表达因果关系 |
| 适用场景 | 初步头脑风暴 | 深度逻辑分析、定量风险评估 |
| 输出 | 原因列表 | 最小割集 + 事件概率 |
| 典型用户 | 产线质量工程师 | 可靠性工程师、安全分析 |
简单说：鱼骨图帮你"列清单"，故障树帮你"建模型"。
三、故障树的核心概念：三个东西就够了
拿出一张纸，掌握三个要素你就能画故障树：
3.1 顶事件（Top Event）
你最关心的那个"坏事"是什么？把它写在最上面。
例如："CNC 加工中心意外停机"
3.2 中间事件与基本事件
每一层往下问："这件事发生，是因为什么？"一层一层拆，直到拆到不能再拆的基本事件（根本原因）。
3.3 逻辑门：AND 和 OR
这是故障树区别于鱼骨图的关键：
- OR 门：下面任意一个事件发生，上面的就发生。比如"停机"可能因为"刀具断裂"或"冷却液不足"或"电气故障"——任意一个就够了。
- AND 门：下面所有事件同时发生，上面的才发生。比如"火灾"需要"可燃物"且"氧气"且"点火源"三者同时具备。
这个逻辑门的意义在于——不是所有原因都平级，有些原因是"帮凶"，单独存在不构成威胁。
四、用一个例子走一遍
场景： 汽车轮毂螺栓拧紧工位，扭矩合格率从 99.7% 掉到 97.3%。
第一步：定义顶事件
"M12 螺栓扭矩超差（< 115Nm 或 > 125Nm）"
第二步：第一层分解（OR 门）
扭矩超差可能因为：
- 拧紧工具问题
- 被连接件问题
- 操作过程问题
第三步：继续往下拆
拧紧工具问题 →
- 拧紧枪扭矩传感器漂移（基本事件）
- 套筒磨损导致打滑（基本事件）
被连接件问题 →
- 螺栓螺纹有毛刺（基本事件）
- 轮毂螺纹孔内有异物（基本事件）
操作过程问题 →
- 未按对角线顺序拧紧（需要 AND 门：操作工培训缺失 且 防错装置失效）
- 拧紧程序参数被误修改（基本事件）
第四步：识别最小割集
最小割集 = 导致顶事件发生的最少基本事件组合。
在这个例子里，大多数原因单独就能导致扭矩超差（OR 关系），只有一个需要两个条件同时满足（AND 门）。这意味着你的排查策略应该是——
先查单点故障（基本事件），最后再查需要组合条件的。
五、什么时候用鱼骨图，什么时候上故障树？
| 情况 | 推荐工具 |
|---|---|
| 问题刚发生，信息不充分，需要快速发散 | 鱼骨图 |
| 已经有了初步的原因列表，需要排优先级 | 帕累托图 |
| 需要向管理层/客户汇报根因分析的逻辑链条 | 故障树 |
| 安全性要求极高的系统（航空、医疗、汽车安全件） | 必须用故障树 |
| 需要计算顶事件的发生概率 | 故障树（定量分析） |
一个推荐的工作流：先用鱼骨图做头脑风暴 → 用帕累托图筛出关键少数 → 对 Top 3 原因上故障树做深度逻辑拆解。
六、"你有病，我有药"——这个方法论怎么落地？
用澹墨质量的故障树工具，你只需要拖拽逻辑门和事件节点——改一个 AND 门后面的连线自动重排，不用重画整张图。
说实话，故障树在纸面上画很痛苦。改一个逻辑门意味着后面所有的连线都要重画。更不用说如果你需要计算顶事件概率——手动算最小割集是可靠性工程师的噩梦。
澹墨质量的故障树工具让这个流程变得简单：你只需要关心逻辑，工具帮你处理可视化。
写完逻辑关系，工具自动生成故障树图，导出一张 PNG 直接放进你的 8D 报告或质量分析报告——这比你在 PPT 里用文本框一根一根画线快 10 倍。