B/T19017—2020/ISO10007:2017

b 适用的法律法规要求； c） 风险和安全方面的关键程度； d) 新的或改进的技术、设计或开发； e 与其他技术状态项的接口； f) 采购条件； g） 支持与服务。 选择技术状态项的数量应考虑尽可能优化组织控制产品或服务的能力。在产品或服务生命周期中 立尽可能早地开展技术状态项的选择。随产品或服务的进展，应对技术状态项进行评审

5.3.2技术状态信息

技术状态信息包括定义和使用信息。它们通常包括：要求、规范、设计图样、零件清单、数据模型、试 验规范、操作手册（用于调试、维护和运行），及有关停用和处置的所有具体要求。 技术状态信息应是相关的并可追溯。组织应确定唯一的命名和编号方式，以确保对每一个技术状 态项、数据和与之相关的技术状态项的适当控制，并应考愿组织现有的命名和编号方式，以及更改控制 的信息，例如：版本修订状态

给水标准规范范本5.3.3技术状态基线

技术状态基线由代表对产品或服务定义的经批准的技术状态信息所组成。技术状态基线及其经批 准的更改，代表了现行有效的技术状态。 在产品或服务生命周期中，一且需要就应建立技术状态基线，以便为后续活动或满足评审的特定要 求确定基准， 在技术状态基线中，定义产品或服务的详细程度取决于所要求的控制程度

技术状态信息在初次发布后，所有的更改都应受控。更改的潜在后果、顾客要求和技术状态基线， 将影响到对处理建议更改或让步所需的控制程度。 控制更改的过程应形成文件，并应包括下述内容： a 对更改的表述、理由和成文信息； b） 依据复杂程度、资源和进度所确定的更改的类别； c 更改结果的评价； d) 如何处理更改的细节； e 如何实施和验证更改的细节。 注：有些组织使用术语例如“例外放行”或“偏离"代替“让步”

5.4.2更改需求的提出、标识和文件编制

更改可由组织、顾客或外部供方首先提出。在提交管理机构（见4.2)评价前，所有的更改建议都应 予以标识，并作为成文信息予以保留。 更改建议通常包括下述信息： a）需要更改的技术状态项和相关信息，包括它们的名称和当前版本修订状态的详细情况； b）对建议更改的描述；

017—2020/ISO10007.2

会受到更改影响的其他技术状态项或信息的详细情况； d 提出更改建议的相关方以及提出的日期； e） 更改的理由； f 更改的类别。 更改处理的状况、相关的决定和处置应作为成文信息予以保留。为便于识别和追溯，将更改形成文 件的典型方法是使用可给出唯一标识号的标准表格

5.4.3.1组织应对建议更改进行评价并作为成文信息予以保留。评价的范围应与产品或服务的复杂程 度、更改的类别相一致，并应包括下述内容： a） 建议更改的技术效益； b) 与建议更改有关的风险； c) 对合同、进度和成本带来的潜在后果； d) 建议更改未被批准的潜在影响。 5.4.3.2 在确定更改的后果时，还应考虑下述因素： a 适用的相关法律法规要求； b) 技术状态项的互换性，以及重新标识它们的需求； ) 技术状态项之间的接口； d) 制造、试验和检验方法； e） 库存和采购； f) 交付活动； 顾客支持要求

应建立、实施并保持更改处理的过程，对每一个建议更改确定其管理机构（见4.2），并应考虑建议更 改类别。 建议更改经评价后，管理机构应对这个评价进行评审，并对更改的处理做出决策。 对更改的处理应作为成文信息予以保留，并应将处理通知分发给内部和外部的有关相关方

5.4.5更改的实施和验证

实施经批准的更改通常包括： a）对已经向有关相关方发布的技术状态信息的更改； b）受到更改影响的内部和外部有关相关方采取的措施。 更改实施后，对其与经批准的更改的符合性应进行验证。这种验证应作为成文信息予以保留，以便 于追溯

技术状态记实活动形成与产品或服务及其技术状态信息相关的成文信息、报告。 组织应在产品或服务的整个生命周期中开展技术状态记实活动，以便支持技术状态管理 其有效。

5.5.2.1在进行技术状态标识和更改控制活动期间，将产生技术状态记实成文信息。这些成文信息考 虑了可见性和可追溯性，以及对不断演变的技术状态的高效管理。它们通常包括下述详细内容： a） 技术状态信息（例如：标识号、标题、生效日期、版本修订状态、更改历史及其在任何基线中所包 含的内容）； b） 产品或服务的技术状态（例如：零件号、产品设计或制造状况）； c 新技术状态信息发布的状况； 更改的处理。 5.5.2.2 不断演变的技术状态信息应作为成文信息予以保留，保留方式应能识别出提供要求的报告（见 5.5.3）所需的相互引用和关联关系。 5.5.2.3 为了保护技术状态信息的完整性，并为更改控制提供基础，推荐将技术状态项和相关的信息保 存在下述环境条件下： a 符合所要求的条件（例如：计算机硬件、软件、数据、成文信息、图样所要求的条件）； b） 提供保护防止完整性缺失或未经许可的更改； C） 提供灾难恢复的方法； 在需要的时间和地点，可以获得并适合使用；

为了达到技术状态管理的目的，需要各种类型的报告。这样的报告可以覆盖单独的技术状态项或 整个产品或服务。 通常，报告包括： a） 包含在某一特定的技术状态基线内的技术状态信息清单； b） 技术状态项及其技术状态基线清单； C 当前的版本修订状况及更改历史的详细情况； d) 更改和让步的情况报告； e） 交付技术状态和维护技术状态的详细情况（例如零部件、追溯号码及其版本修订状况）

技术状态审核应根据成文信息进行，以确定产品或服务是否符合要求并与技术状态信息一致， 通常有两类技术状态审核： a）功能技术状态审核。这是一种正式的审查，以验证技术状态项已经达到了在技术状态信息中 规定的功能和性能特性。 b） 物理技术状态审核。这是一种正式的审查，以验证技术状态项已经达到了在技术状态信息中 规定的物理特性。 在技术状态项正式验收前，可要求进行技术状态审核。这种审核并不是要取代其他形式的验证、评 、试验或检验，但它可能受这些活动结果的影响。

GB/T19017—2020/IS010007:2017

附录A （资料性附录） 技术状态管理计划的结构和内容

技术状态管理计划的编制架构，应包含A.2至A.7的标题的内容，并形成相应的章节。A.2至A.7 也给出了相关内容的指南

技术状态管理计划需包含引言，给出概述性信息。引言通常包括下述主题的内容： 技术状态管理计划的目的和范围； b 对该计划适用的产品或服务以及技术状态项的描述； C) 为编制重要技术状态管理活动时序表提供指导的进度安排； 技术状态管理工具的描述； 相关的成文信息（例如：来自供方的技术状态管理计划）； 有关成文信息及其相互关系的清单

技术状态管理计划应详述已经与顾客和供方达成一致的技术状态管理方针。它应为合同范围内的 技术状态管理活动提供依据，例如： a） 在技术状态管理和相关管理活动实施方面的方针： b） 有关相关方的组织、职责和权限； ） 资质和培训； d） 技术状态项选择的准则； e） 报告的频次、分发和控制： f） 术语。

技术状态管理计划应详述： a） 技术状态项的分解结构、规范和其他成文信息； 规范、图样、让步和更改采用的命名和编号方法； 版本修订状态的标识方法； d） 需要建立的技术状态基线、进度计划以及需要包括的技术状态信息类型； e) 顺序号或其他追溯标识的使用和分配； f） 确定技术状态信息发布过程（包括任何相关的程序）的成文信息

安全生产标准技术状态管埋计划应详述： a）组织的管理机构（见4.2)与其他有关相关方之间的关系； b）在合同规定的技术状态基线建立之前的更改控制的成文信息： c）处理更改（包括那些由顾客或供方提出的更改）和让步的方法。

B/T19017—2020/ISO10007:2017

技术状态管理计划应详述： a）收集、记录、处理、维护和归档用于生成技术状态记实成文信息所必需数据的方法 b）所有技术状态记实报告内容和格式的定义

技术状态管理计划应详述： a）收集、记录、处理、维护和归档用于生成技术状态记实成文信息所必需数据的方法； b）所有技术状态记实报告内容和格式的定义

技术状态管理计划应详述： 需要进行技术状态审核的清单及其在项目进度计划中的安排； D 需要使用的技术状态审核的成文信息： 内部和外部有关相关方的职责和权限； d）技术状态审核报告格式的规定

技术状态管理计划应详述： 需要进行技术状态审核的清单及其在项目进度计划中的安排； D 需要使用的技术状态审核的成文信息： 内部和外部有关相关方的职责和权限； d）技术状态审核报告格式的规定

工程规范9017—2020/ISO10007:2