手机版
共有六条评价准则：
1.问题症状已被定义和量化；
2.顾客（包括经历症状以及受影响的各方）已经被确定；
3.量化的测量结果表明存在性能差异和/或症状的优先度（严重度、紧迫性、增长趋势）使启动8D过程显得合理；
4.症状原因不明；
5.管理层承诺投入必要的资源从根源上解决问题，并防止其再发生；
6.症状的复杂性仅凭靠个人的能力是不能解决的。
如果上述6项准则都满足了，并且没有其它的8D小组正在解决相同或相似的问题，那就需要开始8D了。
一、8D步骤包括
D1: 建立小组
D2: 描述问题
D3: 制定临时遏制措施（ICAs: Interim Containment Actions）
D4: 确定和验证根本原因和问题逃出点（Escape Point）
D5: 选择和验证永久纠正措施（PCAs: Permanent Corrective Actions）
D6: 执行和确认永久纠正措施
D7: 防止再发生
D8: 表彰小组和个人的贡献
二、对于理解8D方法，有几个关键点需要理清的
1.三大措施针对问题的不同层次。
紧急反应措施（ERA）针对的是问题的结果，因为问题导致的结果会影响顾客，所以应采取紧急反应措施来保护顾客（如：紧急空运替代品到客户那里，防止客户生产断线）；
临时遏制措施（ICA）针对的是问题的症状，也即是问题所显现出的失效表象，在FMEA中失效模式就是指问题的症状，针对问题的症状应采取临时遏制措施，隔离、筛选有问题的产品防止其流到客户那里造成更大的影响；
纠正措施（PCA）针对的是问题的根本原因，只有针对根本原因所采取的永久纠正措施得到确认，问题才能宣告已基本解决（后续步骤就是在系统的层面采取措施防止其再发生，并将这些相关措施举一反三落实到类似的产品和过程中）。
2.描述问题这个步骤非常关键，“问题描述清楚了，问题也就解决了一半”，这句话确实在理。
问题描述（Problem Description）和问题陈述（Problem Statement）是两个不同的概念，问题陈述只是简单提供基本事实，即问题发生的对象和缺陷的类型，而问题描述则是在问题陈述的基础上，对所观察到的事实的更细致地描绘，它能提供找出问题根本原因的细节。详细而有效的问题描述包含四大要素：
（1）什么
1）是什么对象发生了问题？
2）那个问题是什么？
（2）何处
3）有问题的对象在哪里（地理位置）？
4）哪个问题在对象上的哪个部位？
（3）何时
5）问题何时被首次发现（日期或时刻）？
6）问题首次发生在生命周期（或流程）的哪个阶段？
7）问题是以哪种模式出现的（偶尔、不断地、周期性地、等等）？
（4）程度
8）问题有多严重？
9）有多少对象出现了这个问题？
10）问题的趋势是怎样的（恶化、好转、维持在一定的状态、等等）？
与5W2H描述法相同，谁（Who）在什么时间（When）什么地点（where）如何发现（How ）什么东西（What）出现了什么样的（Why）问题，该问题带来的影响是什么（How many）。
3.问题逃出点（Escape Point） 是一般解决问题过程中容易忽视的地方。
其实确定问题的逃出点实际上是帮助我们找出“问题为什么会流到顾客哪儿？”这个引申出来的过程控制或雷竞技百科 控制有效性方面的问题。
一般来说，好的问题解决方法应关注三个方面：
1）问题为什么会发生？
2）问题为什么会流到顾客哪儿？
3）我们的雷竞技百科 管理体系为什么不能防止问题的发生和流出？至少来说，前面两个方面是一定要关注到的，这样“防止再发生”的措施才切实有效。
4.理解验证和确认的区别。
验证和确认这两个术语在ISO9000中有明确的定义。
验证（Verification/Verify）是指通过提供客观证据对规定要求得到满足的认定；
确认（Validation/Validate）是指通过提供客观证据对特定的预期用途或应用要求得到满足的认定。
也就是说，验证针对的是满足技术规范的要求，而确认针对的是满足客户预期的功能或用途的要求。比如：我们要制作一枚钥匙，会按这枚钥匙的图纸所规定的规格尺寸来制作，我们把制作好的钥匙按这份图纸（也就是技术规范）的尺寸和公差要求来检验，这个过程就是验证；但符合图纸的尺寸和公差要求的钥匙不一定能实现“开锁”这个预期的功能和用途，那我们还要把按图纸检验合格的钥匙拿去试试看能否打开与其配对的锁，这个过程就是确认。
简单来说，验证是认定技术要求是否得到满足，而确认则是认定顾客要求是否得到满足，验证和确认的根本目的是要最终满足顾客的预期用途或应用要求。
