噩梦般的情景。 电话响了，你惊恐地得知，你以为一个月前已经摆脱的问题又回来了，而且比以前更大。 你的胃在下沉，你的脉搏在加快，因为你急于找出到底发生了什么。 你知道工厂管理层迟早会出现在你的门口，与你进行 "严肃 "的讨论。
这种情况经常发生，并占用了我们获得奖励的宝贵时间--将产品送出门外。 更糟的是，它使我们进入了我们被惩罚的领域--修复。 再次。 我们被告知的问题已被永久解决。
在我们讨论现在该做什么之前，让我们快速看一下，看看当我们认为自己做对了的时候发生了什么，以及事实上什么出了问题。
大多数日常的根本原因分析（RCA）遵循以下几个步骤中的一个或一个组合。
- "我知道原因。" (RCA行动-头脑风暴）修复它，并希望考虑修复后上游/下游可能出现的问题（超越修复的思考）。
- "我想我知道原因。" (RCA行动-五个原因)验证，修复，"超越修复的思考"。
- "我有一些关于原因的想法。" (RCA行动-鱼骨图) 使用鱼骨图中的原因，修复它，并 "超越修复的思考"。
那么，在这个过程中，当他们没有得到正确的结果时，会发生什么？ 它通常从问题陈述开始。 在许多情况下，操作者倾向于跳到原因，并以如此模糊的术语记录问题，只有他们知道自己的意思。 当你试图给他们一些结构，即使用 "五个为什么 "的过程时，情况是这样的。
问题。 "为什么三号线的生产很慢？"....
答案是。 "新管子不合适"
问题。 "为什么新管子不合适？"...
回答：。 "孔太小，不容易插进去"
问题。 "为什么孔太小？"...
回答：。 "我不知道，昨天对我们来说还不错"
问题。 "昨天以来发生了什么？
回答："我不知道。 "我不知道。
通常在这个时候，操作员会与他周围的人和班长讨论，他们通过口头的鱼骨式讨论，提出一些 "修复 "的想法。 然后，他们做出改变，记录他们所做的一切--希望如此--并继续前进。
当确认应该取代头脑风暴时
那么，什么地方出了问题？ 首先，在 "五个为什么 "过程中，五不是一个神奇的数字。有时，它需要额外的问题来获得有效的可能原因。 以 "我不知道 "结束并不能提供有效的数据来定义一个原因。它只是表明需要更多的信息。 在使用 "五个为什么 "时，重要的是隔离并集中确认--而不仅仅是头脑风暴--来自前一个问题的答案。 头脑风暴，而不是集中的、有针对性的提问，意味着所有的答案都是有效的，这鼓励操作者应用许多 "修复 "来解决所有的答案。 这只是掩盖了真正的根本原因，并在问题再次出现时使数据变得混乱，供今后分析。
继续前进。找到原因的原因
这里还有一件可能出错的事情。 同样重要的是 不是 将中间原因定义为 "根本 "原因，而不首先根据事实和数据对其进行测试，以确定它是否是真正的原因。 不首先根据事实检查可能的原因的弊端是，它可能导致操作人员将他们的故障排除工作推向 "已知原因 "的修复，在许多情况下，这与原始问题无关。
最后，如果你的操作人员在RCA问题上深入推动，并寻找 原因的原因 像这样。
问题。 "为什么三号线的生产很慢？"....
答案是。 "新管子不合适"
问题。 "为什么新管子不合适？"...
回答：。 "孔太小，不容易插进去"
问题。 "为什么洞口太小？"...
回答：。 "我不知道，昨天对我们来说还不错"
问题。 "昨天以来发生了什么？
回答："我不知道。 "我不知道。
问题。 "对孔的规定是什么？"...
回答："它是在工具设置中指定的。 "它是在工具设置中指定的"
问题。 "工具设置中规定了什么"？.....
回答："工具设置SOP中有什么？ "工具设置SOP中的内容"
问题。 "我们是否检查了为工具设置的内容？"....
回答。 "不，我们认为它是好的去处"
问题。 "让我们检查一下。"......
回答。 "看来在编程过程中，设置的数据输入有误。"
通过提出有针对性的问题，分离出针对问题的数据，你可以减少你的问题。 邪恶的 将问题转移到关键的少数人身上，避免出现噩梦般的情况...... "ITS BACK"!
