Wiki源代码26 某汽车金融有限公司ITIL问题管理流程说明书
由 superadmin 于 2024/10/15, 16:43 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | [[返回本章节索引>>url:http://www.itil4hub.cn/bin/view/G %E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86/]] 阅读下一章 | ||
| 2 | |||
| 3 | |||
| 4 | **文档信息** | ||
| 5 | |||
| 6 | |**项目名称**|(% colspan="3" %)**IT桌面支持及IT运维项目** | ||
| 7 | |**项目经理**| |**文档版本号**|0.1 | ||
| 8 | |**阶段**| |**文档版本日期**|2015-12-01 | ||
| 9 | |**起草人**|张XX|**准备日期**| | ||
| 10 | |**审核人**| |**审核日期**| | ||
| 11 | |||
| 12 | **版本历史** | ||
| 13 | |||
| 14 | |**版本编号**|**版本日期**|**修改者**|**说明** | ||
| 15 | |1.0|2015-12-01|张XX|起草 | ||
| 16 | |1.1|2015-12-07|张XX|根据Ai-hua review结果修改 | ||
| 17 | | | | | | ||
| 18 | | | | | | ||
| 19 | |||
| 20 | **分发记录** | ||
| 21 | |||
| 22 | |接收人|操作*|接收日期|接收方式(传真/邮件等) | ||
| 23 | | | | | | ||
| 24 | |||
| 25 | //*操作类型包括:批准,审核,通知,要求采取行动,其它(请注明)等// | ||
| 26 | |||
| 27 | |||
| 28 | |||
| 29 | = **1.1.流程目的** = | ||
| 30 | |||
| 31 | 问题管理流程是一个化被动为主动的管理流程,重点是通过解决事件的根本原因来达到减少生产环境中突发事件的数量。因此,问题管理流程不仅针对已经发生的问题,更主要是找出潜在的问题并及时解决。 | ||
| 32 | |||
| 33 | 综上,问题管理流程的目的包括: | ||
| 34 | |||
| 35 | 1. 消除或减少生产环境中事件发生的数量和严重程度 | ||
| 36 | 1. 防止类似事件再次发生 | ||
| 37 | 1. 提高IT服务的可靠性和降低IT支持成本 | ||
| 38 | |||
| 39 | == == | ||
| 40 | |||
| 41 | = **1.2.流程主要内容** = | ||
| 42 | |||
| 43 | 问题管理流程着重于消除事件或减少事件发生,确定事件的根本原因。主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭,以消除事件或在其发生时降低对用户或业务的影响。其主要内容如下: | ||
| 44 | |||
| 45 | * 记录问题 | ||
| 46 | |||
| 47 | IT部门根据问题单填写规范,生成问题单并将相关信息(如:事件单、变更单等)关联至问题单并启动问题管理流程。 | ||
| 48 | |||
| 49 | * 分派问题 | ||
| 50 | |||
| 51 | 问题经理判定问题属于基础架构范畴还是属于业务范畴后确定合适的问题专家并分派。 | ||
| 52 | |||
| 53 | * 诊断问题并提供解决方案 | ||
| 54 | |||
| 55 | 问题专家调查分析问题、找出其根本原因后,制定解决方案、变通方法或提出预防性措施,旨在解决问题或问题复发时最大程度弱化对业务的影响。 | ||
| 56 | |||
| 57 | * 开发、确认、实施解决方案 | ||
| 58 | |||
| 59 | 问题专家根据解决方案、变通方法或预防性措施开展准备工作、制定实施计划。若实施涉及变更,则需要启动变更管理流程。 | ||
| 60 | |||
| 61 | * 回顾问题 | ||
| 62 | |||
| 63 | 在实施解决方案后,问题专家观察实施结果并决定是否进入问题总结和关闭阶段。 | ||
| 64 | |||
| 65 | * 总结和关闭问题 | ||
| 66 | |||
| 67 | 问题经理先根据实际需要和相关问题专家一起总结问题处理过程、问题解决方案等工作项,旨在确认问题已得到解决并问题信息记录完整后关闭问题单,同时为后续的问题处理积累经验。 | ||
| 68 | |||
| 69 | == == | ||
| 70 | |||
| 71 | = **1.3.与其他流程的关系** = | ||
| 72 | |||
| 73 | * 和事件管理流程的关联 | ||
| 74 | ** 所有事件结束代码为“使用变通方法解决”和“无法重现”的事件原则上在事件关闭前都需要升级为问题 | ||
| 75 | ** 所有一级事件在事后补单时,原则上在关闭前都需要升级为问题。 | ||
| 76 | ** 定期分析突发事件是否有趋势或规律,以此找出潜在问题并创建问题单(问题单必须和所有相关事件单建立关联) | ||
| 77 | * 和变更管理流程的关联 | ||
| 78 | ** 问题处理过程中,如果需要对系统进行变更,必须按照变更管理的定义,提交变更请求单(变更单必须和问题单建立关联),变更完成后,继续问题单的处理 | ||
| 79 | * 和配置和资产管理的关联 | ||
| 80 | ** 问题处理过程中,可以通过配置和资产管理流程查询相关的配置项信息 | ||
| 81 | ** 问题处理过程中,如果可以将根本原因定位到某个配置项,则必须将问题单与该配置项关联 | ||
| 82 | |||
| 83 | == == | ||
| 84 | |||
| 85 | = **1.4.流程范围** = | ||
| 86 | |||
| 87 | 问题管理流程的范围是对IT生产环境中发生的问题进行管理,以采取主动性预防措施来降低事件数量。 | ||
| 88 | |||
| 89 | 不包括: | ||
| 90 | |||
| 91 | * 处于开发环境的系统和应用 | ||
| 92 | |||
| 93 | == == | ||
| 94 | |||
| 95 | == == | ||
| 96 | |||
| 97 | = **1.5.流程执行原则** = | ||
| 98 | |||
| 99 | === === | ||
| 100 | |||
| 101 | == **1.5.1.常规原则** == | ||
| 102 | |||
| 103 | * 事件处理过程中故障消除、业务恢复后如需后续分析处理,应转问题管理流程 | ||
| 104 | * 应该每月定期回顾和产生问题管理报表,对没有解决的问题,应该举行定期的问题管理会议对这些问题进行评估 | ||
| 105 | * 应该每半年对问题管理流程的关键衡量指标、流程执行效率、流程支撑工具有效性等进行回顾,以改进和优化流程 | ||
| 106 | |||
| 107 | === === | ||
| 108 | |||
| 109 | == **1.5.2.所有权原则** == | ||
| 110 | |||
| 111 | 所有权原则用来确保每个问题在任何时段都有适当的人员负责,问题经理是每个问题的负责人。有效管理问题的前提是必须确保每个问题在任何时段都有适当的人员负责。 | ||
| 112 | |||
| 113 | 下表是各角色在各环节中承担不同责任的RACI模型。 | ||
| 114 | |||
| 115 | | |((( | ||
| 116 | **问题经理** | ||
| 117 | |||
| 118 | **(职能经理)** | ||
| 119 | )))|((( | ||
| 120 | **问题专家** | ||
| 121 | |||
| 122 | **(员工)** | ||
| 123 | )))|((( | ||
| 124 | **问题相关厂商** | ||
| 125 | |||
| 126 | **(厂商)** | ||
| 127 | ))) | ||
| 128 | |问题确定与记录|R|A|R/C | ||
| 129 | |问题确认与分派|A|C/I|I | ||
| 130 | |分析并诊断问题/提供变通方法|C/I|A/R|R/C | ||
| 131 | |开发、确认、实施解决方案|C/I|A/R|R/C | ||
| 132 | |问题监控|A|R|I | ||
| 133 | |问题回顾|R/C|A|C/I | ||
| 134 | |问题关闭|A|R/C|C/I | ||
| 135 | |(% colspan="4" %)RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会 | ||
| 136 | |||
| 137 | === === | ||
| 138 | |||
| 139 | == **1.5.3.问题流程启动原则** == | ||
| 140 | |||
| 141 | * 所有事件结束代码为“使用变通方法解决”和“无法重现”的事件原则上在事件关闭前都需要升级为问题 | ||
| 142 | * 所有一级事件在事后补单时,原则上在关闭前都需要升级为问题。 | ||
| 143 | * 定期分析突发事件是否有趋势或规律,以此找出潜在问题并创建问题单(问题单必须和所有相关事件单建立关联) | ||
| 144 | * 因为变更实施导致的突发事件,可直接发起问题管理流程 | ||
| 145 | * 在会议上,相关人员提出需要按问题管理流程进行处理的事项,可直接发起问题管理流程 | ||
| 146 | * IT人员在日常运维工作中,应主动发现潜在问题并在Agile-ITSM管理系统中开问题单 | ||
| 147 | |||
| 148 | === === | ||
| 149 | |||
| 150 | == **1.5.4.转派原则** == | ||
| 151 | |||
| 152 | 问题专家认为问题分派错误或工作负载已满无法抽出足够时间排查问题时,可与问题经理线下沟通后,再由其转派给另一问题专家。为确保问题单不被过于频繁的相互转派、以至于无法在规定时间内得到解决,应当尽量减少问题单转派的几率。 | ||
| 153 | |||
| 154 | === === | ||
| 155 | |||
| 156 | == **1.5.5.问题回退原则** == | ||
| 157 | |||
| 158 | 在问题回顾过程中,问题专家发现问题并未解决。此时,他可以选择将问题回退至问题处理环节或回退至问题经理请他协调其他专家一起处理该问题。 | ||
| 159 | |||
| 160 | === === | ||
| 161 | |||
| 162 | == **1.5.6.问题关闭原则** == | ||
| 163 | |||
| 164 | 问题单在实施了解决方案之后并通过问题专家自己的回顾后,由问题经理根据实际需求负责组织问题专家参与确认解决方案是否达到了预期的效果,如果成功的实施,由问题经理确认问题信息记录完整后关闭问题。 | ||
| 165 | |||
| 166 | === === | ||
| 167 | |||
| 168 | == **1.5.7.问题单重开原则** == | ||
| 169 | |||
| 170 | 已关闭的问题单不允许重开。如果问题重复发生,则创建一个新的问题单。 | ||
| 171 | |||
| 172 | === === | ||
| 173 | |||
| 174 | == **1.5.8.趋势分析原则** == | ||
| 175 | |||
| 176 | 问题经理定期组织会议,对所处理事件历史记录进行趋势分析: | ||
| 177 | |||
| 178 | * 参加者应包括事件经理及问题专家 | ||
| 179 | * 会议定期组织 | ||
| 180 | * 定义趋势分析规则 | ||
| 181 | |||
| 182 | == == | ||
| 183 | |||
| 184 | = **1.6.流程相关定义** = | ||
| 185 | |||
| 186 | === === | ||
| 187 | |||
| 188 | == **1.6.1.问题信息项** == | ||
| 189 | |||
| 190 | 问题单包含如下信息项: | ||
| 191 | |||
| 192 | |序号|信息项|描述 | ||
| 193 | |1|工单号|为每个问题分配一个唯一的序列号(系统自动产生) | ||
| 194 | |2|登记人|系统自动生成 | ||
| 195 | |3|登记时间|生成问题记录的时间(系统自动产生) | ||
| 196 | |4|问题申请人|系统内查询并选择 | ||
| 197 | |5|电话|根据问题申请人自动产生 | ||
| 198 | |6|电子邮件|根据问题申请人自动产生 | ||
| 199 | |7|申请人部门|根据问题申请人自动产生 | ||
| 200 | |8|申请人工号|根据问题申请人自动产生 | ||
| 201 | |9|地点|记录问题发生的地点(手工填写) | ||
| 202 | |10|问题来源|“事件”、“会议”、“性能”、“容量”、“趋势分析”、“变更”、“其他”、“监控”、“应用Bug”、“任务” | ||
| 203 | |11|优先级|参见“优先级” | ||
| 204 | |12|服务类别|参见“事件管理流程”的同类定义 | ||
| 205 | |13|服务子类|参见“事件管理流程”的同类定义 | ||
| 206 | |14|影响范围|“所有用户”、“多个用户”、“单个用户或无明显影响” | ||
| 207 | |15|问题描述|详细描述问题内容(手工填写) | ||
| 208 | |16|是否找到根本原因|“是”和“否” | ||
| 209 | |17|重复问题标记|“是”和“否”(重复问题指经问题专家分析判断后某几个问题是同一个根本原因,则重负问题标记选择为“是”) | ||
| 210 | |18|实际开始时间|手动填写 | ||
| 211 | |19|实际结束时间|手动填写 | ||
| 212 | |20|根本原因|详细记录问题产生的根本原因(手工填写) | ||
| 213 | |21|解决方案|问题解决方案的详细描述(手工填写) | ||
| 214 | |22|无法解决原因|解释问题无法解决的原因(手工填写) | ||
| 215 | |23|结束代码|“变更解决”、“变通解决”、“无法解决”、“取消” | ||
| 216 | |24|关联配置项|记录问题的配置项代码(手工填写) | ||
| 217 | |25|关联的事件单号|记录引发该问题的事件单号(手工填写) | ||
| 218 | |26|关联的变更单号|记录由问题发变更时,关联的变更单号(手工填写) | ||
| 219 | |27|关闭时间|当问题状态更新为“结束并关闭“的时间(手工填写) | ||
| 220 | |28|是否已知错误|“是”和“否”(已知错误指该问题已存在与知识库中,则是否已知错误选择为“是”,未来可与知识管理流程做集成) | ||
| 221 | |||
| 222 | 表1-1问题信息项 | ||
| 223 | |||
| 224 | === === | ||
| 225 | |||
| 226 | == **1.6.2.问题优先级** == | ||
| 227 | |||
| 228 | 问题的优先级是问题处理专家解决问题的参照标准,对于优先级为一级的问题,问题经理应该优先协调资源进行这些问题的解决。问题优先级将遵从事件优先级定义,确保问题优先级符合实际工作需要,定义如下: | ||
| 229 | |||
| 230 | |(% colspan="2" rowspan="2" %)问题优先级判定说明|(% colspan="3" %)影响范围 | ||
| 231 | |所有用户|1个以上用户|1个用户或无明显影响 | ||
| 232 | |(% colspan="2" %)业务关键性|关键(2)|重要(1)|一般(0) | ||
| 233 | |关键业务|关键(2)|一级|二级|四级 | ||
| 234 | |重要业务|重要(1)|二级|三级|四级 | ||
| 235 | |一般业务|一般(0)|三级|四级|五级 | ||
| 236 | |||
| 237 | 表1-2问题优先级 | ||
| 238 | |||
| 239 | === === | ||
| 240 | |||
| 241 | == **1.6.3.问题响应时限和诊断时限** == | ||
| 242 | |||
| 243 | 在问题处理过程中,对于一个问题有响应时限和诊断时限。一方面,需要问题专家在响应问题的时候有时间的概念;另一方面,也需要问题专家在分析、解决问题的时候有时间的概念,并要求问题经理必须实时地督促问题的解决;如果该问题的响应或解决超过了时限,问题专家需要及时线下通告问题经理,由问题经理酌情协调其他问题专家协同解决。 | ||
| 244 | |||
| 245 | 问题优先级对应的响应时限和诊断时限参考下表: | ||
| 246 | |||
| 247 | |问题级别|响应时限|分析时限 | ||
| 248 | |1级问题|5分钟|48小时 | ||
| 249 | |2级问题|20分钟|72小时 | ||
| 250 | |3级问题|20分钟|120小时 | ||
| 251 | |4级问题|30分钟|168小时 | ||
| 252 | |5级问题|60分钟|192小时 | ||
| 253 | |||
| 254 | 表1-3问题响应时限和诊断时限 | ||
| 255 | |||
| 256 | === === | ||
| 257 | |||
| 258 | == **1.6.4.服务类别、服务子类** == | ||
| 259 | |||
| 260 | 请参照事件管理流程说明书的“服务类别、服务子类”章节。 | ||
| 261 | |||
| 262 | |||
| 263 | = **1.7.流程概要设计** = | ||
| 264 | |||
| 265 | [[image:1728892390838-939.png]] | ||
| 266 | |||
| 267 | |||
| 268 | 问题管理流程文字说明: | ||
| 269 | |||
| 270 | |(% style="width:78px" %)序号|(% style="width:145px" %)步骤名称|(% style="width:87px" %)责任人|(% style="width:813px" %)说明 | ||
| 271 | |(% style="width:78px" %)300.1|(% style="width:145px" %)问题记录|(% style="width:87px" %)问题专家|(% style="width:813px" %)问题专家是任意一名IT部门的同事。问题的记录可以通过事件管理流程直接升级或者直接开单。 | ||
| 272 | |(% style="width:78px" %)300.2|(% style="width:145px" %)问题确认分派|(% style="width:87px" %)问题经理|(% style="width:813px" %)问题经理判断问题属于基础架构范畴还是业务应用范畴,然后选择合适的问题专家。 | ||
| 273 | |(% style="width:78px" %)300.3|(% style="width:145px" %)诊断问题并提供解决方案|(% style="width:87px" %)问题专家|(% style="width:813px" %)问题专家诊断问题找出根本原因后提出解决方案、变通方法或预防性措施。 | ||
| 274 | |(% style="width:78px" %)300.4|(% style="width:145px" %)开发、确认、实施解决方案|(% style="width:87px" %)问题专家|(% style="width:813px" %)问题专家开展解决问题的准备工作,制定实施计划等。若解决问题涉及变更,则启动变更管理流程。完成所有准备工作后,实施解决方案。 | ||
| 275 | |(% style="width:78px" %)300.5|(% style="width:145px" %)问题回顾|(% style="width:87px" %)问题专家|(% style="width:813px" %)问题专家观察解决方案实施结果,问题是否已被解决。若问题复发,则问题专家可以选择将流程节点回退到300.3或300.2。若问题确认已解决,问题专家完成问题回顾。 | ||
| 276 | |(% style="width:78px" %)300.6|(% style="width:145px" %)问题总结与关闭|(% style="width:87px" %)问题经理|(% style="width:813px" %)问题经理根据实际需要召集问题专家或点对点与问题专家一起总结该问题的各相关工作环节,并确认问题已解决同时问题信息记录完整可关闭问题 | ||
| 277 | |||
| 278 | 表1-4问题响应时限和诊断时限 | ||
| 279 | |||
| 280 | == == | ||
| 281 | |||
| 282 | = **1.8.关键角色、职责定义** = | ||
| 283 | |||
| 284 | 问题管理流程主要包括问题管理流程负责人、问题经理和问题专家四个角色。 | ||
| 285 | |||
| 286 | === === | ||
| 287 | |||
| 288 | == **1.8.1.问题管理流程负责人** == | ||
| 289 | |||
| 290 | 问题管理流程负责人从总体上对问题管理流程的设计、实施、执行及优化负责,确保问题管理流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时,流程负责人必须及时的对此进行分析、找出缺陷、进行改进,从而实现可持续提高。 | ||
| 291 | |||
| 292 | |||
| 293 | 职责: | ||
| 294 | |||
| 295 | 1. 确保问题管理流程的设计、实施及执行,能够取得管理层的参与和支持 | ||
| 296 | 1. 确保问题管理流程符合公司实际状况和公司 IT发展战略 | ||
| 297 | 1. 整体上对问题管理流程负责,建立流程实施、评估和持续优化机制 | ||
| 298 | 1. 确保问题管理流程的有效执行,定期评估流程,制定流程改进计划 | ||
| 299 | 1. 保持与其他流程负责人的定期沟通 | ||
| 300 | |||
| 301 | 技能要求: | ||
| 302 | |||
| 303 | 1. 深刻理解问题管理流程 | ||
| 304 | 1. 充分理解业务支撑网维护管理流程梳理项目的其他流程,能够进行流程接口设计 | ||
| 305 | 1. 能够很好地理解业务对于问题管理的需求 | ||
| 306 | 1. 对质量控制与保障有很深入的了解 | ||
| 307 | 1. 有决策权,能够确保问题管理流程设计要求在实施项目中得到贯彻和执行 | ||
| 308 | 1. 具有很好的沟通技能,能够取得公司高层的支持,获得所需资源 | ||
| 309 | 1. 具有较强的计划、组织、领导和控制才能,能够综合各方意见,按时制订和定期优化问题管理流程 | ||
| 310 | |||
| 311 | === === | ||
| 312 | |||
| 313 | == **1.8.2.问题经理** == | ||
| 314 | |||
| 315 | 问题经理负责协调日常的问题管理工作,包括对问题的审核、监控、所需资源的协调、定期产生报表等。 | ||
| 316 | |||
| 317 | 职责: | ||
| 318 | |||
| 319 | 1. 领导问题管理小组,确保大家的积极性、技能水平 | ||
| 320 | 1. 定期组织相关人员对事件记录进行分析,发现潜在问题 | ||
| 321 | 1. 确认和审核问题 | ||
| 322 | 1. 必要时对问题进行上报 | ||
| 323 | 1. 监视问题的诊断、分析和处理过程 | ||
| 324 | 1. 必要时与问题专家沟通问题的相关信息 | ||
| 325 | 1. 必要时协调所需资源 | ||
| 326 | 1. 定期制定问题报表,提供正确决策信息 | ||
| 327 | |||
| 328 | 技能要求: | ||
| 329 | |||
| 330 | 1. 具有较好的沟通和口头表达能力 | ||
| 331 | 1. 熟悉技术平台和技术环境 | ||
| 332 | 1. 较强的分析事件趋势的能力 | ||
| 333 | 1. 深刻熟悉问题管理流程 | ||
| 334 | |||
| 335 | === === | ||
| 336 | |||
| 337 | == **1.8.3.问题专家** == | ||
| 338 | |||
| 339 | 问题专家为问题的诊断及解决提供技术支持。通常由各专业组技术人员承担。 | ||
| 340 | |||
| 341 | |||
| 342 | 职责: | ||
| 343 | |||
| 344 | 1. 接受问题经理分派过来的问题 | ||
| 345 | 1. 分析和诊断问题,确定根本原因 | ||
| 346 | 1. 确定和测试解决方案 | ||
| 347 | 1. 提交变更请求并监控变更实施 | ||
| 348 | 1. 协助事件支持人员进行重大或紧急事件的处理 | ||
| 349 | 1. 需要时协调第三方的资源来帮助诊断和改正问题 | ||
| 350 | |||
| 351 | 技能要求: | ||
| 352 | |||
| 353 | 1. 较强的问题解决能力, 能够对问题进行分析并给出解决方案 | ||
| 354 | 1. 较强的专业知识 | ||
| 355 | 1. 较强的分析问题的能力和技巧 | ||
| 356 | 1. 较好的沟通和表达能力 | ||
| 357 | |||
| 358 | === === | ||
| 359 | |||
| 360 | == **1.8.4.流程角色和人员对应表** == | ||
| 361 | |||
| 362 | |角色|成员 | ||
| 363 | |问题管理流程负责人|Stanley | ||
| 364 | |问题经理|Stanley | ||
| 365 | |(% rowspan="2" %)问题专家|IT团队成员 | ||
| 366 | |厂商和服务商的技术专家 | ||
| 367 | |||
| 368 | 表1-5流程角色和人员 | ||
| 369 | |||
| 370 | == == | ||
| 371 | |||
| 372 | = **1.9.流程衡量指标和报表** = | ||
| 373 | |||
| 374 | 问题管理流程的关键衡量指标如下: | ||
| 375 | |||
| 376 | |序号|衡量指标|指标计算说明 | ||
| 377 | |(% rowspan="4" %)1|(% rowspan="4" %)问题总数|数量:在问题单中根据以下条件过滤, | ||
| 378 | |1. 【重复问题标记】为空 | ||
| 379 | |2. 【问题结束代码】不等于‘取消’ | ||
| 380 | |3. 【登记时间】在统计周期内 | ||
| 381 | |2|已找到根本原因的问题百分比|数量:在问题总数中,【找到根本原因】=‘是’ 的问题个数 | ||
| 382 | |5|通过变通办法解决的问题百分比|数量:在关闭问题数量中,【问题结束代码】=‘变通方法’的问题个数 | ||
| 383 | |(% rowspan="2" %)6|(% rowspan="2" %)问题成功解决率|数量:在关闭问题数量中,【结束代码】=‘变更解决 或 变通解决’的问题个数 | ||
| 384 | |比率:数量 /关闭问题数量 × 100 % | ||
| 385 | |||
| 386 | 表1-6问题响应时限和诊断时限 |