标准的正文用黑色斜体标出，解读部分则用正常字体。

8.2 产品和服务的要求

标准单独把“产品和服务的要求”放到一个小章节里，可见对其的重视程度。这也非常好理解，既然公司是销售“产品和服务”给客户的，那当然要弄清楚客户需要什么样的产品和服务。在这个章节里，标准写了如何确认相关的要求，以及有什么要求。

8.2.1 顾客沟通

与顾客沟通的内容应(shall)包括：

因为这里是shall的要求，所以大家可以对照一下自己公司在与客户确认“产品和服务的要求”的时候，有没有涵盖以下5点。

a)提供有关产品和服务的信息；

公司必须向客户提供自己的信息，而且还是要和客户的需求相关，证明自己是有能力向客户提供合格的产品和服务。这里可以包括初期的公司介绍、接待客户到厂参观等，当然也包括提交样品时，客户需要的各种文件等信息。读标准的时候，需要发散自己思维，把工作上遇到的信息不断地与标准条款对比，这样相当于给自己的工作找到了指导思想，有利于自己的工作。

b)处理问询、合同或订单，包括更改；

这个我想是毫无疑问的，客户的咨询，特别是下订单之前的咨询肯定需要给予处理。收到合同或订单后，肯定要确认产品的具体内容，包括图纸、版本等等。审核的时候，客户订单评审是很容易被审到的，特别是客户订单变更或者图纸升级，公司如何与客户确认好。这部分没有什么难的，就是是否能够严格执行的区别。

c)获取有关产品和服务的顾客反馈，包括顾客投诉；

这个条款也是毫无疑问的，因为本标准的目的是增强顾客满意，所以这里就强制要求公司要和客户保持沟通，获取反馈。这部分和“9.1.2顾客满意”是相关的。

d)处置或控制顾客财产；

比如客户需要采购产品，但是里面需要用到的一个零件是客户来采购，只是放在你这边进行代组装。或者干脆你所在的是一家外包公司，给客户加工客户的产品的。那如何管理这些属于客户的财产，就必须要和客户确认清楚，如何保存、使用、盘点频率等等。

e)关系重大时，制定应急措施的特定要求。

这个条款用到的机会不多，比如你是在一家热处理的公司，可能就需要和客户确认好，如果因意外停电（园区电路故障等非企业可控的因素），那么热处理到一半的产品，要如何处理？报废还是可以进行返工，如果返工的话有没有特殊的处理要求？

8.2.2 产品和服务要求的确定

在确定向顾客提供的产品和服务的要求时，组织应(shall)确保：

其实日常工作中，和公司息息相关的是8.2.3的部分，那里才是公司在面对客户需求时，如何做评审的具体要求。所以8.2.2这部分，是为了明确对公司要担负的责任的要求。要求公司确保自己卖给客户的产品和服务，能够达到要求。那我们就来看看，最终，公司要达到哪些要求才可以。

a)产品和服务的要求得到规定，包括：

1)适用的法律法规要求；

2)组织认为的必要要求。

b)提供的产品和服务能够满足所声明的要求。

这里的逻辑是本标准一以贯之的：要求——证据。和前面几章里提到的思路是一致的。先确定某个要求，然后提供证据表明产品或者过程符合要求。如果不行，那就PDCA一下。没有什么是几次PDCA不能解决的。

8.2.3 产品和服务要求的评审

8.2.3.1 组织应(shall)确保有能力向顾客提供满足要求的产品和服务。在承诺向顾客提供产品和服务之前，组织应(shall)对如下各项要求进行评审：

审核的时候，对客户订单评审过程进行审核的条款，就是参考这里的。只不过标准的范围更广一些，也可以帮助我们打开思路。

a)顾客规定的要求，包括对交付及交付后活动的要求；

这个条款很好理解，客户规定的要求包括：图纸、合同等有明文规定的要求，仍然要注意一下，要求是对于“产品和服务”的，不仅仅对于产品。至于交付后的活动，则涉及到后续的服务以及客户反馈或投诉的反应等。

特别是交付后的活动，客户反馈或者投诉，公司的相关部门对问题进行分析并且向客户提交报告，这都是常规操作，大家应该都很熟悉了。

但是对于交付后活动的变化，其实也比较重要。举个例子，客户退回故障件要求返工/返修，公司原来的操作是进行检测并返修。经过几年后，客户不再满足于仅仅对故障件的分析和返修，还要公司提供出现故障的原因分析和改善，那势必要求公司在这方面投入更多的人员和时间，因为分析真正的原因，要做测试与验证，还要了解客户的使用环境等等，搜集和分析的信息量是增加一个数量级的。如果客户明确了新要求，那公司一定要考虑增加合适的人力或物力，不然操作的人会累死的，而且由于资源限制，也不容易出成果。

b)顾客虽然没有明示，但规定的用途或已知的预期用途所必需的要求；

这个条款是比较模糊的，属于不成文的规定，大家都知道，但没落到纸面上。具体怎么界定真的是仁者见仁了。

我在好多年前遇到过一次这个例子，让当时还年轻的我十分困惑。

那时候我所在的公司是生产中压开关柜的，在某次出货的时候我看到开关柜面板上的标签都是空的，于是我暂停了产品的发货。结果后来查了一圈下来，技术部没有对面板标签做规定，生产部于是也就没把这一项加入控制项。中间扯皮的事情不提。

当时让我纳闷的是：如果面板上标签都没有，客户如何使用上面的按钮和开关？这不是很明显的需求吗，怎么就没有被定义呢？

所以这个第b条的内容，是标准写在这里，防止企业推卸一些明知故犯的小错误的。工作还是要好好做才行，推卸责任的事情要不得。我们主动选择学习和进步，不仅仅是为了钱，也是要让自己真正的做得更好才是。

c)组织规定的要求；

这部分是企业的内部要求，往大了说企业对出货的产品和服务的检测要求，是要大于客户要求的，这样才能有足够的安全余量。往小了说，企业对过程和出货，都是有要求的，只有达到所有的要求，才可以提供给客户。

企业如何根据客户的要求，来逐步分解和设定自己过程中的各个要求，推荐大家去搜索一下QFD（质量功能展开）的资料，有很详细的解释。这个工具对研发、质量策划的岗位用处很大，但是里面的思路，其实对所有的岗位都适用，看完后会发现，本标准中的过程方法，在里面的应用是十分广泛的。

d)适用于产品和服务的法律法规要求；

这一条不需要解释。

e)与以前表述不一致的合同或订单要求。

这个条款，是直接涉及到审核时最常用的内容。我们在审核供应商的时候，会看供应商在接到订单后，会不会核对产品物料号、数量、版本、交期、订单号等等信息，然后再看供应商在生产和出货的过程中，有没有把客户的订单要求进行确认和链接。特别是发现客户订单的图纸版本变更后，有没有及时与客户确认变更的内容。

但根据标准的要求，其实真正的重点是，公司在接到客户要求时，如何分析客户的要求，如何将客户要求展开（实际上就是QFD过程），如何把客户的要求转化成内部控制的具体要求。这才是应用8.2.3条款进行和审核的核心内容。而看看怎么确认订单要求，没什么含金量，审核的常规操作罢了。

说句题外话，如果有朋友在大公司上班，特别是和一线生产打交道，平时是得不到前端的消息的，不知道自己日常工作的内容起什么作用。这时候就可以多琢磨琢磨8.2.3条款的内容，把日常工作、前后道反馈的信息联系起来，会增加对整个过程的理解，对适应工作，抓住重点，都有不少帮助。

组织应(shall)确保与以前不一致的合同或订单要求已得到解决。

注意shall的表述，如果发现客户新订单与之前要求有差别，必须确认和解决，不然因为确认工作不到位而导致的投诉，责任全是公司的。

若顾客没有提供成文的要求，组织在接受顾客要求之前应(shall)对顾客要求进行确认。

这句话是针对小公司或者一些紧急情况（来不及修改或者下发订单）时所用，一定要做好确认和留下信息，通过电话确认并发送相应的微信或短信，固定要确认内容。

注：在某些情况下，如网上销售，对每一个订单进行正式的评审可能是不实际的，作为替代方法，可评审有关的产品信息，如产品目录。

8.2.3.2 使用时，组织应(shall)保留与下列方面有关的成文信息：

因为对产品和服务的评审实在太重要了，所以一定要留下足够的证据，标准这里直接要求要留下成文信息，作为日后查证用，也可以用来转化为以后的组织知识。

a)评审结果；

不管是评审客户要求的结果，还是评审客户订单的结果，都要保留成文信息。前者是企业制定WI和过程、测试要求的基础，后者是排产的基础，都要保留成文信息。

b)产品和服务的新要求。

如果有新要求，必须记录下来，同时评审目前的过程和要求，能不能满足新要求，如果不行，就要改变过程和要求。

8.2.4 产品和服务要求的更改

若产品和服务要求发生更改，组织应(shall)确保相关的成文信息得到修改，并确保相关人员知道已更改的要求。

这一条是紧接着8.2.3.2，先评审客户的新要求，如果需要更改，那势必会导致公司的WI以及测试要求，甚至售后要求都发生变化。这些变化必须要体现在公司的程序文件或者WI中。这也是为什么标准在这里要用shall的原因。

现实中有太多的例子了，客户的要求发给供应商，供应商没能做好沟通，导致可能技术部或者质量部知道，但是其他部门不知道变更，或者只是口头告知变更，根据8.2.3.2和8.2.4的条款，都可以开具不符合项。

当然了，找到合适的条款开具不符合项，并不是审核的目的。更重要的是，找到问题的归属，然后改善。

就像现在我随口说的例子，有些人会说客户要求内部没沟通好，是人员不够、不重视、信息传递太慢等等，需要培训或者设置更好的流程。

但根据标准来解读，是对生产和服务要求的评审与变更做的不好，从这个高度去解读，一开始就会着眼于打通销售、研发、质量、生产的壁垒，这是一整个过程，理顺过程间的配合。这么一看，思考的纬度是不是比单纯盯着谁谁谁没通知到这个细节要好很多？