一、ISO 9001:2015 8.3.6 标准原文

二、条款解读说明

2.1 为什么设计更改往往比初次设计更危险

设计和开发更改在组织中极为常见。可能是顾客提出新要求、法规更新、缺陷修复、成本优化、材料替代、软件迭代、接口变更、工艺改善或供应链调整。相比初次设计，更改的难点在于系统已经在运行：相关文件、生产条件、库存、在制品、外包接口、顾客版本、历史数据和既有验证结论都已经存在。此时任何一个更改如果影响评估不充分，都可能牵一发而动全身。

这就是为什么8.3.6强调识别、评审并控制所有设计和开发过程中或随后所作的更改。它并不反对更改，相反承认更改是常态；它真正反对的是“改动被低估”“改动未经评审”“改动版本失控”“改动后影响外溢却无人察觉”。

2.2 条款要求的四个关键词，构成完整更改链条

2.3 设计更改的风险，常常发生在“看起来没那么大”的地方

很多严重问题并不是由大范围重构引起，而是由被低估的小改动引起。例如材料替代导致耐久性变化、参数微调引起接口兼容问题、标签字段修改导致追溯断裂、软件权限调整导致数据风险、结构简化影响装配工序。组织若没有明确的更改识别边界，往往会把高影响变更放进低强度流程，结果让问题悄悄流入后端。

因此，8.3.6强调的是基于影响的控制强度，而不是基于“改得多还是少”的直观判断。关键不是改动大小，而是改动可能带来的符合性、功能性、安全性、合规性和一致性后果。

2.4 设计更改不只发生在开发阶段，也发生在后续运行阶段

标准明确提到“在产品和服务设计和开发过程中或随后所作的更改”，说明设计更改并不在项目发布后自动终止。量产后的工程变更、服务上线后的功能迭代、现场反馈驱动的方案优化、法规更新后的调整、停产替代件导入、质量问题纠正带来的设计修改，都属于8.3.6控制范围。很多组织恰恰是在产品或服务已经运行后，最容易放松设计更改纪律。

2.5 更改控制的关键，是识别受影响对象和切换策略

设计更改绝不只是修改图纸、代码或流程文件那么简单。组织必须评估受影响的输入、输出、验证结果、在制品、库存、供方、生产工装、检验方法、顾客现场版本、服务手册和培训材料。评估之后，还要确定切换策略：是一次性切换、并行切换、分客户分批次切换，还是先试点再全面切换。没有切换策略的更改，很容易产生新旧版本混用问题。

三、实施要点

3.1 建立清晰的设计更改识别边界

组织应定义哪些变化必须进入设计更改流程，例如功能变化、性能变化、材料替代、参数调整、软件逻辑修改、接口变化、标签版式变化、服务范围变化和法规应对性修改等。边界越清晰，越不容易把高风险变更漏进日常小调整里。

• 将典型更改场景列表化，便于前端识别。
• 对看似小但风险高的更改单独列为强制评审项。
• 明确谁有权判断某项调整是否属于设计更改。

3.2 对更改做系统性影响评估

更改评审不能只看技术本身，还要看其对顾客要求、法规、关键特性、验证结果、库存、在制品、生产工艺、供应链、说明书、培训和售后支持的影响。特别是已量产或已上线的产品和服务，更要评估历史版本、在场版本和过渡版本的管理问题。

• 建立受影响对象清单，避免遗漏外围环节。
• 对高风险更改增加跨部门联合评审。
• 必要时要求重新验证、重新确认或重新顾客确认。

3.3 设置与风险匹配的批准和验证强度

更改不是一刀切审批。低风险更改可以走简化路径，高风险更改则应要求更高层级批准、更充分验证和更严格切换控制。尤其涉及安全、法规、关键功能、顾客接口和批量产品的更改，不能仅由单一技术角色自行决定。

• 按更改等级设定审批层级和验证深度。
• 对关键更改保留例外风险说明和补充控制措施。
• 对紧急更改建立快速但仍可追溯的应急路径。

3.4 同步控制版本切换和旧版退出

更改生效之后，最常见风险是新旧版本并存。组织应明确更改生效时点、适用批次、适用客户、库存处置、在制品处理、旧版文件回收、系统切换和现场培训要求。特别是软件版本、图纸、BOM、标签模板和操作指引，必须保证同一时间内的有效版本唯一可识别。

• 明确新旧版本过渡规则和切换时点。
• 对在制品和库存定义返工、报废、豁免或并行策略。
• 更新后验证现场和系统是否真的已切换到新版。

3.5 用更改后表现反向验证更改质量

更改不应在批准后就视为结束。组织应跟踪更改后的质量表现、顾客反馈、过程波动、验证结果和外部投诉，检查改动是否真的解决了原问题，是否引入新的副作用。对问题型更改，要及时回滚、再改进或重新评审。

• 对重大更改设置更改后观察周期。
• 收集顾客、生产、服务和供方多方反馈。
• 将不良更改案例纳入经验库，防止重复踩坑。

四、常用工具与实施方法

五、典型案例

案例一：材料替代引发批量问题的纠偏

1. 背景：企业因供应紧张替换了一种材料，初看技术参数接近，后续却出现耐久性下降。
2. 问题：组织把材料替代当采购事项处理，没有走设计更改评审。
3. 8.3.6行动：将材料替代纳入设计更改边界，实施重新验证和库存切换管理。
4. 结果：后续替代更受控，批量风险明显下降。
5. 启示：看似小的材料变化，可能实质上是高风险设计更改。

案例二：软件权限调整导致数据越权的修复

1. 背景：团队为提升效率修改了角色权限规则，结果引发数据访问越权问题。
2. 问题：更改未评估对顾客场景和安全边界的影响。
3. 8.3.6行动：建立高风险软件更改评审、场景验证和回滚预案。
4. 结果：后续权限更改稳定性提升，异常可快速回退。
5. 启示：设计更改不仅要看功能改善，也必须看副作用和边界风险。

案例三：量产图纸更新后的旧版残留治理

1. 背景：企业已发布新版图纸，但部分车间和供方仍使用旧版。
2. 问题：更改批准了，但版本切换和旧版退出未被系统控制。
3. 8.3.6行动：重建版本切换规则、旧版回收清单和供方确认机制。
4. 结果：新旧混用问题大幅减少，供方协同更稳定。
5. 启示：设计更改管理的一半工作，在批准后才真正开始。

六、成文信息管理要求

8.3.6明确要求组织保留设计和开发更改的形成文件的信息，包括更改内容、评审结果、批准和防止不利影响所采取的措施。这意味着设计更改不能只留一个最终版本，而要有完整的决策和影响证据链。

6.1 建议保留的核心记录

6.2 管控建议

• 更改单应与受影响输入、输出、验证和顾客要求建立关联。
• 重大更改建议同时保留切换策略和回滚策略。
• 量产后或上线后的更改要特别关注库存、在制品和存量客户影响。
• 更改记录应保留足够时间，覆盖至少一个完整问题暴露周期。

七、常见误区及踩坑提醒