测量手册模板.doc

测量手册模板

135
2020年4月19日
资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。
1.简介

TL9000手册( TL9000质量管理体系要求手册和TL9000质量管理体系测量手册) 是专门为电信业设计的文件化的行业质量管理体系要求和测量。
TL9000质量管理体系要求手册包含4个主要的部分及附录。手册为提供硬件、 软件和服务这些电信产品的供方建立了一套通用的质量管理体系要求。本要求是在已存在的行业标准( 包括ISO9001) 的基础上建立起来的。TL9000质量管理体系测量手册建立了最小的一套绩效测量。所选择的测量方法用于测量供方的改进以及评价质量管理体系实施的效果。
1.1目标
TL9000的目标是:
l建立质量管理体系以有效地保护电信产品( 包括硬件、 软件或服务) 的完整性和使用性
l建立并保持一套基本的质量管理体系要求
l减少电信质量管理体系标准的数目
l定义有效成本和绩效测量, 以指导改进和评价质量管理体系实施的效果
l推动持续改进
l加强顾客一供方之间的关系
l促进行业遵从一致的评估过程
1.2 目的
TL9000的目的是定义了电信产品( 包括硬件, 软件或服务) 的设计、 开发、 生产、 交付、 安装和维护的质量管理体系要求。包含在TL9000中, 以绩效为基础, 测量这些产品的可靠性和质量绩效。长期目标还包括成本和以绩效为基础的测量。
1.3实施的益处
电信服务的供方, 她们的用户和所有的顾客都会从TL9000的实施中受益。
所期望的益处是:
l对用户服务的持续改进
l加强顾客和供方的关系
l质量管理体系要求的标准化
l外审和现场访问的有效管理
l统一的测量
l全面成本减少而且增加竞争力
l加强管理并改进供方绩效
l用TL9000测量进行行业比较
1.4 与ISO9001和其它要求之间的关系
探索论坛维持同其它要求和标准的相容性。TL9000是在ISO9001: 1994框架的基础上建立起来的一套电信业特殊要求, 在TL9000开发的过程中, 所考虑的标准和要求请参见其目录。
TL9001同其它要求的关系特征是:
lTL9000包括ISO9001: 1994。而且还包括ISO9001未来的任何修订
l符合TL9000即符合相必须的ISO9001要求
l探索论坛的意图是符合TL9000将免除符合多种电信质量管理标准的要求。
1.5手册的开发和维护
探索论坛负责开发、 出版、 发行和维护能够公开获得的TL9000手册, 随着TL9000手册发行后出现的任何更改要提交探索论坛管理者。本手册的任何使用者都能够提交更改要求。更该要求将由论坛管理者递交给相必须的手册部门负责人, 并将在下一次修订中考虑。更改的要求/反馈表编排在本手册的后面。
TL9000手册的所有变更, 都要经过探索论坛的投票成员按论坛要求投票经过, 才能最终批准。TL9000手册的再发行由论坛决定, 但再发行不会超过最近发行时间5年。当论坛决定TL9000的发行影响第三方注册时, 那么附加活动或类似的沟通机制将用于为行业提供标准的纠正和更新的信息。
2.结构

2.1.整体结构( 看图2.1－1)
TL9000的整体结构由如下几个层次构成
1. 国际标准ISO9001
2. 通用的TL9000要求
3. 硬件、 软件和服务的特殊质量管理体系要求
4. 通用的TL9000测量
5. 硬件、 软件和服务的特殊质量管理体系测量
TL9000模型

国际标准ISO9001
通用的TL9000要求
TL9000
硬件特殊要求
软件特殊要求
服务特殊要求
通用的TL9000测量
硬件特殊的测量
软件特殊的测量
服务特殊的测量

图2.1－1 TL9000模型
除其它机构的版权材料外, 探索论坛保留对内容的全面控制。

在TL9000中有一些术语, 如必须( Shall) , 应该( Should) , 能够( may) , 能( can) 与IS9000术语表中所定义的一样, 单词必须( Shall) 表示强制性的要求, 单词应该( Should) 表示首选的方法, 选择其它方法的供方必须能够表明她们的方法满足TL9000的内容。在有单词典型( typical) 和例子( examples) 的地方, 表示针对特殊的商品或过程是一个合适的选择。文中有注( NOTE) 的地方是指南而不是审核内容。

2.2.术语
供
方

顾
客
持续改进
程序
探索论坛网站
测量储存体系( MRS)
MRS报告
TL9000数据
行业统计
在本手册中所引用的术语主要是组织在TL9000的实施、 符合和认证过程中所遇到的术语。
2.3.测量的流程和用途
图2.2－1显示出TL9000手册中质量管理体系测量的数据流程和用途

图2.3－1 TL9000测量数据流程和用法
必须设计测量的应用以满足探索论坛为准则, 这在3.2节中讲到:

使用方法－图2.2－1描述了经过顾客－供方交互的方式以及TL9000所显示的信息来识别改进的机会所处的环境。
a. 能够在供方和顾客之间用测量来设定相互目标以改进产品。这将有助于改进顾客和供方之间的关系, 而且能建立最佳地满足双方需要的目标。
b. TL9000中有一些测量能够由独立的供方来改进测量, 这些测量经过仔细的评审以决定这些测量是否真正具有可比性。这些测量由测量管理者所监控, 以保证供方得出的简明统计是有效的和有意义的。简明统计定义将按需要进行修订。这些测量的定义包括指定”比较数据”。
c. 其它测量包括定义”研究数据”, 研究数据不能用作比较的目的。可是, 测量管理者将分析数据用来显示可能的行业趋向, 这些分析仅供制定测量的工作组以备未来可能用来进行检查。
d. 当每个供方按简明统计方法比较其测量时, 可改进产品绩效以改进供方的绩效。
e. 探索论坛测量数据库并不倾向于用作供方的管理工具, 而是作为数据贮存。数据库的输出包括从TL9000测量存贮系统( MRS) 中针对产品所作的每一种测量而得出的统计简明报告。
3.测量用法和职责

3.1 测量使用的要求
为了完全满足本手册的要求, 组织必须遵从本处所规定的测量要求
a. 内部作为持续改进程序和管理报告的一部分
b. 适当时, 作为顾客——组织交流和共同持续改进程序
c. 认证时, 向测量管理者报告
3.2 测量的使用原则
TL9000注册要求执行TL9000质量管理体系要求, 而且将用于TL9000注册的TL9000质量管理体系测量的具体数据报告给测量管理中心。下面这些处理和使用测量的原则意味着培养一种环境, 以使顾客和供方能一起工作推动持续改进。
a. 在测量适用表( 附录A、 表格A－2) 中所定义的产品类别适用测量都必须报告。
b. 在注册范围内特殊测量的剪裁必须形成文件以表述剪裁原因, 并可在认证机构和顾客要求时得到。
c. 供方必须将TL9000测量数据提供给测量管理中心, 她们将编辑数据, 而且计算产品类别的统计值, 例如”行业平均值””标准偏差”, ”中位数”、 ”极差””数据点的数目”和”行业最佳”, 这些统计值对各产品类别都是合适的, 测量管理中心产生的产品结果或报告将不会确定单一供方。
d. 探索论坛的成员顾客必须提供TL9000领域所必须的绩效数据给供方, 以计算特殊的测量。
e. 顾客能够要求她们的供方提供TL9000的具体测量情况, 经过协议, 这种信息交流将严格发生在供方和顾客之间, 任何情况下, 论坛管理者和测量管理中心都不能涉及其中。
f. 在探索论坛管理者没有对供方进行分级。
g. 测量的运用不能局限于数据的所有特性。
3.3 测量使用的原则
TL9000测量使用的意图是:
a. 提供适合于比较的行业绩效的信息。
b. 改进电信过程和产品。
c. 识别顾客－供方改进机会。
d. 标准化顾客报告卡或评价。

3.4 测量数据集合和顾客库
3.4.1.产品集合
如果供方希望在同一产品类中认证多个产品而且在各自的认证范围内清楚地识别她们, 那么供方可能要分别给每个产品报告数据。同理, 如果一个供方认证一个商业单位或地点, 那供方有权决定认证哪一个产品, 以及数据如何收集。
3.4.2 顾客库
a. 顾客库指的是供方测量数据所包含的一组定义的顾客。顾客库必须具备如下条件:
（1） 论坛成员: 仅仅是探索论坛的成员的供方顾客。
（2） 全部: 测量适用的产品所针正确所有顾客供方。
b. 在每一次测量数据提交时, 针对测量表格中指定的每一个测量都必须报告顾客库。
c. 供方必须针对每一个单一的测量, 报告来自一个顾客库的测量数据。

3.5 职责
3.5.1论坛管理者职责
论坛管理者必须
a. 维护公司信息的安全和保密。
b. 开发、 实施、 出版和保持定义TL9000测量过程的正确操作程序。
c. 从测量管理者处接受”数据确认报告”, 而且将”数据确认报告”转发给供方。
d. 与测量管理者的有遗失的数据或可疑数据的供方联系。
e. 保持成员数据库, 包括认证和测量提交历史。
f. 经过以下方式发布和保持行业报告统计值:
（1） 来自于全部顾客库的数据的产品类别
（2） 仅来自探索论坛顾客库数据的产品类别。
（3） 对一个产品类别所有适用的数据( 即1和2)
g. 经过探索论坛网站, 提供和控制测量数据输出的访问。
h. 对探索论坛管理者的相关操作开发和实施一个灾难性恢复计划。
i. 支持外审或论坛管理者活动的监督。
j. 当探索论坛网站上发布的附录A—”产品类别表”更新时, 通知认证的供方和受影响的单位。
3.5.2测量管理者职责
测量管理者必须:
a. 维护数据的安全和保密。
b. 开发、 实施、 发行和保持定义TL9000测量过程工具和技术的正式操作程序。
c. 从供方处接受和确认数据, 包括识别遗失数据或错误数据, 并报告给论坛管理着。
d. 计算行业统计数据, 例如: ”行业平均值””标准偏差””中位值””极差””数据点数目”和”行业内最佳”。适当时, 经过产品类别对有可比较数据的每一种测量使用合适的数据单元。
e. 经过下列方式计算行业统计:
（1） 来自于所有顾客库数据的产品类别。
（2） 仅来自于探索论坛顾客库数据的产品类别。
（3） 对一个产品类别中所有适用的数据( 即1和2) 。
f. 记录可比较的数据, 而且至少每季度将之输出到网页上。
g. 开发和实施相关操作的灾难恢复计划。
h. 支持外审或活动监督。
i. 决定什么时候对每个测量产品类别收集充分的数据以发布统计后的正确结果。
j. 负责提供数据的准确表示。
k. 创立并保持用户手册。
l. 提供产品类别的集合, 以产生有意义的测量作为输入分析的结果。
m. 分析”研究数据”以显示行业趋向、 这些内容仅向测量工作组报告。
n. 分析”研究数据”以确定是否有数据比较的条件, 而且仅推荐给测量工作组以达到可比性。
3.5..3.供方职责
供方必须
a. 建立文件化过程, 以捕获和确认适用的测量数据, 使源数据记录能够获得。
b. 收集, 确认和提交每一个指定的测量所定义的数据给测量管理者。
c. 提交在认证范围内的测量数据。
d. 向测量管理者提交至少连续3个月的数据, 而且接受”数据确认报告”, 证实提交的有效性以获得TL9000认证。
e. 提交在认证范围内的测量。
f. 如果新产品在认证范围内, 那么就要提供6个月内的产品总可用性测量数据。
g. 将内部测量同行业统计相比较, 并在适当的时候采取措施改进产品和实践。
h. 提供定期的TL9000质量管理体系测量报告给负有职责的管理者。
i. 纠正任何矛盾数据。
j. 在2年内提交的任何错误数据, 要再提交纠正数据。
3.5.4.顾客职责
顾客必须:
a. 提供必须的数据允许供方形成TL9000测量。
b. 建立一个过程以捕获并确认适用的测量数据。
c. 使用TL9000测量定义以标准化供方绩效评审过程( 例如: 报告卡)
d. 建立顾客一供方联合改进小组以及基于TL9000测量的目标和其它所需要的绩效目标。
e. 当确定了生命周期成本时, 考虑使用TL9000测量作为输入。
3.5.5.探索论坛职责
a. 负责管理TL9000质量管理体系测量手册。
b. 保证TL9000质量管理体系手册能公共获得, 在探索论坛的指导下出版、 分发和维护, 而且保持其版权。
c. 负责保证提供适当的培训以帮助用户正确地, 一致地解释TL9000要求, 并报告TL9000测量。
d. 提供测量过程监督。
e. 记录与测量过程有关的问题和内容, 并向探索论坛提供摘要和建议。
f. 评审由测量管理者提交的建议的产品类别集合。
3.5.6.审核员职责
在每次审核期间, 审核员必须验证:
a. 过程能保证数据对于TL9000质量管理体系测量的定义和要求来说是正确的和完整的。
b. 所有供方的职责已满足。
c. 在审核员指定的时间内, 所有测量的过程不符合已被纠正。
4.通用测量要求

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

4.2 测量报告要求
4.2.1 符合测量报告
供方必须按本手册中文件所描述的那样对应用的产品类别生成测量数据, 并向测量管理者( 和有要求的顾客) 发布此数据。测量数据必须符合相应文件的要求。报告数据的变化必须符合附录A中新的高版本或新版本测量手册的要求, 新版本的测量也必须在6个月内完成。
注: 数据表中带引号的文字是正确报告的变量字串。
4.2.2 适用的产品类别
对每一种产品, 供方必须按附录A识别产品类别以及适用的测量。附录A是这本手册版本当前的最新内容, 参见探索论坛网址( WWW.questforum.org) 可获得高版本( master) 内容, 高版本( master) 必须同认证联网, 并将所有数据提交到探索论坛数据库。
4.3 测量数据和报告
4.3.1 顾客源数据
当顾客没有提供为测量所需要的数据时, 不能要求供方向顾客报告测量结果。
注: 如果测量管理者没有要求供方提交数据, 那么一定是供方的顾客没有提供所需要的信息。如果任何顾客的确提供此信息, 则供方必须提交测量数据。
4.3.2 可接受的可选的测量
当测量文件中”报告和分发方法”的标题下表明RQMS作为替代报告是可接受的, 则必须满足下列要求:
a. RQMS数据可接受性
如果供方正在使用最新版本的Telcordia技术文件GR－929－CORE, 即电信系统的可靠性和质量测量( RQMS) , 来计算具体的测量。如果下面的条件满足, 这些方法和结果数据将替代TL9000的定义。
（1） 用于报告给探索论坛和其成员的数据包括TL9000所定义的所有可应用的数据, 而且它不局限于RQMS客户公司的数据子集。
（2） 对于不隶属于RQMS报告的产品类别, 必须使用TL9000的定义。
b. TL9000数据优先
在所有情况中, TL9000所定义的测量是优先选择的方法。如果供方的顾客没有一个要求供方产生RQMS报告, 那么必须使用TL9000方法。供方在报告此测量时, 必须说明使用的是何种方式。
注: 当RQMS和TL9000测量都是合同要求时, RQMS选择的测量其目的是经过供方使多余工作最小化, 在那种情况下, 符合性审核将接受以RQMS为基础且与上列出的条件相符的程序作为这一测量的有效计算。
4.3.3 报告频率和方法
除非文件中有具体的规定, 供方必须每月收集数据, 而且每季度向探索论坛数据库报告一次所需要的结果。供方能够采用适合于向她的顾客及内部报告的任何时间周期和形式, 每季度更新必须包括前3个月的新数据点。
4.3.4 财务周期和日历天
供方必须在日历月或定义的财务月基础上报告TL9000测量数据, 供方必须一致地使用所选择的方法。供方必须在涉及到日历天的测量中使用日历天。
4.3.5 比较数据和研究数据的报告
供方必须按照认同的规则将本手册中所有适用的测量数据报告给测量管理者。这个报告要求适用于无论是供方使用的TL9000方法或RQMS替换报告, 而且无论测量中是否包括指定的”比较数据”或”研究数据”( RD) 。参见附录中表A－5。
注: 在文件交付和报告部分指定的”比较数据”意味着能够在论坛管理者处得到行业统计值。可是, 指定的”研究数据”是得不到可比较的行业统计值的, 而且测量管理者仅向探索论坛工作组报告行业趋势的分析。
4.3.6.产品剪裁
供方能够剪裁那些不再支持通用顾客库的产品数据, 为了使这种剪裁得以必须用, 必须使顾客得到”增加和维持( A＆M) ”或””制造终止( MD) ”状态下的产品分布的正式通知。
4.3.7.测量适用性
如果没有其它的说明, 测量必须适用于在总可用性期间的产品。
4.3.8 标准化因子的计算
标准化因子是转换能力的基础, 例如DS1, OC-1, DSL, 或终端, 计算应在正确的转换基础上进行。
5.通用测量

通用测量是适用于所有产品的测量: 硬件、 软件和服务。
5.1 问题报告数( NPR) ( C)
5.1.1 一般描述和标题
全部问题报告( 抱怨) 测量是在测量适用性表A－2( 标准形式) 中具体说明的全部问题报告的测量。这种测量适合于RQMS, 而且必须用于所有产品。硬件( H) , 软件( S) , 和服务。
5.1.2 目的
测量的目的是测量由顾客引发的问题报告( 抱怨) 数, 该数目能显示出产品在运行寿命周期内所交付的产品质量, 这么做的目的是要降低问题报告数以及相关的成本和收入损失。问题报告可能对供方、 顾客产生负面影响( 例如重复安排现场访问) 而且能够减少最终用户的忠诚。
5.1.3. 适用的产品类别
此测量适用于附录A中的产品类别。
5.1.4.详细的描述
a. 术语－如下用于NPR测量的术语的定义。
l 顾客
l 复制问题报告
l 总可用性( GA)
l 在用版本
l 信息要求( IR)
l 无故障发现( NTF)
l 正式修理
l 问题－关键H/S
l 问题－主要H/S
l 顾客问题－一般H/S
l 问题报告－( PR)
l 服务问题报告
l 严重级别
l 版本
b. 计算规则
（1） 在硬件或软件情况下, 涉及到任何和所有在用支持的发行版本相关的问题报告都必须计算在内。
（2） 在服务的情况下, 在服务交付过程中或之后的任何正式的问题报告必须计算在内。
（3） 仅仅由顾客引发的问题报告必须计算在内。
（4） 对于硬件或软件, 在每种版本的总可用性之后, 任何问题报告都必须计算, 除非有另外的规定, 不论它是否与软件, 硬件、 文本、 无故障发现, 程序, 复制或其它等有关。
（5） 完全相同的问题报告, 即同一时间, 同一地点, 同一问题同样发生的多个报告必须算作1个问题报告。
（6） 复制问题报告, 即在不同顾客地点或在不同的时间发生的同样故障, 每一个问题必须分别计算问题报告数。
（7） 记录在同一问题报告上的多个问题( 在一个问题报告表或屏幕中) 必须分别计算, 除非顾客认为这些问题都与顾客经历的功能有相同的征兆相关。
（8） 常规的关于中断方面的问题报告, 如服务功能分析报告( SFAR) , 不能计算在内。
（9） 有关硬件和软件的问题报告必须按照问题的严重程度分级进行统计。
（10） 临时修理, 例如临时补丁或临时工作区, 频繁用于解决关键的软件或硬件问题。正式的修理常常是在随后的或”追随”于涉及到原始的关键问题报告的主要和一般问题报告的情况下开发出来的。这种类型的关键问题报告不能重新分类, 必须作为关键问题来报告, 随后的主要或一般问题报告不能计算在内。
（11） NPR必须按照她们接受数据的当月进行统计。
c. 计算规则剪裁
在统计NPR测量时, 下面这些情况应该排除
（1） 在供方和顾客之间经过协议形成的有关信息要求或请求的问题报告
（2） 有关产品使用中采用了并不在供方和组织之间经过协议而形成的产品规范中的方式而形成的问题报告。
（3） 有关常规事项的问题报告如: 所期望的维护, 正常的现场、 可替换单元的返回, 软件升级;
（4） 有关中断的常规报告, 例如: 服务失效分析报告( SFAR)
d. 计算和公式
（1） 测量( 见表5.1-1中的NPR1, NPR2, NPR3和NPR4) 必须每月计算: 用附录A中所列的所有产品类别输入的问题报告总数, 除以附录A中所列的标准因素。
（2） 在硬件和软件产品类别中, 如果顾客不能容易地在使用因素中识别产品数量, 将不能计算问题报告测量( NPR) 。还是要求供方去追溯问题报告的数目和她们的答案( 在这种情况下, 输入标准化因素=”无”, 见表5.1－3)
（3） 当对硬件和/或对软件报告RQMS可选测量时, 供方必须引用表5.1-2中的IPR1, IPR2和IPR3, 以确定报告内容。
符号:
NU＝附录A, 表A－2的标准化单位
S ＝标准化因素; 总的NU数
NP1＝H/S关键问题报告数
NP2＝H/S主要问题报告数
NP3＝H/S一般问题报告数
NP4＝服务问题报告数
表5.1-1问题报告数( NPR) 测量标识符和公式
标识符
名称
公式
NPR1
每个NU的H/S关键问题报告
NP1/S
NPR2
每个NU的H/S主要问题报告
NP2/S
NPR3
每个NU的H/S一般问题报告
NP3/S
NPR4
每个NU的服务问题报告
NP4/S

表5.1-2问题报告数－RQMS可选的测量( IPR)
标识符
名称
IPR1
每个系统每个月输入的关键问题报告
IPR2
每个系统每个月输入的主要问题报告
IPR3
每个系统每个月输入的一般问题报告

e. 报告的数据和格式
（1） 数据必须每个季度报告一次, 每次报告必须包括该季度3个月的数据。
（2） TL9000数据NPR表( 表5.1－3) －NPR测量必须采用每个月和每个产品的数据单元( 或等同于论坛管理者所定义的形式) 进行报告。如下例:

表5.1-3 NPR数据表
年和月: YYYYMM
报告ID: 为论坛管理者所提供
产品类别代号: ( 见附录A)
测量方法: TL9000
顾客库: ( 1) 全部或( 2) 论坛成员
标准化因素: S或无
年度因素: Afactor( 见术语表)
测量标识符: NPR
NPR1分子: NP1
NPR2分子: NP2
NPR3分子: NP3
NPR4分子: NP4
（3） RQMS可选的数据表( 5.1-4) －RQMS可选的测量必须采用每个月和每个产品类别的数据单元( 或等同于测量管理者定义的形式) 进行报告, 如下例:

表5.1-4 RQMS可选的NPR数据表( IPR)
年和月: YYYYMM
报告ID: 由论坛管理者提供
产品类别代码: ( 见附录A)
测量方法: RQMS
顾客库: ( 1) 全部或( 2) 论坛成员
标准化因素: 在用系统的数目
测量标识符: IPR
IPR1分子: 输入的关键问题报告数
IPR2分子: 输入的主要问题报告数
IPR3分子: 输入的一般问题报告数

5.1.5 数据来源
NPR测量的数据是从以下顾客提供的信息和供方的分析推导出来的。
a. 顾客
l 向供方报告问题。
l 按照附录A中的产品类别表, 向供方报告硬件或软件种类的标准化信息。
b. 供方
l 根据产品类别和顾客库, 计算报告问题, 而且按照适当的规则转化为”问题报告数”。
l 对于服务产品, 追溯和报告服务标准化单位。
l 计算标准化因素。
5.1.6 交付或报告的方法
a. 比较数据( CD) 或研究数据( RD)
每个NU的关键问题报告 CD
每个NU的主要问题报告 CD
每个NU的一般问题报告 CD
每个NU的服务问题报告 CD
b. RQMS可选的报告
每个NU的关键问题报告 是
每个NU的主要问题报告 是
每个NU的一般问题报告 是
每个NU的服务问题报告 否

5.1.7. 计算示例
a. 例1－H/S产品的NPR
（1） 假设一个特殊的运行支持系统( OSS) 的供方将一个月的数据出售给探索论坛的成员和非成员, 在整个月期内, 有30个在用系统, 而且NU是”在用系统”。
（2） 报告数据显示在表5.1－5

表5.1－5 例1: NPR数据报告
年和月: YYYYMM
报告ID: 由论坛管理者提供
产品类别代码: 4.2
测量方法 TL9000
顾客库: 全部
标准化因素: 30
年度因素: 12
测量标识符: NPR
NPR1分子: 0
NPR2分子: 3
NPR3分子: 45
NPR4分子: 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） 假设一项特殊维护服务的供方将1个月的数据出售给探索论坛的成员和非成员, 在整个月内有20个被维护的单位, 而且NU是”在用单位”。
（2） 表5.1-7显示的报告数据。

表5.1-7 例2: NPR数据报告
年和月: YYYYMM
报告ID: 为论坛管理者提供
产品类别代码: 7.3
测量方法: TL9000
顾客库: 全部
标准化因素: 20
年度因素: 12
测量标示符: NPR
NPR1分子: 不适用
NPR2分子: 不适用
NPR3分子: 不适用
NPR4分子: 30

（3） 测量的计算显示在表5.1-8中

表5.1-8 例2: NPR源数据和测量
问题报告
等级
Afactor
标准化因素
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问题报告不包括在这些内容中, 是因为关键问题在关闭前, 享有优先处理的权利。这些测量来源于RQMS。

5.2.2 目的
测量的目的是度量问题报告的响应, 而且促进问题报告的迅速修理和关闭。
5.2.3 适用的产品类别
这些测量适用于附录A中所列的产品类别。
5.2.4 详细的描述
a． 述语－术语表包括了用于FRT测量的术语的定义
l 关闭标准
l 关闭日期
l 关闭间隔
l 修理
l 修理响应时间
l 正式的修理
l 延误问题报告
l 问题－关键H/S
l 问题－主要H/S
l 问题－一般H/S
l 问题报告PR
l 严重级别
l 临时修理
b． 计算规则
（1） 仅仅是顾客产生的问题报告, 而且满足问题报告数量标准, 必须包含在响应测量中。在5.1.4.b和5.1.4.c中所有的计算规则和剪裁说明也适用于FRT。
（2） 计算FRT中间隔的时间起点必须从接受供方问题报告开始, 如果问题的严重程度被重新分类, FRT应从问题报告的接受开始算起。
（3） 计算FRT间隔的时间终点必须是正式修理或关闭标准的生效日期, 如果问题报告的最初指定者由于不完善或引起边际效应导致后来拒绝修理, 那么问题报告必须被再分类为打开。
（4） 对于FRT, 所统计的问题报告数是指当月应该关闭的问题报告数, 而不是当月正在处理的问题报告数。
（5） 总FRT应按照修理应该被关闭的时间和问题的严重度分级来报告。
（6） 顾客对问题报告的解决有最终决定权。所有的决定必须为顾客所认可, 以使供方所提供的解决方案满足顾客要求。这是与规则会随个别顾客而改变的副本问题报告的解决相关。
（7） 由于这种测量是测量供方的修理响应时间, 在问题报告关闭时,由顾客所引起的任何额外的延误必须从全部关闭时间中删除。供方必须保持这些耽搁的记录, 包括具体的起始日期, 这类型事件的例子是:
——因顾客提出的约束条件的原因, 对建议的解决方案进行测试时引起的额外延时。
——在打开一个问题报告和供方要求提供所需的资料后, 顾客延误了向供方提供充分的信息以开始问题的解决。
——供方不易解决一个服务问题报告。
（8） 如果在问题报告过程期内, 问题的严重程度被重新分类( 例如: 从关键到主要, 从主要到一般) 。FRT必须从问题最初打开算起的所有时间累加。除非有另外的规定, 总共的问题报告修理响应时间必须在关闭时按严重程度的分类予以报告。
（9） 如果在顾客特别的要求下( 不是因为供方的问题) , 修理的展开被推迟了( 或根本没有开始) , 则当正式的修理首次可用于交付时, 时间间隔被定义为结束标志。延误的时间间隔不包括在FRT计算之内。
（10） 对于关键问题所擦爱区的临时修理不应该在这种测量中计算, 随后的主要问题和一般问题应该包括。
（11） 如果在得到顾客同意后( 例如: 顾客同意等待对补丁的下一次软件更新) , 这样延误的间隔不能包括在内。
c. 计算规则剪裁
在5.1.4中所有的计算规则剪裁也适用于FRT
d. 计算和公式
（1） FRT测量中的每一项( 见表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/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)
标识符