再聊8D

最近发现很多朋友在写8D报告时遇到很多问题，那咱们就来再说一说怎么来用8D吧。8D流行起来，要说1987年，福特汽车公司首次用书面记录下

最近发现很多朋友在写8D报告时遇到很多问题，那咱们就来再说一说怎么来用8D吧。

8D流行起来，要说1987年，福特汽车公司首次用书面记录下8D法，在其一份课程手册中这一方法被命名为TOPS（Team Oriented Problem Solving）即 “团队导向问题解决法”，从此8D方法被广泛应用，但其实8D问题解决的思路是由美国国防部在1974年创立后来被发扬起来的。

一开始8D是有8个步骤的，后来又加了个D0（紧急反应行动ERA），这个D0是做什么的呢？主要是为了看此类问题是否需要8D来解决，很多公司出了问题就用8D，觉得这是个好工具，这么想没毛病，但是这是需要花费资源的，很多培训资料也都提出来，一般三类问题做8D：一直重复发生的问题；比较重大的质量问题；客户要求回复的投诉。

而我的理解，复杂的问题，需要跨部门分析时再进行8D，还有就是系统性的问题，避免再次发生时使用8D。因为8D要做好是要小组一起下功夫的，势必需要一些资源（人员/经费/时间等）。我相信大部分人是找到了问题原因和解决方案再返过来编写报告的。

D0在很多材料里除了判定是否进行8D，还要做一个紧急反应措施（ERA），我觉得这个不是很合理，我们在这个阶段会有一个初步的原因分析，如果问题简单明了，我们可以进行ERA，后续就不需要8D了，如果客户强制要求我们写8D，那我们可以写在D3这个步骤里，毕竟是后写（编呗），如果我们初步找不到原因，那我们定义要做8D，这样我们按照顺序也可以在D3的时候进行ERA，这样逻辑也不冲突，综上，我觉得一份8D报告中，是不应该体现D0这一个步骤的，这一个步骤应该是现场人员思维达成一致的体现。

开始正题，大家可以想想看，有多少人是自己一个人就完成了8D报告的，你觉得你一个人就把问题解决了还需要做一个8D报告吗？成立团队，首先一定要把和这个问题相关的人拉进来，这个很重要，否则对于问题描述可能会得不到详细的信息，另外就是一些有经验的相关人员，毕竟解决的是重大的、系统的问题。很多资料对这块扩展了不少，比如DICS，各种风格的人相互配合，我觉得这些倒不重要，D1完全和D2可以一起完成，甚至可以先D2再D1。

说实话，D2是我认为最重要的一条，要用量化的术语详细说明与该问题有关的内/外部顾客抱怨，如什么、地点、时间、程度、频率等，我们最常用的就是5W2H法，我见过很多问题描述写的都是什么坏了，这让人看了从哪下手呢？最起码我们要知道什么东西出了什么问题，要搞清楚对象和缺陷，描述出来可以让人明确问题是什么，问题不是什么。

只有搞清楚了问题，我们后面才能避免做无用功，也是为什么D1的时候要把相关人员拉进来，确定了范围，我们也能有针对性地做出D3的决定和后续的分析方向。在描述问题时，我们尽量多使用照片和视频作为辅助，才能更直观地来了解问题。

有的人用4W3H来描述问题，也非常地好，毕竟有时候Why没有那么直观，描述问题一定要客观，如果一开始你就感觉到了结论，你描述问题的现象就会偏向你结论的方向。

保证在永久纠正措施实施前，将问题与内外部顾客隔离，这时候我们可以根据问题严重程度进行ERA，一般的措施有100%挑选，停产，返工返修，召回，补料等等。及时的处理会让客户满意。

需要注意的就是不要等着原因分析完再进行围堵措施，那如何做出正确的遏制行动就非常重要，一定要秉承从客户的角度出发来对策。

可从上面这几个方面来进行围堵，避免遗漏。

识别和试验所有的潜在原因，将问题描述中提到的造成偏差的一系列事件或环境或原因相互隔离测试并确定产生问题的根本原因。大部分的报告采用的都是鱼骨刺图，其实我们还可以使用树图，关联图、排列图等等。

在做原因分析的时候，一般采用的先是头脑风暴法，从人/机/料/法/环，从发生/流出/系统，从各个工序，从各种原因类别……

找到这么多原因，下一步怎么办呢，从个人经验来讲，团队会议上一定要排出优先级来，我们有有经验的队员，初步识别出排列靠前的因素，然后进一步分析下去，这块就用上我们嘴上常说的5Why方法了，也就是刨根问底儿：

刨到最根本的原因后，我们就要验证，这里可以仿真模拟，也可以故障再现，确保原因识别正确。经常编8D的人，肯定会分析人员责任心差，操作失误，设备故障了，未能监督到位等等。其实原因分析会耗费很多时间，就是为了找到根本的原因，以杜绝类似问题再次发生。

找到了原因就好说了，根据原因我们开始选择纠正措施，我们可以理解为D3在纠正（为消除已发现的不合格所采取的措施），D5这块是纠正措施（消除已发现的不合格或其他不期望情况的原因所采取的措施）。

这一条和D4的方法一样，最终筛选出需要采取的措施，并要进行确认，实施的措施能够解决问题，且不能产生新的问题。

其实在这一步就要明确出纠正措施，大家善用的方法是德尔菲法或试验、试产等。德尔菲法亦称 “专家意见征询法”，主要是采取专家意见，但要注意：

1． 吸收专家参与预测，充分利用专家的经验和学识；

2． 采用匿名的方式，能使每一位专家独立自由地作出自己的判断；

3． 预测过程几轮反馈，使专家的意见逐渐趋同。

一般在看别的写的报告时，我主要看的还是D2、D4和D5，这几块其实就是报告的核心内容了。

到了这一步就没啥可说的了，按照计划实施纠正措施：

也可以做甘特图，主要还是不要忘记确认结果，要确保措施落地。

提出预防建议，并横向展开，更新CP、PFMEA、SOP等标准文件，大部分人搞不清楚这块和D6怎么写，直接点就是D6解决的是问题本身，描述了解决方法但还没有到更新文件的步骤，D7要从两个角度考虑，该问题的解决思路更新相关的指导文件，如CP，SOP等，再者就是更新FMEA，横展到类似产品中去。这块再回顾一下和纠正措施的区别：

纠正措施（消除已发现的不合格或其他不期望情况的原因所采取的措施）；

预防措施（消除潜在的不合格或其他不期望情况的原因所采取的措施）。

扁鹊的故事大家应该都听过，他说：大哥治病是在病人发病以前，这时候病人都不知道自己有病，大哥下药就把病情扼杀在萌芽中，即使他的医术不被世人所理解，但在我们家，都认为他的医术很高明（这就像是预防措施，干了没人看得到）；我的二哥治病是在病情刚刚显现的时候，这个时候病人的病情还不是很严重，病人也没有什么痛苦，二哥一剂药下去就可以药到病除，所以很多人都认为二哥只是治小病很灵（这就像是过程控制，避免走偏发生批量）；而我治病，是在病情已经很严重的时候，病人已经受到了很多的疼痛的折磨（这就是纠正了，大部分人喜欢看这个）。

最后这条实在没啥写的，国内不流行这个。很多培训资料都把这条改成了经验总结，我是不太认可。就应该好好地奖励一下嘛，要培养大家团队协作的意识嘛。工作中除了困扰大家多时的问题，最好还是别用8D，不然光自己搁那编报告就得烧死多少脑细胞，拿出来的报告也让人不忍直视。