困惑7.5.2 ---请各位老师答疑

温勇钦

在编制程序文书的时候 要将产品的特殊过程形成文件说明吗？

rml

把过去在某群空间论坛的帖子转过来。希望有点帮助。
这一帖是lxxxxx老师的帖子，原发CCAA论坛。

[原创]先定位再深入讨论7.5.2的建议

lixiji

需要先行定位的三点建议：
1。尽量引用“质量管理原则”来佐证论点；（原则的作用本身就是制定标准的基础和帮助理解标准）
2。明确标准的要求是为需要证实组织具有“稳定的能力”而规定；
3。按4.1的b)确定7.5.2在整个体系（业务过程）中的顺序。
还希望网友们重温一下“基础统计概念知识”（TS16949 8.1.2：整个组织应了解和使用基本的统计概念，如变差、控制（稳定性）、过程能力和过度调整）
本人确定的过程顺序为：7.2.1——7.3——7.5.2——7.5.1；简述为：根据顾客要求（7.2.1）进行产品和过程设计，将顾客要求转化为组织的过程、产品控制要求（7.3），确认组织策划的业务过程具备生产满足顾客要求的产品的能力（7.5.2），在此基础上对过程进行控制确保过程稳定即受控（7.5.1）。
所以如此提议的目的是，以前很多这方面的讨论由于各位老师的视角不同，可能大家都说对了，但依然不能相互接受对方的观点。建立这个平台是为了能够从同一视角参与讨论，方便大家取长补短。
希望各位老师不吝赐教。

rml

这帖是zdhm在某群空间的回应，下面字数限制也是原文。

zdhm 2010-10-04 10:24:47 删除 1楼    1.用最基本的原则来佐证具体条款相当于用属概念去解释种概念，用粗线条去证实细线是精确的。这好象是逻辑颠倒。最多只能证明7.5.2的基本原理能归属到基本原则上去，是正确的。其实7.5.2的归属是过程控制原理，归属到八项原则上会是很勉强的。更重要的是，深入地讨论7.5.2的目的应该不是讨论其本身的正确性与归属，而是应用讨论。这种讨论应该是向广处和深处推开的，在总体上适用的是演绎方法，而不是归纳方法。
2.理由同上，标准是必须服从的要求。作为执行者而非修订者，所有的讨论应该基于执行规定。而证实“稳定的能力”，是标准总体的主要目的。所以平台统一的第二个基点，也是向初级回归，没有注意到标准在7.5.2所需要证实的是——生产/服务提供过程在输出（即结果）不可验证的情况下实现过程策划结果的能力。亦即：当生产/服务某过程的某些特性不可验时，为这些过程为解决不可验过程的控制所做的安排是否具备有效控制过程的能力的证实。这与由工序能力指数所代表的过程能力和作业量能力有显著的区别。不明白这一点，就不能理解7.5.2。
3.同样的，4.1过于宏观。尽管有许多教师级的人物甚至ISO直隶级的组织一再告诫4.1的确定不能只是产品实现过程，但在客观上，标准中产品实现的过程是不能删减的，“所需的”大过程就产品实现过程条款允许删减，而组织的产品实现过程不论贯标与否，都是应产品技术要求而产生的一种客观实在，所以，客观的过程及其相互关系的确定，绝对是以组织的产品实现过程为核心的。从这一点来说，2000版的“识别”或许用得更恰当。那么。lixiji老师所要求的第三个基点实际上也是上向回归宏观，对7.5.2应用讨论也是南辕北辙的。4.1b确定了过程的相互关系和顺序，其中自然包含了可能的需要确认的过程，却并没有涉及到确认的要求。说实在的，要到了4.1c需要为过程安排控制方法了，4.1e需要监测了，才在理论上应该发现存在一些无法利用结果监测来实施控制的过程。但因为标准这里是宏观的，并没有提供解决办法，等到了7.1c才说“产品要求的……确认”也应该在产品实现的策划中明确。这才引也了具体表述确认要求的7.5.2条款。逻辑过程是这样的，现在我们把标准基点放在最高层的宏观要求中去，其价值是什么呢？我想，至少起不到对应用方法的指导作用的。
所以，个人认为，上述三项建议，对统一讨论的目的未能明白，犯了本末倒置的毛病。是没有意义的。
（字数限制？打不下了）

rml

这是上帖的后续

zdhm 2010-10-04 11:12:51 删除 2楼    TS16949 “8.1.2整个组织应了解和使用基本的统计概念，如变差、控制（稳定性）、过程能力和过度调整”是对其上所引ISO9001-2000标准8.1条款最后一段（“这应包括对统计技术在内的适用方法及其应用程度的确定”）的行业细化（确定）。lixiji老师在这里要求大家重温的原因，估计是这里涉及到了“过程能力”（“如”后只是举例）。
应该注意的是，在TS（以下均用简称）尤其是五大工具里，主要提到的“过程能力”主要是从误差理论提出的控制能力和产能。这与7.5.2特定的无验情况下的保证能力是有区别的。前者主要是满足某种指数以期稳定作业的能力证实，后者是对结果不可验时替代控制能力的证实。
确认推开或被认识后，客观上有这么三种情况的“确认”：
1.因为交付前不可验，安排并证实其替代控制方法的确认。这是必须的确认，不确认则无控制方法（当然，客观上存在有技术标准要求、组织自己进行了安排并证实了控制却不明白这就是确认的情况）。这是必要且必须的确认；
2.可检，但因为验出的不合格品处理（报废或返工）成本功其它影响难以接受，为避免不合格损失组织自己安排并证实了验证以外的控制。我把这叫做扩展确认（对标准未要求对象的应用。扩展应用，因为已经不在9001要求范围，适用的情况只能鼓励，不可强求）。扩展确认属额外增值，不受7.5.2约束。因为存在应按规进行的验证，确认也不能免除验证责任，这是必要非必须的确认；
3.出于多种原因（如标准理解错误、有关人员胡乱要求、混淆过程作业能力与不可验情况下的替代控制能力，个别规范的呆板要求等）所进行无意义确认。理由：当产品不可验时，通常只是部分特性不可验，如其外观与计量等特征通常是可验的，不可验特性是明确的。当产品存在不可承受不合格损失时，影响这个不合格的主要特性也是明确的。这两种（不可验和主要）特性，成为需要解决的问题，构成确认的目的和方向。我把这称为“确认点”。随意的“确认”活动，确认点不明确，目的、方向和解决的问题不明确。往往就是一种形式，劳民伤财却起不到应有的作用（参见1、2条）。是不必要也不必须的活动。

rml

zdhm 2010-10-04 11:50:21 删除 3楼    SO9001-2000/2008明确要求的是第一种确认。这使得结果不可验过程的确认的必要也必须成为标准要求（遗憾的是2008将在2000中表述为包容关系的“不可验”与“后显现”改表为因果关系。但可以抓住一个共同点——“交付前不可验”来回避这个冲突）。
TS16949-2002标准“7.5.2.1 生产和服务提供过程的确认— 补充——7.5.2的要求应适用于生产和服务提供的所有过程”，如果只是在“所有过程”中针对不可验过程，则没有必要提出。因为ISO9001:2000/2008都已经清楚地毫无限制地表明对象在“产品/服务提供过程“中。那么，事实上，TS7.5.2.1将确认要求扩展到了生产和服务提供的所有必要或不必要确认的过程，即上面据说的所有三种确认均是TS所要求的（TS还有一些机械呆板甚至冲突的地方，这里不一一分析）。
这样，lixiji老师提出的过程顺序就会与一般ISO9001-2000/2008使用者有所不同。因为lixiji老师的7.5.2在TS下已经是常规过程，以所有过程为对象，成了”确认组织策划的业务过程具备生产满足顾客要求的产品的能力（7.5.2） “（事实上是7.2.2）了。而在一般ISO9001-2000/2008标准使用者来说，7.5.2只是个触发过程——当7.1c策划时遇到不可验，则启动7.5.2。
那么，在一般ISO9001-2000/2008使用者来说一般顺序是这样的：7.2.1/7.2.3（确定产品有关要求）→7.2.2/7.2.3（评审这些要求的明确性、一致性和可满足性并采取措施、沟通）→（7.3（需要时决定产品做成什么样））→7.1（解决各过程怎么做怎么检的问题（目的、记录是围绕这个的）当不可检时→7.5.2（为不的验证安排控制措施并证实这些安排的控制能力））→7.5.1（策划（通常7.1已经策划否则7.1结果无用）并实施（按7.5.1适用内容和7.1结果）过程控制）……
好吧，先说这些。呵呵，不去CCAA论坛了，在这里自言自语。希望三天后，群空间公开，能因此找到想讨论的朋友。就这个论坛差了点。但可以防止捣乱分子，还是不错。

rml

zdhm 2010-10-05 21:59:33 删除 4楼    本帖引用lixiji老师的帖子，对礼节部分予以删减，

（此处删去礼节性语言30字（连标点符号））
实践中接触到“标准的使用者”很多坦诚地表示7。5。2难以搞懂搞通，原因是各种资料
众说纷纭、莫衷一是。所以想到先把“过程确认”处于整个“产品实现过程”的具体阶段“定位”，结合在此阶段的制造过程的目的和需实际解决的问题，进行讨论，会有些好的效果。
（此处删去39字）

rml

zdhm 2010-10-05 22:42:32 删除 5楼    7.5.2对管理理论和专业实践要求较高，但其实也不难。
其实，“各种资料”对很多标准条款即过程的理解都存在或多或少的误区。这尤其是在2000以后版本的理解上，由于通用程度的提高，标准益发地框架化。这使得使用者不太习惯，总希望以自己或自己老师的理解去阐释标准。大家忘了——标准是协商一致的规范性文件，而且标准是应该能够让未参与编制的使用者能够理解的。由于这个遗忘，大家很少能朴素地理解标准。所以误区解决不了。而一些编制不太好的标准，则继续扩大大家的误区。
前面自言自语的帖子，其实是在我开放了群资料之后写的，据说需要三天时间，公开群的设置才会有效，希望到时你能看到。
在1 楼的帖子里我反对了你的三条建议，其实，如果你仍然站在TS立场我却站在9001立场，这定位是不能统一的。因为9001要求的是必要且必须的确认。它只是针对生产/服务提供过程输出不能验证情况所要求的必须的安排。是一种触发性活动（触发事件为结果不可验证）。连为避免不合格损失必要却非必须的扩展确认也不在它控制范围（无法确定明确的范围和准则）。而TS却连同这两种和其它不必要的确认一同搞成了常规活动。这样，7.5.2的意义和价值都被改变了，两个标准中7.5.2在产品实现过程中所处的位置就当然不同了。
而你只要朴素地去看9001标准（由于上述，TS补充内容是含混的，不可取的），除了有一个问题需要回顾对比2000版本，有一个问题需要管理知识和专业实践，标准都是非常清楚的。
标准的第一段，是清楚地说明了应确认的对象范围。对于2008版本，这需要回顾一下2000。2000描述的“不可验”和“后显现”是处于包容关系的，到了2008，却改成了因果关系。它忽略了“后显现”其实有两种情况：完全不可验和可验但交前验不出，同时在这个地方，因为标准已经非常明白地办界定了对象范围。造成不要再去使用9000标准3.4.1注——7.5.2并未说对象就是该注介绍的俗语“特殊过程”，而这个注所使用的“不易”、“不能经济地”都是不确切概念。这是9000族里最差的注。没有意义还误导范围不清。
标准的第二段，是要求证实过程实现所策划结果的能力。这句话省略了第一段表述的对象特征——交付前不可验证——时（它可是针对对象而要求的）能力。明白了这个前提，明白这个“能力”与CpK等并不直接等同。而是指在结果不可验情况下所作的控制安排保证过程实现所策划结果的能力了。这一段在实用中存在的问题是“证实”高度被忽略和忽悠——大多以零散的过程要素如（续）
zdhm 2010-10-05 23:04:33 删除 6楼    （接）6.2/6.3/7.5.1b甚至7.5.2本身（如过程确认准则）来搪塞这个证实要求。而几乎看不到针对经安排过程的过程整体能力进行证实的。
当然，第三段表述的适用时的安排内容也确实具有真正的难度。标准中所有“必要时”、“适当时”、“适用时”、“适宜的”要求都存在判定其是否“必要”、“适当”、“适用”、“适宜”的难度。应该说，这也是不单纯明确的准则。这时就需要专业与管理经验了。但经验能作为准则吗？显然不能。专业经验只能帮助你识别不可验与后显现，并寻找出正确适用的准则。管理经验则可以帮助你将“适用”的a~c分配到对应的三种不可验情况下的基本控制方法（或它们的组合），并给出记录（d）的最低要求。9001在这里的确有一个缺陷——没有将这些基础方法及其组合与安排的适用性对应起来——这是能够对应的。
如果你明白了这几点，你的过程确认就不再是糊涂的了。
在这个讨论中你同时看到了，标准的要求在正常情况下是明确的，无需作多余阐释的。需要阐释的地方，一定是标准有了问题或使用者还没有进入相应领域。
呵呵，我在几年前为换网币临时写了个《也谈特殊过程》曾被广泛转载，也引来很多审核员朋友。作为基础，还是可以看一下的。只不知还能够搜到不。我的QQ空间里有。

朱迪

又学习了

admin

RML写的很好，不愧是大家