TL9000认证机构实施QuEST Forum TL9000质量管理体系测量 … ·...

认可说明编号：CNAS-EC-020:2007

发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

TL9000认证机构实施QuEST Forum

《TL9000质量管理体系要求》（4.0）和

《TL9000质量管理体系测量》（4.0）及

认可资格转换的说明

1 目的

CNAS 鉴于以下情况特制订本文件：

(1) TL9000 认证所依据的 QuEST Forum《TL9000 质量管理体系要求》（3.0）和

《TL9000 质量管理体系测量》（3.5）已分别被 QuEST Forum《TL9000 质量

管理体系要求》（4.0，2006 年 6 月 30 日发布）和《TL9000 质量管理体系测

量》（4.0，2006 年 12 月 31 日发布）取代；

(2) CNAS 对 TL9000 认证机构实施认可所依据的 CNAS-CC11:2006《质量管理

体系认证机构通用要求》将于 2008 年 9 月 15 日被 CNAS-CC01:2007《管理

体系认证机构认可要求》取代。

本文件对经 CNAS 认可的 TL9000 认证机构实施 QuEST Forum《TL9000 质

量管理体系要求》（4.0）和《TL9000 质量管理体系测量》（4.0）以及 TL9000 认

证机构认可资格的转换做出说明。

2 依据

本文件依据QuEST Forum相关要求（详见QuEST Forum网站www.tl9000.org）制定。

3 适用范围

本文件适用于经CNAS认可的TL9000认证机构实施QuEST Forum《TL9000质量管理

体系要求》（4.0）、《TL9000质量管理体系测量》（4.0）及其相关文件，CNAS对TL9000认

证机构实施上述文件情况的评审，以及依据CNAS-CC01的认可资格转换。

4 关于实施QuEST Forum《TL9000质量管理体系要求》（4.0）和《TL9000质量管理体系测

量》（4.0）的说明

4.1 QuEST Forum《TL9000 质量管理体系要求》（4.0）的实施


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

4.1.1 QuEST Forum 对《TL9000 质量管理体系测量》（4.0）的实施要求为：

(1) 2006 年 6 月 30 日后的 TL9000 审核可以按照 QuEST Forum《TL9000 质量管理

体系要求》（4.0）实施。

(2) 2007 年 6 月 30 日后的 TL9000 审核必须按照 QuEST Forum《TL9000 质量管理

体系要求》（4.0）实施。

(3) 审核员在根据 QuEST Forum《TL9000 质量管理体系要求》（4.0）实施第三方审

核前 , 应按照 QuEST Forum 要求接受培训，详细要求参见

http://www.tl9000.org/tl_training-delta.htm。

4.1.2 QuEST Forum《TL9000 质量管理体系要求》（4.0）与 QuEST Forum《TL9000

质量管理体系要求》（3.0）的异同主要体现在：所引用的 ISO 9001:2000 要求保持不变；

约 30%的 TL9000 专用要求保持不变；约 30% 的 TL9000 专用要求有较小变化；约 40%

的 TL9000 专用要求有较大变化或为新增要求，变化后的要求和新增要求旨在：

确保实现预期的结果，而不是规定操作方法；

强调设计过程的质量测量；

增加了所要求的测试；

扩大了某些要求的适用范围，例如从仅适用于软件转为通用要求，或硬件和软

件均适用。

QuEST Forum《TL9000 质量管理体系要求》（4.0）与 QuEST Forum《TL9000 质

量管理体系要求》（3.0）的详细对照见本文件附件 1（英文）。

4.1.3 原QuEST Forum《TL9000质量管理体系要求》（3.0）的附录A－H也由QuEST

Forum进行了修订和重新发布，其参考译文见本文件附件2－9。

4.2 QuEST Forum《TL9000 质量管理体系测量》（4.0）的实施

QuEST Forum 关于《TL9000 质量管理体系测量》（4.0）的实施要求如下：

(1) 《TL9000 质量管理体系测量》（4.0）从 2007 年 1 月 1 日起实施；

(2) 从 2007 年 2 月 1 日起，2007 年 1 月和 1 月以后的数据可以按照 QuEST Forum

《TL9000 质量管理体系测量》（4.0）的规则提交；

(3) 2007 年 7 月和 7 月之后的数据必须按照 QuEST Forum《TL9000 质量管理体系

测量》（4.0）的规则提交。

4.3 CNAS-SC12:2006《TL9000 认可方案》的过渡性使用

http://www.tl9000.org/tl_training-delta.htm


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

CNAS-SC12:2006 引用了 QuEST Forum《TL9000 质量管理体系要求》（3.0）附

录 A、B 和 G 以及 QuEST Forum《TL9000 质量管理体系测量》（3.5）。CNAS 将依据

QuEST Forum《TL9000 质量管理体系要求》（4.0）、《TL9000 质量管理体系测量》（4.0）

及 4.1.3 所述文件（这些文件以下统称为“新文件”）对 CNAS-SC12:2006 进行修订。

但在修订后的 CNAS-SC12 实施前，CNAS-SC12:2006 仍保持有效。因此，考虑到

QuEST Forum 对新文件的实施要求，从 2007 年 7 月 1 日起，作为过渡性措施，

CNAS-SC12:2006 中与新文件不一致的规定，暂以新文件的规定为准，直至修订后的

CNAS-SC12 实施为止。

5 CNAS对QuEST Forum新文件实施情况的评审和TL9000认证机构认可资格的转换

5.1 根据 4.1 和 4.2 所述的 QuEST Forum 要求，自 2007 年 7 月 1 日起，已获得认

可的 TL9000 认证机构应确保符合 QuEST Forum 新文件的要求。自本文件发布之日起，

CNAS 将结合对 TL9000 认证机构的认可评审，对 TL9000 认证机构实施新文件的情况

进行评审。对于 TL9000 认证机构不能符合新文件的情况，CNAS 将按照相关认可规范

的要求暂停或撤销其 TL9000 认可资格。

5.2 目前，CNAS 依据 CNAS-CC11 和 CNAS-SC12:2006 对 TL9000 认证机构实施

认可。CNAS-SC12:2006 引用了 CNAS-CC11，并包含对 CNAS-CC11 和 CNAS-CC12

的补充要求。由于 CNAS-CC11 将于 2008 年 9 月 15 日被 CNAS-CC01 取代，TL9000

认证机构依据 CNAS-CC11 的认可资格需要转换为依据 CNAS-CC01 的认可资格，详见

CNAS-EC-018:2007《管理体系认证机构依据 CNAS-CC11/CC31/CC41 的认可资格转

换为依据 CNAS-CC01 的认可资格的说明》。由于 CNAS-SC12:2006 目前暂时保持有效

（见 4.3），在 TL9000 认证机构进行依据 CNAS-CC01 的认可资格转换时，

CNAS-SC12:2006 与 CNAS-CC01 不一致的规定，以 CNAS-CC01 的规定为准，直至

修订后的 CNAS-SC12 实施为止。

附件 1－9


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 A（参考译文）

本文件由通讯业优质供方论坛（QuEST Forum）监督工作组制定。本文件的前身是 TL9000

质量管理体系要求的附录 A，现经监督工作组修订后作为独立文件发布。TL9000 质量管理

体系要求手册（版本 4.0）的 3.5引用了本文件。本文件由监督工作组负责维护并发布最新

版本。

TL 9000 认可机构实施要求

以下是 TL9000 实施要求，包括认证机构资格、认证机构审核员资格、证书和将认证机

构的认可升级至包括 TL9000 在内的准则。这些要求适用于所有通讯业优质供方论坛（QuEST

Forum）承认的认可机构和由这些认可机构认可合格的，实施 TL9000认证的认证机构。

获准认可的认证机构应：

1.1 向认可机构就遵守以前的附录 B——TL9000 认证机构的作业规程实施 TL9000 认证，提

供书面协议。

1.2 在 TL9000 认证开始之前，向认可机构提供证明认证机构的过程符合以前的附录 B——

TL9000 认证机构的作业规程和在这些附录中的认证要求的相关文件。

1.3 保存合格的 TL9000审核员的名单。

1.4 具有专家委员会的工作人员，其具有在通讯行业的经历，同时具有现行认可机构操作所

限定的特定范围的专业知识。

1.5 至少具备一名认证决策机构中的成员，其成功地完成和通过了特定行业的培训考试。这

名成员对 TL9000认证决定具有否决权。

1.6使用符合以前附录 G——TL9000认证机构审核员的资格和经历要求文件中规定的要求的

审核员。

1.7 使用至少具备一名具备与通讯业相关经历成员的审核组（见以前附录 G——TL9000 认证

机构审核员的资格和经历要求）。

1.8 只有在认可机构见证和批准认证机构的 TL9000 审核后，才可在证书上使用 TL9000的标

志。

1.9 在见证评审令人满意地完成之后，对于以前已评审的，并符合 TL9000 要求的组织，允


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

许将 ISO9001的证书更新为 TL9000证书。认证机构应在 3个月或 6次最初 TL9000审核，进

行一次见证评审，并受到下述条款 2.2的约束。

1.10 在认证机构不能令人满意地完成见证评审的情况下，认证机构在得到认可机构同意时，

应负责向以前已评审的组织提供适合于所发现问题的内容和严重程度的补救措施。没有附加

的 TL9000审核应得到允许，直至认可机构接受认证机构的纠正措施。

1.11 允许使用全部 TL9000 或由 ISO9001升级的 TL9000作为见证评审。

1.12 对符合 TL9000的组织提供认证证书，证明其符合标准 TL9000和 ISO9001：2000。

1.13 规定对被认证机构撤消准则和撤消步骤。

1.14 负责为受到被认可机构撤消认证资格的认证机构影响的，任何 TL9000 受认证的组织提

供适宜被发现问题严重程度的补救措施。认可机构应同意这些补救措施。

1.15 为按照通讯业优质供方论坛（QuEST Forum）的指南和转化计划，对 TL9000 新版本提

供转换支持。

认可机构应：

2.1 通过谅解备忘录的方式与通讯业优质供方论坛（QuEST Forum）签订协议，以遵守由通

讯业优质供方论坛（QuEST Forum）提出的承认准则。

2.2 负责为审核员（审核组）提供对 ISO9001 获准认可的认证机构完成以上条款 1.1 和 1.2

的最初的 6 次 TL9000 认证审核中的一次进行见证评审。认可机构应将每一个认证机构成功

完成见证评审的日期通知通讯业优质供方论坛（QuEST Forum）管理委员会。

2.3 使用所需的任何外部专家或观察员负责实施见证评审。这个应包括避免利益冲突、实用

性和适时性。

2.4 规定：

a) 对撤消准则和撤消已获资格的认证机构的步骤，及

b) 对见证决定和出现在 TL9000过程中的任何其他步骤提出申诉的适宜的过程。

2.5 保持已获资格的 TL9000 认证机构的更新的名单并在名单变化时，发送给通讯业优质供

方论坛（QuEST Forum）管理委员会。这些名单应标注从以前的版本中新增加或取消的机构。

认可的损失通知应立即正式地与通讯业优质供方论坛（QuEST Forum）管理委员会进行沟通。

2.6 向每个合格的、满足 TL9000 所有要求（见本文件以前的附录 B——TL9000 认证机构的

作业规程）的 TL9000认证机构提供作为记录认证机构资格的证书，或相似的正式性的通知。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

2.7 按照通讯业优质供方论坛（QuEST Forum）的指南和转化计划，对 TL9000 新版本提供转

换支持。

通讯业优质供方论坛（QuEST Forum）应：

3.1 建立论坛管理委员会，作为联络的中心以担当所有询问、认可、认证机构和与认证有关

的事宜、问题和关注的交换所的角色。

3.2 与其他的被承认的认可机构分享适当的 TL9000 沟通。

3.3 承认任何作为国际认可论坛（IAF）多边协议（MLA）针对通过谅解备忘录的方式与通讯

业优质供方论坛（QuEST Forum）签订协议以遵守由通讯业优质供方论坛（QuEST Forum）提

出的承认准则的签约方的认可机构。这些认可机构必须对彼此的用于支持 TL9000 的见证评

审进行相互承认。

3.4 为新版本的 TL9000的简介提供指南和转化计划。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 B（参考译文）


质量管理体系要求的附录 B，现经监督工作组修订后作为独立文件发布。本文件由监督工作

组负责维护并发布最新版本。

TL9000 认证机构的作业规程

认证机构必须得到通讯业优质供方论坛（QuEST Forum）承认的机构的认可。认证机构

的认可范围应包括获得认证的活动（例如：硬件、软件或服务，或任何组合）。得到承认的

认可机构的名单在 TL9000 的网站上（访问 tl9000.org）。

评审应包括对所有组织质量管理体系要素，在认可范围内，有效地执行了 TL9000 的要

求进行评价。

每三年，应对获得认证的机构的 100%的全部认证范围和所有适宜 TL9000 的要求和测量

进行评审。审核报告应清晰地显示体系在每次监督检查中得到审核的部分。

审核组应就审核现行的 RvA出版物（对编写质量体系审核报告的指南）的模型 B的运作，

在每次初次审核和监督（部分）审核 45 天内，向组织提供全面的报告，除非得到组织的同

意才可以不提供。在审核过程中，不合格和改进的机会非常明显时，第三方的审核员将对不

合格和改进的机会进行识别，但不推荐具体的解决方法。这些不合格和机会应包含在向组织

提供的报告中。

提供质量管理体系咨询服务和/或对特定顾客提供专门培训的认证机构与认证有关的机

构，不可以对该顾客进行认证服务，也不可以提供审核员。

实施对 TL9000 要求审核的认证机构的审核组的每个成员都应令人满意地完成了由通讯

业优质供方论坛（QuEST Forum）批准的 TL9000审核员课程。同时，负责作出认证决定的大

多数成员，或至少一名具有否决权的成员应令人满意地完成了这个培训。证书应说明是令人

满意的完成。

为组织提供咨询的质量管理体系的咨询师，如果在评审过程中出现，其职责只能被限定

为观察员。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

所有结构的或是体系的不合格都应在 TL9000 证书颁发之前得到解决。所有不合格都应

依据认证机构的标准运行程序进行处理。

认证机构被授权在 ISO 证书上证明对 TL9000 的符合，当认证机构：

a) 与组织约定遵守本作业规程，和

b) 得到通讯业优质供方论坛（QuEST Forum）承认的认可机构的认可颁发 TL9000证书。

认证机构必须具备平息在标准的解释中出现的争议的过程。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 C（参考译文）


质量管理体系要求的附录 C，现经监督工作组修订后作为独立文件发布。本文件由监督工作


认证指南

当一个组织考虑申请进行 TL9000认证时，宜说明以下关键步骤：

a) 确定认证范围。

b) 如果还没有，开发和实施形成文件的质量管理体系，以便满足或超越 TL9000 质量

管理体系。

c) 进行自我评审和实施任何所需的改进，以遵守 TL9000质量管理体系。

d) 根据选定的范围，与 TL9000获准认可的认证机构签约进行认证。

e) 遵守认证机构的认证过程和监督审核，以获得和保持 TL9000认证。

f) 本指南也可以在 TL9000的网站上获得（访问 tl9000.org）。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 D（参考译文）


质量管理体系要求的附录 D，现经监督工作组修订后作为独立文件发布。本文件由监督工作


转换途径、审核天数和要求来源

通讯业优质供方论坛（QuEST Forum）承认现有的质量管理体系努力的成果。这些努力

将在转换到 TL9000过程中得到补充。为遵守任一以下转换途径，TL9000 申请人必须具备得

到承认的质量管理体系现有的认证。现有的认证范围应与正在寻求的 TL9000 认证的范围进

行比较。对现有的认证范围之外的部分必须根据 TL9000的要求进行评审。

以下的质量管理体系认证是现在得到承认的：

a) ISO9001：2000，

b) TS16949，和

c) AS9100。

TS16949和 AS9100认证被视为等同于 ISO认证。

必要时，其他的饿质量管理体系将得到承认。

转换途径：

本转换过程仅在初次认证过程中使用。随后的评审活动将针对每个标准认证程序

进行。

从 ISO9001：2000 或其他的质量管理体系转换为 TL9000要求（版本 4.0），组织应

在 TL9000 的认证范围内，符合所有适用的 TL9000的附加要求和测量。

审核天数表：

审核天数表规定了实施全面的 ISO9000 审核所需的、最少的现场审核的天数。最

新版本的审核天数表可以在 TL9000网站上得到（访问 tl9000.org）。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

审核天数表显示了认证机构用于初次 TL9000/ISO9001：2000质量管理体系审核和正在

进行的监督审核所需要的现场审核的最少天数。

认证机构将记录实际的审核天数。任何大于 0.5个现场审核天数的偏差都将形成记录，

并在报价后的 5个工作日内递交给认证机构的认可机构。直到所递交的偏差得到认可机构的

书面同意后，才能颁发 TL9000 的证书。审核可以继续，但认证机构应对如果认可机构要求

附加的审核天数所涉及的风险提出建议。

认可机构应在 10个工作日内对收到的认证机构就减少最少的现场审核天数的书面要求

作出答复。认可机构将以书面方式确定同意或拒绝。

认证机构对 TL9000 版本 4.0转换途径和审核天数表的使用是发布后立即生效的，并一

直保持有效直至通讯业优质供方论坛（QuEST Forum）对其进行修改。最新版本的审核天数

表可以在 TL9000网站上得到（访问 tl9000.org）。

要求来源表：

对从旧版本到新版本的关于要求来历的变化，参见 TL9000网站上（访问 tl9000.org）

的要求来源表。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 E（参考译文）

用于 TL9000 认证的高级监督和复评程序（ASRP）

（取代为保持 TL900O 认证的其他方法）


质量管理体系要求的附录 E，现经监督工作组修订后作为独立文件发布。本文件由监督工作


本程序（ASRP）来源于对 ISO/IEC 导则 62：1996，版本 4 的附录 5 的国际认可论坛指

南。

部分 1——目标和原则

1.1 ASRP 是确定组织的质量管理体系（QMS）是否满足 ISO9001 和 TL9000 的准则以确保获

准认可的第三方认证机构认证的延续性一种方法。本程序基于使用绩效指标、顾客满意度和

作为对认证机构监督过程的补充的组织（第一方）的内部审核体系。

1.2 对于一个在一段时间内，通过持续证明其质量管理体系（QMS）有效性的，

在其质量管理体系（QMS）建立自信的组织，在经与组织进行磋商，可以选择应用先进的监

督和复评程序（ASRP）。这种先进的监督和复评程序对组织内部的审核和管理评审过程有很

大（但不是全部）的依赖性，包括设为目标的监督主题，考虑来自组织的具体的设计输入，

和/或使用适宜证明质量管理体系（QMS）符合性的其他方法。

1.3 本程序的目的是为了确保，对在保持其拥有的获准认可的质量管理体系（QMS）证书的

完整性的时候，具备已证实的绩效记录的组织提供更加有效和高效的评审。

1.4 ASRP 只适用于组织和认证机构满足一些要求（资格/合格准则）和一些要求可以被验

证的情况。ASRP通常是：

1.4.1 供任何满足资格准则的组织使用，无任何对场所的规模、场所的数量或行业区域的歧

视；

1.4.2 限定第三方监督审核和复评，及

1.4.3只适用于组织的质量管理体系是否全部符合获准认可的第三方认证机构所确定的所有


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

TL9000 的要求。

1.4.4 只适用于组织是否满足 ISO/IEC导则 62：1996，版本 4的附录 5的国际认可论坛指南

中提出的必备要求。

部分 2——用于组织的资格/合格准则

2.1组织必须满足 ISO/IEC 导则 62：1996，版本 4 的附录 5的国际认可论坛指南中提出的必

备要求。

2.2 组织必须满足以下提出的、所有附加的 TL9000 必备要求：

2.2.1 组织的质量管理体系在一段时间内，至少在一个完整的 TL9000认证周期（包括初次、

监督和复评审核）内，已证实与标准 TL9000的要求相符合。

2.2.1.1 任何例外（例如：使用 ASRP用于 ISO9001 认证的和随后将 TL9000 认证添加到其质

量管理体系（QMS）中的组织）都可能需要得到适当的认可机构的复核和批准。

2.2.2 可能导致不合格的 TL9000测量的迟报、测量的试用或 TL9000的暂停可能需要与所有

其他的 NCR一起，被成功地解决（结束）。

2.2.3 要求的 TL9000 的测量应成为被组织识别的绩效指标的一部分，并得到认证机构的同

意，但是，测量不宜只成为绩效指标。

2.2.4 组织的内部审核员的能力过程应要求组织内部审核员符合 TL9000 的资格要求、经历

和 TL9000 认证机构审核员（附录 G）的保持要求。组织的内部审核员不必须符合认证机构

对其自己的审核员的附加要求。

2.2.5 组织的内部审核过程应最低限度地包括：

2.2.5.1 组织必须具备成熟的有效的中心内部审核程序（例如：在认证周期没有严重不合格

出现）。

2.2.5.2 组织至少每年进行一次对所有过程的内部审核。

部分 3——用于认证机构（CBs）的资格/合格准则

3.1 组织必须满足 ISO/IEC 导则 62：1996，版本 4 的附录 5的国际认可论坛指南中提出的必

备要求。

部分 4——认证机构（CBs）提供的程序设计


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

4.1 认证机构遵守在 ISO/IEC 导则 62：1996，版本 4的附录 5的国际认可论坛指南中提出的

用于设计 ASRP程序的过程。

4.2 认证机构必须满足以下提出的，所有附加的 TL9000 程序设计要求：

4.2.1 认证组织应考虑组织的 TL9000测量数据，作为在设计每个单独的 ASRP的、组织具体

的输入准则的一部分。这些数据应在设计过程中和在 ASRP实施之前提供给认证机构。

4.2.2 认证机构应验证组织的顾客的合同/要求没有禁止使用 ASRP进行 TL9000 认证。

4.2.3 认证机构可能与组织的战略性的 TL9000顾客进行联系（在抽样的基础上），以验证顾

客满意度。联系可能包括组织。

部分 5——组织和认证机构对 ASRP 的维护

5.1 组织和认证机构必须遵守 ISO/IEC导则 62：1996，版本 4的附录 5的国际认可论坛指南

中提出的要求。

5.2 组织和认证机构必须满足以下提出的，所有附加的 TL9000要求：

5.2.1 适宜时，认证机构应在每次认证机构的访问中，对以下的过程进行审核：

5.2.1.1 组织的测量过程，包括数据收集、计算规则的应用、测量的确认和这些测量的递交。

5.2.1.2 组织的纠正措施的过程。

5.2.2 认证机构应符合 TL9000 审核员时间的要求，要求具体说明了分配用于对测量时（和

测量过程）进行复核的最短的时间。

5.2.3 组织应就在内部审核过程中的任何基础性的改变向认证机构提供书面报告（例如：频

度、审核员的能力要求等）。

5.2.4 如果使用 ASRP进行 TL9000认证的组织由于兼并、收购等与其他组织合并，新的组织

必须符合考虑使用 ASRP的所有要求（包括在整个的认证期间正在接受认证）。唯一的例外是，

如果组织进行两个分开的 TL9000的认证。

5.2.5 对组织满足双方同意的绩效目标的损害应包括组织对 TL9000测量的迟报。

5.2.6 如果 TL9000 认证受到损害，包括（因为 TL9000 测量的迟报而暂停），ASRP 应停止或

组织将不得不重新使用 ASRP（例如：每个 1.3.1.a 中的，在一段时间内，至少是一个完整

的认证周期内，已证实符合要求的组织的质量管理体系（QMS），包括 TL9000）。

部分 6——ASRP 的监督


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

6.1 认可机构有责任对要求在组织内使用 ASRP的认证机构进行监督。

6.2 认可机构必须遵守 ISO/IEC 导则 62：1996，版本 4的附录 5的国际认可论坛指南中提出

的要求。

6.3 通讯业优质供方论坛（QuEST Forum）将在对每个认可机构再次审批的过程中（每四年），

对认可机构用于监督 ASRP 的过程进行复核。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 F（参考译文）


质量管理体系要求的附录 F，现经监督工作组修订后作为独立文件发布。本文件由监督工作


与顾客沟通的指南

以下是包括 4种可能用来在组织和其顾客之间建立相互受益的沟通的事例方法。其他一

些方法可能适用于组织的业务情况。另外，直接与设计过程测量有关的与顾客沟通的指南可

以在本文件中获得，设计过程测量的建立和运行可参考以前的附录 H。

方法 A：共同分享期望团队

沟通的一种方法是自愿分享期望的过程。这是一种过程，在过程中一个组织与顾客共同

工作，以产生对相互期望的理解并在持续的基础上改善质量。目的是把参与双方之间的关系

变得更紧密和长远。

由组织和顾客方人员组成的联合团队是检查期望、识别差距并产生一种减小差距的机

制。当得到组织和顾客双方同意，一个公正的、具有通讯业经验的促进人员可以加入到团队

中。团队制定行动项目并对行动项目以登记形式进行追踪。通常，行动项目是由联合任务组

进行工作的。费用由顾客和组织共同分担。

建议团队在 1年之内至少进行 2次会面。一些工具是用于持续的质量改进，包括行动项

目的登记和质量改进的方法。首次会面的典型的议程可以包括：

a) 顾客的期望；

b) 组织的期望；

c) 现有的绩效与期望的比较；

d) 差距的识别；

e) 行动计划的制定说明差距，和

f) 追踪和监视行动计划的措施的定义。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

方法 B：质量复核会议

为了便于沟通，鼓励顾客和组织定期会面来讨论组织的质量管理体系。当由组织提供的

设备在运行中，建议会议轮流在组织和顾客的场地进行。

组织的场地：

在组织的场地进行的会议的议程可以包括：

a) TL9000不合格；

b) 内部审核报告的样例和相关的改进措施；

c) 测量；

d) 工程投诉；

e) 产品变更通知；

f) 顾客的关注；

g) 组织的关注，和

h) 行动项目的登记。

顾客场地的访问：

在组织的设备运行少于 1年（可能是 3-6个月）的情况下，在顾客的场地会面。所有顾

客的直接涉及工程、设备的采购、安装、启动和运行的功能都要邀请组织的代表（包括程序

和/或产品经理、质量和销售代表或其他适当的人员）参与。

访问的目标是为了获得对采购整个过程和运行的设备及相关服务的反馈。以顾客方参与

者为基础，反馈可能说明以下一些或全部：

a) 硬件和软件的质量和可靠性；

b) 定货的简便性；

c) 组织的代表；

d) 新产品的介绍；

e) 产品的交付；

f) 技术支持；

g) 文件；

h) 产品变更通知；

i) 发票；


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

j) 安装；

k) 维修，和

l) 培训。

其他顾客或供方组织的关注宜进行讨论，并在行动项目登记中检查/更新。

在访问中获得的反馈宜形成文件，任何问题都包括在一个行动项目的登记中，并由组织

和/或顾客提供计划好的改进措施。

方法 C：用户化的报告

组织在顾客识别的需求的基础上，定期提供报告。这样的报告可能包括：

a) 硬件返回率；

b) 交付的绩效；

c) 维修周转时间；

d) 报告的问题，和

e) 技术支持活动。

方法 D：程序检查

在顾客或组织的场地定期进行程序检查，可能包括：

a) 现有的交付；

b) 对未来要求的预测；

c) 技术问题；

d) 产品特性要求/需求；

e) 定货/发票问题；

f) 与所提供的产品有关的改进机会，和

g) 顾客和组织的界面。

宜保持行动项目登记，如适宜，在每次检查中或更经常地将行动项目形成报告。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 G（参考译文）


质量管理体系要求的附录 G，现经监督工作组修订后作为独立文件发布。本文件由监督工作


TL9000 认证机构审核员的资格和经历要求

被批准的审核员：

质量管理体系的审核员最低限度应满足 ISO19011-2002中对教育背景、培训、工作经历

和审核经历的要求，及以下：

在最近的 3 年内，至少参与 4 次、最少是 20 天的审核，审核包括 ISO9000 系列标

准的所有要素，并具备覆盖由审核组长或相同级别人员确定的所有要素的能力。

继续教育：符合认证机构对保持必须包括 TL9000质量管理体系要求手册和 TL9000

质量管理体系测量手册现行版本在内的审核员资格的要求

通讯业资格：

合格的 TL9000审核员必须：

满足以上被认可的审核员所提出的要求，并

成功地完成和通过通讯业优质供方论坛（QuEST Forum）认可的 TL9000质量管理体

系审核培训。

另外，至少有一名审核组成员必须：

在最近的 10 年中具有 2 年在通讯业直接参与通讯业服务提供者或第一或第二级供

方的工程、设计、制造、质量和/或过程控制的相关工作经历（由认证机构所使用

的、适宜的 NACE 规程或等效的方法规定的）；

或

在最近的 2年内，在 NACE规程中，与被审核的通讯业的组织相关的，具有 20天的

现场审核经历。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

附录 H（参考译文）


质量管理体系要求的附录 H，现经监督工作组修订后作为独立文件发布。本文件由监督工作


设计过程的测量体系的建立和运行

以下是包括对设计过程的测量的选择和实施的指南。

过程测量体系

过程（参见术语表）是一系列将输入转化为输出的活动；项目是有起止日期的并达到特

定目标的独特过程。虽然以下的讨论将重点在项目上，同时也也容易地适用于过程。

过程测量体系的使用是有效地监视、管理和改进项目的基本方法；测量体系的目的是帮

助经理做出更好的决策。

现在有许多好的、经常得到用户群或支持中心（见参考）支持的设计过程测量模型和指

南可供使用。大多数模型能够为组织愿意建立和运行其自己的过程测量体系识别一些基本要

素：

1) 为手边的项目规定一系列的的测量方法，当规定了一个适宜的测量组合，这一要素

就完成了。

2) 使用的方法和工具来收集和报告所选用的测量，当测量报告定期发布，这一要素就

完成了。

3) 使用测量结果来帮助管理和改进项目，当一个管理措施和改进动机以测量分析为基

础，得到识别和实施，这一要素就完成了。

另外，许多模型清楚地建议，根据组织的要求，系统地改进测量体系本身，这个任务是

正在进行的努力，确保测量体系的持续的有效性。

定制测量

要素 1（测量组合的选择）对过程测量体系的成功是至关重要的，因为对用于收集和分

析的测量的错误选择很容易危及到整个测量成果的有效性。

一个项目的许多方面都可以通过例如：成本、周期、输入、输出、缺陷或对计划的坚持


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

来测量的。问题是，有太多的可能的测量方法以经济上可行的方式收集它们，更重要的是，

许多测量方法的有效性依赖于测量使用者的目的和看法，并来自于具体项目的相关问题。

由于这些目标、看法和问题不必须是固定的，并且每个项目和每个项目都不同，于是就

出现了清晰地建立测量活动的目标的需求，并从这些目标中产生了适当的和经济懂得测量组

合。总之，组织不得不定制测量方法，以便其能够适合具体的项目特点和需要。

定制意味着：

从推荐的测量组合中选择次级测量组合；

如需要，所选的次级测量组合中修改单独的测量方法，例如：修改通报的方式，或

修改一些数据的定义或公式，或使用部分测量方法；

例如：对于给定的项目，重要事件延迟测量从所推荐的测量组合中被选出，但它并

不是以重要事件趋势分析（图表的方式）的方式报告的，或作为一个每天或每周延

迟的清单。而且，重要事件延迟的报告安排在不同的项目中各有不同。

如果需要，添加新的测量方法到选定的次级测量组合中。

经验证明，有几个因素在不同程度上可以影响测量的定制。最重要的因素看来是具体的

业务目标和对测量或预测质量的具体要求。

其他的因素包括：

具体项目的规模、复杂程度和周期；

在组织中，支持工具的可用性，或现存的实践经验；

对发现问题、项目状况的跟踪和过程质量的监视的需求；

联合复评，和/或由组织向顾客定期报告的需求。

对定制测量的有用的指南可以从参考中找到。其中，GQM（目标问题度量）和 PSM（实

用软件和体系测量）的方法将特别重点放在定制过程，作为测量活动的起点。

收集、报告和分析测量

测量体系的要素 2和 3对在定制过程（要素 1）中选定的测量的实施作出贡献。

测量的收集和报告是测量成果的技术部分，它需要足够的工具和与项目的周期活动结合

起来。

数据的可用性、时效性、一致性、完整性和准确性确定作为结果的信息的价值。而且，

在收集和报告之间的时间滞后应尽可能的短，所以以在线的方式进入项目的数据库是收集项


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

目数据的首选方法。

另一方面，测量分析是确保组织收获投资在测量体系得到的利益。

分析的步骤宜将定量测量结果和其他的定性的项目信息相结合，以便为项目经理提供做

出有效决策所需的反馈。

对收集、报告和分析测量有用的指南可以从参考中找到。其中在 PSM 指南中特别的丰富

和具备资料性。

以下两个部分着力于对 GQM和 PSM的简短介绍。GQM已成为的承认定制责任的第一种方

法，PSM可能是现有的、在测量体系每个方面的最好的指南。

目标问题量度

GQM（目标问题度量）方法起源于 1980 早期由 V.R.Basili 领导的一些研究者的成果。

他们拒绝固定的测量组合的概念，提倡一种方法为具体的组织目标和环境的定制测量提供帮

助。

因为这些目标和环境将市非常地不同，选择测量是必要的。测量活动的起点宜是“测量

的目的是什么？”，而不是“我们使用什么测量方法？”。

明确的测量目标的识别是 GQM的基础。这个目标将被提炼成几个问题，每个问题有助于

选择测量，为问答这些问题提供信息。

当测量用一个明确的目标进行规定时，测量提供的信息将根据那个目标得到诠释和分

析。

实用软件和体系测量

实用软件和体系测量（PSM）是由美国国防部和美国军方发起的一种方法。项目的目标

是为项目经理提供成功满足项目成本、日程安排和技术目标要求所需的客观的信息。

PSM允许项目经理识别对于他们的项目非常重要的问题，然后在整个项目周期内实施对

这些问题的领悟的测量程序/

问题是关注的范围，它可能对项目的目标所取得的成绩造成影响，问题包括疑难问题、

风险和信息的缺乏。

有价值的问题的来源可能是风险评估，项目的限制和假设，具备优势的技术、产品的接

受准则、外部要求，及项目组在类似项目中的经验。


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

一旦项目的具体问题得到识别，下一步就是将它们安排到 PSM 的共同问题区域中。PSM

所包括的 7个共同区域是：

日期安排和进度

资源和成本

产品的规模和稳定性

产品质量

过程绩效

技术的有效性

顾客满意度

共同的问题区域是测量选择和规范表格的起点。这些表格有助于从基本的 PSM测量组合

（包括 20个测量类别和多于 50个单独的测量指标）中选择测量指标。

但是，测量指标的选择不仅陷于在推荐的测量组合中选择。修改现有的测量指标也是可

能的，甚至是添加全新的测量指标。

PSM提供免费的指南和软件工具 PSM Insight，以支持测量指标的定制过程和测量活动。

在这个工具里，PSM 的共同问题区域、种类和测量指标可以使用，或由测量分析师开发

新的测量指标来满足项目信息的需要。

数据可以通过用户化数据输入屏输入，或从其他的来源引入。一旦数据加载到软件工具

PSM Insight 上，其分析功能被用于产生测量指标、分析和趋势追踪和报告发现。

顾客沟通

在具体项目的范围内，组织定期提供设计过程测量报告。

为了理解报告，顾客需要组织发展和/或生产过程及所使用的测量过程的知识。

形成报告的数据的使用：

这些报告的目的是向顾客提供有关实施情况和已交付产品的质量的可见性。

通报过程帮助组织理解顾客的需求，例如：质量要求、上市的日期安排等；

在与同意的目标相偏离的情况，要提供分析报告，并纠正措施要得到批准和实施。

为双边通报的测量的选择：

在开始一个项目之前，应从组织可用的 TL9000 设计过程测量组合中选择适合的设计过

程测量组合指标。

在设计过程测量通报实施之前，要了解顾客的要求和需要。

设计过程测量报告可以包括：

a) 实施的测试的数量与计划的对比；


发布日期: 2007 年 6 月 19 日实施日期:2007 年 6 月 19 日

b) 发现缺陷的数量和纠正的每个阶段；

c) 阶段转换监视数据

d) 内部的重大事件（成就/延迟）。

参考：

关于过程测量体系的模型、标准和指南。

a) PSM——实用软件和体系测量（美国国防部和美国军方）；

b) 荷兰代夫特工业大学的 GQM网站（访问 www.gqm.nl）；

c) 系统工程测量初级（INCOSE——系统工程的国际委员会）；

d) ISO/IEC15939——软件测量过程的框架

（ISO/IEC JTC1/SC7 软件和体系工程）

e) CMMI体系和 SW 工程——测量和分析

（梅隆 ·卡内基大学——软件工程学院）

f) IPQM——过程中的质量度量通用要求（GR-1315）

g) EIRUS的想法和贡献（欧洲 IPQM和 RQMS 用户群，现与通讯业优质供方论坛（QuEST

Forum）合并）已编入本文件中。

其他的有关 GQM的参考：

h) ESERG （ dec.bournemouth.ac.uk/ESERG/mshepperd/SEMGQM.html ）的 Martin

Shepperd 教授对 GQM的总体看法。

i) 在 NASA GSFC 的软件工程实验室：（访问

sel.gsfc.nasa.gov/website/esp-facotry/gqm.htm）

其他的有关 PSM的参考：

j) PSM支持中心网站（访问 www.psmsc.com）

k) 实用软件测量：给决策者的客观信息。

（John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark,

Joseph Dean, Fred Hall Addision –Wesley 2002）.

http://www.gqm.nl/

http://www.psmsc.com/

Conversion Table for TL 9000 Requirements Release 3.0 to 4.0

Section TL 9000 Requirements Release 3.0

TL 9000 Requirements Release 4.0 Type of Change

Comment

4.2.3 4.2.3.C.1 Control of Customer-Supplied Documents and Data

The organization shall establish and maintain a documented procedure(s) to control all customer-supplied documents and data (e.g., network architecture, topology, capacity, installation termination assignments, drawings, and database) if these documents and data influence the realization and/or support of the product.

Reworded Added ‘drawings’ and simplified wording from ‘design, verification, validation, inspection and testing, or servicing’ to ‘realization and/or support of’ the product.

5.2 5.2.C.1 Customer Relationship Development

NO CHANGE No Change

5.2 5.2.C.2 Customer Communication Procedures

Customer Communication Methods – The organization shall establish and maintain methods for communicating with selected customers to share expectations, to solicit and consider customer input for quality planning activities, and to ensure product quality improvement. The outcome of customer communication should generate actions for resolving identified issues and provide opportunities for improving customer satisfaction. [4]

Reworded Changed title. Deleted ‘Procedure(s)’ and added ‘Methods.’ Requirement was reworded to incorporate intent of former bulleted items into body of text. Deleted procedure requirement.

5.2 5.2.C.2 NOTE 1 5.2.C.2-NOTE It is recognized that it is not possible for an organization to provide the same level of communication with all its customers. The level provided may depend on the amount of business with the customer, the history of problems, customer expectations, and other factors (see the Appendix, “Guidance for Communication with Customers.”)

Renumbered Deleted ‘1’ in Note number. Deleted ‘F’ after Appendix in parenthesis. All Appendices are now located on the TL 9000 website.

5.4.1 5.4.1.C.1 Quality Objectives NO CHANGE No Change

5.4.2 5.4.2.C.1 Long- and Short-Term Quality Planning

The organization’s quality planning activities shall include long- and short-term plans with goals for improving quality and customer satisfaction. The plans shall address business factors relevant to the organization and its customers, including performance objectives established jointly with selected customers. Performance to these goals shall be monitored and reported.

Reworded Added ‘The plans shall address business factors relevant to the organization and its customers, including performance objectives established jointly with selected customers.’ Deleted bullets a)-f) and incorporated into NOTE 1. (see 5.4.2.C.1 NOTE 1).

5.4.1 5.4.2.C.1 NOTE 1 See 5.4.2.C.1-NOTE 2 Renumbered Placement now follows 5.4.2.C.1 NOTE 1

5.4.2 5.4.2.C.1 NOTE 1 5.4.2.C.1-NOTE 1 Example factors which might be considered for planning are a) cycle time, b) customer service, c) training, d) cost, e) delivery commitments, and f) product reliability.

New New Note. Changed bullets a)-f) from requirements to examples.

5.4.2 5.4.2.C.1-NOTE 2 Top Management should demonstrate their active involvement in long- and short-term quality planning.

Renumbered Renumbered only, from 5.4.2.C.1-NOTE 1 to 5.4.2.C.1-NOTE 2. No change to text.

Copyright © 2006 Quality Excellence for Suppliers of Telecommunications Forum




Comment

5.4.2 5.4.2.C.2 Customer Input NO CHANGE No Change

5.4.2 5.4.2.C.3 Supplier Input NO CHANGE No Change

5.5.3 5.5.3.C.1 Organization Performance Feedback

NO CHANGE No Change

6.2.2 6.2.2.C-NOTE Education and training needs may vary greatly depending on the nature of the organization’s activities, individual responsibilities, and the stage of organizational and personal development. Methods of delivery may include on-the-job training, cross-training, job rotation, classroom experience, computer-based training, distance learning, or other methods. Training may take place within the organization or be provided externally, and should be reinforced on the job.

New New Note

6.2.2 6.2.2.C.1 Internal Course Development

Where the organization is responsible for developing internal training courses, the organization shall establish and maintain methods to ensure consistency in course planning, development, and delivery.

Reworded Reworded to clarify intent. Replaced ‘process’ with ‘methods’ for consistency.

6.2.2 6.2.2.C.2 Quality Improvement Concepts

Quality and Process Improvement Concepts – Those employees that have a direct impact on the quality of the product, including top management, shall be trained in and apply the fundamental concepts of continual improvement, problem solving, and customer satisfaction. [4]

Reworded Added ‘and Process’ to title. Added ‘and apply’ to better convey intent of requirement.

6.2.2 6.2.2.C.3 Training Requirements and Awareness

Product Quality Training Opportunity Awareness – Where training that affects product quality is required, the organization shall implement methods to ensure employees are enabled to participate. Methods should address a) communication of training opportunities, and b) availability of training.

Reworded Changed title. Reworded to clarify intent. Added bullets to requirement and requirement for availability of training.

6.2.2 6.2.2.C.4 ESD Training Electrostatic Discharge (ESD) Training – All employees with functions that involve handling, storage, packaging, preservation, or delivery of ESD-sensitive products shall receive training in ESD protection prior to performing their jobs.

Reworded Moved definition of ESD acronym from body of text to title. Deleted ‘any’ in body of text.

6.2.2 6.2.2.C.5 Advanced Quality Training

NO CHANGE No Change

6.2.2 6.2.2.C.6 Training Content Hazardous Conditions Training Content – Where the potential for hazardous conditions exists, training content shall include a) task execution, b) personal safety and appropriate protective equipment, c) awareness of hazardous environment, and d) equipment protection.

Reworded Changed title. Added ‘Hazardous Conditions’ to title to better reflect intent. Changed ‘should’ to ‘shall’ and added ‘and appropriate protective equipment’ to bullet b).





Comment

6.2.2 6.2.2.HV.1 Operator Qualification

Qualification of Personnel – The organization shall establish personnel qualification and requalification requirements for all applicable processes. Qualification requirements shall address employee education, experience, training, and demonstration of skills. [4]

Reworded Changed title. Replaced ‘Operator’ with ‘Personnel’ in title and body of text. Deleted ‘The organization shall communicate this information to all affected employees.’

6.2.2 6.2.2.HV.1-NOTE Examples of processes which may require personnel qualification and re-qualification include wire wrapping, soldering, welding, and fiber-optic fusion splicing.

New New Note

6.3 6.3.C.1 Infrastructure – The organization shall identify critical areas of the infrastructure and provide for the security needed to protect these areas. Security restoration plans shall be developed and periodically assessed.

New New Requirement

6.4 6.4.C.1 Work Areas Areas used for handling, storage, and packaging of products shall be clean, safe, and organized to ensure that they do not adversely affect product quality or personnel performance. [5]

Reworded Added the word ‘product.’

7.1 7.1.C.1 Life Cycle Model The organization shall establish and maintain an integrated set of method(s) that covers the life cycle of its products. The method(s) shall contain, as appropriate, the processes, activities, and tasks involved in the concept, definition, development, introduction, production, operation, maintenance, and (if required) disposal of products, spanning the life of the products. [9]

Reworded Replaced ‘guidelines’ and ‘framework’ with ‘method(s)’ for consistency and added the word ‘introduction.’ Reference [10] is now [9].

7.1 7.1.C.2 New Product Introduction

DELETED REQUIREMENT Deleted Covered elsewhere

7.1 7.1.C.2 NOTE 1 7.1.C.1-NOTE The new product introduction methods should include provisions for such programs as quality and reliability prediction studies, pilot production, demand and capacity studies, sales and service personnel training, customer documentation and training, and new product post-introduction evaluations.

Renumbered Reworded

Renumbered Note to map to 7.1.C.1. Added ‘customer documentation and training’ and changed ‘program’ to ‘methods’ for clarification and consistency.

7.1 7.1.C.3 Disaster Recovery 7.1.C.2 Disaster Recovery – The organization shall establish and maintain documented plans for disaster recovery to ensure the organization’s ability to recreate and service the product throughout its life cycle. [9]

Renumbered Reworded

Renumbered from 7.1.C.3 to 7.1.C.2. ‘Methods’ changed to ‘documented plans.’ Reference [10] is now [9].

7.1 7.1.C.2-NOTE Types of recovery capabilities should include a series of action statements related to disaster recovery. Examples include: who is notified, under what circumstances are they notified, who has authority to act, and who will coordinate the steps outlined in the plan.

New New Note





Comment

7.1 7.1.C.4 End of Life Planning 7.1.C.3 End of Life Planning – The organization shall establish and maintain a documented procedure(s) for the discontinuance of manufacturing and/or support of a product. The documented procedure(s) should include a) cessation of full or partial support after a certain period of time, b) archiving product documentation and software, c) responsibility for any future residual support issues, d) transition to the new product, if applicable, and e) accessibility of archive copies of data. [9]

Renumbered Reworded

Renumbered from 7.1.C.4 to 7.1.C.3. Deleted ‘by the operation and service organizations.’ Reference [10] is now [9].

7.1 7.1.C.4 Tools Management – The organization shall ensure that internally developed software and/or tools used in the product life cycle are subject to the appropriate quality method(s). [10]

Renumbered Reworded

Renumbered from 7.1.S.3 to 7.1.C.4. Expanded scope to common from software only. Changed title from ‘Support Software and Tools Management’ to ‘Tools Management.’ Examples previously in text were split out to a separate Note (see 7.1.C.4-NOTE). Reference [11] is now [10].

7.1 7.1.C.4-NOTE Examples of tools to be considered include: design and development, testing, configuration management, documentation, and diagnostic tools, including scripts and customizations, as well as software used to build and test product.

New New Note

7.1 7.1.HS.1 Configuration Management Plan

NO CHANGE to text or title. Reference Change Only

Reference is now [9] not [10].

7.1 7.1.HS.1 NOTE 1 7.1.HS.1-NOTE Work instructions defining general configuration management tasks and responsibilities need not be replicated as part of a specific documented configuration management plan. The Configuration Management Plan need not be contained in a single document.

Renumbered Reworded

Deleted ‘1’ in Note number. Deleted the word ‘General’ and added ‘The Configuration Management Plan need not be contained in a single document.’

7.1 7.1.S.1 Estimation See 7.3.1.S.2 Renumbered Moved from Section 7.1 to Section 7.3.

7.1 7.1.S.1 NOTE 1 See 7.3.1.S.2-NOTE Renumbered Moved from Section 7.1 to Section 7.3.

7.1 7.1.S.2 Computer Resources See 7.3.1.S.3 Renumbered Moved from Section 7.1 to Section 7.3.

7.1 7.1.S.3 Support Software and Tools Management

See 7.1.C.4 Expanded Scope

Placement now follows 7.1.C.3.

7.1 7.1.V.1 Service Delivery Plan Organizations that are responsible for the delivery or implementation of a service, and are not responsible for the design and development of that service, shall comply with the Project Plan requirements of 7.3.1.C.1.

Reworded Changed ‘Suppliers’ to ‘Organizations.’





Comment

7.2.2 7.2.2.C NOTE 1 DELETED NOTE Deleted 7.2.2.C-NOTE 1 text became new requirement, see 7.2.2.C.2 Contract Review.

7.2.2 7.2.2.C-NOTE The product acceptance plan should include, as appropriate, a) acceptance review process, b) acceptance criteria, c) documented test procedure(s), d) test environment, e) test cases, f) test data, g) test responsibilities, h) resources involved, i) method(s) for problem tracking and resolution, and j) required acceptance test reports. [9]

Renumbered Reworded

Renumbered Note from 7.2.2.C NOTE 2 to 7.2.2.C-NOTE. Added new bullet item, g) test responsibilities.

7.2.2 7.2.2.C NOTE 2 See 7.2.2.C-NOTE Renumbered

7.2.2 7.2.2.C.1 Closure Tracking – All actions resulting from requirements reviews shall be tracked to closure.

New New Requirement

7.2.2 7.2.2.C.2 Contract Review – The organization shall establish and maintain a contract review process that should include a) product acceptance criteria and criteria review process, b) method(s) for handling problems detected after product acceptance, including customer complaints, c) plan(s) for removal and/or correction of nonconformities after applicable warranty period or during product maintenance contract period, d) identification of risks and possible contingencies, e) adequate protection of proprietary information, f) definition of the organization's responsibility with regard to outsourced work, g) activities carried out by customer, including the customer's role in requirements, specifications and acceptance, h) facilities, tools, and software items to be provided by the customer, and i) all referenced standards and procedures. [8]

New New Requirement. This new requirement contains much of the same text in 7.2.2.C-NOTE 1 from Release 3.0. Bulleted items d) – i) are new.

7.2.3 7.2.3.C.1 Notification About Problems

NO CHANGE No Change





Comment

7.2.3 7.2.3.C.2 Problem Severity Except for those products specifically excluded from severity level reporting, the organization shall assign severity levels to customer-reported problems based on the impact to the customer in accordance with the definitions of critical, major, and minor problem reports contained in the TL 9000 Measurements Handbook. The severity level shall be used in determining the timeliness of the organization’s response. [10]

Reworded Added ‘except for those products specifically excluded from severity level reporting’ and changed ‘contained in the glossary of this handbook’ to ‘contained in the TL 9000 Measurements Handbook’ to text. Reference [11] is now [10].

7.2.3 7.2.3.C.2 NOTE 1 7.2.3.C.2-NOTE NO CHANGE to text or title. Renumbered Deleted ‘1’ from Note number.

7.2.3 7.2.3.C.3 Problem Escalation NO CHANGE to text or title. Reference Change Only

Reference [11] is now [10].

7.2.3 7.2.3.C.4 Customer Feedback The organization shall provide the customer with feedback on their problem reports in a timely and systematic manner.

Reworded Deleted procedure requirement and added ‘and systematic’ to text.

7.2.3 7.2.3.H.1 Organization’s Recall Process

7.2.3.HS.1 NO CHANGE to text or title. Expanded Scope

Renumbered from 7.2.3.H.1 to 7.2.3.HS.1. Expanded scope of requirement to include software.

7.2.3 7.2.3.HS.2 Design and Development Process Quality Measurements Data Reporting – On request by the customer, communications shall include reporting and evaluation of a jointly agreed set of design and development process measurements.

New New Requirement

7.3.1 7.3.1.C.1 Project Plan The organization's project planning activities shall be based on the defined product life cycle model (see 7.1.C.1). The project plan should include a) project organizational structure, b) roles, responsibilities, and accountabilities of the project team, c) roles, responsibilities, and accountabilities of related teams or individuals, within and outside the organization, and interfaces between them and the project team, d) means for scheduling, tracking, issue resolution, and management reporting, e) budgets, staffing, and schedules associated with project activities, f) identification of method(s), standards, documented procedure(s), and tools to be used (If such items are clearly defined as part of the product life cycle model, a reference to that life cycle model is sufficient.), g) references to related plans (e.g., development, testing, configuration management, and quality), h) project-specific development or service delivery environment and physical resource considerations (e.g., resources to address development, user documentation, testing, operation, required development tools, secure computing environment, lab space, workstations, etc.), i) customer, user, and supplier involvement during the product life cycle (e.g., joint reviews, informal meetings, and approvals), j) management of project quality, k) risk management and contingency plans (e.g., risks of rework, poor field reliability and defects, resource and schedule variance), l) project-specific training requirements,

Reworded Reworded for clarification. Deleted bullet l) ‘performance, safety, security, and other critical requirements’ from Release 3.0. Added reference to Life Cycle Model 7.1.C.1. Reference [10] is now [9].





Comment

m) required certifications (e.g., product certifications or employee technical certifications), n) proprietary, usage, ownership, warranty, licensing rights, and o) post-project analysis. [9]

7.3.1 7.3.1.C.1 NOTE 1 NO CHANGE No Change

7.3.1 7.3.1.C.1 NOTE 2 Work instructions defining tasks and responsibilities common to all development projects need not be replicated as part of a project plan.

Reworded Deleted the word ‘General’ in text.

7.3.1 7.3.1.C.2 Requirements Traceability



7.3.1 7.3.1.C.2 NOTE 1 NO CHANGE to text or title. Renumbered Deleted ‘1’ from Note number.

7.3.1 7.3.1.C.3 Test Planning Test plans shall be documented and should include a) scope of testing (e.g., unit, feature, integration, system, acceptance, field, migration and regression), b) types of tests to be performed (e.g., functional, boundary, usability, performance, regression, interoperability, stress), c) traceability to requirements, d) test environment (e.g., relevancy to customer environment, operational use), e) test coverage (degree to which a test verifies a product’s functions, sometimes expressed as a percent of functions tested), f) expected results, g) data definition and database requirements, h) set of tests, repeatable test cases (inputs, outputs, test criteria), and documented test procedure(s), i) use of external testing, j) method of reporting and resolving defects, and k) customer test requirements. [10] The results of testing and subsequent action taken shall be recorded (see 4.2.4).

Reworded Added bullet k) ‘customer test requirements’ and expanded bullet a) to include ‘field, migration and regression’ testing. Deleted ‘results recorded’ but added reference to 4.2.4 Control of Records. Reference [11] is now [10].

7.3.1 7.3.1.C.3 NOTE 1 DELETED NOTE Deleted Covered elsewhere in standard.





Comment

7.3.1 7.3.1.HS.1 Migration Planning – The organization shall develop and document a migration plan when a system, hardware or software product is planned to be migrated from an old to a new operational environment. If the old environment will no longer be supported, users shall be given notification of migration plans and activities which shall include a description of the new environment with its date of availability, and a description of other support options available, if any, once support for the old environment has been removed. The migration plan should also include a) requirements analysis and definition of migration, b) development of migration tools, c) conversion of product and data, d) migration execution, e) migration verification, and f) support for the old environment in the future. [9]

Expanded Scope

Renumbered from 7.3.1.S.2 to 7.3.1.HS.1. Expanded scope to include hardware. Reference [10] is now [9].

7.3.1 7.3.1.HS.1-NOTE 1 The operational environment is made up of hardware, software or systems on which the product depends, that the customer purchases and installs separately, from either the organization or other suppliers. Examples of changes from old to new software operational environments include upgrades to the operating system, database, or communications protocol stack. Examples of changes from old to new hardware operational environments include using existing circuit packs in new racks or with new controllers, or upgrading computer hardware. Both hardware and software platform migration could affect either hardware or software components or systems so migration plans should cover all possibilities.

New New Note

7.3.1 7.3.1.HS.1-NOTE 2 If the old environment will no longer be supported, consideration should be given to arrangements for access to data that was used by, or associated with, the old operational environment, for data protection and audit purposes, in accordance with regulatory and contract requirements.

New New Note

7.3.1 7.3.1.HS.2 Design and Development Process Quality Measurement Planning and Implementation – During the design and development planning phase, the organization shall establish and maintain a method(s) for selecting and reporting appropriate design and development process quality measures for the project. As recommended during this phase, this measurement system shall be implemented appropriately to the project.

New New Requirement





Comment

7.3.1 7.3.1.HS.2-NOTE See the Appendix “Set Up and Operation of a Design Process Measurement System” for guidelines to aid in selecting and establishing appropriate design and development process measurements for the project.

New New Note. All Appendices are now located on the TL 9000 website.

7.3.1 7.3.1.S.1 Integration Planning NO CHANGE to text or title. Reference Change Only


7.3.1 7.3.1.S.2 Migration Planning See 7.3.1.HS.1 Expanded Scope

7.3.1 7.3.1.S.2 Estimation – The organization shall establish and maintain a method for estimating and tracking project factors during project planning, execution, and change management. [10]

Renumbered Renumbered from 7.1.S.1 to 7.3.1.S.2. No change to title or text. Reference [11] is now [10].

7.3.1 7.3.1.S.2-NOTE Project factors should include product size, complexity, requirements changes, effort, staffing, schedules, cost, quality, reliability, and productivity.

Renumbered Renumbered from 7.1.S.1-NOTE 1 to 7.3.1.S.2-NOTE. No change to text.

7.3.1 7.3.1.S.3 Computer Resources – The organization shall establish and maintain methods for estimating and tracking critical computer resources for the target computer, the computer on which the software is intended to operate. [10]

Renumbered Renumbered from 7.1.S.2 to 7.3.1.S.3. No change to text or title. Reference [11] is now [10].

7.3.1 7.3.1.S.3-NOTE Examples of these resources are utilization of memory, throughput, real-time performance, and I/O channels. Firmware examples include utilization of processor, memory, I/O channels, etc.

New New Note

7.3.1 7.3.1.S.4 Regression Test Planning – If regression testing is to be performed, test plans shall specify which tests are regression and what features and functions are covered by these regression tests.

New New Requirement

7.3.2 7.3.2.C.1 Customer and Supplier Input

NO CHANGE No Change

7.3.2 7.3.2.C.2 Design and Development Requirements

Design and development requirements shall be defined and documented, and should include a) quality and reliability requirements, b) functions and capabilities of the product, c) business, organizational, and user requirements, d) safety, environmental, and security requirements, e) installability, usability, and maintainability requirements, f) design constraints, g) testing requirements, and h) computer resources for the target computer. [9]

Reworded Added new bullet h) ‘computer resources for the target computer.’ Reference [10] is now [9].





Comment

7.3.2 7.3.2.C.3 Requirements Allocation – The organization shall document the allocation of the product requirements to the product architecture. [8]

Expanded Scope

Renumbered from 7.3.2.S.2 to 7.3.2.C.3. Expanded scope to common from software only. No change to text or title. Reference [9] is now [8].

7.3.2 7.3.2.C.3-Note Examples of requirements which should be allocated are response time for software, heat dissipation for hardware and service response time for services.

New New Note

7.3.2 7.3.2.H.1 Content of Requirements

NO CHANGE No Change

7.3.2 7.3.2.S.1 Identification of Software Requirements



7.3.2 7.3.2.S.2 Requirements Allocation

See 7.3.2.C.3 Expanded Scope

No change to text or title.

7.3.3 7.3.3.S.1 Software Design and Development Output

7.3.3.HS.1 Design and Development Output – Design and development outputs should include, but are not limited to a) system architecture, b) system detailed design, c) source code, and d) user documentation. [8]

Expanded Scope

Renumbered from 7.3.3.S.1 to 7.3.3.HS.1. Expanded scope to include hardware. Deleted ‘Software’ from title and text.

7.3.3 7.3.3.V.1 Services Design and Development Output



7.3.5 7.3.5.C.1 Verification of Documentation – The organization shall verify the customer and/or user documentation prior to product delivery.

New New Requirement

7.3.5 7.3.5.HS.1 Stress Testing – The organization shall test the product under stress conditions, including, but not limited to, out-of-boundary and invalid input conditions, high volume and peak load simulations, and operational errors. [10]

New New Requirement

7.3.5 7.3.5.HS.2 Abnormal Conditions – The organization shall test the product under abnormal conditions, which shall include, as appropriate a) hardware errors, b) software errors, c) operations, administration, maintenance and provisioning (OAM&P) errors, d) overload traffic, e) invalid user input, and f) system recovery from an outage

New New Requirement

7.3.5 7.3.5.S.1 System Testing – Each software release shall be subjected to a system test in accordance with a documented system test plan. [14]

New New Requirement

7.3.6 7.3.6.C NOTE 1 NO CHANGE to text or title. Renumbered Deleted ‘1’ from Note number.





Comment

7.3.6 7.3.6.S.1 Release Management

7.3.6.S.1 Release Management – The organization shall establish and maintain method(s) to ensure that the release and delivery of software products and related documentation are carried out under controlled conditions. Method(s) should provide for the delivery to the customer of a) release planning information in advance of the release, b) product introduction and release schedules, c) detailed descriptions of product features delivered, including any changes incorporated in new software products or releases, and d) advisories regarding current or planned changes to contractual terms (see 7.3.7.C.2). [10]

Reworded Deleted procedure requirement. Reworded for clarification of intent. Added reference to 7.3.7.C.2. Reference [11] is now [10].

7.3.7 7.3.7.C.1 Change Management Process

The organization shall establish and maintain a documented procedure to ensure that all requirements and design changes, which may arise at any time during the product life cycle, are managed and tracked in a systematic and timely manner appropriate to the life cycle stage. The organization shall ensure that changes which adversely affect mutually agreed conditions for quality, reliability and functional intent are reviewed with the customer prior to approval. Management of changes should include a) impact analysis, including impact on resources and schedule, b) planning, c) implementation, d) testing, e) documentation, f) communication, and g) review and approval. [5]

Reworded Added documented procedure requirement. Reworded to clarify intent. Expanded bullet a) to add ‘including impact on resources and schedule.’ Added NOTE to this requirement.

7.3.7 7.3.7.C.1-NOTE While a change management process is required throughout the life cycle, controls within that process may depend on the life cycle stage. For example, during design, the organization should be able to react to rapidly changing customer requirements, and take advantage of emerging technologies with an encompassing, responsive change management process. After General Availability the change management process scope should consider how the change on the operation and maintenance of the product and its installed base impacts the community of customers and stakeholders. The consideration should include quality, reliability, and functional intent.

New New Note

7.3.7 7.3.7.C.2 Informing Customers NO CHANGE No change





Comment

7.3.7 7.3.7.HS.1 Problem Resolution Configuration Management

7.3.7.C.3 Problem Resolution Configuration Management – The organization shall ensure that its configuration management system tracks fixes to problems and incorporates those fixes in future revisions. [10]

Expanded Scope Reworded

Renumbered from 7.3.7.HS.1 to 7.3.7.C.3. Expanded scope to common from hardware and software only. Reworded to clarify intent. Reference [11] is now [10].

7.3.7 7.3.7.H.1 Component Changes NO CHANGE No Change

7.4.1 7.4.1.C.1 Purchasing Procedure(s)

The organization shall establish and maintain a documented purchasing procedure(s) to ensure a) product requirements are clearly defined, b) risks are understood and managed, c) qualification criteria are established, d) acceptance criteria are established, e) contracts are defined, f) proprietary, usage, ownership, warranty, and licensing rights are satisfied, g) future support for the product is planned, h) ongoing supply-base management and monitoring is in place, i) supplier selection criteria are defined, j) suppliers are re-evaluated based on defined criteria, and k) feedback is provided to key suppliers based on data analysis of supplier performance. [9]

Reworded Reworded to clarify intent. Added new bullet d) ‘acceptance criteria are established.’ Corrected typo in bullet list by adding bullet j). Reference [10] is now [9].

7.4.1 7.4.1.C.1 NOTE 1 NO CHANGE to text or title. Renumbered Deleted ‘1’ from Note number.

7.5.1 7.5.1.C.1 Organization’s Support Program

DELETED REQUIREMENT Deleted Covered elsewhere in standard.

7.5.1 7.5.1.C.2 Service Resources 7.5.1.C.1 Service Resources – The organization shall provide customer contact employees with appropriate tools, training, and resources necessary to provide effective and timely customer service. [4]

Renumbered Renumbered from 7.5.1.C.2 to 7.5.1.C.1. No change to text or title.

7.5.1 7.5.1.C.2 Product Delivery – The organization shall establish and maintain method(s) to minimize interference with the customer’s normal site operation and service during product delivery and installation. [4]

New New Requirement

7.5.1 7.5.1.HS.1 Emergency Service The organization shall ensure that services and resources are available to support recovery from emergency failures of product in the field throughout its expected life. The organization shall identify potential situations that may have an impact on its ability to provide the emergency service and shall have response plans to address these situations. These plans shall be based on risk and periodically assessed. [4]

Kept original text. Added ‘The organization shall identify potential situations that may have an impact on its ability to provide the emergency service and shall have response plans to address these situations. These plans shall be based on risk and periodically assessed.’





Comment

7.5.1 7.5.1.HS.2 Installation Plan The organization shall establish and maintain a documented installation plan. The installation plan shall identify the resources, the information required, the sequence of events and any necessary records. [9]

Reworded Reworded to clarify intent. Reference [10] is now [9].

7.5.1 7.5.1.HV.1 Operational Changes – Each time a significant change is made in the established operation (e.g., a new operator, new machine, or new technique), a critical examination shall be made of the first unit(s)/service(s) processed after the change. [5]

Renumbered Renumbered requirement from 7.5.2.HV.1 to 7.5.1.HV.1. No change to text or title.

7.5.1 7.5.1.S.1 Patching Procedure(s)

The organization shall establish and maintain a documented patching procedure(s) that a) guides the decision to solve problems by patching, b) addresses patch development procedures, propagation (forward and backward), and resolution, c) is consistent with customer needs or contractual requirements for maintenance support, and d) ensures that the organization provides the customer with a statement of impact on the customer's operation for each patch. [10]

Reworded Reworded requirement to clarify intent. Reference [11] is now [10].

7.5.1 7.5.1.S.2 Patch Documentation NO CHANGE to text or title. Reference Change Only


7.5.1 7.5.1.S.3 Replication The organization shall establish and maintain a documented procedure(s) for replication, which should include a) identification of master copy, b) identification of replicate copies for delivery, c) quantity of replicates to deliver, d) type of media, e) labeling, f) identification of required documentation such as user guides, g) packaging of documentation, and h) control of environment to ensure repeatable replication. [8]

Reworded Deleted the words ‘the following:’ for consistency. Reference [9] is now [8].

7.5.1 7.5.1.V.1 Software Used in Service Delivery

The organization shall establish and maintain a documented procedure(s) for the maintenance and control of software used in service delivery to ensure continued process capability and integrity.

Reworded Reworded for clarification and consistency. Deleted the words, ‘and implement processes.’

7.5.1 7.5.1.V.2 Tool Changes The organization shall establish and maintain a documented procedure(s) to ensure that substitutions or changes to tools used in performing the service do not adversely affect the quality of the service.

Reworded Reworded for consistency.

7.5.2 7.5.2.HV.1 Operational Changes

See 7.5.1.HV.1. Renumbered No change to text or title.

7.5.3 7.5.3.HS.1 Product Identification

REORDERED Reordered Reordered. Placement now follows 7.5.3.H.2.

7.5.3 7.5.3.H.1 Traceability for Recall

NO CHANGE No Change





Comment

7.5.3 7.5.3.H.2 Traceability of Design Changes

The organization shall define and implement methods necessary to provide traceability of design changes to identifiable manufacturing dates, lots, or serial numbers.

Reworded Deleted procedure requirement.

7.5.3 7.5.3.HS.1 Product Identification – The organization shall establish and maintain a process for the identification of each product and the level of required control. For each product and its versions, the following shall be identified where they exist: a) product documentation, b) development or production tools essential to repeat product creation, c) interfaces to other products, and d) software and hardware environment. [8]

Reordered Reordered. Added NOTE to this requirement. No change to text or title. Reference [9] is now [8].

7.5.3 7.5.3.HS.1-NOTE Examples of product identification include barcode, tag, label, electronic ID, etc., containing information such as production lot numbers and dates, and serial numbers. New technologies for data retrieving such as RFID may also be considered.

New New Note

7.5.5 7.5.5.C.1 Anti-Static Protection Electrostatic Discharge Sensitive (ESDS) Protection – Where applicable, anti-static protection shall be employed for components and products susceptible to electrostatic discharge (ESD) damage.

Reworded Changed title from ‘Anti-Static Protection' to ‘Electrostatic Discharge Sensitive (ESDS) Protection.’ Added NOTE 1 and 2 to this requirement.

7.5.5 7.5.5.C.1-NOTE 1 Types of components and products which should be protected include electronic parts, integrated circuits, printed wiring board assemblies, magnetic tapes and disks, and other media used for software or data storage. [5]

New New Note

7.5.5 7.5.5.C.1-NOTE 2 Certification to ANSI/ESD S20.20 published by the ESD Association should be taken as indication that the certified facilities meet TL 9000 requirements 6.2.2.C.4 and 7.5.5.C.1 concerning ESD protection. Please check the TL 9000 website (visit tl9000.org) for the acceptability of any later editions of the ANSI standard.

New New Note

7.5.5 7.5.5.HS.1 Packaging and Labeling Audit

7.5.5.HS.1 Packaging and Labeling Verification – The organization shall establish and maintain methods to ensure that the packaging and labeling of products and components conform to specified requirements.

Reworded Changed title. Deleted ‘Audit’ and added ‘Verification’ to title. Reworded requirement to clarify intent. Deleted examples from requirement and incorporated them into a new NOTE.

7.5.5 7.5.5.HS.1 NOTE 1 7.5.5.HS.1-NOTE Packaging and labeling verification is normally performed on products ready to ship and may include, for example, marking, labeling, kitting, documentation, addressing, customer-specific marks, and verification of quantities to be shipped.

Renumbered Reworded

Deleted ‘1’ from Note number. Deleted ‘This audit is normally done on products ready to ship.’





Comment

7.5.5 7.5.5.H.1 Deterioration 7.5.5.HV.1 Deterioration – Where the possibility of deterioration exists, the organization shall establish and maintain methods to determine when materials that may impact product quality have deteriorated or exceeded their expiration dates, and assess any required subsequent action. [5]


Renumbered from 7.5.5.H.1 to 7.5.5.HV.1. Expanded scope to include services from hardware only. Reworded to clarify intent.

7.5.5 7.5.5.S.1 Software Virus Protection



7.6 7.6.H.1 Identified Equipment 7.6.C.1 Equipment Identification – Monitoring and measuring devices that are either inactive or unsuitable for use shall be visibly identified and not used. All monitoring and measuring devices that do not require calibration shall be identified. [5]


Renumbered from 7.6.H.1 to 7.6.C.1. Expanded scope to common from hardware only. Changed title to ‘Equipment Identification’ from ‘Identified Equipment.’ No change to text.

8.2.1 8.2.1.C.1 Customer Satisfaction Data

The organization shall establish and maintain a method to collect data directly from customers concerning their satisfaction with provided products. The organization shall also collect customer data on how well the organization meets commitments and its responsiveness to customer feedback and needs. This data shall be analyzed and trended. [4]

Reworded Deleted the words ‘collected and’ and the sentence, ‘Trends of the data shall be kept.’ Added the words ‘and trended.’

8.2.3 8.2.3.C.1 Process Measurement

Process measurements shall be identified, documented, and monitored at appropriate points to ensure continued suitability and promote increased effectiveness of processes. This includes the establishment of appropriate design process measurements. Key process measurements that impact product quality should have specific performance targets or control limits established. [8]

Reworded Deleted ‘developed,’ added ‘identified,’ and text ‘This includes the establishment of appropriate design process measurements. Key process measurements that impact product quality should have specific performance targets or control limits established.’ Reference [9] is now [8].

8.2.4 8.2.4.HV.1 Inspection and Test Documentation

REORDERED Reordered Placement now follows 8.2.4.H.4.

8.2.4 8.2.4.HV. 2 Inspection and Test Records

REORDERED Reordered Placement now precedes 8.2.4.S.1.

8.2.4 8.2.4.H.1 Periodic Retesting The organization shall establish and maintain a documented procedure(s) that ensures products are periodically retested to assess the product's ability to continue to meet design requirements. When determining the depth of the retest, the organization should consider the conditions in 8.2.4.H.3 [5]

Reworded Added reference to 8.2.4.H.3.

8.2.4 8.2.4.H.2 Content of Testing NO CHANGE No Change

8.2.4 8.2.4.H.2-NOTE 1 8.2.4.H.2-NOTE Product specifications may include environmental, vibration, flammability, operational stress type testing, and intrusion/penetration testing.

Renumbered Reworded

Added ‘and intrusion/penetration testing.’ Deleted ‘1’ from Note number.





Comment

8.2.4 8.2.4.H.3 Frequency of Testing The organization shall establish and document the frequency for test and periodic retest. When determining the test frequency, the organization shall include a) product complexity and service criticality, b) number of design, engineering and/or manufacturing changes made to the product and whether the change(s) affect form, fit, and/or function, c) changes to the manufacturing process, d) manufacturing variations, (e.g., tooling wear), e) material and/or component substitutions and failure rates, and f) the field performance record of the product. [5]

Reworded Deleted ‘the following:’ for consistency. No change to bulleted items.

8.2.4 8.2.4.H.4 Testing of Repair and Return Products

NO CHANGE No Change

8.2.4 8.2.4.HV.1 Inspection and Test Documentation – Each inspection or testing activity shall have detailed documentation. Details should include, but are not limited to a) parameters to be checked with acceptable tolerances, b) the use of statistical techniques, control charts, etc., c) sampling plan, including frequency, sample size, and acceptance criteria, d) handling of nonconformities, e) data to be recorded (see 4.2.4), f) defect classification scheme, g) method for designating an inspection item or lot, and h) electrical, functional, and feature testing. [5]

Reordered Reworded

Reordered. Deleted ‘the following’ and added ‘but are not limited to’ for bulleted list. Added reference to 4.2.4, Control of Records for bullet e).

8.2.4 8.2.4.HV.2 Inspection and Test Records – Inspection or test records shall include a) product identification, b) quantity of product, c) documented procedure(s) followed, d) person performing the test or inspection, e) calibrated equipment used (see 7.6), f) date performed, and g) number, type, and severity of defects found. [5]

Reordered Reworded

Reordered. Added bullet e) ‘calibrated equipment used (see 7.6).’ Added reference to 7.6, Control of Monitoring and Measuring Devices.

8.2.4 8.2.4.S.1 Test Documentation Software tests shall be conducted per the test plan according to a documented procedure(s). Records of testing shall include a) test results, b) analysis of test results, c) conformity to expected results, and d) problem reporting for nonconforming items. [10]

Reworded Reworded for clarity and consistency. Reference [11] is now [10].





Comment

8.4 8.4.C.1 Trend Analysis of Nonconforming Product

NO CHANGE No Change

8.4 8.4.H.1 Field Performance Data

8.4.HS.1 Field Performance Data – The quality management system shall include the collection and analysis of field performance data which can be used to help identify the cause and frequency of product failure. In addition, no trouble found (NTF) data shall also be maintained. This information shall be provided to the appropriate organizations to foster continual improvement. [5]


Renumbered from 8.4.H.1 to 8.4.HS.1. Expanded scope to include software from hardware only. Deleted ‘equipment’ and added ‘product’ to text.

8.4 8.4.V.1 Service Performance Data

NO CHANGE No Change

8.5.1 8.5.1.C.1 Quality Improvement Program

8.5.1.C.1 Continual Improvement Program(s) – The organization shall establish and maintain a continual improvement program(s) that includes a focus to improve a) customer satisfaction, b) quality and reliability of the product, and c) other processes/products/services used within the organization. [5]

Reworded Changed title from ‘Quality Improvement Program’ to ‘Continual Improvement Program(s). Deleted ‘documented’ requirement.

8.5.1 8.5.1.C NOTE 2 8.5.1.C.1-NOTE Inputs to the continual improvement process may include lessons learned from past experience, lessons learned from previous projects, analysis of measurements and post-project reviews, and comparisons with industry best practices.

Renumbered Corrected Note number, from 8.5.1.C-NOTE 2 to 8.5.1.C.1-NOTE for consistency. No change to text.

8.5.1 8.5.1.C.2 Employee Participation

NO CHANGE No Change

8.5.2 8.5.2.C NOTE 1 DELETED NOTE Deleted Covered elsewhere in standard.

8.5.2 8.5.2.C NOTE 2 8.5.2.C-NOTE 1 Review of corrective action is intended to ensure that the action taken was effective. Review activities may include ensuring that root cause was properly identified and addressed, appropriate containment action was taken, and corrective actions have not introduced additional problems.

Renumbered Renumbered from 8.5.2.C NOTE 2 to 8.5.2.C-NOTE 1. NO CHANGE to text.

8.5.2 8.5.2.C NOTE 3 8.5.2.C-NOTE 2 Consideration should be given to include training as part of implementing corrective and preventive actions.

Renumbered Renumbered from 8.5.2.C NOTE 3 to 8.5.2.C-NOTE 2. NO CHANGE to text.

8.5.2 8.5.2.S.1 Problem Resolution NO CHANGE to text or title. Reference Change Only




Cross Reference for TL 9000 Release 3.0 to 4.0

TL 9000 Release 3.0 TL 9000 Release 4.0 Type of Change 4.2.3.C.1 Control of Customer-Supplied Documents and Data 4.2.3.C.1 Control of Customer-Supplied Documents and Data Reworded 5.2.C.1 Customer Relationship Development 5.2.C.1 Customer Relationship Development No Change 5.2.C.2 Customer Communication Procedures 5.2.C.2 Customer Communication Methods Reworded 5.2.C.2 NOTE 1 5.2.C.2 NOTE Renumbered 5.4.1.C.1 Quality Objectives 5.4.1.C.1 Quality Objectives No Change 5.4.2.C.1 Long- and Short-Term Quality Planning 5.4.2.C.1 Long- and Short-Term Quality Planning Reworded 5.4.2.C.1 NOTE 1 New 5.4.2.C.1 NOTE 1 5.4.2.C.1 NOTE 2 Renumbered 5.4.2.C.2 Customer Input 5.4.2.C.2 Customer Input No Change 5.4.2.C.3 Supplier Input 5.4.2.C.3 Supplier Input No Change 5.5.3.C.1 Organization Performance Feedback 5.5.3.C.1 Organization Performance Feedback No Change 6.2.2.C NOTE New 6.2.2.C.1 Internal Course Development 6.2.2.C.1 Internal Course Development Reworded 6.2.2.C.2 Quality Improvement Concepts 6.2.2.C.2 Quality and Process Improvement Concepts Reworded 6.2.2.C.3 Training Requirements and Awareness 6.2.2.C.3 Product Quality Training Opportunity Awareness Reworded 6.2.2.C.4 ESD Training 6.2.2.C.4 Electrostatic Discharge (ESD) Training Reworded 6.2.2.C.5 Advanced Quality Training 6.2.2.C.5 Advanced Quality Training No Change 6.2.2.C.6 Training Content 6.2.2.C.6 Hazardous Conditions Training Content Reworded 6.2.2.HV.1 Operator Qualification 6.2.2.HV.1 Qualification of Personnel Reworded 6.2.2.HV.1 NOTE New 6.3.C.1 Infrastructure New 6.4.C.1 Work Areas 6.4.C.1 Work Areas Reworded 7.1.C.1 Life Cycle Model 7.1.C.1 Life Cycle Model Reworded 7.1.C.1 NOTE New 7.1.C.2 New Product Introduction Deleted 7.1.C.2 NOTE 1 Deleted

7.1.C.3 Disaster Recovery 7.1.C.2 Disaster Recovery Renumbered Reworded

7.1.C.2 NOTE New

7.1.C.4 End of Life Planning 7.1.C.3 End of Life Planning Renumbered Reworded

7.1.HS.1 Configuration Management Plan 7.1.HS.1 Configuration Management Plan Reference Change Only



TL 9000 Release 3.0 TL 9000 Release 4.0 Type of Change

7.1.HS.1 NOTE 1 7.1.HS.1 NOTE Renumbered Reworded

7.1.S.1 Estimation 7.3.1.S.2 Estimation Renumbered 7.1.S.1 NOTE 1 7.3.1.S.2 NOTE Renumbered 7.1.S.2 Computer Resources 7.3.1.S.3 Computer Resources Renumbered 7.1.S.3 Support Software and Tools Management 7.1.C.4 Tools Management Expanded Scope 7.1.C.4 NOTE New 7.1.V.1 Service Delivery Plan 7.1.V.1 Service Delivery Plan Reworded 7.2.2.C NOTE 1 Deleted

7.2.2.C NOTE 2 7.2.2.C NOTE Renumbered Reworded

7.2.2.C.1 Closure Tracking New 7.2.2.C.2 Contract Review New 7.2.3.C.1 Notification About Problems 7.2.3.C.1 Notification About Problems No Change 7.2.3.C.2 Problem Severity 7.2.3.C.2 Problem Severity Reworded 7.2.3.C.2 NOTE 1 7.2.3.C.2 NOTE Renumbered 7.2.3.C.3 Problem Escalation 7.2.3.C.3 Problem Escalation Reference Change Only 7.2.3.C.4 Customer Feedback 7.2.3.C.4 Customer Feedback Reworded 7.2.3.H.1 Organization’s Recall Process 7.2.3.HS.1 Organization’s Recall Process Expanded Scope

7.2.3.HS.2 Design and Development Process Quality Measurements Data Reporting New

7.3.1.C.1 Project Plan 7.3.1.C.1 Project Plan Reworded 7.3.1.C.1 NOTE 1 7.3.1.C.1 NOTE 1 No Change 7.3.1.C.1 NOTE 2 7.3.1.C.1 NOTE 2 Reworded 7.3.1.C.2 Requirements Traceability 7.3.1.C.2 Requirements Traceability Reference Change Only 7.3.1.C.2 NOTE 1 7.3.1.C.2 NOTE Renumbered 7.3.1.C.3 Test Planning 7.3.1.C.3 Test Planning Reworded 7.3.1.C.3 NOTE 1 Deleted 7.3.1.S.1 Integration Planning 7.3.1.S.1 Integration Planning Reference Change Only 7.3.1.S.2 Migration Planning 7.3.1.HS.1 Migration Planning Expanded Scope 7.3.1.HS.1 NOTE 1 New 7.3.1.HS.1 NOTE 2 New

7.3.1.HS.2 Design and Development Process Quality Measurement Planning and Implementation New



TL 9000 Release 3.0 TL 9000 Release 4.0 Type of Change 7.3.1.HS.2 NOTE New 7.3.1.S.3 NOTE New 7.3.1.S.4 Regression Test Planning New 7.3.2.C.1 Customer and Supplier Input 7.3.2.C.1 Customer and Supplier Input No Change 7.3.2.C.2 Design and Development Requirements 7.3.2.C.2 Design and Development Requirements Reworded 7.3.2.H.1 Content of Requirements 7.3.2.H.1 Content of Requirements No Change 7.3.2.S.1 Identification of Software Requirements 7.3.2.S.1 Identification of Software Requirements Reference Change Only 7.3.2.S.2 Requirements Allocation 7.3.2.C.3 Requirements Allocation Expanded Scope 7.3.2.C.3 NOTE New 7.3.3.S.1 Software Design and Development Output 7.3.3.HS.1 Design and Development Output Expanded Scope 7.3.3.V.1 Services Design and Development Output 7.3.3.V.1 Services Design and Development Output Reference Change Only 7.3.5.C.1 Verification of Documentation New 7.3.5.HS.1 Stress Testing New 7.3.5.HS.2 Abnormal Conditions New 7.3.5.S.1 System Testing New 7.3.6.C NOTE 1 7.3.6.C NOTE Renumbered 7.3.6.S.1 Release Management 7.3.6.S.1 Release Management Reworded 7.3.7.C.1 Change Management Process 7.3.7.C.1 Change Management Process Reworded 7.3.7.C.1 NOTE New 7.3.7.C.2 Informing Customers 7.3.7.C.2 Informing Customers No change

7.3.7.HS.1 Problem Resolution Configuration Management 7.3.7.C.3 Problem Resolution Configuration Management Expanded Scope Reworded

7.3.7.H.1 Component Changes 7.3.7.H.1 Component Changes No Change 7.4.1.C.1 Purchasing Procedure(s) 7.4.1.C.1 Purchasing Procedure(s) Reworded 7.4.1.C.1 NOTE 1 7.4.1.C.1 NOTE Renumbered 7.5.1.C.1 Organization’s Support Program Deleted 7.5.1.C.2 Service Resources 7.5.1.C.1 Service Resources Renumbered 7.5.1.C.2 Product Delivery New 7.5.1.HS.1 Emergency Service 7.5.1.HS.1 Emergency Service Reworded 7.5.1.HS.2 Installation Plan 7.5.1.HS.2 Installation Plan Reworded 7.5.1.S.1 Patching Procedure(s) 7.5.1.S.1 Patching Procedure(s) Reworded 7.5.1.S.2 Patch Documentation 7.5.1.S.2 Patch Documentation Reference Change Only 7.5.1.S.3 Replication 7.5.1.S.3 Replication Reworded 7.5.1.V.1 Software Used in Service Delivery 7.5.1.V.1 Software Used in Service Delivery Reworded



TL 9000 Release 3.0 TL 9000 Release 4.0 Type of Change 7.5.1.V.2 Tool Changes 7.5.1.V.2 Tool Changes Reworded 7.5.2.HV.1 Operational Changes 7.5.1.HV.1 Operational Changes Renumbered 7.5.3.HS.1 Product Identification 7.5.3.HS.1 Product Identification Reordered 7.5.3.HS.1 NOTE New 7.5.3.H.1 Traceability for Recall 7.5.3.H.1 Traceability for Recall No Change 7.5.3.H.2 Traceability of Design Changes 7.5.3.H.2 Traceability of Design Changes Reworded 7.5.5.C.1 Anti-Static Protection 7.5.5.C.1 Electrostatic Discharge Sensitive (ESDS) Protection Reworded 7.5.5.C.1 NOTE 1 New 7.5.5.C.1 NOTE 2 New 7.5.5.HS.1 Packaging and Labeling Audit 7.5.5.HS.1 Packaging and Labeling Verification Reworded

7.5.5.HS.1 NOTE 1 7.5.5.HS.1 NOTE Renumbered Reworded

7.5.5.H.1 Deterioration 7.5.5.HV.1 Deterioration Expanded Scope Reworded

7.5.5.S.1 Software Virus Protection 7.5.5.S.1 Software Virus Protection Reference Change Only 7.6.H.1 Identified Equipment 7.6.C.1 Equipment Identification Expanded Scope 8.2.1.C.1 Customer Satisfaction Data 8.2.1.C.1 Customer Satisfaction Data Reworded 8.2.3.C.1 Process Measurement 8.2.3.C.1 Process Measurement Reworded 8.2.4.HV.1 Inspection and Test Documentation 8.2.4.HV.1 Inspection and Test Documentation Reordered 8.2.4.HV. 2 Inspection and Test Records 8.2.4.HV. 2 Inspection and Test Records Reordered 8.2.4.H.1 Periodic Retesting 8.2.4.H.1 Periodic Retesting Reworded 8.2.4.H.2 Content of Testing 8.2.4.H.2 Content of Testing No Change

8.2.4.H.2 NOTE 1 8.2.4.H.2-NOTE Renumbered Reworded

8.2.4.H.3 Frequency of Testing 8.2.4.H.3 Frequency of Testing Reworded 8.2.4.H.4 Testing of Repair and Return Products 8.2.4.H.4 Testing of Repair and Return Products No Change 8.2.4.S.1 Test Documentation 8.2.4.S.1 Test Documentation Reworded 8.4.C.1 Trend Analysis of Nonconforming Product 8.4.C.1 Trend Analysis of Nonconforming Product No Change 8.4.H.1 Field Performance Data 8.4.HS.1 Field Performance Data Expanded Scope 8.4.V.1 Service Performance Data 8.4.V.1 Service Performance Data No Change 8.5.1.C.1 Quality Improvement Program 8.5.1.C.1 Continual Improvement Program(s) Reworded 8.5.1.C NOTE 1 8.5.1.C.1 NOTE Renumbered 8.5.1.C.2 Employee Participation 8.5.1.C.2 Employee Participation No Change 8.5.2.C NOTE 1 Deleted



TL 9000 Release 3.0 TL 9000 Release 4.0 Type of Change 8.5.2.C NOTE 2 8.5.2.C NOTE 1 Renumbered 8.5.2.C NOTE 3 8.5.2.C NOTE 2 Renumbered 8.5.2.S.1 Problem Resolution 8.5.2.S.1 Problem Resolution Reference Change Only


TL 9000 Accreditation Body Implementation Requirements

This document is a product of the Oversight Work Group of the QuEST Forum. It was formerly published in the TL 9000 Quality Management System Requirements Handbook as Appendix A and is subject to change by the Oversight Work Group with the latest version always appearing here. This document is referenced in Section 3.5 of the TL 9000 Quality Management System Requirements Handbook, Release 4.0. Note that Accreditation Bodies are sometimes called AB’s and that Registrar companies are sometimes called Certification Bodies, or CB’s.

TL 9000 Accreditation Body Implementation Requirements Below are TL 9000 implementation requirements including criteria for registrar qualification, registrar auditor qualifications, certificates, and upgrading of registrar accreditation to include TL 9000. These requirements will apply to all QuEST Forum-recognized accreditation bodies and the registrars qualified by these accreditation bodies to conduct TL 9000 registrations.

Accredited registrars shall: 1.1 Provide accreditation bodies with written agreement to conduct TL 9000 registrations in

conformance with “Code of Practice for TL 9000 Registrars,” formerly Appendix B.

1.2 Provide accreditation bodies, prior to beginning TL 9000 registrations, relevant documentation showing that the registrars’ process conforms to document “Code of Practice for TL 9000 Registrars,” formerly Appendix B, and the registrar requirements in these appendices.

1.3 Maintain a listing of their TL 9000 qualified auditors.

1.4 Have personnel on the governing board/council of experts that have telecommunications industry experience, as well as expertise in the specific scope, as defined by the current accreditation body practice.

1.5 Have at least one member of the registration decision making body who has successfully completed and passed the exam of the sector-specific training. This member shall have veto power with regard to TL 9000 registration decisions.

1.6 Utilize auditors that meet the requirements specified in document “Qualifications and Experience Requirements for TL 9000 Registrar Auditors,” formerly Appendix g.

1.7 Utilize an audit team, which has at least one member with relevant experience in the telecommunications industry (see document “Qualifications and Experience Requirements For TL 9000 Registrar Auditors,” formerly Appendix G).

1.8 Use the TL 9000 notation on certificates only after the accreditation body has witnessed and approved a registrar’s TL 9000 audit.

1.9 Be permitted, after the witness audit has been satisfactorily completed, to update the ISO 9001 certificates to TL 9000 certificates of previously assessed companies who were found to be in conformance with TL 9000. The registrar shall obtain a witness audit within three months or six audits of their initial TL 9000 audit and shall be subject to 2.2 below.

1.10 Where the registrar does not satisfactorily complete the witness audit, the registrar shall be responsible for remedies for any previously assessed companies appropriate to the content and severity of the problems discovered, and as agreed by the accreditation body. No additional TL 9000 audits shall be permitted until the accreditation body accepts the registrar’s corrective actions.

1.11 Be permitted to use a full TL 9000 or an ISO 9001 upgrade to TL 9000 as a witness audit.

Copyright 2006 by QuEST Forum Effective June 30, 2006

Page 1 of 2

TL 9000 Accreditation Body Implementation Requirements

1.12 Provide certificates of registration to TL 9000 compliant organizations citing conformance to TL 9000 and the ISO 9001:2000 standard.

1.13 Define delisting criteria, and steps for delisting registrants.

1.14 Be responsible for remedies for any TL 9000 registrants affected by the delisting of the registrar by the accreditation body, appropriate to the severity of the problems discovered. The accreditation body shall agree on these remedies.

1.15 Provide transition support for future TL 9000 releases consistent with the QuEST Forum’s guidance and transition plan.

Accreditation bodies shall: 2.1 Establish agreements with the QuEST Forum through a Memorandum of Understanding to

adhere to the criteria for recognition set forth by the QuEST Forum.

2.2 Be responsible for providing an auditor (audit team) to witness one of the initial six TL 9000 audits of any ISO 9001 accredited registrar completing items 1.1 and 1.2 above. The accreditation body shall notify the QuEST Forum Administrator of the date when each registrar has successfully completed the witness audit.

2.3 Be responsible in the conduct of witnessing for utilizing any outside experts or observers needed. This responsibility shall include avoidance of conflict of interest, availability, and timeliness.

2.4 Define: a) delisting criteria, and steps for delisting TL 9000 qualified registrars, and b) an appropriate process for appeal of a witnessing decision or any other steps in the TL 9000

process.

2.5 Maintain a TL 9000 Qualified Registrar Listing kept up-to-date and distributed to the QuEST Forum Administrator whenever the listing changes. These lists shall note new additions or deletions from previous revisions. Notice of loss of accreditation shall be formally communicated promptly to the QuEST Forum Administrator.

2.6 Provide a certificate, or similar formal notification, that can be used to document the registrar’s qualification, to each qualified TL 9000 registrar who has met all requirements of TL 9000 (see “Code of Practice for TL 9000 Registrars,” formerly Appendix B, and this document).

2.7 Provide transition support for future TL 9000 releases consistent with the QuEST Forum’s guidance and transition plan.

The QuEST Forum shall: 3.1 Establish the Forum Administrator as the central point of contact to act as the clearinghouse for

all inquiries, accreditation, registrar and certification-related items, issues and concerns.

3.2 Share appropriate TL 9000 communications with their recognized accreditation bodies.

3.3 Recognize any accreditation body that is a signatory to the International Accreditation Forum (IAF) Multi Lateral Agreement (MLA) subject to establishing agreements with the QuEST Forum through a Memorandum of Understanding to adhere to the criteria for recognition set forth by the QuEST Forum. These accreditation bodies must implement a mutual recognition of each other’s witness audits, in support of TL 9000.

3.4 Provide guidance and a transition plan for the introduction of future TL 9000 releases.


Page 2 of 2

Code of Practice for TL 9000 Registrars

This document is a product of the Oversight Work Group of the QuEST Forum. It was formerly published in the TL 9000 Quality Management System Requirements Handbook as Appendix B and is subject to change by the Oversight Work Group with the latest version always appearing here.

Code of Practice for TL 9000 Registrars The registrars must be accredited by a body recognized by the QuEST Forum. The registrar’s scope of accreditation shall cover the activity being registered (i.e., Hardware, Software, or Services, or any combination). Recognized accreditation bodies are listed on the TL 9000 website (visit tl9000.org).

The assessment shall include evaluation of all organization quality management system elements for effective implementation of TL 9000 requirements within the scope of registration.

For each three-year interval, 100% of the entire scope of the organization being registered and all applicable TL 9000 requirements and measurements shall be assessed. The Audit Report shall clearly show the part of the system that was audited on each surveillance visit.

The audit team shall provide a full report on the operation audited per Model B of the current RvA publication, Guideline for Compiling Reports on Quality System Audits, to the company within 45 days of each initial and surveillance (partial) audit unless otherwise agreed by the company. Third-party auditors will identify nonconformances and opportunities for improvement, as these become evident during the audit, without recommending specific solutions. These nonconformances and opportunities shall be included in the report to the company.

Registrars, or bodies related to a registrar, that have provided quality management system consulting services and/or private training to a particular client may not conduct registration services for that client, nor may they supply auditors.

Each member of the registrar’s team performing audits to TL 9000 requirements shall have satisfactorily completed the TL 9000 auditor course that has been approved by the QuEST Forum. Also, a majority of those responsible for making certification decisions, or at least one with veto authority, shall satisfactorily complete this training. A certificate will indicate satisfactory completion.

Quality management system consultants to the organization, if present during the assessment, are limited to the role of observer.

All structural or systemic nonconformances shall be resolved prior to the issuance of the TL 9000 certificate. All nonconformances are handled in accordance with the registrar’s standard operating procedure(s).

Registrars are authorized to cite conformance to TL 9000 on ISO certificates, when they: a) contract with an organization to follow this Code of Practice, and b) are accredited by a QuEST Forum-recognized accreditation body to issue TL 9000 certificates. The registrar must have a process to settle disputes over interpretations of the standard.


Page 1 of 1

Registration Guidance

This document is a product of the Oversight Work Group of the QuEST Forum. It was formerly published in the TL 9000 Quality Management System Requirements Handbook as Appendix C and is subject to change by the Oversight Work Group with the latest version always appearing here.

Registration Guidance An organization should address the following key steps when it is considering TL 9000 registration. a) Determine the scope of the registration. b) If not already in place, develop and implement a documented quality management system so that it

meets or exceeds the TL 9000 Quality management System. c) Conduct a self-assessment and implement any needed improvements to comply with the TL 9000

Quality Management System. d) Contract with a TL 9000 accredited registrar to conduct the registration in accordance with the

selected scope. e) Follow the registrar’s process of registration and surveillance audits to obtain and maintain the

TL 9000 registration. f) Guidance is also available on the TL 9000 website (visit tl9000.org).


Page 1 of 1

Migration Path, Audit Days, and Requirements Origin

This document is a product of the Oversight Work Group of the QuEST Forum. It was formerly published in the TL 9000 Quality Management System Requirements Handbook as Appendix D and is subject to change by the Oversight Work Group with the latest version always appearing here.

Migration Path, Audit Days, and Requirements Origin The QuEST Forum recognizes the achievement of existing quality management systems efforts. These efforts will be leveraged in the migration path to TL 9000. To follow any of the migration paths below, the TL 9000 candidate must have a current registration to a recognized Quality Management System. The scope of the existing registration shall be compared to the scope of the TL 9000 registration being sought. Additions to the existing scope must be assessed to the TL 9000 requirements.

The following Quality Management System registrations are currently recognized: a) ISO 9001:2000, b) TS 16949, and c) AS9100.

TS 16949 and AS9100 registrations will be treated the same as ISO registrations.

Other quality management systems will be recognized as necessary.

Migration Paths This migration process is to be used only during the initial registration process. Subsequent assessment activities will be conducted per standard registration procedures.

To migrate from ISO 9001:2000 or other quality management systems to TL 9000 Requirements Release 4.0, the organization shall conform to all TL 9000 additional requirements and measurements applicable within the scope of the TL 9000 registration.

Audit Days Table The Audit Days Table defines the minimum number of on-site audit-days needed to perform a comprehensive TL 9000 audit. The most current version of the table is available on the TL 9000 website (visit tl9000.org).

The table shows the minimum number of on-site audit days that should be spent by the registrar on the initial TL 9000/ISO 9001:2000 quality management system audits and ongoing surveillance audits.

Registrars will document actual audit days. Any deviation greater than 0.5 on-site auditor days under the minimum on-site audit days total is to be documented and submitted to the registrar’s accreditation body within five working days after the quotation date. No certificate for TL 9000 is to be issued until the submitted deviation has been concurred to in writing by the accreditation body. The audit can proceed but the registrar shall advise the organization of the risk involved if the accreditation body requires additional audit days.

The accreditation body shall respond within 10 working days of receipt of the registrar’s written request for reducing the minimum on-site audit days. The accreditation body will confirm its written agreement or rejection.

Use of the TL 9000 Release 4.0 Migration Path and Audit Days table by registrars is effective immediately on release and remains in effect until modified by the QuEST Forum. The most current version of the table is available on the TL 9000 website (visit tl9000.org).


Page 1 of 2

Migration Path, Audit Days, and Requirements Origin

Requirements Origin Table See the TL 9000 website (visit tl9000.org) Requirements Origin Table for changes to the requirements’ history from release to release.


Page 2 of 2

Alternative Method for Maintaining TL 9000 Registration

This document is a product of the Oversight Work Group of the QuEST Forum. It was formerly published in the TL 9000 Quality Management System Requirements Handbook as Appendix E and is subject to change by the Oversight Work Group with the latest version always appearing here.

Alternative Method for Maintaining TL 9000 Certification/Registration This alternative method for maintaining TL 9000 certification/registration is taken from the International Accreditation Forum, Working Group III, January 21, 1998.

Objectives and Principles The “Alternative Method for Maintaining TL 9000 Certification/Registration” (AM) is a method to determine if an organization’s quality management system meets the ISO 9001 criteria to warrant continuation of an accredited certification by a third party (see Figure E-1). The method is based on utilizing the organization’s (first party) internal audit system as a complement to the certifier’s/registrar’s (third party) own assessment activities.

Certification Body/ Registrar

Organization Organization Audits

Customer/ Consumer

Accreditation Body

Supervision

Third Party Audits

Parties Concerned

Certification/Registration

Figure E-1 – Alternative Accreditation Process

The objectives are elimination of unnecessary audit duplication and improving the effectiveness of third party TL 9000 audits and certification/registration. Higher value can be achieved by increasing benefits or


Page 1 of 4


decreasing costs to customers. However, the primary goal is not to decrease costs but is to add value when compared to other more traditional methods of third party auditing. The aim is more added value compared to other methods of third-party auditing.

Advantages to the organization are: • recognition of a common and consistently implemented quality management system, • reduced costs of maintaining certification/registration as a result of:

- reduced on-site days of certifiers/registrars, - site sampling which reduces plant interruptions, and - enhanced monitoring of internal audits by certifiers/registrars,

• more robust internal audit system, and • improved communication among certifiers/registrars and registered organizations.

Advantages to third parties are: • improving effectiveness of third-party auditing, and • in depth auditing possible by monitoring internal audits.

0% Use of Internal Audits 100% 0%

100%

Use

of T

hird

Par

ty A

udits

Third Party Audits

Internal Audits

Figure E-2 – Internal Audits

The extent to which internal audit results are taken into account depends on a number of factors such as the structure of the quality organization, the maturity of the quality management system, and the possibility for verification by the certification body/registrar. When appropriate, existing guidelines for sampling may apply in external audits.


Page 2 of 4


The AM approach is applicable only if a number of requirements (qualification/eligibility criteria) have been met by the organization and can be verified by the certification body/registrar. The AM approach is in general:

• available to any organization that meets the qualification criteria, without any discrimination with respect to size of sites, number of sites or sector of industry,

• restricted to third-party surveillance and re-assessment audits, and • applicable only if:

a) the organization’s quality management system fully conforms to all TL 9000 requirements as determined by an accredited third-party registrar,

b) the organization’s internal audit system is effective and its results accurately reflect the actual status of the quality management system and its conformance to TL 9000,

c) the organization is capable of demonstrating with its management review that the management is in full control and command of goals/objectives and routinely takes adequate preventive and corrective actions, and

d) independent third-party auditing is utilized to assure the impartiality and effectiveness of the organization’s internal audits.

Qualification/Eligibility Criteria for Organizations The organization must have a quality management system in conformance with TL 9000 for a period of at least three years. Accredited certification/registration meets the intent of this requirement.

The organization shall demonstrate customer satisfaction within its industry of operation, by: • customer satisfaction responses, and • acceptable delivered quality, warranty/customer returns and delivery.

The organization can demonstrate having a centrally coordinated system for: • internal auditing which adheres to ISO 19011-2002, and • corrective and preventive actions based on audit results and customer complaints.

The organization’s management shall demonstrate its commitment to quality and continual improvement of quality objectives and results in a quantified way over a period of time exceeding two years.

Internal auditors should have a sufficient background in the activities they evaluate and a good knowledge of the applicable procedures.

Qualification Assessment by Certification Body/Registrar As a first step in the application of the AM approach, the accredited certification body/registrar will carry out a qualification assessment in which the qualification criteria are verified.

The certification body/registrar reserves the right to select the audit sites and TL 9000 elements to be sampled.

In the verification of the criteria, the certification body/registrar looks for evidence of effectiveness of the organization’s quality performance over the last three years. This evidence shall be gathered based on earlier surveillance audit results, results from independent customer satisfaction surveys, and customer complaints.

The certification body/registrar shall have access to results of all phases of the management control process for quality, including results of management reviews and corrective and preventive actions. The auditing results will be reviewed by the certification body/registrar.

In addition, the certification body/registrar investigates and verifies the effectiveness of the organization’s internal audit system and the conformance to the relevant criteria, namely:


Page 3 of 4


The organization must have an effective internal audit system in which audit teams are independent from the unit/activity to be audited to avoid conflicts of interest.

• Internal audits shall regularly cover all requirements of TL 9000. • Internal audits shall be scheduled on the basis of the status and importance of the activities. • Internal audits shall be carried out in accordance with ISO 19011-2002. • Internal lead auditors shall be qualified in accordance with ISO 19011-2002 by an external

independent organization.

Qualification/Eligibility Criteria for Certification Bodies/Registrars In order to utilize the AM approach, the certification body/registrar must be able to design an approach that meets the unique requirements of the organization’s quality management system. The design process of the certification body/registrar must operate in full conformance to TL 9000. The accreditation body may verify the design capability of the certification body/registrar.

In principle, the qualification criteria for registrars who want to apply the AM approach can be derived from qualification criteria for the organization if:

• the certification body/registrar has been accredited in accordance with ISO/IEC Guide 62 (EN 45012) requirements for at least three years,

• the certification body/registrar can demonstrate improvement of service quality objectives and results over a period of three years.

If the certification body/registrar finds evidence that any of the requirements of the AM program, or its implementation thereof, are not being satisfied (or no longer being satisfied), then the AM program shall be suspended. The certification body/registrar shall then apply its normal procedures with full audit coverage of all sites and activities of the organization. This option, on the part of the registrar, is to be incorporated in a contractual agreement.

When appropriate, existing IAF guidelines (e.g., for sampling rates) will be applied in the AM audit program of the certification body/registrar. The design of the AM audit program will be different for each case, because it must be tailored to the specific circumstances.


Page 4 of 4

Guidance for Communication with Customers

This document is a product of the Oversight Work Group of the QuEST Forum. It was formerly published in the TL 9000 Quality Management System Requirements Handbook as Appendix F and is subject to change by the Oversight Work Group with the latest version always appearing here.

Guidance for Communication with Customers Included below are four sample approaches that may be used to establish mutually-beneficial communications between the organization and its customers. Other approaches may be applicable to an organization’s business situation. In addition, guidance on customer communications directly related to design process measures is contained in document, Set Up and Operation of a Design Process Measurement, formerly referred to as Appendix H.

Approach A – Shared Expectations Team One approach to communications is a voluntary shared expectations process. This is a process in which a single organization works jointly with a customer to create an understanding of each other’s expectations and improve quality on a continuing basis. The objective is a closer, long-term relationship between the two participants.

A joint team of the organization and customer personnel is formed to review expectations, identify gaps, and create the mechanism for reducing the gaps. An impartial, telecommunications-experienced facilitator may be added to the team when agreed to by both the customer and the organization. The team develops action items and tracks them on an action item register. Often, action items are worked on by joint task forces. Costs are shared by the customer and the organization.

It is recommended that the team will meet at least twice a year. A number of tools are used for continual quality improvement, including the action item register and quality improvement methodologies. A typical agenda for the initial meeting may include:

a) customer expectations, b) organization expectations, c) comparison of current performance against expectations, d) identification of gaps, e) development of action plans to address the gaps, and f) definition of measures to track and monitor the action plans.

Approach B – Quality Review Meetings To facilitate communications, the customer and the organization are encouraged to meet periodically to discuss the organization's quality management system. It is recommended that meetings alternate between the organization location and customer site where equipment furnished by the organization is in operation.

Organization’s Location

A sample meeting agenda for the organization’s location meeting may include: a) nonconformances to TL 9000, b) sample of internal audit reports and related improvement actions, c) measurements, d) engineering complaints, e) product change notices, f) customer concerns, g) organization concerns, and h) action item registers.


Page 1 of 2

Guidance for Communication with Customers

Customer Site Visit

Meet at a customer site where the organization's equipment has been operating for less than one year (preferably 3 to 6 months). All customer functions that were directly involved with the engineering, procurement, installation, activation, and operation of the equipment are invited to participate along with the organization representatives, which may include the program and/or product managers, quality and sales representatives, and others as appropriate.

The purpose of the visit is to obtain feedback on the entire process of procuring and operating equipment plus related services. Based on customer participants, the feedback would address some or all of the following:

a) quality and reliability of hardware and software, b) ease of ordering, c) organization representatives, d) new product introduction, e) product delivery, f) technical support, g) documentation, h) product change notices, i) invoices, j) installation, k) repair, and l) training.

Other customer or supplier organization concerns should be discussed as well as a review/update to the action item register.

The feedback obtained in this visit should be documented and any issues included in an action item register with planned improvement actions by the organization and/or customer.

Approach C – Customized Reports The organization provides periodic reports based on customer-identified needs. Such reports may include:

a) hardware return rates, b) delivery performance, c) repair turnaround time, d) reported problems, and e) technical support activity.

Approach D – Program Reviews Conduct periodic program reviews at customer or organization locations with an agenda that may include:

a) current deliveries, b) forecast of future requirements, c) technical issues, d) product feature requests/needs, e) quality issues, f) ordering/invoicing issues, g) improvement opportunities relative to supplied products, and h) the customer and organization interface.

The action item register should be maintained and action items reported during each review or more often, if appropriate.


Page 2 of 2

Qualification and Experience Requirements for TL 9000 Registrar Auditors

This document is a product of the Oversight Work Group of the QuEST Forum. It was formerly published in the TL 9000 Quality Management System Requirements Handbook as Appendix G and is subject to change by the Oversight Work Group with the latest version always appearing here.

Qualifications and Experience Requirements For TL 9000 Registrar Auditors Approved Auditors Auditors of quality management systems shall, at a minimum, meet the education, training, work experience, audit experience of ISO 19011-2002, and have the following:

• Auditing Experience – Participation in at least four audits for a minimum of 20 days that cover all the elements of the ISO 9000 series standards within the last three years and have the ability to cover all the elements as determined by the audit program manager or equivalent person.

• Continuing Education – Conform to the registrar’s requirements for maintenance of qualifications which must include the current version of the TL 9000 Quality Management System Requirements Handbook and TL 9000 Quality Management System Measurements Handbook.

Telecommunications Industry Qualification For auditors to be TL 9000 qualified, they must:

• meet the requirements for approved auditors noted above, and • have successfully completed and passed the QuEST Forum sanctioned TL 9000 Quality

Management System Auditing Training. In addition, at least one team member must:

• have at least two years within the last 10 years of relevant workplace experience (as defined by the appropriate Nomenclature des Activities Economiques (NACE) code or equivalent method used by the registrar) in the Telecommunications industry directly involved in Engineering, Design, Manufacturing, Quality and/or Process Control for a Telecommunications Service Provider, or a 1st or 2nd tier supplier, or

• have 20 days of on-site auditing experience within the last two years in the NACE code relevant to the telecommunications organization being audited.


Page 1 of 1

Set Up and Operation of a Design Process Measurement System

This document is a product of the Oversight Work Group of the QuEST Forum. It was never published in the TL 9000 Quality Management System Requirements Handbook and is known informally as Appendix H. It is subject to change by the Oversight Work Group with the latest version always appearing here.

Set Up and Operation of a Design Process Measurement System Included below is guidance for the selection and implementation of design process measurements.

The Process Measurement System A process (see Glossary) is a set of activities that transforms inputs into outputs; a project is a unique occurrence of a process, with start and finish dates and with a specific goal to accomplish. Although the following discussion will focus on projects, it can easily apply to processes as well.

Usage of a process measurement system is an essential method to effectively monitor, manage and improve projects; the purpose of a measurement system is to help managers make better decisions.

Many good design process measurement models and guidebooks are available today, often supported by Users Groups or Support Centers (see references). Most models identify a few basic elements for an organization willing to set up and operate its own process measurement system:

1) Define a set of measurements for the project at hand; this element is completed when a suitable measurement set is specified.

2) Put in place methods and tools to collect and report the selected measurements; this element is completed when measurement reports are issued on a regular basis;

3) Employ measurement results to help manage and improve the project; this element is completed when a number of management actions and improvement initiatives are routinely identified and implemented based on measurement analysis.

In addition, many models explicitly suggest to systematically improve the measurement system itself, according to the organizational needs; this task is an ongoing effort that ensures the continued effectiveness of the measurement system.

Tailoring Measurements Element 1 (the choice of a measurement set) is crucial to the success of the process measurement system, as a poor choice of the measurements to collect and analyze can easily jeopardize the effectiveness of the whole measurement effort.

Many aspects of a project can be measured such as costs, duration, inputs, outputs, defects, or adherence to plans. The problem is, there are too many possible measurements to collect them all in an economically feasible way and, more importantly, the usefulness of many measurements depends on the goals and perspective of the measurement users, and from the relevant issues of the specific project.

Since these goals, perspectives and issues are not necessarily fixed, but may vary from project to project, the need arises to clearly establish the goals of the measurement activities and then derive from these goals a suitable and economical measurement set. In summary, the organization has to tailor the measurements in order to fit them to the specific project characteristics and needs.


Page 1 of 4


Tailoring means: • selecting a subset of measurements from a recommended measurement set; • if needed, modifying individual measurements in the selected subset, e.g. changing the way of

reporting, or changing some data definitions or formulas, or using the measurement only partially; For instance, for a given project the ‘milestone delay’ measurement could be selected from the recommended set, but it could be reported in the way of Milestone Trend Analysis (a graphical way) or as a list of delays per day or per week. Moreover, the reporting schedule for milestone delay could be different in different projects.

• if needed, adding new measurements to the selected subset.

Experience has shown that several factors can influence, to different degrees, the tailoring of measurements; the most important factors appear to be specific business goals and specific requests to measure or predict quality.

Other factors include: • size, complexity and lead time of the specific project; • availability of support tools, or existing current practices in the organization; • needs for problem detection, project status tracking and process quality monitoring; • needs for joint reviews, and/or regular reporting from organization to customer.

Useful guidance on tailoring measurements can be found in the references; among them, the GQM (Goal Question Metric) and PSM (Practical Software and Systems Measurement) methods put special emphasis on the tailoring process as the starting point of the measurement activities.

Collecting, Reporting and Analyzing Measurements Elements 2 and 3 of the measurement system contribute to implement the measurements selected in the tailoring process (element 1).

Collecting and reporting measurements is the technical part of the measurement effort, which requires adequate tools and needs to be integrated into the project life cycle activities.

The availability, timeliness, consistency, completeness and accuracy of the data determine the value of the resulting information. Moreover, the lag time between collecting and reporting should be as short as possible, so online access to the project databases is the preferred method of collecting project data.

Measurement analysis, on the other hand, is what enables the organization to reap the benefits of the investments made in the measurement system.

The analysis step should integrate quantitative measurements results and other qualitative project information, in order to provide managers the feedback needed for effective decision making.

Useful guidance on collecting, reporting and analyzing measurements can be found in the references; among them, the PSM guidebook is especially rich and informative.

The next two sections are devoted to a short presentation of GQM and PSM; GQM has been the first methodology to recognize the role of tailoring, and PSM is probably the best guidance currently available on every aspect of a measurement system.

Goal Question Metric The GQM (Goal Question Metric) method originated in the early 1980s from the efforts of a number of researchers, led by V. R. Basili. They came to reject the notion of fixed sets of measurements, in favor of a method to help tailor measurements to specific organizational goals and environments.


Page 2 of 4


Since these goals and environments will be extremely varied, so will necessarily be the selected measurements; the starting point for the measurement activities should be "What is the purpose of measurement?", and not "What measurements should we use?".

Identification of an explicit measurement goal is the cornerstone to GQM. This goal is then refined into several questions, and each question helps select measurements that provide information to answer that question.

As the measurements were defined with an explicit goal in mind, the information provided by the measurements will then be interpreted and analyzed with respect to that goal.

Practical Software and Systems Measurement Practical Software and System Measurement (PSM) is sponsored by the Department of Defense and US Army. The goal of the project is to provide Project Managers with the objective information needed to successfully meet cost, schedule, and technical objectives on projects.

PSM allows managers to identify the issues that are important to their projects, then implement a measurement program designed to provide insight into those issues throughout the project life.

Issues are areas of concern that may impact the achievement of a project objective; issues include problems, risks, and lack of information.

Useful issue sources could be risk assessments, project constraints and assumptions, leveraged technologies, product acceptance criteria, external requirements and, of course, the project team’s experience with similar projects.

Once the project specific issues have been identified, the next step is to map them to the PSM common issue areas. The seven common issue areas included in PSM are:

• Schedule and Progress • Resources and Cost • Product Size and Stability • Product Quality

• Process Performance • Technology Effectiveness • Customer Satisfaction

Common issue areas are then the entry points to the Measurement Selection and Specification Tables; these tables help select measurements from the basic PSM measurement set, comprising some twenty measurements categories and more than fifty individual measurements.

However, the choice is not limited to this recommended measurement set; it is possible to modify existing measurements, and even add completely new measurements.

PSM provides a free Guidebook and a free software tool, PSM Insight, to support the tailoring process and the measurement activities.

Within this tool, PSM’s common issue areas, categories and measurements can be used, or the measurement analyst can develop new measurements to meet project information needs.

Data can be entered via the tool’s customizable data entry screens or can be imported from a number of other sources. Once data is loaded into PSM Insight, its analysis capabilities can be used to generate measurement indicators, analyze and track trends, and report findings.

Customer Communications In the scope of a specific project the organization provides periodic design process measurement reports.

To understand the reports, the customer needs knowledge of the organization's development and/or production process and the applied measurement process.


Page 3 of 4


Usage of reported data:

The purpose of these reports is to provide visibility to the customer about the implementation status and the quality of the product to be delivered.

The reporting process should help the organization to understand the customer needs such as quality requirements, time to market schedule, etc.

In case of deviations from agreed targets, analysis reports should be provided and corrective actions are jointly to be agreed and implemented.

Selection of measurements for bilateral reporting:

Prior to the start of the project a suitable set of design process measurements is selected from the organization’s available set of TL 9000 design process measurements.

Customer requirements and needs shall be known before the design process measurement reporting will be implemented.

Design process measurement reports may include: a) number of tests performed versus planned b) number of faults detected and corrected per phase c) phase transition monitoring data d) internal milestones (achievement/delay)

References Models, standards and guidebooks on Process Measurement Systems: a) PSM - Practical Software and Systems Measurement (Department of Defense and US Army) b) the GQM website at Delft University of Technology (Holland) (visit www.gqm.nl) c) Systems Engineering Measurement Primer (INCOSE - International Council on Systems Engineering) d) ISO/IEC 15939 - Software Measurement Process Framework

(ISO/IEC JTC1/SC7 Software and Systems Engineering) e) CMMI for Systems and SW Engineering - Measurement and Analysis

(Carnegie Mellon University - Software Engineering Institute) f) IPQM - In-Process Quality Metrics Generic Requirements (GR-1315) (Telcordia, formerly Bellcore) g) Ideas and contributions from EIRUS (the European IPQM & RQMS Users Group, now merged with

QuEST Forum) have been incorporated in this document

Other references on GQM: h) a GQM overview by Prof. Martin Shepperd of ESERG (Empirical SW Engineering Research Group)

at Bournemouth University (UK): dec.bournemouth.ac.uk/ESERG/mshepperd/SEMGQM.html i) the Software Engineering Laboratory at NASA GSFC: (visit sel.gsfc.nasa.gov/website/exp-

factory/gqm.htm)

Other references on PSM: j) the PSM Support Center website (visit www.psmsc.com) k) Practical Software Measurement: Objective Information for Decision Makers

(John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean and Fred Hall – Addison-Wesley 2002)


Page 4 of 4

TL9000认证机构实施QuEST Forum TL9000质量管理体系测量 … ·...

Documents

Transcript of TL9000认证机构实施QuEST Forum TL9000质量管理体系测量 … ·...