关键词：TL9000认证|TL9000培训|TL90005.0认证
4.2.3.C.1 客户提供文件和资料的控制 如果影响产品实现和/或支持，组织必须建立和保持一个或多个形成文件的程序 以控制客户提供的文件和资料(例如：网络架构、拓普图、容量、安装委托书、 图纸和数据库)。
5.2.C.1 客户关系开发 最高管理层必须就组织及其客户之间互利关系的建立和维持体现出积极的参与和介入。
5.2.C.2 顾客沟通方法 组织必须建立和保持沟通的方法，以便和经选择的客户分享期望，确保产品质量 改进。顾客沟通的结果应该包括解决识别出来的事项所产生的行动和提供改进客 户满意的机会。
5.2.c.2-注 公认对于一个组织不可能对所有客户提供同等水平的沟通。所提供的水平依靠于和客户的业务量、问题的历史、客户的期望和其他因素 。
5.4.1.C.1 质量目标
质量目标必须包括《TL 9000 质量管理体系测量手册》中规定的 TL 9000 测量指标。
5.4.2.C.1 长和短期质量策划 组织的质量策划活动必须包括以改进质量和顾客满意为目标的长和短期计划。这 些计划必须针对组织及其客户相关的业务因素，包括和经选择的客户共同建立的 绩效目标。这些目标的绩效必须加以监控和报告到最高管理层。
5.4.2.C.1-注 1 策划时可以考虑的因素例子是：
a) 周期时间; b) 客户服务; c) 培训;
d) 成本;
e) 交付承诺;
f) 产品可靠性;
g) 可持续发展性
5.4.2.C.1-注 2 最高管理层应该在长和短期质量策划中体现积极的参与。
5.4.2.C.2 客户输入 组织在质量策划活动时，必须实施方法以征求和考虑客户的输入。组织应该和客
户一起共同建立质量改进方案。
5.4.2.C.3 供方输入 组织在质量策划活动时，必须实施方法以征求和考虑供方的输入。
5.5.3.C.1 组织绩效反馈 组织必须把其质量绩效和顾客满意水平告知员工，包括质量管理体系评审的结 果。
5.5.3.C.1-注 组织的敏感信息可以排除在本要求之外。
6.2.2.C-注 依赖于组织活动的性质、单独的职责、以及组织和个人发展的阶段，教育和 培训的需求可以非常不同。(培训)交付的方法可以包括在岗培训、交叉培训、工作轮 换、教室经验(教授/分享)、电脑(操作)培训、远程学习或其他方法。培训可以在组 织内发生或由外部提供，并应在工作中加以强化。
6.2.2.C.1 内部课程开发 当组织负责开发内部培训课程时，组织必须就确保课程策划、开发和交付的一致 性而建立和保持方法。
6.2.2.C.2 质量和过程改进概念意识 对产品质量有直接影响的员工，包括最高管理层，必须在持续改进基本概念，问 题解决和顾客满意方面接受培训并加以应用。
6.2.2.C.3 产品质量培训机会的获知 在要求(开展)影响产品质量的培训时，组织必须实施方法以确保员工能够参加。 方法应该针对：
a) 培训机会的沟通;
b) 培训课程可开办。
6.2.2.C.4 静电释放ESD培训所有牵涉到静电释放敏感产品的搬运、储存、包装、防护或交付的员工，必须在执行工作前接受静电释放保护的培训。静电释放知识更新培训的形式和频次必须 由组织来规定。
6.2.2.C.5 高级质量培训 组织必须提供适当层次的高级质量培训。高级质量培训的例子可以包括统计技 术、过程能力、统计抽样、数据搜集和分析、问题识别、问题分析，以及根本原因分析。
6.2.2.C.6 危险状况(条件)培训内容 当存在潜在的危险(源)情况时，培训内容必须包括
a) 任务的执行;
b) 个人安全和适当的防护设施;
c) 对危险环境的意识;以及
d) 设备防护。
6.2.2.HV.1 人员资格认定组织必须对所有适用的过程建立人员资格认定和再认定的要求。资格认定要求必 须针对员工教育、经验、培训和技能的证实。
6.2.2.HV.1-注需要人员资格认定和再认定的过程例子包括绕线、焊锡、焊接、光纤熔接和实验室过程。
6.3.C.1 基础设施组织必须识别基础设施中的关键区域并提供安全以保护这些区域。
6.4.C.1 工作区域 搬运、储存和包装产品的区域必须清洁、安全并(得到良好地)组织(规划)， 以确保他们不会负面地影响产品质量和人员表现。
7.1.C.1 生命周期模型 组织必须建立和保持一套或多套整合的方法，覆盖其产品的生命周期。该方法适 当时必须包括产品在概念、定义、开发、导入、生产、运行、维护和处置时牵涉 的过程、活动和任务，跨越产品的寿命。
7.1.C.1-注 1 生命周期模型可以包括，针对选定准则所评估的替代解决方案的考虑和开发。
7.1.C.1-注 2 生命周期模型需要考虑可持续性的实践，诸如能源和资源消耗的节约、对生态负责的处置和适当的生命周期终了的处置。
7.1.C.1-注 3 新产品导入的方法应该包括提供以下方案：质量和可靠性预测研究、试产、需求和(市场)容量研究，销售和服务人员培训、客户文档(形成)和培训，以及新产品导入后的评估。
7.1.C.2 灾害恢复 组织必须建立和保持文件化的灾害恢复计划和安全恢复计划，以确保组织在整个 生命周期中产品再创造和服务的能力。灾害恢复计划必须至少包括危机管理、业务连续性，以及信息技术。灾害恢复和安全恢复计划必须对有效性加以定期评价， 并由适当级别的管理层进行评审。
7.1.C.2-注 恢复能力的类型应该包括与灾害恢复有关的一系列行动陈述。例子包括：通知谁，在什么情况下通知他们，谁有授权采取行动，以及谁将协调计划中描划的步骤。
7.1.C.3 寿命结束的策划 对不再继续产品的制造和/或支持，组织必须建立和保持一个或多个形成文件的 程序。该程序文件应该包括：
a) 在某一定时期后终止全部或部分的支持;
b) 产品文档和软件的存档;
c) 将来任何剩余支持事项的职责;
d) 如适用，转换到新产品;
e) 对数据存档副本的获取;以及
f) 组织的零件和组件的处置。
7.1.C.4 工具管理 组织必须确保在产品生命周期内，内部开发的软件和/或工具有适当的方法加以(质量)管理。
7.1.C.4-注：需考虑的工具的例子包括：设计和开发、测试、配置管理、文档、手稿、 定制、模具、印模、夹具，以及诊断工具，包括建立和测试产品的软件。
7.1.HS.1 配置管理计划组织必须建立和保持一个配置管理计划，应该包括：
a) 配置管理活动的识别和范围;
b) 实施这些活动的进度安排;
c) 配置管理工具;
d) 配置管理的方法和文件化的程序;
e) 分派给他们的组织(机构)和职责;
f) 每个配置项所需控制的程度;以及
g) 哪些点需要加以配置管理。
7.1.HS.1-注 配置管理计划不需要被包含在一份单独的文件中。
7.1.V.1 服务交付计划
负责交付或执行服务的组织，必须遵守 7.3.1.C.1 项目计划和 7.3.1.C.4 风险管理的要求。
7.2.2.C.1 结案追踪 所有要求评审所引起的行动必须加以追踪直至结案。
7.2.2.C.2 合同评审 组织必须建立和保持一个合同评审过程，它需要包括：
a) 产品接受的准则和准则评审的过程;
b) 产品接受后发现问题的处理方法，包括客户投诉;
c) 在适用的保质期后或产品维护合同期内，不符合事项消除和/或纠正的计划;
d) 对风险和可能的事故的识别;
e) 对知识产权的充分保护;
f) 对外包工作时组织职责的界定; g)客户所开展的工作，包括客户在要求、规格和接受方面的角色; h) 客户所提供的设施、工具和软件;以及
i) 所有参考的标准和程序。
7.2.2.C.2-注 产品接受准则应该包括，适当时
a) 文件化的测试程序;
b) 测试环境;
c) 测试容器装置;
d) 测试数据;
e) 测试职责;
f) 涉及的资源;以及
g) 所要求的测试接受的报告。
7.2.3.C.1 问题告知 组织必须建立和保持一个或多个形成文件的程序，把致命的问题报告，对可能受 影响的所有客户加以告知。
7.2.3.C.2 问题严重性分类 除了那些特别注明没有严重等级报告的产品之外，组织必须根据《TL 9000 质量 管理体系测量手册》中定义的致命、严重和轻微问题报告，基于对客户的影响， 对客户报告的问题指定严重程度。该严重性程度必须用于确定组织响应的时效性。
7.2.3.C.2-注 客户和组织应该一起决定解决客户所报告问题的优先程度。
7.2.3.C.3 问题升级 组织必须建立和保持一个或多个形成文件的(问题)升级程序以解决客户报告的 问题。
7.2.3.C.4 问题报告的反馈 组织必须以及时和系统的态度，对客户的问题报告提供反馈。
7.2.3.HS.1 产品替换 组织必须建立和保持一个或多个形成文件的程序，以识别和替换不适合用于服务 的产品。
7.2.3.HS.2 设计和开发过程质量监控数据汇报 客户要求时，沟通须包括对双方共同同意的一套设计开发过程监控措施的汇报和 评价。
7.3.1.C.1 项目计划 组织的项目策划活动必须基于已定的产品生命周期模型来进行(参阅 7.1.C.1)。 项目计划应该包括：
a) 项目的组织结构;
b) 项目小组的角色、职责和责任;
c) 组织内或外，相关小组或个人的角色、职责和责任，以及他们和项目小组之 间的接口;
d) 进度编排、追踪、事项解决和管理汇报的方式;
e) 与项目活动相关的预算、人手和进度安排;
f) 对所用的方法、标准、书面程序和工具的识别(如果这些事项作为产品生命 周期模型的一部分，已经清楚地作出规定，对该生命周期模型的引用就足够了); g) 对相关计划的引用(例如：风险管理、开发、测试、配置管理、以及质量); h) 对具体项目开发，或服务交付环境和硬件物理资源的考虑(例如：用于开发 的资源，用户文档，测试、操作、要求的开发工具，安全的电脑环境，实验室空 间，工作站等);
i) 在产品生命周期中牵涉到的客户、用户和供方(例如：共同评审、非正式会议、 以及审批);
j) 项目质量的管理，包括适当的质量措施;
k) 对产品生命周期适当的设计“X”计划(计划的例子包括但不限于：可制造性、 可靠性、合规性、可服务性、安全性、可持续性和可测性);
l) 从以往项目后分析所学习到的教训;
m) 针对项目的培训要求;
n) 所需的认证(例如：产品认证或员工技术认证);
o) 所有权、保证期、执照(使用)权;以及
p) 项目(结束)后的分析和改进活动，包括项目教训(总结)学习时的根本原 因分析，以及在将来的项目中为预防重复发生所采取的纠正措施。
7.3.1.C.1-注 1 项目计划和任何相关的计划可以是一份独立的文件，另一份文件的一部
分，或由几份文件组成。
7.3.1.C.2-注 2 对所有开发项目共同规定任务和职责的工作指引，不需要重复复制为项目计划的一部分。
7.3.1.C.2 要求的追溯性 组织必须建立和保持一个方法，以从设计到测试追溯到书面的要求。
7.3.1.C.2-注 组织应该就产品要求和要求更改的传递，对经识别在项目计划中的所有受影响方，建立沟通的方法。
7.3.1.C.3 测试的策划 必须书面制定测试计划，计划中应该包括
a) 测试的范围(例如：产品单体，特性，集成，系统，接受性，市场，移植和 回归);
b) 所要进行测试的类型(例如：功能的，临界的，可用性，绩效表现，回归， 可操作性，互操作性，压力);
c) 对(产品设计)要求的追溯性;
d) 测试环境(例如：与客户环境的相关性，实际操作使用的环境);
e) 测试的覆盖性(具体某项验证产品功能测试的程度，有时用所测功能的百分比的方式表达);
f) 预期的结果;
g) 数据的定义和数据库的要求;
h) 整套的测试，可以重复的测试(例如：输入，输出，测试准则)，以及书面的 测试规程;
i) 所使用的外部测试;
j) 测试报告的方式，对缺陷的解决;
k) 客户的测试要求;以及
l) 事前界定的(测试)退出的准则。 测试的结果和随后所采取的行动必须加以记录。
7.3.1.C.4 风险管理计划 组织必须开发一个计划，并加以文件化，用作识别、分析和控制项目中影响成本、
进度、产品质量或性能的风险。
7.3.1.C.4-注 风险管理应该在产品开发的所有阶段中进行，并应包括：
a) 确定风险源、种类和优先程度的方式;
b) 对重要或关键特性和失效模式，包括客户体验的识别;
c) 用于确定风险优先程度和任何评分机制的风险参数(例如：发生的可能性、影响的 严重性)的界定;
d) 这些风险将如何管理(例如：所用的工具、减少风险的行动、减缓的策略、监视和 报告的要求);
e) 来自适当的功能领域方面的输入;以及
f) 把握和应用教训的机制。
7.3.1.C.5 集成策划 组织必须开发一个计划并形成文件，将硬件、软件和/或服务部分集成在产品中 以确保它们如设计般起作用。该计划必须包括：
a) 方法和形成文件的程序;
b) 职责;
c) 集成的进度安排;以及
d) 测试要求。
7.3.1.C.6 估算 组织必须建立和保持一个方法，针对贯穿产品生命周期的项目计划作估算和追 踪。
7.3.1.S.2-注 项目因素应该包括产品尺寸、复杂性、要求的变更、成果、人手安排、进
度、成本、质量、可靠性和生产力。估算过程得出的数据，应该通过比较原始估算和实 际情况来加以分析。
7.3.1.HS.1 移植策划 当一个系统、硬件或软件产品计划从一个旧的操作环境移植到新的操作环境时， 组织必须开发一个移植计划，并形成文件。如果对旧环境不再支持，移植计划和 活动必须包括，一旦对旧环境的支持被取消，对新环境可以使用的日期的描述， 和其他可采用的支持选项的描述，这些信息必须告知用户。 移植计划也应该包括：
a) 移植的要求分析和定义;
b) 移植工具的开发;
c) 产品和数据的转换;
d) 移植的实施;
e) 移植的验证;和
f) 将来对旧环境的支持。
7.3.1.HS.1-注 1 操作环境是由硬件、软件或系统形成的，这些硬件、软件或系统有的 是产品所依赖的，有的是客户分别采购和安装的，有的来自与组织或其他供应商的。从 旧到新软件操作环境的改变的例子包括操作系统的升级，数据，或通信协议的叠加。从 旧到新硬件操作环境的改变的例子包括在新的框架内使用当前的电路包，或带上新的控 制器，或电脑硬件升级。硬件和软件平台的移植可能影响硬件或软件零件，或(整个) 系统，因此移植计划应该覆盖各种可能性。
7.3.1.HS.1-注 2 如果对旧环境不再支持，那么在旧环境下所使用或相关数据的获取、出 于数据保护和审核的目的、根据法规和合同的要求，对上述几方面的安排需要给予考虑。
7.3.1.HS.2 设计和开发过程质量度量的策划和实施 在设计和开发策划阶段，组织必须建立和保持一种或多种方法，对项目的设计和 开发过程的适当的质量度量措施加以选择和汇报。根据这一阶段的推荐，该(监 控)测量系统必须适当地对项目加以实施。这些度量措施需要覆盖项目进度的各 个区域(生命周期阶段的过渡转换或里程碑监控)，测试的执行，以及测试阶段 缺陷的监控。
7.3.1.HS.2-注 参见 http://tl9000.org/links.html 中指南部分里的文件“设计过程测量系统的设置和运行”，有助于为项目选择和建立适当的设计和开发过程测量监控。
7.3.1.S.1 电脑资源 组织必须建立和保持方法，以便为目标电脑、软件打算运行的电脑，估算和追踪关键的电脑资源。
7.3.1.S.3-注 这些资源的例子是内存的利用、通过量、实时性能和输入/输出通道。硬件例子包括处理器的利用、内存，输入/输出通道等。
7.3.1.S.2 回归测试的策划 如果要进行回归测试，测试计划必须包括哪些测试是回归，这些回归测试覆盖哪 些特征和功能。
7.3.2.C.1 客户和供方输入 组织必须建立和保持方法，在开发新的或修订的产品要求时，征求和使用客户和 供应商的输入。
7.3.2.C.1-注 与客户和供应商输入相结合，组织也需要考虑竞争分析的结果。
7.3.2.C.2 设计和开发要求 设计和开发的要求必须用书面的方式加以规定，并应该包括： a) 质量和可靠性要求;
b) 产品的功能和能力;
c) 业务、组织和用户的要求;
d) 安全、环境、可持续性和保安的要求;
e) 可制造性、可安装性、使用性、可交互操作性和维护性的要求;
f) 设计所受的约束;
g) 测试要求;
h) 目标电脑所需的资源配置;以及
i) 从以往项目所学到的教训。
7.3.2.C.2-注 在界定设计和开发要求时应该以防错为关注焦点。
7.3.2.C.3 要求的分配 组织必须书面分配产品要求到产品结构中。
7.3.2.C.3 注 应被分配要求的例子是软件的响应时间、硬件的散热和服务的响应时间。
7.3.2.H.1 要求的内容 产品要求必须包括但不限于：
a) 名义(额定)值和公差范围;
b) 维护性需求;以及
c) 最终成品包装要求。
7.3.2.S.1 软件要求的识别 组织必须确定、分析系统中软件部分的要求，并形成文件。
7.3.3.HS.1 设计和开发输出 设计和开发输出应该包括但不限于： a) 系统结构;
b) 系统的详细设计;
c) 源代码;以及
d) 用户文档
7.3.3.V.1 服务的设计和开发输出 服务设计和开发所需要的输出必须包含所要提供的服务的完整和准确的表述。设 计和开发输出必须包括，但不限于：
a) 服务交付程序;
b) 资源和技能要求;
c) 对供方的依赖;
d) 以客户评价为依据的服务特性;和
e) 每项服务特性的接受标准。
7.3.5.C.1 文档验证 组织必须在产品交付前验证客户和/或用户的文档。
7.3.5.HS.1 压力测试 组织必须在压力条件下测试产品，包括但不限于，超出边界和无效输入的条件， 高容量和模拟峰值负载，以及操作错误。
7.3.5.HS.2 非正常条件 组织必须在非正常条件下测试产品，适当时必须包括： a) 硬件错误;
b) 软件错误;
c) 操作、管理、维护和提供(软件)错误;
d) 流量过载;
e) 无效的用户输入;以及
f) 系统故障停顿后的恢复。
7.3.5.S.1 系统测试 每个软件的发布，必须根据一个书面的系统测试计划进行系统的测试。
7.3.6.C-注 适当时，组织应当在不同的确认阶段包括客户或第三方。
7.3.6.S.1 发布(版本)管理 组织必须建立和保持一个或多个方法，以确保在发布和交付软件产品及相关文档时，是在受控制的条件下进行。
该方法需要为交付客户所提供的
a) 发布前，发布策划的信息;
b) 产品介绍和发布日程安排;
c) 所交付的产品特征的详细描述，包括与新软件产品或发布相结合的任何变更;
d) 与现有的或计划变更的合同条款有关的提示(见 7.3.7.C.2).
7.3.7.C.1 变更管理过程 组织必须建立和保持一个或多个形成文件的程序，以确保在产品生命周期中任何 时候产生的要求和设计更改，用和该生命周期适合的系统和及时的方法加以管理 和追踪。组织必须确保，对双方已同意的质量、可靠性和功能意图条件产生负面 影响的更改，在批准前和客户一起评审过。变更的管理应该包括：
a) 对影响的分析，包括对资源和进度的影响;
b) 策划; c) 执行; d) 测试; e) 文档;
f) 沟通;
g) 评审和批准
7.3.7.C.1-注 当一个变更管理过程需要贯穿整个生命周期时，对该过程的控制也许依靠 于(相应不同的)生命周期阶段。例如，在设计时，组织应该能够对客户快速改变的要 求作出反应，充分利用所包含和响应的变更管理流程中所形成的技术。在产品投入市场商用后，变更管理过程的范围应该考虑，产品的操作和维护，以及安装的机站，对 顾客群和股东们的影响。该考虑应该包括质量、可靠性和功能意图。
7.3.7.C.2 对客户的告知 组织必须建立和保持一个或多个形成文件的程序，以确保客户被告知影响合同承 诺的设计更改。
7.3.7.C.3 问题解决的配置管理 组织必须确保其配置管理系统追踪到问题的解决方案，并把这(些)解决(方 案)结合到将来的(设计)改版中。
7.3.7.H.1 零件更改 组织必须具有一个或多个形成文件的程序以确保材料或零件的代用或变更不反 面地影响产品质量或绩效。该程序文件应该包括：
a) 功能测试;
b) 资格鉴定测试;
c) 压力测试;
d) 批准的零件清单;和/或
e) 关键零件清单
7.4.1.C.1 采购程序 组织必须建立和保持一个或多个形成文件的程序以确保： a) 产品要求被清楚地界定;
b) 风险得以理解并加以管理; c) 资格认可的准则得以建立; d) 接收准则得以建立;
e) 合同得以规定;
f) 所有权、使用(权)、担保和许可权得以满足;
g) 对产品将来的支持得以计划;
h) 持续的供货管理和监控得以到位;
i) 供方选择的准则得以规定;
j) 供方按规定的准则加以重新再评价;和
k) 基于供方绩效数据分析对重要供方进行反馈。
7.4.1.C.1-注 该程序文件应该适用于商店货架上的产品。这典型地包括原厂代工制造商 的产品和用于软件系统中从商店货架上直接可以购买的产品。
7.4.1.C.2 供应商绩效管理 组织必须策划并开展供应商绩效管理和开发活动以便 a) 供应商根据所建立的准则得以资格认定，
b) 在供应商选择活动过程中考虑评价的结果，
c) 使用所建立的准则对供应商加以定期的再评价，
d) 对供应商的质量绩效加以追踪，并反馈到供应商以驱使持续改进
e) 对所识别的关键供应商，在其产品在与 TL 9000 要求和测量，或其他适当的 质量管理体系方面的符合性形成一致共识，偏向采用 TL 9000。
7.4.1.C.2-注 1 供应商绩效管理的策划和活动应该与(本标准)8.5 部分组织的改进过程相结合。
7.4.1.C.2-注 2 已经认识到，组织对所有供应商提供同一水平的互动是不可能的。所提 供的水平可以依赖于和一个供应商的业务量、产品的重要性、问题的历史、组织的期望、 供应商在供应链中的重要性，或其他因素。
7.4.1.C.2-注 3 与适当的质量管理体系符合性的一致共识，(这样的)例子可以包括调查、 供应商问卷、供应商关于标准符合性方面的教育和培训;TL 9000 要求和测量指标的全 部或部分使用;评价 TL 9000 或适当的质量管理体系的符合性的第二方审核;以及 TL9000 或其他质量标准的认证。(标准的)例子包括 ISO 9001，AS9100，CMMI，ISO/TS16949 等等。
7.5.1.C.1 服务资源 组织必须为和客户接触的员工提供合适和必要的工具、培训和资源以提供有效和 及时的客户服务。
7.5.1.C.2 产品交付
组织必须建立和保持方法，使产品交付和安装时，对客户正常的现场操作和服务的影响最小。
7.5.1.HS.1 紧急服务 当产品在(交付到)市场中，在其预期的寿命里出现紧急失效时，组织必须有服务和资源以支持它们的恢复。有些潜在的情况，可能对提供紧急服务的能力产生 影响，组织必须识别出这些潜在的情况，并且有针对这些情况的响应计划。这些计划必须基于风险的基础，并得以定期的评估。
7.5.1.HS.2 安装计划 组织必须建立和保持一个或多个形成文件的安装计划。该计划必须识别资源，所 需的信息，(安装)事件的顺序以及任何必需的记录。
7.5.1.HV.1 操作的变更 每次对已经建立的操作产生重大变更(如：新的操作员、新机器或新技术工艺) 时，必须对变更后第一件加工出来的产品/服务进行严格的测试。
7.5.1.S.1 补丁程序 组织必须建立和保持一个或多个形成文件的补丁程序以： a) 为通过补丁解决问题提供决策上的指导;
b) 针对补丁开发程序、传播(向前和向后)，以及决议;
c) 与维护支持的客户需求或合同要求保持一致;以及
d) 针对每个补丁对客户的影响，确保组织给客户提供一个声明。
7.5.1.S.2 补丁文档 组织必须建立和保持方法，以确保所有与描述、测试、安装和应用补丁所要求的 文档，经过验证并随补丁一起交付。
7.5.1.S.3 (同步)复制 组织必须建立和保持一个或多个形成文件的程序，应该包括： a) 对母(版)本的识别;
b) 对用作交付的复制版的识别;
c) 用作交付的复制版的数量;
d) 媒介的方式;
e) 贴上标贴;
f) 对所需文档的识别，例如用户指南;
g) 对文档的打包;以及
h) 对环境的控制，以确保可重复的复制。
7.5.1.V.1 用作服务交付的软件 组织必须建立和保持一个或多个形成文件的程序，对用作服务交付的软件加以维 护和控制，以确保持续的过程能力和完整性。
7.5.1.V.1-注 需要考虑的软件的例子包括查错/诊断、服务恢复、脚本，或把 HEX 数据信息翻译为孤立问题的工具。
7.5.1.V.2 工具变更 组织必须建立和保持一个或多个形成文件的程序，确保进行服务的工具的替换或 变更，不会负面影响到服务质量。
7.5.3.H.1 召回的追溯性 市场可替换组(零)件必须在产品生命周期内能被追溯，(该追溯的)方法可以 帮助组织和他们的客户识别被召回的、需要被替换的、或修改的产品。
7.5.3.H.2 设计更改的追溯 组织必须规定和实施必要的方法，在可标识的生产日期、批次或序列号上提供设 计更改的可追溯性。
7.5.3.HS.1 产品标识 组织必须建立和保持一个过程，为每件产品和所需控制的层次加以标识。对于每 件产品及其版本，当以下情况存在时必须标识：
a) 产品文档;
b) 对产品重复创建所必需的开发或生产工具;
c) 与其他产品的接口;以及
d) 软件和硬件环境。
7.5.3.HS.1-注 产品标识的例子包括条形码、标签、标贴、电子标记等等，包含的信息 例如生产批号和日期，以及序列号。数据提取的新技术例如射频识别也可加以考虑。
7.5.5.C.1 对静电释放损害的防护 适用时，对易受静电释放损害的零件和产品必须实施防静电保护。
7.5.5.C.1-注 1 应该防护的元件和产品包括电子零件、集成电路、印刷线路板组件、磁
带和 磁盘 ，以 及其 他用 于软 件或 数据 储存 的媒 介。 可以 通过 链 接
http://tl9000.org/links.html 找到静电防护的有关信息。
7.5.5.C.1-注 2 对 ESD 协会颁布的 ANSI/ESD S20.20 通过认证，应当可以接受视为认 证的企业就静电防护方面达到 TL 9000 中 6.2.2.C.4 和 7.5.5.C.1 的要求的证明。
7.5.5.HS.1 包装和标贴验证 组织必须建立和保持方法，以确保产品和零(组)件的包装和标贴符合规定的要 求。
7.5.5.HS.1-注 包装和标贴验证通常在产品准备发运时进行，可以包括做标记和贴标贴
(例如：有害材料标记、对静电敏感、贴条形码)、配套、随货文件(的清点)、对地址
(的确认)、客户指定的标记，以及对所运数量的验证。
7.5.5.HV.1 变质 在存在变质可能性的地方，组织必须建立和保持方法以决定，影响产品质量的材 料何时变质或超出它们的有效期，并评核任何随后所需要的措施。
7.5.5.S.1 软件病毒防护
组织必须建立和保持方法以从可交付产品中防止、检测和移除软件病毒。
7.6.C.1 设备标识 停用或不适合使用的监视和测量装置必须清晰地标识并不得使用。所有不需要检 定的监视和测量装置必须标识。
8.2.1.C.1 顾客满意数据 组织必须建立和保持一个方法，关于所提供产品的满意(情况)，直接从客户搜 集数据。组织满足承诺(的程度)有多好，以及对客户反馈和需求的响应(的程 度)有多好，组织也必须搜集这些方面的数据。这些数据必须加以分析和趋势(比 较)。
8.2.3.C.1 过程测量 必须在适当的点上识别、书面规定和监控过程的测量，以确保过程的持续适宜性 和促进有效性的提高。这包括建立适当的设计过程测量。对产品质量有影响的重 要的过程测量，应该具有特定的绩效指标或控制限度。
8.2.4.H.1 周期重测 组织必须建立和保持一个(或多个)形成文件的程序，以确保产品经过周期重测 以评核产品持续符合设计要求的能力。当决定重测的深度时，组织需要考虑
8.2.4.H.3 中的条件。
8.2.4.H.2 测试的内容 初始测试和周期重测须比日常质量测试更加广泛。初始测试必须包括包含在客户 和/或组织产品规格和/或合同中的内容。这些测试的结果必须文件化(地记录下 来)。
8.2.4.H.3 测试的频次 组织必须建立和文件化地规定测试和周期重测的频次。在确定测试频次时，组织 必须包括：
a) 产品复杂性和服务重要性，
b) 产品设计、工程和/或制造更改的次数，以及这些更改是否影响形式、装配和
/或功能，
c) 对制造过程的变更;
d) 制造的变异(例如：工装);
e) 材料和/或零件的替换和不良率;以及
f) 产品在市场上表现的记录。
8.2.4.H.4 维修和退货产品的测试 维修和退货产品必须通过适当的评估和/或测试以确保产品规格的功能性符合。
8.2.4.HV.1 检验和试验文件 每一项检验或试验活动必须有详细的文件(规定)以贯穿产品生命周期。细节需 要包括，但不限于：
a) 所要检查的参数，以及可接受的公差范围;
b) 所使用的统计技术，控制图等;
c) 抽样计划，包括频次，样本量和接收准则;
d) 不符合的处理;
e) 所要记录的数据(参考 4.2.4);
f) 缺陷分类(计划);
g) 确定检验项目或批次的方法;以及
h) 电气，功能和特性测试。
8.2.4.HV.2 检验和试验记录 检验和试验记录必须包括
a) 产品的识别;
b) 产品的数量;
c) 当时所依据的文件化的程序(测试规程、指导书、图纸、标准、规格等);
d) 进行检验或试验操作的人员;
e) 当时所使用的计量设备;
f) 日期;和
g) 所发现的缺陷的数量、类型和严重性。
8.4.C.1 不合格品的趋势分析 必须在规定和固定的基础上对不合格品中发现的缺陷加以趋势分析，该结果用作 纠正和预防措施的输入。
8.4.HS.1 市场表现的数据 质量管理体系必须包括(产品在)市场表现数据的收集和分析，该数据能用作协 助识别产品失效的原因和频次。另外，“无发现故障”方面的数据也必须保持。 这些信息必须提供给合适的组织以促进持续改进。
8.4.V.1 服务绩效数据 质量管理体系必须包括(产品在)市场表现数据的收集和分析，该数据能用作识 别产品失效的原因和频次。这些信息必须提供给合适的组织以促进持续改进。
8.5.1.C.1 持续改进方案 组织必须建立和保持一个或多个持续改进方案，以聚焦于改进 a) 客户满意;
b) 产品的质量和可靠性;以及
c) 其他组织内所用的过程/产品/服务。
8.5.1.C.1-注 持续改进方案的输入可以包括从以往经验得到的教训，从以往项目得到的 教训，测量指标数据的分析，不良质量的成本，项目后的评审，支持可持续性的显现技 术，以及与行业最佳实践的比较。
8.5.1.C.2 员工参与 组织必须贯彻方法，以在持续改进方案中鼓励员工参与。
8.5.2.C-注 1 对纠正措施加以评审的目的在于确保所采取的措施是有效的。评审活动可 以包括确保根本原因得到合适的识别和针对，适当的临时措施得以采取，以及纠正措施 没有引起额外的问题(故障)。
8.5.2.C-注 2 培训应当可以作为纠正和预防措施的一部分加以考虑。
8.5.2.S.1 问题解析的决议 组织必须建立和保持一个(或多个)形成文件的程序，一旦在一个报告的麻烦被 诊断为(故障)问题时可以启动纠正措施。从潜在的解决方案中辨别出(适当的 方案)，该形成文件的程序应当提供指南，例如：
a) 补丁;
b) 对源代码的立即更正;
c) 将解决方案延迟到原定的软件版本发布，以及
d) 根据问题的严重性，在指定时间范围内提供书面的临时迂回操作程序和(正 式)的解决方案。
《TL 9000 测量手册》
3.5.2 组织(被审核方)的职责 组织必须
a) 使用形成文件的(书面)过程以获取和确认适用的测量数据，以便可以应用 原始数据记录;
b) 使用所提供的工具，根据规定的测量指标定义，收集、确认和向 TL 9000 管理员提交数据;
c) 在认证范围内的测量指标提交数据;
d) 向 TL 9000 管理员提交至少连续三个月的数据，并收到作为告知有效提报的
《TL 9000 数据提报收据/回执》，以便获取 TL 9000 认证;
e) 取得认证后，在每月结束后不迟于七个星期的时间内，提交月度数据;
f) 从当前产品新的发布或版本试商用开始提供测量数据;
g) 对新产品提供测量数据，该产品试商用之后不迟于六个月，在组织 TL 9000认证范围内，并在当前所报告的产品类别内;
h) TL 9000 认证范围内扩展新产品类别前，提供三个月的测量数据，并收到《TL9000 数据提报回执》以获知有效的提报; 注：(认证)范围只有与认证机构的审核相结合才可以变更。
i) 把内部的测量数据，和可获得的行业绩效数据报告进行比较，并在适当时对 产品和过程采取改进;
j) 对责任管理层提供定期的 TL9000质量管理体系测量数据报告;
k) 对任何的数据偏差加以纠正，并对之前两年内所提报的任何错误数据进行再次提交; 注：组织将可以选择使用当前的工具、手册要求和有效的产品类别表来重新 提交数据，或者使用当初提交数据时的工具、要求和产品类别表来重新提交 数据;
l) 向供应商提供他所拥有的所有必要的信息，以允许该组织(供应商)创建他们的TL 9000 测量指标;
m) 当组织有责任向供应商提交数据时，使用通过 TL9000 网站获取的标准化数据模板。
上一篇：TL9000认证
下一篇：质量管理工具培训
专业 高效 严谨 价优
ISO9001认证
