服务中心

我们不难看出，标准在定义“验证”和“确认”这两个词汇时，所用到的措辞是这样的：

“验证”的关键词：客观证据、证明、满足规定要求

“确认”的关键词：验证、规定要求、满足预期用途

标准对“确认”的定义直截了当：“确认”就是一种“验证”。

“验证”的目的是证明对象“满足规定要求”；“确认”的目的是验证对象能否“满足预期用途”。

显然，“满足预期用途”是“满足规定要求”的一种形式，所以标准才规定“确认”是“验证”的一种情形。

“验证”的对象没有限制范围，也就是说可以是“实体”也可以是“规定要求”之类的虚体；而“确认”的对象只能是“规定要求”。

这里的“实体”可以解释为：具体的人、物品等及其客观属性；具体的情况等事实。

这里的“规定要求”可以解释为：明确表达的需求和期望。例如：经过思考、梳理、制定和审查以后，明确下来的程序、方法、要求、规则、计划、方案等。又如：客户或其他外部单位通过书面（合同、委托、信函等）和口头（谈话、报怨）表达的要求、需求。

当我们说某个人的年龄、学历、持证、技能、履历等等，这些属性都是依附于这个人而客观存在的，因此属于客观证据。例如我们评价这个人的年龄、学历、持证、技能、履历等有没有满足我们机构某个岗位的任职要求。这个任职要求是我们机构自己制定的，即“规定要求”。因此，验证就是拿“客观证据”去和“规定要求”进行比较，满足还是不满足，一目了然。

而当我们机构对某个岗位制定任职要求的时候，我们通常会明确：这个人应该具有什么学历，应该持有哪些资格证书，技能应该达到什么水平，是否以及应该有多少年的工作经历等等。但是这些制定出来的要求，是不是就真的适合这个岗位呢？假如我们按照这个要求招募到了一众人员，他们都能胜任这个岗位吗？这种探求“规定要求”能不能满足预期用途的过程，叫做确认。

■  方法确认 

比如，当我们为了证明自己开发的一种检测程序可以在指定的范围内准确地检测出某种物质的含量的时候，我们就要开展方法确认。

这里的“一种检测程序”指的就是一个需要确认的“规定要求”，要确认的目的是什么呢？就是“在指定的范围内准确地检测出某种物质的含量”，这就是一种典型的“预期用途”。

由于“确认”就是“验证”，“验证”必须要有客观的证据来证实，因此，我们必须采用实证的方法来证明这个方法（而不仅仅是拍脑袋，主观决定），例如：

——与其他标准的检测方法来比较；

——对已知的标准物质进行检测；等等

注意，这里列举的方式并不完整，具体可以参考CNAS规范对方法确认的指南。

而在这些充分的客观证据的支撑下，我们才能拍着胸脯说：“你瞧！我们自己开发的这个检测方法，可以准确地检测出那个物质的含量！”换句话说就是：我们拟定的“规定要求”，满足了“预期的用途”。

所以，通常来说，需要确认的检测方法，基本上都属于非标准方法，例如：实验室自行开发的方法、超出预定范围使用的标准方法、其他修改的标准方法等等。那为什么标准方法不需要确认呢？因为在国家对标准的管理制度之下，标准的编写、研制单位在起草过程之前就已经做好了这些“确认”工作。当标准发布出来以后，标准中的检测程序就已经是能够满足预期的用途了，不需要我们使用方法的人再去确认了。

那么，与“方法确认”相对的概念就是“方法验证”。这里必须要注意的是，“方法验证”是另一个被赋予了独特含义的习惯性表述，而且“验证”的对象也不是检测方法，而是我们检测机构。我们要验证机构能不能正确地应用检测方法。而这才是“方法验证”的含义。

这里必须注意的是，只有用于收集、处理、记录、报告、存储或检索数据的实验室信息管理系统，才需要在正式投入使用之前进行功能确认。而且，标准又规定，经过充分商业化的软件和系统，可以被认为已经经过了确认。因此，我们就不必去过度扩大“软件”的范围了。

“软件系统”是否属于“规定要求”？

在我们朴素的印象里，软件显然更像一个客观存在的“实体”（比如光盘、U盘之类的载体；又如代码、程序文件之类的电子文件）。但是，由于软件系统内置的功能、规则、流程，实质上就是实验室对内部工作如何开展而制定的“规定要求”。因此，软件系统的功能、安全性等，需要进行“确认”。比如我们可以检查软件系统能否正常工作，验证其能否支撑实验室在收集、处理、记录、报告、存储或检索数据等方面的预期用途。

所以，我们会对软件系统开展试运行，查看试运行的过程是否顺利，检查运行的结果及其存储的记录是否正常；我们还会在试运行中提出修改意见和建议，并且对修改的方案和内容进行评审和检查。而且就算系统正式投入运行了，我们还会提出改进的建议，并且在正式部署修改之前，再测试一轮。而这些举措，都是“确认”。

这是一个从ISO 9001:2015的8.3.2条中引述出来的概念。这一条款里面包含了“设计和开发的验证”“设计和开发的确认”这两个概念。

什么是“设计和开发的确认”呢？即设计和开发的内容（能不能）满足规定的用途或已知的预期用途。

确认的对象就是这个“设计和开发的内容”，即设计方案。例如：产品的功能、性能、材质、结构，以及要求的工艺过程，乃至所设计的使用方法、使用环境等等。怎么确认？

由于“确认”即“验证”，因此，对设计方案的确认也必须建立在客观证据的证实基础之上。例如我们对试产阶段的产品进行加工和装配后，开展一些功能性试验，例如：密封、摩擦、碰撞、盐雾等等。经历了一些模拟最终用途的测试和分析以后，我们才可以说：这个产品的设计方案（能不能）满足预期的用途。

那么“设计和开发的验证”和“设计和开发的确认”又有什么区别呢？

既然“确认”即“验证”，我们为什么又要把设计验证和设计确认分开来看呢？这里其实又是一个习惯性的表述。的确！我们完全可以将“设计和开发的确认”并入“设计和开发的验证”。只不过，由于一些习惯问题（比如我们更重视产品最终实现的功能和用途，而不是过分地关注过程中的材料力学特性、制造装配误差、功能性试验结果等等），所以，我们才把“确认”从“验证”中拿出来，单独对待。

而且，在实践过程中，“验证”的结果和“确认”的结果是可能存在差异的。例如：产品制造中某个零件的尺寸超差，那么，这就是不满足规定的要求，属于不合格品了。但是，经过技术分析和处理，即便在最终产品中安装使用了这个不合格的零件，依然可以不影响产品的最终功能和用途。那么请问，这个产品是合格，还是不合格呢？是能用，还是不能用呢？对不合格零件经过技术分析和处理，并在多方共同认可之下“让步接收”，这是生产制造过程中很常见的操作。

因此，部分项目的“验证”不合格，不必然导致最终功能和用途的“确认”不通过。同理，仅凭单个或部分项目的“验证”合格，也不能说明产品功能和用途就可以满足预期。例如，一艘轮船按照设计图纸的所有要求制造出来了，但是航速达不到设计要求。这个时候，就属于预期用途不能确认通过，显然就是设计方案有问题了。

对投诉内容的确认，与前面列举的几种“确认”相比，有一点反直觉。对于接收到的投诉，我们通常会开展调查、分析，明确所投诉的内容是否属实，查明所投诉事项的责任是否在我公司。其实这个做法就是“确认”。

因为投诉的本质就是在表达一种诉求，既然是一种明确的需求，就属于“规定要求”的概念。而我们要确认的，就是这个投诉能否用于后续的处理流程，这种“预期用途”（当然了，这一说法，同样反直觉，但确实符合这种概念）。而且，我们也的确要通过调查——也就是取得客观证据，来验证投诉内容是否属实，是否责任在我。

因此，投诉的确认，也是一种“确认”。

最后再来谈一谈我们经常用错了的“确认”。

我们经常把人员能力确认视为上岗授权之前的一个必要步骤。确认什么呢？

确认这个人有没有能力，以及他具有哪些能力。但是只要一结合“确认”的定义就不难发现，我们对这名人员的能力，不是“确认”，而是“验证”。因为对于指定的人员，他的能力是客观存在的，我们要做的是验证他的能力有没有符合我们机构规定的岗位任职要求。

好，那么这个环节是否应该改名叫做“能力验证”呢？显然不行，因为“能力验证”已经成为了一种质量控制措施的习惯性表述了。

这也是我们经常挂在嘴边的一个词语。很多人都知道设备检定校准以后要进行结果确认。但是，同前面的“人员能力确认”一样，设备经过检定校准以后，它的精度、性能等属性，是一个客观存在的结果（毕竟都写在证书上面了）。而我们要拿这个客观证据，和谁进行比较呢？就是检验检测的要求——这是我们的“规定要求”。而这就是典型的“验证”。而且标准原文用的就是就是“验证”（GB/T 27025-2009·6.4.4：“……应验证其符合规定要求”）。

以上两个“能力确认”“计量确认”的概念，由于最终的结果是：人员满足岗位要求；设备满足检测要求。非常符合“满足预期用途”这一类表述。这大概就是为什么很多人会习惯性地使用“确认”这个词语。但是！我们前面说了，“确认”不仅仅是目的“满足预期用途”，对象还必须是一种“规定要求”。显然，人员的能力和设备检定校准的结果，并不是“规定要求”，而是一种客观存在。

质量管理体系是一门严肃的管理科学，其措辞和用语也十分严谨。很多看似相同、详尽的概念，其背后的含义却有差别，不能混同。自我国70年代引进质量管理体系理念，已有大约50年了，但质量管理体系的很多思想和理念仍然是一个舶来品。很多术语、概念、定义并不完全基于自然语言和本地文化，而包含了很多人为制造的差异。我们在学习和应用质量管理体系知识的时候，尤其需要注意这里面的关系。