《16949理解与实施》连载——8.3.6 设计和开发更改
8.3.6设计和开发更改
组织应对产品和服务在设计和开发期间以及后续所做的更改进行适当的识别、评审和控制,以确保这更改对满足要求不会产生不利影响。
组织应保留下列方面的成文信息:
a)设计和开发更改;
b)评审的结果;
c)更改的授权;
d )为防止不利影响而采取的措施。
[理解与实施要点]
一、本条款规定了对变更的识别、评审和控制。 这些变更发生于设计开发过程之中或之后。组织应考虑,作为设计和开发过程的一部分，如何实现与其他过程或相关方(如顾客或外部供方)的沟通,并在确定设计和开发变更时同样加以考虑。
二、设计和开发变更可能产生于如下阶段,包括但不限于:
1.在设计和开发过程实施中;
2.在设计开发输出发布和批准后;
3.作为监视顾客满意和外部供方绩效的结果。
三、更改,不仅包括组织自身的更改,也包括来自供应商的更改。更改实施之前,组织应对这些更改实施适用的设计评审、设计验证和/或设计确认,以确保这些更改对产品的可装配性、形式功能性能和/或耐久性不会造成影响,且满足顾客要求。
四、文件化信息应包括批准变更的授权人。在某些情况下,该批准被要求来自顾客或监管机构。文件化信息可能包括被批准的变更命令或变更的电子签名。
五、在“初始产品批准之后”发生的设计和开发更改，一般而言是指“设计冻结”之后的更改。
六、除非顾客弃权,对于涉及重大的变更(如产品设计变更等),应得到顾客的重新批准。顾客对变更批准的要求,参见顾客的产品批准程序要求。
七、对于嵌人式软件及带有嵌人式软件的产品的更改控制,必须包含形成文件的软硬件版本的控制。
8.3.6.1设计和开发更改--补充
组织应评价初始产品批准之后的所有设计更改,包括组织或其供应商提议的更改,评价这些更改对可装配性、形式、功能性能和/或耐久性的影响。这些更改应对照顾客要求进行确认,并在生产实施之前得到内部批准。
如顾客有要求时,组织应在生产实施之前,从顾客处获得形成文件的批准或弃权。
对于带有嵌入式软件的产品,组织应对软硬件的版本级别形成文件,作为更改记录的一部分。
[理解与实施要点]
1.进一步明确了汽车行业的设计和开发的更改的要求,所有PPAP之后的变更,不管是组织内部发起,还是供应商发起,或顾客发起,必须进行充分的内部批准,在和顾客关于变更进行沟通后,如果顾客有再次PPAP的提交要求的,必须按照要求进行重新的PPAP确认。
2.对于带有嵌入式软件的产品,必须对变更前后的软硬件版本进行识别和区分。
