TL9000测量手册.doc

1、11.简介TL9000 手册（TL9000 质量管理体系要求手册和 TL9000 质量管理体系测量手册）是专门为电信业设计的文件化的行业质量管理体系要求和测量。TL9000 质量管理体系要求手册包含 4 个主要的部分及附录。手册为提供硬件、软件和服务这些电信产品的供方建立了一套通用的质量管理体系要求。本要求是在已存在的行业标准（包括 ISO9001）的基础上建立起来的。TL9000 质量管理体系测量手册建立了最小的一套绩效测量。所选择的测量方法用于测量供方的改进以及评价质量管理体系实施的效果。1.1目标TL9000 的目标是：建立质量管理体系以有效地保护电信产品（包括硬件、软件或服务）的完整性

2、和使用性建立并保持一套基本的质量管理体系要求减少电信质量管理体系标准的数目定义有效成本和绩效测量，以指导改进和评价质量管理体系实施的效果推动持续改进加强顾客一供方之间的关系促进行业遵从一致的评估过程1.2 目的TL9000 的目的是定义了电信产品（包括硬件，软件或服务）的设计、开发、生产、交付、安装和维护的质量管理体系要求。包含在 TL9000 中，以绩效为基础，测量这些产品的可靠性和质量绩效。长期目标还包括成本和以绩效为基础的测量。1.3实施的益处电信服务的供方，他们的用户和所有的顾客都会从 TL9000 的实施中受益。所期望的益处是：2对用户服务的持续改进加强顾客和供方的关系质量管理体系要

3、求的标准化外审和现场访问的有效管理统一的测量全面成本减少并且增加竞争力加强管理并改进供方绩效用 TL9000 测量进行行业比较1.4 与 ISO9001和其他要求之间的关系探索论坛维持同其他要求和标准的相容性。TL9000 是在 ISO9001：1994框架的基础上建立起来的一套电信业特殊要求，在 TL9000 开发的过程中，所考虑的标准和要求请参见其目录。TL9001 同其他要求的关系特征是：TL9000 包括 ISO9001：1994。而且还包括 ISO9001 未来的任何修订符合 TL9000 即符合相必须的 ISO9001 要求探索论坛的意图是符合 TL9000 将免除符合多种电信质量

4、管理标准的要求。1.5手册的开发和维护探索论坛负责开发、出版、发行和维护可以公开获得的 TL9000 手册，随着 TL9000 手册发行后出现的任何更改要提交探索论坛管理者。本手册的任何使用者都可以提交更改要求。更该要求将由论坛管理者递交给相必须的手册部门负责人，并将在下一次修订中考虑。更改的要求/ 反馈表编排在本手册的后面。TL9000 手册的所有变更，都要经过探索论坛的投票成员按论坛要求投票通过，才能最终批准。TL9000 手册的再发行由论坛决定，但再发行不会超过最近发行时间 5 年。当论坛决定 TL9000 的发行影响第三方注册时，那么附加活动或类似的沟通机制将用于为行业提供标准的纠正和

5、更新的信息。32.结构2.1.整体结构（看图 2.11）TL9000 的整体结构由如下几个层次构成1.国际标准 ISO90012.通用的 TL9000 要求3.硬件、软件和服务的特殊质量管理体系要求4.通用的 TL9000 测量5.硬件、软件和服务的特殊质量管理体系测量TL9000 模型国际标准 ISO9001通用的 TL9000 要求硬件特殊要求 软件特殊要求 服务特殊要求通用的 TL9000 测量硬件特殊的测量软件特殊的测量服务特殊的测量图 2.11 TL9000 模型除其他机构的版权材料外，探索论坛保留对内容的全面控制。在 TL9000 中有一些术语，如必须（Shall） ，应该（Sho

6、uld） ，可以（may） ，能（ can）与 IS9000 术语表中所定义的一样，单词必须（Shall）表示强制性的要求，单词应该（Should）表示首选的方法，选择其他方法的供方必须能够表明他们的方法满足 TL9000 的内容。在有单词典型（typical）和例子（examples）的地方，表示针对特殊的商品或过程是一个合适的选择。文中有注（NOTE ）的地方是指南而不是审核内容。TL900042.2.术语在本手册中所引用的术语主要是组织在 TL9000 的实施、符合和认证过程中所遇到的术语。2.3.测量的流程和用途图 2.21 显示出 TL9000 手册中质量管理体系测量的数据流程和用途

7、图 2.31 TL9000 测量数据流程和用法必须设计测量的应用以满足探索论坛为准则，这在 3.2 节中讲到：使用方法图 2.21 描述了通过顾客供方交互的方式以及 TL9000 所显示的信息来识别改进的机会所处的环境。a. 可以在供方和顾客之间用测量来设定相互目标以改进产品。这将有助于改进顾客和供方之间的关系，并且能建立最佳地满足双方需要的目标。b. TL9000 中有一些测量可以由独立的供方来改进测量，这些测量经过仔细的评审以决定这些测量是否真正具有可比性。这些测量由测量管理者所监控，以保证供方得出的简明统计是有效的和有意义的。简明统计定义将按需要进行供方顾客持续改进程序探索论坛网站测量储

8、存体系（MRS）MRS 报告TL9000 数据行业统计5修订。这些测量的定义包括指定“比较数据” 。c. 其他测量包括定义“研究数据” ， 研究数据不能用作比较的目的。但是，测量管理者将分析数据用来显示可能的行业趋向，这些分析仅供制定测量的工作组以备未来可能用来进行检查。d. 当每个供方按简明统计方法比较其测量时，可改进产品绩效以改进供方的绩效。e. 探索论坛测量数据库并不倾向于用作供方的管理工具，而是作为数据贮存。数据库的输出包括从 TL9000 测量存贮系统（MRS）中针对产品所作的每一种测量而得出的统计简明报告。63.测量用法和职责3.1 测量使用的要求为了完全满足本手册的要求，组织必须

9、遵从本处所规定的测量要求a. 内部作为持续改进程序和管理报告的一部分b. 适当时，作为顾客组织交流和共同持续改进程序c. 认证时，向测量管理者报告3.2 测量的使用原则TL9000 注册要求执行 TL9000 质量管理体系要求，并且将用于 TL9000 注册的 TL9000 质量管理体系测量的具体数据报告给测量管理中心。下面这些处理和使用测量的原则意味着培养一种环境，以使顾客和供方能一起工作推动持续改进。a. 在测量适用表（附录 A、表格 A2）中所定义的产品类别适用测量都必须报告。b. 在注册范围内特殊测量的剪裁必须形成文件以表述剪裁原因，并可在认证机构和顾客要求时得到。c. 供方必须将 T

10、L9000 测量数据提供给测量管理中心，他们将编辑数据，并且计算产品类别的统计值，例如“行业平均值” “标准偏差” ， “中位数” 、 “极差” “数据点的数目”和“行业最佳” ，这些统计值对各产品类别都是合适的，测量管理中心产生的产品结果或报告将不会确定单一供方。d. 探索论坛的成员顾客必须提供 TL9000 领域所必须的绩效数据给供方，以计算特殊的测量。e. 顾客可以要求他们的供方提供 TL9000 的具体测量情况，通过协议，这种信息交流将严格发生在供方和顾客之间，任何情况下，论坛管理者和测量管理中心都不能涉及其中。f. 在探索论坛管理者没有对供方进行分级。g. 测量的运用不能局限于数据的

11、所有特性。3.3 测量使用的原则7TL9000 测量使用的意图是：a. 提供适合于比较的行业绩效的信息。b. 改进电信过程和产品。c. 识别顾客供方改进机会。d. 标准化顾客报告卡或评价。3.4 测量数据集合和顾客库3.4.1.产品集合如果供方希望在同一产品类中认证多个产品并且在各自的认证范围内清楚地识别他们，那么供方也许要分别给每个产品报告数据。同理，如果一个供方认证一个商业单位或地点，那供方有权决定认证哪一个产品，以及数据如何收集。3.4.2 顾客库a. 顾客库指的是供方测量数据所包含的一组定义的顾客。顾客库必须具备如下条件：（1）论坛成员：仅仅是探索论坛的成员的供方顾客。（2）全部：测量

12、适用的产品所针对的所有顾客供方。b. 在每一次测量数据提交时，针对测量表格中指定的每一个测量都必须报告顾客库。c. 供方必须针对每一个单一的测量，报告来自一个顾客库的测量数据。3.5 职责3.5.1 论坛管理者职责论坛管理者必须a. 维护公司信息的安全和保密。b. 开发、实施、出版和保持定义 TL9000 测量过程的正确操作程序。c. 从测量管理者处接受“数据确认报告” ，并且将“数据确认报告”转发给供方。d. 与测量管理者的有遗失的数据或可疑数据的供方联系。8e. 保持成员数据库，包括认证和测量提交历史。f. 通过以下方式发布和保持行业报告统计值：（1）来自于全部顾客库的数据的产品类别（2）

13、仅来自探索论坛顾客库数据的产品类别。（3）对一个产品类别所有适用的数据（即 1 和 2）g. 通过探索论坛网站，提供和控制测量数据输出的访问。h. 对探索论坛管理者的相关操作开发和实施一个灾难性恢复计划。i. 支持外审或论坛管理者活动的监督。j. 当探索论坛网站上发布的附录 A“产品类别表 ”更新时，通知认证的供方和受影响的单位。3.5.2 测量管理者职责测量管理者必须：a. 维护数据的安全和保密。b. 开发、实施、发行和保持定义 TL9000 测量过程工具和技术的正式操作程序。c. 从供方处接受和确认数据，包括识别遗失数据或错误数据，并报告给论坛管理着。d. 计算行业统计数据，例如：“行业平

14、均值” “标准偏差” “中位值” “极差”“数据点数目”和“行业内最佳” 。适当时，通过产品类别对有可比较数据的每一种测量使用合适的数据单元。e. 通过下列方式计算行业统计：（1）来自于所有顾客库数据的产品类别。（2）仅来自于探索论坛顾客库数据的产品类别。（3）对一个产品类别中所有适用的数据（即 1 和 2） 。f. 记录可比较的数据，并且至少每季度将之输出到网页上。g. 开发和实施相关操作的灾难恢复计划。h. 支持外审或活动监督。i. 决定什么时候对每个测量产品类别收集充分的数据以发布统计后的正确结果。9j. 负责提供数据的准确表达。k. 创建并保持用户手册。l. 提供产品类别的集合，以产生

15、有意义的测量作为输入分析的结果。m. 分析“研究数据”以显示行业趋向、这些内容仅向测量工作组报告。n. 分析“研究数据”以确定是否有数据比较的条件，并且仅推荐给测量工作组以达到可比性。3.53.供方职责供方必须a. 建立文件化过程，以捕获和确认适用的测量数据，使源数据记录可以获得。b. 收集，确认和提交每一个指定的测量所定义的数据给测量管理者。c. 提交在认证范围内的测量数据。d. 向测量管理者提交至少连续 3 个月的数据，并且接受“数据确认报告” ，证实提交的有效性以获得 TL9000 认证。e. 提交在认证范围内的测量。f. 如果新产品在认证范围内，那么就要提供 6 个月内的产品总可用性测

16、量数据。g. 将内部测量同行业统计相比较，并在适当的时候采取措施改进产品和实践。h. 提供定期的 TL9000 质量管理体系测量报告给负有职责的管理者。i. 纠正任何矛盾数据。j. 在 2 年内提交的任何错误数据，要再提交纠正数据。3.5.4.顾客职责顾客必须：a. 提供必需的数据允许供方形成 TL9000 测量。b. 建立一个过程以捕获并确认适用的测量数据。c. 使用 TL9000 测量定义以标准化供方绩效评审过程（例如：报告卡）d. 建立顾客一供方联合改进小组以及基于 TL9000 测量的目标和其他所需要的绩效目标。10e. 当确定了生命周期成本时，考虑使用 TL9000 测量作为输入。3

17、.5.5.探索论坛职责a. 负责管理 TL9000 质量管理体系测量手册。b. 保证 TL9000 质量管理体系手册能公共获得，在探索论坛的指导下出版、分发和维护，并且保持其版权。c. 负责保证提供适当的培训以帮助用户正确地，一致地解释 TL9000 要求，并报告 TL9000 测量。d. 提供测量过程监督。e. 记录与测量过程有关的问题和内容，并向探索论坛提供摘要和建议。f. 评审由测量管理者提交的建议的产品类别集合。3.5.6.审核员职责在每次审核期间，审核员必须验证：a. 过程能保证数据对于 TL9000 质量管理体系测量的定义和要求来说是正确的和完整的。b. 所有供方的职责已满足。c.

18、 在审核员指定的时间内，所有测量的过程不符合已被纠正。114.通用测量要求4.1 测量清单标题 手册章节通用测量（C） 5问题报告数（NPR） （C ） 5.1问题报告修理响应时间（FRT） （C） 5.2和延误问题报告修理响应测量（OFR） （C ） 5.3按时交付（OTD） （C） 5.4硬件和软件测量（HS） 6系统中断测量（SO） （HS） 6.1硬件测量（H） 7返回率 7.1软件测量（S ） 8软件安装和维护 8.1版本应用终止（RAA） 8.1.5纠正补丁质量（CPQ）和特征补丁质量（FPQ） 8.1.6软件更新质量（SWU） 8.1.7服务测量（V） 9服务质量（SQ） 9.1

19、4.2 测量报告要求4.2.1 符合测量报告供方必须按本手册中文件所描述的那样对应用的产品类别生成测量数据，并向测量管理者（和有要求的顾客）发布此数据。测量数据必须符合相应文件12的要求。报告数据的变化必须符合附录 A 中新的高版本或新版本测量手册的要求，新版本的测量也必须在 6 个月内完成。注：数据表中带引号的文字是正确报告的变量字串。4.2.2 适用的产品类别对每一种产品，供方必须按附录 A 识别产品类别以及适用的测量。附录 A是这本手册版本当前的最新内容，参见探索论坛网址（WWW.questforum.org）可获得高版本（master）内容，高版本（master ）必须同认证联网，并将

20、所有数据提交到探索论坛数据库。4.3 测量数据和报告4.3.1 顾客源数据当顾客没有提供为测量所需要的数据时，不能要求供方向顾客报告测量结果。注：如果测量管理者没有要求供方提交数据，那么一定是供方的顾客没有提供所需要的信息。如果任何顾客的确提供此信息，则供方必须提交测量数据。4.3.2 可接受的可选的测量当测量文件中“报告和分发方法”的标题下表明 RQMS 作为替代报告是可接受的，则必须满足下列要求：a. RQMS 数据可接受性如果供方正在使用最新版本的 Telcordia 技术文件 GR929CORE，即电信系统的可靠性和质量测量（RQMS） ，来计算具体的测量。如果下面的条件满足，这些方法

21、和结果数据将替代 TL9000 的定义。（1）用于报告给探索论坛和其成员的数据包括 TL9000 所定义的所有可应用的数据，并且它不局限于 RQMS 客户公司的数据子集。（2）对于不隶属于 RQMS 报告的产品类别，必须使用 TL9000 的定义。b. TL9000 数据优先在所有情况中，TL9000 所定义的测量是优先选择的方法。如果供方的顾客没有一个要求供方产生 RQMS 报告，那么必须使用 TL9000 方法。供方在报告此测量时，必须说明使用的是何种方式。13注：当 RQMS 和 TL9000 测量都是合同要求时，RQMS 选择的测量其目的是通过供方使多余工作最小化，在那种情况下，符合性

22、审核将接受以 RQMS 为基础且与上列出的条件相符的程序作为这一测量的有效计算。4.3.3 报告频率和方法除非文件中有具体的规定，供方必须每月收集数据，并且每季度向探索论坛数据库报告一次所需要的结果。供方可以采用适合于向他的顾客及内部报告的任何时间周期和形式，每季度更新必须包括前 3 个月的新数据点。4.3.4 财务周期和日历天供方必须在日历月或定义的财务月基础上报告 TL9000 测量数据，供方必须一致地使用所选择的方法。供方必须在涉及到日历天的测量中使用日历天。4.3.5 比较数据和研究数据的报告供方必须按照认同的规则将本手册中所有适用的测量数据报告给测量管理者。这个报告要求适用于无论是供

23、方使用的 TL9000 方法或 RQMS 替换报告，并且无论测量中是否包括指定的“比较数据”或“研究数据” （RD） 。参见附录中表 A5。注：在文件交付和报告部分指定的“比较数据”意味着可以在论坛管理者处得到行业统计值。但是，指定的“研究数据”是得不到可比较的行业统计值的，并且测量管理者仅向探索论坛工作组报告行业趋势的分析。4.3.6.产品剪裁供方可以剪裁那些不再支持通用顾客库的产品数据，为了使这种剪裁得以必须用，必须使顾客得到“增加和维持（AM） “或” “制造终止（MD） ”状态下的产品分布的正式通知。4.3.7.测量适用性如果没有其他的说明，测量必须适用于在总可用性期间的产品。4.3.

24、8 标准化因子的计算标准化因子是转换能力的基础，例如 DS1，OC-1， DSL，或终端，计算应在正确的转换基础上进行。145.通用测量通用测量是适用于所有产品的测量：硬件、软件和服务。5.1 问题报告数（NPR） （C）5.1.1 一般描述和标题全部问题报告（抱怨）测量是在测量适用性表 A 2（标准形式）中具体说明的全部问题报告的测量。这种测量适合于 RQMS，并且必须用于所有产品。硬件（H） ，软件（S） ，和服务。5.1.2 目的测量的目的是测量由顾客引发的问题报告（抱怨）数，该数目能显示出产品在运行寿命周期内所交付的产品质量，这么做的目的是要降低问题报告数以及相关的成本和收入损失。问题

25、报告可能对供方、顾客产生负面影响（例如重复安排现场访问）并且可以减少最终用户的忠诚。5.1.3. 适用的产品类别此测量适用于附录 A 中的产品类别。5.1.4.详细的描述a. 术语如下用于 NPR 测量的术语的定义。 顾客 复制问题报告 总可用性（GA） 在用版本 信息要求（IR） 无故障发现（NTF） 正式修理 问题关键 H/S 问题主要 H/S 顾客问题一般 H/S 问题报告（PR）15 服务问题报告 严重级别 版本b. 计算规则（1）在硬件或软件情况下，涉及到任何和所有在用支持的发行版本相关的问题报告都必须计算在内。（2）在服务的情况下，在服务交付过程中或之后的任何正式的问题报告必须计算

26、在内。（3）仅仅由顾客引发的问题报告必须计算在内。（4）对于硬件或软件，在每种版本的总可用性之后，任何问题报告都必须计算，除非有另外的规定，不论它是否与软件，硬件、文本、无故障发现，程序，复制或其他等有关。（5）完全相同的问题报告，即同一时间，同一地点，同一问题同样发生的多个报告必须算作 1 个问题报告。（6）复制问题报告，即在不同顾客地点或在不同的时间发生的同样故障，每一个问题必须分别计算问题报告数。（7）记录在同一问题报告上的多个问题（在一个问题报告表或屏幕中）必须分别计算，除非顾客认为这些问题都与顾客经历的功能有相同的征兆相关。（8）常规的关于中断方面的问题报告，如服务功能分析报告（SF

27、AR） ，不能计算在内。（9）有关硬件和软件的问题报告必须按照问题的严重程度分级进行统计。（10） 临时修理，例如临时补丁或临时工作区，频繁用于解决关键的软件或硬件问题。正式的修理常常是在随后的或“追随”于涉及到原始的关键问题报告的主要和一般问题报告的情况下开发出来的。这种类型的关键问题报告不能重新分类，必须作为关键问题来报告，随后的主要或一般问题报告不能计算在内。（11） NPR 必须按照他们接受数据的当月进行统计。c. 计算规则剪裁16在统计 NPR 测量时，下面这些情况应该排除（1）在供方和顾客之间通过协议形成的有关信息要求或请求的问题报告（2）有关产品使用中采用了并不在供方和组织之间通

28、过协议而形成的产品规范中的方式而形成的问题报告。（3）有关常规事项的问题报告如：所期望的维护，正常的现场、可替换单元的返回，软件升级；（4）有关中断的常规报告，例如：服务失效分析报告（SFAR）d. 计算和公式（1）测量（见表 5.1-1 中的 NPR1，NPR2 ，NPR3 和 NPR4）必须每月计算：用附录 A 中所列的所有产品类别输入的问题报告总数，除以附录 A 中所列的标准因素。（2）在硬件和软件产品类别中，如果顾客不能容易地在使用因素中识别产品数量，将不能计算问题报告测量（NPR） 。还是要求供方去追溯问题报告的数目和他们的答案（在这种情况下，输入标准化因素=“无” ，见表 5.13

29、）（3）当对硬件和/或对软件报告 RQMS 可选测量时，供方必须引用表 5.1-2 中的 IPR1， IPR2 和 IPR3，以确定报告内容。符号：NU附录 A，表 A2 的标准化单位S 标准化因素；总的 NU 数NP1H/S 关键问题报告数NP2H/S 主要问题报告数NP3H/S 一般问题报告数NP4服务问题报告数17表 5.1-1 问题报告数（ NPR）测量标识符和公式标识符 名称 公式NPR1 每个 NU 的 H/S 关键问题报告 NP1/SNPR2 每个 NU 的 H/S 主要问题报告 NP2/SNPR3 每个 NU 的 H/S 一般问题报告 NP3/SNPR4 每个 NU 的服务问题

30、报告 NP4/S表 5.1-2 问题报告数RQMS 可选的测量（IPR ）标识符 名称IPR1 每个系统每个月输入的关键问题报告IPR2 每个系统每个月输入的主要问题报告IPR3 每个系统每个月输入的一般问题报告e. 报告的数据和格式（1）数据必须每个季度报告一次，每次报告必须包括该季度 3 个月的数据。（2）TL9000 数据 NPR 表（表 5.13）NPR 测量必须采用每个月和每个产品的数据单元（或等同于论坛管理者所定义的形式）进行报告。如下例：表 5.1-3 NPR 数据表年和月： YYYYMM报告 ID： 为论坛管理者所提供产品类别代号： （见附录 A）测量方法： TL9000顾客库

31、： （1）全部或（2）论坛成员标准化因素： S 或无年度因素： Afactor（见术语表）测量标识符： NPR18NPR1 分子： NP1NPR2 分子： NP2NPR3 分子： NP3NPR4 分子： NP4（3）RQMS 可选的数据表（5.1-4 ）RQMS 可选的测量必须采用每个月和每个产品类别的数据单元（或等同于测量管理者定义的形式）进行报告，如下例：表 5.1-4 RQMS 可选的 NPR 数据表（IPR）年和月： YYYYMM报告 ID： 由论坛管理者提供产品类别代码： （见附录 A）测量方法： RQMS顾客库： （1）全部或（2）论坛成员标准化因素： 在用系统的数目测量标识符：

32、IPRIPR1 分子： 输入的关键问题报告数IPR2 分子： 输入的主要问题报告数IPR3 分子： 输入的一般问题报告数5.1.5 数据来源NPR 测量的数据是从以下顾客提供的信息和供方的分析推导出来的。a. 顾客 向供方报告问题。 按照附录 A 中的产品类别表，向供方报告硬件或软件种类的标准化信息。b. 供方 根据产品类别和顾客库，计算报告问题，并且按照适当的规则转化为“问题报告数” 。19 对于服务产品，追溯和报告服务标准化单位。 计算标准化因素。5.1.6 交付或报告的方法a. 比较数据（CD）或研究数据（RD）每个 NU 的关键问题报告 CD每个 NU 的主要问题报告 CD每个 NU

33、的一般问题报告 CD每个 NU 的服务问题报告 CDb. RQMS 可选的报告每个 NU 的关键问题报告 是每个 NU 的主要问题报告 是每个 NU 的一般问题报告 是每个 NU 的服务问题报告 否5.1.7. 计算示例a. 例 1H/S 产品的 NPR（1） 假设一个特殊的运行支持系统（OSS）的供方将一个月的数据出售给探索论坛的成员和非成员，在整个月期内，有 30 个在用系统，并且NU 是“在用系统” 。（2） 报告数据显示在表 5.15表 5.15 例 1：NPR 数据报告年和月： YYYYMM报告 ID： 由论坛管理者提供产品类别代码： 4.2测量方法 TL9000顾客库： 全部标准化

34、因素： 30年度因素： 1220测量标识符： NPRNPR1 分子： 0NPR2 分子： 3NPR3 分子： 45NPR4 分子： NA（不适用）（3） 测量的计算为：表 5.1-6 例 1NPR 源数据和测量问题报告严重度Afactor年度因素标准化因素YYYMMM NPR测量（NPR1 ，2，3，4）0（ NP1） 关键 12 30 0 每个月每个系统的关键问题报告3（ NP2） 主要 12 30 1.2 每个系统每个月的主要问题报告45（ NP3） 一般 12 30 18 每个系统每个月的一般问题报告（ NP4） NA 服务问题报告不适用于此产品b. 例 2服务产品的 NPR（1）假设一

35、项特殊维护服务的供方将 1 个月的数据出售给探索论坛的成员和非成员，在整个月内有 20 个被维护的单位，并且 NU 是“在用单位” 。（2）表 5.1-7 显示的报告数据。表 5.1-7 例 2：NPR 数据报告年和月： YYYYMM报告 ID： 为论坛管理者提供产品类别代码： 7.3测量方法： TL9000顾客库： 全部标准化因素： 20年度因素： 12测量标示符： NPR21NPR1 分子： 不适用NPR2 分子： 不适用NPR3 分子： 不适用NPR4 分子： 30（3）测量的计算显示在表 5.1-8 中表 5.1-8 例 2：NPR 源数据和测量问题报告 等级 Afactor标准化因素

36、YYYYMM NPR测量（NPR1，2，3，4）（NP1） 关键 H/S 关键问题报告不适用于服务（NPR1）（NP2） 主要 H/S 主要问题报告不适用于本产品（NPR2）（NP3） 一般 H/S 一般问题报告不适用于本产品（NPR3）30（NP4）不适用于服务12 20 18每个月每个在用维护的单位出现 18 个服务问题报告5.2 问题报告修理响应时间（FRT） （C）5.2.1 一般描述和标题问题报告修理响应时间（FRT）是供方报告问题的总体响应，问题报告修理响应时间仅用于主要的和一般的硬件/软件（H/S）问题报告和所有服务问题报告，关键的 H/S 问题报告不包括在这些内容中，是因为关键

37、问题在关闭前，享有优先处理的权利。这些测量来源于 RQMS。5.2.2 目的22测量的目的是度量问题报告的响应，并且促进问题报告的迅速修理和关闭。5.2.3 适用的产品类别这些测量适用于附录 A 中所列的产品类别。5.2.4 详细的描述a 述语术语表包括了用于 FRT 测量的术语的定义 关闭标准 关闭日期 关闭间隔 修理 修理响应时间 正式的修理 延误问题报告 问题关键 H/S 问题主要 H/S 问题一般 H/S 问题报告 PR 严重级别 临时修理b 计算规则（1） 仅仅是顾客产生的问题报告，并且满足问题报告数量标准，必须包含在响应测量中。在 5.1.4.b 和 5.1.4.c 中所有的计算规

38、则和剪裁说明也适用于 FRT。（2） 计算 FRT 中间隔的时间起点必须从接受供方问题报告开始，如果问题的严重程度被重新分类，FRT 应从问题报告的接受开始算起。（3） 计算 FRT 间隔的时间终点必须是正式修理或关闭标准的生效日期，如果问题报告的最初指定者由于不完善或引起边际效应导致后来拒绝修理，那么问题报告必须被再分类为打开。（4） 对于 FRT，所统计的问题报告数是指当月应该关闭的问题报告数，而不是当月正在处理的问题报告数。23（5） 总 FRT 应按照修理应该被关闭的时间和问题的严重度分级来报告。（6） 顾客对问题报告的解决有最终决定权。所有的决定必须为顾客所认可，以使供方所提供的解决

39、方案满足顾客要求。这是与规则会随个别顾客而改变的副本问题报告的解决相关。（7） 由于这种测量是测量供方的修理响应时间，在问题报告关闭时,由顾客所引起的任何额外的延误必须从全部关闭时间中删除。供方必须保持这些耽搁的记录，包括具体的起始日期，这类型事件的例子是：因顾客提出的约束条件的原因，对建议的解决方案进行测试时引起的额外延时。在打开一个问题报告和供方要求提供所需的资料后，顾客延误了向供方提供充分的信息以开始问题的解决。供方不易解决一个服务问题报告。（8） 如果在问题报告过程期内，问题的严重程度被重新分类（例如：从关键到主要，从主要到一般） 。FRT 必须从问题最初打开算起的所有时间累加。除非有

40、另外的规定，总共的问题报告修理响应时间必须在关闭时按严重程度的分类予以报告。（9） 如果在顾客特别的要求下（不是因为供方的问题） ，修理的展开被推迟了（或根本没有开始） ，则当正式的修理首次可用于交付时，时间间隔被定义为结束标志。延误的时间间隔不包括在 FRT 计算之内。（10）对于关键问题所擦爱区的临时修理不应该在这种测量中计算，随后的主要问题和一般问题应该包括。（11）如果在得到顾客同意后（例如：顾客同意等待对补丁的下一次软件更新） ，这样延误的间隔不能包括在内。c. 计算规则剪裁在 5.1.4 中所有的计算规则剪裁也适用于 FRTd. 计算和公式24（1） FRT 测量中的每一项（见表

41、5.2-1 中 FRT2， FRT3 和 FRT4）必须每月都按定义的计算规则计算当月中所有按时关闭的报告在按预定时间交付的所有问题报告中所占的百分数。预定的期限时间定义为：主要 H/S 问题报告 30 日历天一般 H/S 问题报告 180 日历天对于所有的服务问题报告是顾客和供方之间协议的关闭日期(服务的期望关闭间隔可按合同协议预先决定)。（2） 当为 RQMS 可选的测量中的 FRT 测量时，供方应参考表 5.2-2 中的ORT2 和 ORT3 以确定报告规则。（3） 在报告期间内如果没有问题报告，FRT 应认为是 100%。符号Fr2按时交付的主要 H/S 修理Fr3按时交付的一般 H/

42、S 修理Fr4按时解决的服务问题报告Fr2d应关闭产生的主要 H/S 修理数目Fr3d应关闭产生的一般 H/S 修理数目Fr4d应关闭产生的服务问题报告数目表 5.2-1 问题报告修理响应时间（FRT ）标识符 名称 公式 说明FRT2 H/S 主要问题修理响应时间 100（Fr2/Fr2d） 按时交付FRT3 H/S 一般问题修理响应时间 100（Fr3/Fr3d） 按时交付FRT4 服务问题报告修理响应时间 100（Fr4/Fr4d） 按时解决表 5.2-2 问题报告修理响应时间 RQMS 可选的测量（ORT）标识符 内容 ORT2 按时关闭的主要问题ORT3 按时关闭的一般问题25e.

43、报告数据和格式（1） 数据必须每季度报告一次，每份报告必须包括本季度 3 个月的数据。（2） TL9000 FRT 数据表FRT 测量报告必须附带每个月的数据要素（或等同于测量管理者所定义的数据）以及表 5.2-3 所示的每个产品类别。表 5.2-3 FRT 或 OFR 数据表年和月： YYYYMM报告 ID： 为论坛管理者提供产品类别代码： 见附录 A测量方法： TL9000顾客库： （1）全部或（2 ）论坛成员年度因素： Afactor（见术语表）测量标识符： FRTFRT2 Fr2FRT3 Fr3FRT4 Fr4FRT2 Fr2dFRT3 Fr3dFRT4 Fr4d（3） RQMS 可选

44、的数据表RQMS 可选的测量报告必须附带每个月的数据要素（或等同于测量管理者所定义的数据）以及表 5.2-4 和表 5.2-5 所示的每个产品类别。表 5.2-4 RQMS 之 FRT 数据表（ORT）年和月： YYYYMM报告 ID： 由论坛管理者提供产品类别代号： （见附录 A）测量方法： RQMS26顾客库： （1 ）全部或（ 2）论坛成员测量标识符： ORTORT2 分子： Oert2n-在 3 个月内按时交付的主要修理问题总数ORT2 分母： Oert2d-在 3 个月内应交付的主要修理问题总数ORT3 分子： Oert3n-在 3 个月内按时交付的一般修理问题总数ORT3 分母：

45、Oert3d-在 3 个月内应交付的一般修理问题总数5.2.5.数据来源用于 FRT 测量的数据来自于顾客提供的信息和供方分析的信息。a. 顾客 向供方报告问题 与供方商议建立 H/S 的严重度分类 服务问题报告的协商关闭间隔 同意问题报告关闭的决定b. 供方 追溯问题报告，严重程度（H/S） ，协商的关闭间隔（服务） ，和实际的关闭日期 计数，延误和按时修理，问题报告，并且按照所述的规则计算测量结果5.2.6.交付或报告的方法a 比较数据（CD）或研究数据（RD）：主要 H/S 问题报告修理响应时间： CD一般 H/S 问题报告修理响应时间： CD服务问题报告修理响应时间： CDb.RQMS

46、 可选的报告主要 H/S 问题报告修理响应时间： 是一般 H/S 问题报告修理响应时间： 是服务问题报告修理响应时间： 否275.2.7.计算示例a. 例 1H/S 产品的 FRT（1） 假设考虑一个月内的供方将特定的 OSS 出售给探索论坛的成员或非成员的数据。当月共有 5 个应关闭的严重问题报告的修理，并且 5 个都按时交付，共有 25 个应关闭的一般 H/S 问题报告，并且其中 20个按时交付。（2） FRT 报告数据见表 5.2-5表 5.2-5 FRT 数据报告示例年和月： YYYYMM报告 ID： 由论坛管理者提供产品类别代号 4.2测量方法： TL900顾客库： 全部测量标识符：

47、 FRTFRT2 分子： 5FRT3 分子： 20FRT4 分子： 不适用FRT2 分母： 5FRT3 分母： 25FRT4 分母： 不适用（3） FRT 测量的计算表 5.2-6 FRT 源数据和测量计算按时修理 严重度 预期修理YYYYMM FRT测量 （FRT2、3 ）5（Fr2） 主要 5（Fr2d ）100 按时交付的主要 H/S问题报告修理2820（Fr3 ） 一般 25（Fr3d）80 按时交付的一般 H/S问题报告修理（Fr4） 服务 （Fr4d）服务问题报告不适用于此产品b. 计算：例 2（服务）（1） 考虑一个月内供方将特定安装服务出售给探索论成员和非成员的数据。整月有 20 个应关闭的服务问题报告并