Changes for page 12 XX光电IT服务管理问题管理流程设计分册

Last modified by superadmin on 2024/10/12, 12:00

From version < 17.1 >

edited by superadmin
on 2024/10/11, 20:48

To version < 12.1 >

edited by superadmin
on 2024/10/11, 20:43

< >

Change comment: 上传新附件1728650601805-492.png

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 3 removed)

Details

Page properties

Content

@@ -3,1175
          +3,4 @@
  **文档信息**
--[[image:1728649324419-486.png]]
--
--
--**版本记录**
--
--
--|**版本号**|**日期**|**撰写人**|**描述**
--|0.1|2013-10-15|赵XX|拟定文档结构，撰写部分章节
--|0.2|2013-10-23|赵XX|根据workshop收集信息和内部讨论修改
--|0.3|2013-10-30|赵XX|根据反馈修改
--|1.0|2013-11-27|赵XX|修改问题来源，增加打分和绩效考核机制，定稿
--|1.1|2013-12-10|赵XX|修改紧急程度，状态等的说明
--|1.2|2014-01-03|赵XX|修改状态和问题激励机制等
--
--(% class="wikigeneratedid" %)
--=   =
--
--= **1.文档介绍** =
--
--本文档描述了问题管理的设计方案。内容包括在XX光电IT信息中心实现问题管理模块的流程设计和部分平台实现时的代码设计。
--
--该文档的设计不包括在实现问题管理的流程中，XX光电IT信息中心中非项目范围内其他相关部门自定义的流程/步骤的实现，这些特殊的需求/定义由各自相关部门自己来把握。
--
--==   ==
--
--== **1.1.文档用途** ==
--
--本文档一方面作为本次ITSM项目的问题管理流程的设计方案交付物，也可作为XX光电IT信息中心实行问题管理流程的蓝本，读者对象为与问题管理流程相关的所有技术与管理人员。
--
--本文档所描述的流程在IT服务管理中有许多作用，举例如下：
--
--1. 找出事件的根本原因，从而防止同类事件的再次发生；
--1. 根据合适的优先级，合理调整资源分配，降低支持成本；
--1. 确保问题有责任人负责，并对问题有跟踪、评估和回顾；
--1. 协助突发事件处理总结与共享，支持事件管理流程，提高首次修复率；
--1. 提高客户的满意度；
--1. 改进问题预防流程。
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== **1.2.文档结构** ==
--
--文档内容具体如下：
--
--* 第一章 文档介绍
--
--对文档目的和内容进行简单介绍，同时描述文档中用到的ITIL中的术语。
--
--* 第二章 问题管理流程概述
--
--简单描述问题流程，明确目的、范围、内容以及流程政策等。
--
--* 第三章 问题管理流程设计
--
--描述流程设计内容，如：具体流程、流程代码等。
--
--* 第四章 报表
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== **1.3.ITIL相关术语** ==
--
--下面是ITIL中问题管理相关的术语：
--
--* 问题管理：即Problem Management
--
--是负责解决重大紧急问题或具有相同特征的一组问题的运维流程。它的目的是找出产生这些问题的根本原因，并通过永久性解决方案防止类似问题的再次发生，同时问题管理流程也通过主动式管理降低问题发生的数量。
--
--* 问题
--
--问题是存在某个未知的潜在原因的一种情形，这种原因会导致一起或多起突发事件发生。问题管理经常是分析多个呈现相同症状的事件后发现的某种情形。问题也可从单个重要的事件中确认以表示一项错误。这种错误产生的原因虽然未知，但其产生的影响却可能是非常严重的
--
--* 错误
--
--指问题经过诊断分析后找到突发事件产生的根本原因但并未找出可能的解决方案时所处的状态。
--
--* 已知错误
--
--已知错误是指问题经过诊断分析后找到突发事件产生的根本原因并制定出可能的解决方案时所处的状态。
--
--* 变通方法（Workaround, 有时也称临时规避措施，应对措施）
--
--“变通方法”是相对“根本解决方法”而言的，是指没有根本解决一个问题引起的故障，但恢复了问题影响的服务（或业务）的方法。“变通方法”定义本身也说明了：事件管理流程的目的是在规定时间内恢复服务（或业务），而不完全是针对问题本身。问题管理流程目的是找到根本原因，并尽可能根本解决
--
--* 问题控制
--
--问题控制是对发现的问题进行归类、调查和分析从而提出解决方案或应急措施的流程
--
--* 错误控制
--
--错误控制是对已知错误进行处理和控制的流程。在问题控制将已知错误转交给错误控制之后，错误控制需要向变更管理提交变更请求，再由变更管理实施变更后最终消除已知错误
--
--* 主动问题管理
--
--根据对IT基础架构进行的分析，问题管理可以找到可能出现问题的薄弱环节，在突发事件发生前发现和解决有关问题和已知错误，尽量减少问题和已知错误对业务的影响
--
--
--
--= **2.问题管理流程概述** =
--
--
--== **2.1.基本概念** ==
--
--
--=== **2.1.1.什么是问题管理流程** ===
--
--问题管理流程的根本目的是消除或减少事件的发生，此流程分析发生在生产环境的事件，确定最常发生或具有最大影响的事件，找出根本原因，然后生成变更请求（RFC）、变通方法或建议的预防性措施来防止事件的再次发生。所以问题管理流程可能需要和变更管理流程一起来实施找出的解决方案以从根本上解决问题。
--
--问题的来源：
--
--* 已发生的一个或多个有共同征兆的事件
--* 系统运行期间发生的重要突发事件
--* 系统的运行趋势分析中发现的问题
--
--问题管理的输入有：
--
--* 从事件管理中得到的故障详细信息
--** 故障现象
--** 故障的处理方法和解决方案
--** 故障发生的频率和影响程度及紧急程度
--* 从配置管理数据库中得到的配置详细信息
--** 相关的配置信息
--** 配置项之间的关联关系
--* 从故障管理中得到的替代方法
--
--问题管理流程的输出有：
--
--* 解决方案
--* 变通方法
--* 变更请求
--* 预防性措施
--
--问题管理的输出可以被当作知识内容用于支持前端的事件管理过程，使事件管理操作者能够通过查询历史问题的解决方案，快速的完成事件的处理，同时，问题管理应还配合事件管理，集中优势资源为没有变通方法的疑难突发事件处理提供解决支持。
--
--==   ==
--
--== **2.2.流程目的** ==
--
--问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，提高IT服务的可用性。此流程对发生在生产环境中的问题进行管理，找出产生这些问题的根本原因，然后根据需要通过变更请求(RFC)、变通方法或建议的预防性措施来防止事件的再次发生。问题管理流程常常需要和变更管理流程一起来实施找出的解决方案，以便从根本上解决问题。其目的包括：
--
--* 分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生
--* 确保问题分派了正确支持人员，提高解决率
--* 根据问题优先级合理分派IT资源
--* 对事件记录做趋势性分析，主动提供预防性措施
--* 提高服务的可靠性
--* 降低支持成本
--
--==   ==
--
--== **2.3.管理范围** ==
--
--问题管理主要针对XX光电IT信息中心服务运营过程中遇到的所有问题的记录、跟踪、评估、处理、回顾，以及知识共享。其范围与事件管理中事件管理范围一致。
--
--问题管理负责处理的范围包括：
--
--* 来自于事件管理的重要突发事件，未能解决且无变通方法
--* 来自于事件管理的重要突发事件，有变通方法
--* 来自于阶段性事件总结，多个呈现相同症状的突发事件提取出的问题
--* 来自于定期的系统分析报告的问题
--
--==   ==
--
--== **2.4.主要内容** ==
--
--问题管理流程主要涉及问题控制、错误控制和主动问题管理三种活动。其流程内容如下：
--
--[[image:1728649676157-590.png]]
--
--
--**问题控制：**
--
--* 发现和记录问题
--
--问题控制的第一步是要发现和记录问题。所有导致突发事件产生的未知原因都可以称为问题，但我们通常只将那些重复发生的或非常严重的突发事件归类为问题。问题记录与突发事件记录类似但并不完全相同。突发事件记录强调是受影响的用户数量、影响度等信息，而问题记录则更侧重于突发事件症状、与突发事件相关的基础架构的运行情况等信息。问题记录应与相关事件关联
--
--* 问题归类
--
--在查明和记录问题后，为了评估问题可能对服务级别产生的影响，应首先对问题进行归类。问题归类应当根据问题涉及的领域、影响度和紧迫性等因素进行确定，与事件管理不同，问题归类不是静态的，它在问题生命周期内可能发生调整，如，应急措施可以降低问题的紧迫性，而新出现的突发事件却可能会提高问题的影响度。
--
--* 调查和分析问题
--
--问题调查是要找出问题存在的根源，因此问题调查比突发事件调查要更加全面深入，对导致突发事件的未知原因展开调查后，需要对这些原因进行分析和测试，以确定其是否是问题产生的最主要和最根本的原因。问题分析可通过多种分析方法进行，如：鱼骨图法、头脑风暴法等。
--
--
--**错误控制**
--
--* 发现和记录错误
--
--在问题控制流程查明了问题产生的根本原因，问题就转化为错误，如果同时针对这些错误提出了相关的应急措施，错误就进一步升级为已知错误，问题管理人员需要将问题标记为已知错误存放在问题管理数据库中，以便与事件管理人员共享处理信息和继续问题处理
--
--* 评价错误
--
--在发现和记录错误后，问题管理人员应与其他支持人员一起对解决错误的可能方法进行初步评估，并根据对错误评价的结果制定相应的解决方案
--
--* 记录错误解决过程
--
--在问题管理人员提出解决错误的方案后，错误控制流程应详细记录每个已知错误的解决过程，特别是与已知错误有关的配置项、症状和解决方案，记录的信息可保存于已知错误数据库中备查
--
--* 提出变更请求
--
--发现的已知错误消除时需要改变IT基础架构时，应向变更管理流程提出变更请求，由变更管理处理变更过程
--
--* 问题解决评估
--
--在实施错误解决方案或变更后，问题管理人员需要继续跟踪和监督错误解决过程，必要时应进行实施后评审来确认问题的解决效果
--
--* 问题终止
--
--在确认问题和已知错误得到较好的解决后，问题管理可以终止错误控制流程。同时需要将有关问题的更新信息存入问题数据库中
--
--
--**主动问题管理**
--
--* 趋势分析
--
--趋势分析的目的是为了能够主动采取措施提高服务质量，它可以从以下几个方面进行：
--
--1. 找出基础架构中不稳定的组件
--1. 跟踪分析已发生的突发事件和问题，研究趋势
--1. 通过其它方式和途径分析，如：系统管理工具、用户反馈、座谈会和用户调查
--
--* 制定预防措施
--
--在确定服务支持人员应重点关注的问题之后，问题管理人员就应当采取适当的行动以预防其发生。这些行动包括：
--
--1. 提交变更请求（RFC）
--1. 对服务支持人员、客户教育和培训
--1. 改进相关的流程或程序
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== **2.5.业务价值** ==
--
--问题管理流程将在多方面对华星光电IT信息中心的IT服务产生积极作用，具体表现在：
--
--* 提高服务可用性
--
--通过把单个事件的影响最小化和减少事件的总体数量（预防问题），更多的用户有更多的时间可以使用服务。
--
--* 提高服务质量
--
--在解决事件／问题时，遵循相关的已知错误记录下来的解决方案或信息可以提高服务质量。同样，潜在的故障消除后，执行的服务也更和客户的服务期望相一致。
--
--* 总结经验
--
--问题管理分析历史事件资料以找出可能不被发现的趋势。
--
--* 提高突发事件记录的质量
--
--问题管理通过引入突发事件记录和分类标准，能够更容易发现突发事件、描述突发事件症状，从而提高突发事件报告质量
--
--* 提高IT员工的工作效率
--
--问题分析员所做的工作可以被一线支持人员所学习、采纳，从而可以处理更多的事件故障，并可以大大提高首次修复率。
--
--* 更大的服务控制
--
--管理层通过改进的管理信息可以更好地改进监视服务指标和维护合约。
--
--==   ==
--
--== **2.6.政策与建议** ==
--
--XX光电IT信息中心认识到建立以ITIL为指导的IT服务管理流程对公司IT运维的重要性和必要性，并能够支持所必要的IT服务流程、角色职责和服务质量考核的变革工作。
--
--XX光电IT信息中心在具体的问题管理流程执行过程中，应能够遵守如下的流程政策：
--
--* 规定1：问题管理流程和事件管理流程应相互独立，但具有紧密关系。
--** 必须确定问题根源
--** 事件管理和问题管理具有不同目的，必须分开独立管理
--** 问题管理流程需要和事件管理建立接口
--
--* 规定2：问题管理资源应分配给对业务影响最大的问题或事件
--** 问题必须进行影响度和优先级分类
--** 问题必须被分配给最合适的资源
--** 对影响度最大的问题必须优先分配资源
--
--* 规定3：问题管理流程需对从事件管理系统中采集的数据和其他数据源（如事件日志）数据进行根本原因分析和趋势分析并给出问题的长期性解决方案或建议
--** 应用和系统问题必须优先被检测出来
--** 问题必须进行分类以便于找出潜在原因
--** 问题的解决方案需进行测试并通过变更管理流程实施
--
--* 规定4：对问题必须进行事后回顾，目的是为了预防问题再次发生和发现改进流程的机会
--** 问题或事件必须一直被跟踪直到被解决
--** 问题必须有问题结束代码
--** 问题必须有不同的状态代码
--** 对于重大问题进行回顾分析，以找出改进机会
--
--* 规定5：负责管理已知错误/知识库，向华星光电IT信息中心其他管理流程或部门提供关于问题及其建议方案的信息（如培训，发布公告等方式）
--** 问题的解决方案必须被记录下来
--** 所有事件必须进行登录
--** 事件管理流程的报表必须分发、分析和采取行动
--** 事件管理流程记录事件的形式和分类方法必须允许问题管理能有效运行
--
--* 规定6：问题管理人员定期组织会议，对所处理事件记录进行分析，确定主动性问题的管理趋势
--** 会议参加者至少包括事件管理经理及问题管理经理
--** 会议可每月定期组织一次
--** 对某一类事件数量增长达30%以上者，可作为问题分析
--
--==   ==
--
--== **2.7.与其它流程的关系** ==
--
--[[image:1728649963652-583.png]]
--
--
--* 和事件管理流程的关系
--** 问题管理流程需要来自事件管理流程的详细、精确的记录信息来定位问题及分析问题的趋势
--** 通过问题管理流程找到产生事件及问题的根本原因，并进行解决，从而大大降低重复事件的发生
--
--* 和配置管理流程的关系
--** 需要从配置管理数据库中查询配置项的属性和配置项间的关联关系
--
--* 和变更管理流程的关系
--** 为了从根本上解决已知错误，往往需要通过变更才能实现，问题管理将提出变更请求提交到变更管理流程
--
--注：
--
--1. 考虑到问题调查时间会因为问题的难易程度波动较大，本期不设置对问题管理统一的OLA目标进行自动监控，而是在流程信息项中增加计划开始和计划结束时间，实际开始和实际结束时间来按问题的实际情况加以计划和监控。监控主要由问题协调员负责。
--1. 问题记录单本身可以作为一种知识进行查询和参考。是否需要将有价值的问题记录单按统一的格式整理成知识参照知识管理流程的要求进行。
--
--
--= **3.问题管理流程设计** =
--
--
--== **3.1.问题管理流程角色和职责** ==
--
--
--=== **3.1.1.流程角色和职责** ===
--
--根据XX光电IT信息中心实际情况，在问题管理的过程中我们定义了三种角色：问题经理、问题协调员和问题分析员，定义如下：
--
--====   ====
--
--==== **3.1.1.1.问题经理** ====
--
--职责：
--
--* 确保制定清晰有效的工作流程和准则
--* 提供关于IT服务和客户支持的正确有效的管理信息，生成有效的管理报表
--* 对问题协调员注册的问题设置优先级并对其进行计划。
--* 如果需要，与利益相关者沟通。
--* 如果需要，通知变更经理。
--* 如果需要，延迟问题。
--* 根据已知错误的调查结果作出决定。
--* 注册变更请求或服务请求来解决已知错误。
--* 执行问题审核并记录所获经验。
--* 关闭问题并通知利益相关者。
--* 监控问题和已知错误解决进度并执行必要的操作。
--
--主要技能：
--
--* 深刻了解问题管理流程
--* 熟悉各个业务系统的运维
--* 较强的流程规划和制定能力
--* 较强的组织和协调能力
--* 具备一定企业管理知识
--
--主要考核指标：
--
--* 流程的有效性
--
--====   ====
--
--==== **3.1.1.2.问题协调员** ====
--
--职责：
--
--* 定期执行分析以确定是否需要注册新问题。
--* 注册问题。
--* 将工作分配给问题分析员并协调根本原因分析。
--* 确认问题的根本原因并标记为已知错误。
--* 通知问题经理。
--* 将已知错误分配给问题分析员。
--* 确认建议的已知错误解决方案。
--* 确认关闭变更的结果并关闭已知错误。
--* 确认是否已解决问题。
--
--主要技能：
--
--* 熟悉技术平台和技术环境
--* 较强的客户沟通和口头表达能力
--* 决策的能力
--* 深刻熟悉问题管理流程
--* 熟悉问题管理流程和其他流程之间的关系
--
--主要考核指标：
--
--* 问题成功解决的百分比（问题解决和未解决的比值）
--* 资源的有效使用（问题解决过程中人员的分派，相关人力、物力的协调）
--* 控制系统的使用情况（通过报表统计问题生成、解决的过程，及时了解一定时期内问题管理状况）
--* 问题处理的效率（一段时间或前后时间段问题处理数量与重复事件数量的对比，问题平均处理时间）
--
--====   ====
--
--==== **3.1.1.3.问题分析员** ====
--
--职责：
--
--* 调查、诊断和验证已分配问题的应对措施和/ 或根本原因。
--* 审核和接受或拒绝已分配的已知错误。
--* 调查、诊断和验证分配的已知错误和建议的解决方案及应对措施。
--* 实施修正操作并关闭已知错误。
--
--主要技能：
--
--* 很强的问题解决能力， 能够对问题进行分析并给出解决方案
--* 较强的专业知识
--* 较强的分析问题的能力和技巧
--* 较好的沟通和表达能力
--
--主要考核指标：
--
--* 解决的问题个数（包括升级的事件和主动发现事件）
--* 处理升级的事件的个数（升级事件产生的问题基本上是紧要的，需要尽快处理）
--* 当前事件中的重复事件数和问题发现数比值
--* 解决方案修改次数（解决方案能够彻底解决根本的原因，而不是不断的出现递进的变通的方法）
--* 未解决问题数
--
--问题管理中的问题分析员角色与事件分析员角色理论上最好由不同人员担当，以增强问题处理的有效性和逻辑性，但在XX光电IT信息中心当前的情况下角色重合是不可避免的问题，那么在当前状况下问题管理对XX光电IT信息中心的现实意义何在呢?
--
--当前的问题分析员目前的岗位说明他有较强的专业能力，能够解决各自专业内的问题，同时，他们也与其他部门或厂商保持较好的关系。问题管理和事件管理的分离使得身兼事件分析员和问题分析员的人员能够获得更充足的时间和资源对问题的根源进行分析挖掘，协调、管理第三方资源进行问题的分析，评估和应对。当然这也要求问题协调员能够与内外部建立良好的合作关系，以突破问题分析时资源的局限性。
--
--===   ===
--
--=== **3.1.2.XX光电IT信息中心角色与人员映射** ===
--
--根据当前所属专职不同分配如下，具体如下表：
--
--|角色|成员
--|**问题经理**|陈XX
--|**问题协调员**|各科长
--|**问题分析员**|事件分析员（二线技术支持）、三线技术支持（厂商等）
--
--==   ==
--
--== **3.2.问题流程代码定义** ==
--
--流程代码是问题管理流程不可或缺的一部分，是对问题管理流程关键环节的详细描述的必要准备。本章节后续将详细描述：问题信息项、问题来源、问题分类、问题影响度、问题优先级、问题状态、问题结束、问题原因等代码，这些内容将在流程的具体描述中使用。
--
--===   ===
--
--=== **3.2.1.问题信息项** ===
--
--问题单包含如下信息项：
--
--|**信息项**|**描述**
--|问题ID（ID）|为每个问题分配一个唯一的序列号（系统自动产生）
--|登记时间(Open)|生成问题记录的时间（系统自动产生）
--|问题优先级(Priority)|参见“问题优先级”定义
--|问题分类(Category)|参见“问题分类”定义
--|问题描述(Description)|详细描述问题内容
--|变通方法(Workaround)|详细记录问题的变通方法
--|问题原因(Cause)|详细记录问题产生的根本原因
--|问题状态(Status)|参见“问题状态”定义
--|分配组(Assignment Group)|将问题分配到各问题组
--|分配人员(Assignee)|将问题分配到各组问题处理专家）
--|问题日志(Activities)|反映问题处理过程中问题信息项的变化历史，包括分配的人员，状态等信息
--|计划开始时间|计划问题调查开始时间
--|计划结束时间|计划问题关闭时间
--|实际开始时间|实际问题调查开始时间
--|实际结束时间|实际问题关闭时间
--|解决方案|问题解决方案的详细描述
--|问题结束代码|参见“问题结束代码”定义
--|问题无法解决原因|解释问题无法解决的原因
--|关联信息|记录问题的关联信息，如事件单，配置项，变更号，交互号
--|已知错误标记|标记该问题已经找到根本原因，成为已知错误
--|问题关闭时间|当问题状态更新为“结束并关闭“的时间（系统自动产生）
--|问题来源(Problem Source)| 参见“问题来源”定义
--
--(% class="wikigeneratedid" %)
--===   ===
--
--=== **3.2.2.来源** ===
--
--根据问题的不同来源对问题分类如下：
--
--|**编号**|**代码**|**描述**
--|1|重大事件|来自一/二级事件
--|2|晨会|来自每日的晨会
--|3|风险评估会|来自专题风险评估会
--|4|员工主动提出|员工根据自己判断提出的问题
--|5|其他|不包括在上述来源中的问题，请尽量少用
--
--注意：
--
--未解决的、变通方法解决的，可以直接做为问题管理流程的输入，对于未解决事件事件的优先级通常为最高和高，这部分问题我们在处理过程中要以提出变通方法并解决为目标，是事件管理流程的扩展，也需要对处理时间严格控制。
--
--重复的事件通过报表分析获得，可以把排名靠前的事件分批输入到问题管理流程。
--
--有增加趋势的事件通过报表分析获得（如：某系统故障：上月20个，本月30个），应该尽快输入到问题管理流程中处理。
--
--在突发事件管理流程中，定义了与事件发生趋势的报表IM-006至 IM-011, 问题管理人员也可以根据需要定义更多的报表，如某一重要配置项上发生的突发事件趋势图
--
--需要强调的是，问题管理为事件管理提供变通方法和解决方案，这并不意味着可以在事件管理周期中不做处理。事件管理在处理过程中应尽力从知识库和个人经验中寻找事件的解决方法，以保证事件处理的可控性。任何一个关闭的事件，至少具备变通方法。未解决且没有变通方法的事件，建议根据实际需要升级成问题，多方寻求变通方法以尽快恢复服务。下图说明了问题管理和事件管理间处理的界限
--
-- [[image:1728650221954-912.png]]
--
--===   ===
--
--=== **3.2.3.领域/子领域** ===
--
--问题分类参照突发事件的分类。
--
--===   ===
--
--=== **3.2.4.影响度代码** ===
--
--参照事件流程的影响度划分，定义问题流程的影响度代码。
--
--问题影响度用于衡量事件所影响业务的范围。影响范围通常通过问题所影响的人数、关键系统数以及服务故障所造成的损失来设定。
--
--定义问题影响度等级的因素有：
--
--* 是否影响了关键应用
--* 所影响的用户范围
--* 服务失效的影响范围
--
--下表是当前定义的影响度，后续可根据实际变化进行调整。
--
--|序号|代码|描述
--|1| 公司|影响范围为全公司
--|2| 生产厂 |影响范围为一个或多个厂
--|3| 产线|影响范围为一条或多条生产线
--|4| 个人|影响范围为一个或多个个人
--
--(% class="wikigeneratedid" %)
--===   ===
--
--=== **3.2.5.紧急度代码** ===
--
--问题紧急度决定问题需要处理的急迫程度。
--
--|序号|代码|描述
--|1|紧急|需要当天开始处理
--|2|急|需要2天内开始处理
--|3|普通|需要3天内开始处理
--|4|低|处理开始时间可以有问题协调员或经理决定
--
--(% class="wikigeneratedid" %)
--===   ===
--
--=== **3.2.6.优先级代码** ===
--
--参照事件流程的优先级定义，定义问题流程的优先级代码。问题的优先级(Priority) 决定了问题的处理次序和期限。问题的优先级根据问题的影响度和问题的紧急度代码计算决定。算法为：优先级=[(影响度+紧急度)/2]. “[]”表示取整。
--
--|序号|代码|描述
--|1|优先级1|重大故障处理的优先级，用于严重影响业务应用的突发事件处理.
--|2|优先级2|特殊服务事件的处理，用于紧急服务事件的处理
--|3|优先级3|一般故障处理的优先级，用于中等业务影响度的服务
--|4|优先级4|故障处理中最低的优先级，一般用于业务影响度低的服务，有时需要预约时间
--
--(% class="wikigeneratedid" %)
--===   ===
--
--=== **3.2.7.状态** ===
--
--缺省的问题状态/已知错误状态如下：
--
--|**编号**|**代码**|**描述**
--|1|打开|问题/已知错误由问题提交人或问题协调员提交到到系统中
--|2|计划中|问题/已知错误已被问题协调人接受，进行时间计划和人员指派
--|3|处理中|问题/已知错误由指派的问题分析员处理中
--|4|挂起中|由于跨部门，资源等原因提请问题经理协调中
--|5|已处理|问题关闭前提请问题经理质量审核，回顾中
--|6|已关闭|问题已经关闭
--
--(% class="wikigeneratedid" %)
--===   ===
--
--=== **3.2.8.结束代码** ===
--
--为了表明问题的不同解决方式，定义如下结束代码：
--
--|**编号**|**代码**|**描述**
--|1|变更解决|找出问题的根本原因，并得到解决方案，通过变更流程成功解决
--|2|变通方法|没有根本解决方案或目前没有办法实施根本解决方案，但有临时解决方案作为变通方法
--|3|无法解决|未找到问题的根本原因，没有解决方案，或目前无法实施解决方案，也无变通方法
--|4|取消|问题被问题经理拒绝
--
--(% class="wikigeneratedid" %)
--===   ===
--
--=== **3.2.9.原因代码** ===
--
--|编号|代码|描述
--|1|软件错误|由项目BUG导致的问题
--|2|硬件故障|硬件故障类问题
--|3|线路故障|线路故障类问题
--|4|其他|其他问题
--
--(% class="wikigeneratedid" %)
--==   ==
--
--== **3.3.问题管理流程概要设计** ==
--
--问题管理概要流程是根据华星光电IT信息中心的具体情况，结合HP ITSM的最佳经验，并通过与XX光电IT信息中心人员的共同讨论最终确定的。问题管理概要流程主要从整体上描述问题的处理过程，不会体现具体的细节和涵盖所有的人员，但能够体现当前可能输入和输出。
--
--[[image:1728650292284-661.png]]
--
--
--问题管理概要流程描述如下：
--
--|**序号**|**步骤名称**|**责任人**|**说明**
--|SO4.1|问题检测、记录和分类|问题协调员|(% rowspan="8" %)请参考后面的章节
--|SO4.2|问题优化和计划|问题协调员
--|SO4.3|问题调查和诊断|问题协调员/问题分析员
--|SO4.4|已知错误记录和计划|问题协调员/问题经理
--|SO4.5|已知错误调查|问题协调员/问题分析员
--|SO4.6|确认已知错误解决方案|问题经理
--|SO4.7|已知错误解决方案|问题协调员
--|SO4.8|问题的关闭和审核|问题协调员/问题经理
--
--在流程的各个阶段，各角色直接的交互活动和问题记录的状态转换如下：
--
--[[image:1728650320753-740.png]]
--
--
--== **3.4.问题管理流程详细设计** ==
--
--问题管理详细流程设计如下：
--
--===   ===
--
--=== **3.4.1.（SO4.1）问题检测、记录和分类** ===
--
--[[image:1728650347286-339.png]]
--
--
--详细流程描述如下:
--
--|**序号**|**步骤名称**|**责任人**|**说明**
--|SO4.1.1|(((
--审核已关闭的突发事件
--
--)))|问题协调员|(((
--问题协调员应该定期审核已关闭的突发事件，以检测新问题或将突发事件与尚未解决的现有问题相匹配。对突发事件数据进行分析可能会发现报告的突发事件中有相似的或重复出现的，这意味着必须找到永久性修复措施。使用以下条件选择自上次审核之后的突发事件：
--
--* 重大突发事件（影响大）
--* 通过应对措施或临时修复措施解决的突发事件（未与问题相关联）。
--* 可疑问题（由利益相关者识别）
--* 备选问题项
--)))
--|SO4.1.2|(((
--突发事件是否由未决问题引起？
--
--
--)))|问题协调员|(((
--* 验证突发事件是否由未决问题或已知错误引起。如果是，请转至 SO4.1.3。
--* 如果不是，请转至 SO4.1.4。
--* 将突发事件关联到现有问题对于监控重复出现的突发事件数量很重要，它有助于确认尚未解决的问题。
--)))
--|SO4.1.3|(((
--将突发事件与未决问题相关联
--
--
--)))|问题协调员|(((
--* 如果突发事件是由未决问题引起的，则突发事件必须链接到问题记录。
--* 请在需要时更新问题记录单并通知问题分析员（例如，采取了应对措施时）。
--* 过程结束。
--)))
--|SO4.1.4|创建新问题|问题协调员|(((
--* 如果以前没有创建问题记录，将会创建一个新的问题记录（例如，基于所选的突发事件记录）。将突发事件的详细信息复制到问题记录中。
--* 可以从已注册的突发事件（被动问题管理）或通过在突发事件出现之前主动识别问题和已知错误来创建新问题。
--)))
--|SO4.1.5|(((
--获取问题详细信息
--
--
--)))|问题协调员|(((
--当识别或检测到问题后，必须将其准确地记录下来。填写问题的详细信息（从相关突发事件中复制一些字段）。添加或更新详细描述，以便更详细地定义问题。必须从业务角度按照问题的症状和影响描述问题。问题详细信息的记录由以下活动构成：
--
--* 确定受影响的服务和配置项
--* 确定业务上的影响
--* 提供影响代码和描述
--* 确定突发事件重复出现的频率。
--* 确定可能发生服务中断的特定条件。
--)))
--|SO4.1.6|确定问题分类|问题协调员|确定问题记录的正确分类
--|SO4.1.7|(((
--将突发事件与问题相匹配
--
--
--)))|问题协调员/突发事件分析员|(((
--* 搜索由此问题引起的突发事件。将这些突发事件与新问题关联。
--* 突发事件也可由突发事件管理人员进行关联。
--)))
--|SO4.1.8|(((
--应对措施是否可用？
--
--
--)))|问题协调员|(((
--* 根据突发事件历史记录，验证应对措施或修复措施是否可用。如果是，请转至 SO4.1.9。
--* 如果不是，请转至 SO4.1.10。
--)))
--|SO4.1.9|记录应对措施|问题协调员|记录从相关突发事件获取的应对措施。
--|SO4.1.10|提交问题|问题协调员|(((
--* 审核并完成问题记录详细信息。保存问题记录。完成注册和分类后，必须将问题阶段更新到“问题优化和计划”
--)))
--|SO4.1.11|执行趋势分析|问题协调员|(((
--* 审核事件和监控数据（例如，性能和可用性趋势）。
--* 分析由可用性、容量和安全管理提供的数据，以确定潜在问题。
--)))
--|SO4.1.12|审核供应商发布的问题|问题协调员|(((
--* 定期审核来自供应商的信息，以确认问题和已知错误（即由提供商发现并发布的已知错误）。
--)))
--|SO4.1.13|是否与
--未决问题相关？|问题协调员|(((
--* 分析可疑问题，确定是否需要调查或是否可将已确认的问题与未决问题或已知错误相关。
--* 当通过趋势分析或从供应商和开发团队提供的信息检测到潜在问题后，需要对其进行评估，以确定是否已将此情况作为一个问题或已知错误进行了记录。例如：发现的与此问题相关的其他信息或新信息。如果是，请转至 SO4.1.14。如果不是，请继续 SO4.1.4。
--)))
--|SO4.1.14|更新未决问题|问题协调员|(((
--* 使用从供应商和其他来源获取的信息和详细信息更新问题记录（和任意相关的已知错误）。更新之后，可能要将这个新结果通知利益相关者和负责的问题分析员
--)))
--
--===   ===
--
--=== **3.4.2.（SO4.2）问题优化和计划** ===
--
--[[image:1728650426061-334.png]]
--
--详细流程描述如下:
--
--|**序号**|**步骤名称**|(% style="width:103px" %)**责任人**|(% style="width:800px" %)**说明**
--|SO4.2.1|评估问题优先级|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 问题优先级是基于影响、紧急程度、严重度、频率和风险来评估的。例如，突发事件重复出现的频率可能会影响到解决问题的紧急程度；
--* 也有可能需要进行风险评估。由于资源限制，重点处理对业务影响最大的问题（例如，服务可用性、风险和客户满意度）非常重要。
--)))
--|SO4.2.2|与利益相关者一起讨论问题|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 与利益相关者在问题会议中一起讨论问题，以求在解决问题的优先级上达成一致。
--)))
--|SO4.2.3|是否正确记录了问题？|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 根据与利益相关者一起审核的结果，确定是否已对问题进行了正确的记录和分类。
--* 如果是，请继续活动 SO4.2.4。如果不是，请返回活动 SO4.1.5，更新问题详细信息。
--)))
--|SO4.2.4|是否需要对问题进行调查？|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 在与利益相关者一起审核问题后，确定是否继续调查此问题或延迟此问题。
--* 如果是，请继续 SO4.2.5。如果不是，请转至 SO4.2.7。
--)))
--|SO4.2.5|计划问题|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 为问题处理确定目标日期。根据优先级和对受影响服务的影响确定目标日期。
--* 此计划还需考虑是否有有效的应对措施或修复措施可用。问题将被分配到分配组。
--* 将问题更新到下一阶段“查找问题根本原因”。
--)))
--|SO4.2.6|通知利益相关者|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 向利益相关者通知计划和问题调查的资源分配。
--
--
--)))
--|SO4.2.7|问题是否不再相关？|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 确定是要关闭问题还是将问题延迟一段指定的时间（例如，在后续阶段审核问题）。可能当前不需要为问题调查计划人工（例如，重复出现的可能性低）。
--* 如果利益相关者不把此问题当作问题，则将该问题关闭。必须记录其原因。将问题阶段更新到“问题关闭与审核”。
--* 请继续 SO4.8.8。
--* 如果问题仍然相关，则继续 SO4.2.8。
--)))
--|SO4.2.8|延迟问题并记录原因|(% style="width:103px" %)问题协调员|(% style="width:800px" %)(((
--* 问题将延迟一段指定的时间。
--* 记录原因并更新问题的状态（延迟状态）。
--* 问题协调员会定期对已延迟的问题进行审核以确定采取适当措施。
--)))
--
--===   ===
--
--=== **3.4.3.（SO4.3）查找问题根本原因** ===
--
--[[image:1728650488819-486.png]]
--
--
--详细流程描述如下：
--
--|**序号**|**步骤名称**|(% style="width:98px" %)**责任人**|(% style="width:781px" %)**说明**
--|SO4.3.1|协调根本原因分析|(% style="width:98px" %)问题协调员|(% style="width:781px" %)(((
--* 确定问题调查所需的技能和资源。
--* 分配问题分析员。所分配任务的截止日期由问题协调员填充。此分析还可以使用其他资源（例如，联系供应商和其他专业技术人员）。
--* 监控未决问题任务。
--)))
--|SO4.3.2|调查和诊断|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 问题分析员将查看问题，然后对问题进行调查和诊断。
--* 确定应对措施并查找根本原因。
--)))
--|SO4.3.3|是否已找到根本原因？|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 如果是，请继续 SO4.3.4。
--* 如果不是，请转至 SO4.3.5
--)))
--|SO4.3.4|记录根本原因|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 在问题中记录根本原因。
--* 请继续 SO4.3.10
--)))
--|SO4.3.5|应对措施是否已确定？|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 如果是，请继续 SO4.3.6。
--* 如果不是，请继续 SO4.3.9
--)))
--|SO4.3.6|测试应对措施|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 测试已确定的应对措施，以验证其解决相关突发事件的适用度
--)))
--|SO4.3.7|应对措施是否成功？|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 如果不成功，请转至 SO4.3.9
--)))
--|SO4.3.8|记录应对措施|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 更新应对措施，并通知利益相关者
--)))
--|SO4.3.9|是否继续分析根本原因？|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 分析员确定他或她是否有调查和确定问题根本原因的能力（即，技能级别和可用时间）。
--* 如果是，请继续 SO4.3.2。如果不是，请转至 SO4.3.10
--)))
--|SO4.3.10|通知问题协调员|(% style="width:98px" %)问题分析员|(% style="width:781px" %)(((
--* 问题分析员通知问题协调员找到根本原因或无法找到根本原因
--* 请继续活动 SO4.3.11
--)))
--|SO4.3.11|是否已确定根本原因？|(% style="width:98px" %)问题协调员|(% style="width:781px" %)(((
--* 问题协调员将验证问题分析员的工作结果。
--* 如果找到根本原因，请继续 SO4.3.14
--* 如果未找到根本原因，请转至 SO4.3.12，并确定是否需要额外资源或进行升级
--)))
--|SO4.3.12|是否需要额外资源？|(% style="width:98px" %)问题协调员|(% style="width:781px" %)(((
--* 确定调查问题原因是否需要额外资源。
--* 如果是，请转至 SO4.3.13。
--* 如果不是，请继续 SO4.3.1
--)))
--|SO4.3.13|通知问题经理|(% style="width:98px" %)问题协调员|(% style="width:781px" %)(((
--* 升级到问题经理。通知问题经理解决此问题需要额外资源。
--* 将问题阶段修改为前一个阶段。
--* 请继续 SO4.2.1
--)))
--|SO4.3.14|是否由待定已知错误引起|(% style="width:98px" %)问题协调员|(% style="width:781px" %)(((
--* 根据确定的根本原因决定是否与待定的已知错误相关
--)))
--|SO4.3.15|将问题与待定已知错误关联|(% style="width:98px" %)问题协调员|(% style="width:781px" %)(((
--* 标记问题为已知错误并与待定的已知错误相关联，问题合并处理
--)))
--
--===   ===
--
--=== **3.4.4.（SO4.4）已知错误记录和计划** ===
--
--[[image:1728650550278-872.png]]
--
--详细流程描述如下：
--
--|**序号**|(% style="width:160px" %)**步骤名称**|(% style="width:89px" %)**责任人**|(% style="width:795px" %)**说明**
--|SO4.4.1|(% style="width:160px" %)标记问题为已知错误|(% style="width:89px" %)问题协调员|(% style="width:795px" %)(((
--* 在成功诊断问题后，标记问题为已知错误
--)))
--|SO4.4.2|(% style="width:160px" %)(((
--确定分类
--
--
--)))|(% style="width:89px" %)问题协调员|(% style="width:795px" %)(((
--* 根据根本原因描述，确定原有分类是否正确。必要时修改分类信息
--)))
--|SO4.4.3|(% style="width:160px" %)应对措施是否已确定？|(% style="width:89px" %)问题协调员|(% style="width:795px" %)(((
--* 如果已确定应对措施，请继续 SO4.4.4。
--* 如果没有，请继续 SO4.4.6
--*
--)))
--|SO4.4.4|(% style="width:160px" %)(((
--应对措施是否已经过测试？
--
--
--)))|(% style="width:89px" %)问题协调员|(% style="width:795px" %)(((
--* 验证应对措施是否已经过测试。
--* 如果已经过测试，请继续 SO4.4.5
--* 如果没有，请继续 SO4.4.6
--)))
--|SO4.4.5|(% style="width:160px" %)发布应对措施|(% style="width:89px" %)问题协调员|(% style="width:795px" %)(((
--* 将应对措施通知利益相关者（如事件分析人员等）。
--)))
--|SO4.4.6|(% style="width:160px" %)错误是否由变更导致？|(% style="width:89px" %)问题协调员|(% style="width:795px" %)(((
--* 验证错误是否是由最近实施的变更或发布引入或导致的（即由变更或未正确应用的变更导致的错误）。
--* 如果错误是由最近应用的变更引入的，则可能需要撤销或重新打开此变更。
--* 如果错误是由变更引起的，请继续 SO4.4.7。
--* 如果不是，请继续 SO4.4.9
--)))
--|SO4.4.7|(% style="width:160px" %)将已知错误与变更相关联|(% style="width:89px" %)问题协调员|(% style="width:795px" %)(((
--* 将根本原因与导致问题的初始变更相关联。
--)))
--|SO4.4.8|(% style="width:160px" %)通知变更经理|(% style="width:89px" %)问题经理|(% style="width:795px" %)(((
--* 通知变更经理并确定修正措施（如撤销或恢复变更）。
--* 根据撤销或恢复变更的结果，继续解决方案调查。
--)))
--|SO4.4.9|(% style="width:160px" %)继续进行解决方案调查|(% style="width:89px" %)问题经理|(% style="width:795px" %)(((
--* 确定是否必须对已知错误进行更详细的调查，以便找到解决方案或应对措施。
--* 如果已知错误需要进一步调查，请继续 SO4.5.1
--* 如果不需要，请按照操作 SO4.4.10 延迟问题。
--* 进行解决方案调查需要先对资源和技能进行估计，然后再确定解决方案。其中包括所需工作天数、持续时间和其他成本。
--* 验证是否存在可用应对措施，确定是修改优先级还是计划以解决问题。如果找到了有效应对措施，则可以修改解决已知错误的目标日期。如果没有找到应对措施，则可以提高已知错误的优先级。
--* 更新解决方案调查和解决方案最后期限的计划时间。如果需要，与利益相关者讨论并审核计划。
--* 如果已知错误没有解决，则必须决定是继续定义其他备选解决方案还是延迟问题。
--)))
--|SO4.4.10|(% style="width:160px" %)延迟问题并解释原因|(% style="width:89px" %)问题经理|(% style="width:795px" %)(((
--* 让问题和已知错误延迟一段时间并记录延迟原因。
--)))
--
--===   ===
--
--=== **3.4.5.（SO4.5）查找已知错误解决方案** ===
--
--[[image:1728650601805-492.png]]
--
--
--详细流程描述如下：
--
--|**序号**|**步骤名称**|(% style="width:110px" %)**责任人**|(% style="width:765px" %)**说明**
--|SO4.5.1|协调已知错误调查|(% style="width:110px" %)问题协调员|(% style="width:765px" %)(((
--* 问题协调员将已知错误分配给合适的问题分析员，以调查和确定适合已知错误的解决方案或修复方案。
--)))
--|SO4.5.2|调查和诊断|(% style="width:110px" %)问题分析员|(% style="width:765px" %)(((
--* 确定错误的解决方案。
--* 确定已知错误的可能应对措施或临时修复方案。
--* 根据已知错误的优先级和影响，重点定义可以在短时间内建议或实施的临时修复方案。
--* 在尚无持久的修复方案可供使用的情况下，应对措施将充当临时替代方案来恢复受影响的服务或充当临时的服务改进措施。
--* 确定解决已知错误的备选解决方案。
--如果临时修复方案必须通过变更进行实施，那么可以将此临时修复方案视为备选解决方案。
--* 问题分析员决定他或她是否有能力解决错误，是否需要额外的资源（即技能和时间）。
--)))
--|SO4.5.3|是否已确定解决方案？|(% style="width:110px" %)问题分析员|(% style="width:765px" %)(((
--* 如果找到了一个备选解决方案，请继续 SO4.5.4。
--* 如果没有，请继续 SO4.5.5
--)))
--|SO4.5.4|记录建议的解决方案|(% style="width:110px" %)问题分析员|(% style="width:765px" %)(((
--* 在系统中记录解决方案和实施解决方案所需的操作。请继续 SO4.5.5
--)))
--|SO4.5.5|通知问题协调员|(% style="width:110px" %)问题分析员|(% style="width:765px" %)(((
--* 向问题协调员通知有关调查的信息
--)))
--|SO4.5.6|审核和验证调查结果|(% style="width:110px" %)问题协调员|(% style="width:765px" %)(((
--* 审核由问题分析员确定的建议解决方案。此解决方案是在任务中定义的。
--* 确定建议的解决方案是否可以接受（例如，通过测试或与其他技术专家讨论）。
--* 如果定义了多个解决方案，请选择最佳解决方案。
--* 确保验证过程包括以下考虑因素：
--** 实施解决方案所需的成本和资源
--** 实施解决方案的风险
--)))
--|SO4.5.7|已知错误调查是否已完成？|(% style="width:110px" %)问题协调员|(% style="width:765px" %)(((
--* 确定调查是否已完成，是否已确定和记录了解决方案。
--* 如果已确定合适的解决方案（包括成本和资源限制）
--* 请继续 SO4.5.8 然后 SO4.6.1
--* 如果没有，请继续 SO4.5.1。
--* 如果成功确定了解决方案但未找到应对措施，则问题协调员（包括问题经理）必须评估是否仍有必要去寻找一个应对措施。
--* 如果永久解决方案可以快速实施，则可能没有必要继续定义应对措施。
--* 如果计划和实施永久修复方案需要较长时间或者开销过大，则应继续寻找一个有效的应对措施。
--)))
--|SO4.5.8|最终确定解决方案建议|(% style="width:110px" %)问题协调员|(% style="width:765px" %)(((
--* 记录解决方案，包括影响评估、实施解决方案所需的成本和资源估计
--)))
--
--===   ===
--
--=== **3.4.6.（SO4.6）确认已知错误解决方案** ===
--
--
--[[image:1728650644630-362.png]]
--
--详细流程描述如下:
--
--|**序号**|**步骤名称**|**责任人**|**说明**
--|SO4.6.1|验证和批准解决方案|问题协调员|(((
--* 审核和验证建议的解决方案。
--* 在“问题管理”会议期间，与利益相关者就解决方案的成本和影响一起进行讨论。
--)))
--|SO4.6.2|解决方案是否通过批准？|问题协调员|(((
--* 如果是，请转至 SO4.6.5。
--* 如果不是，请继续 SO4.6.3。
--)))
--|SO4.6.3|是否继续调查解决方案？|问题协调员|(((
--* 确定在没有有效的修复方案可以提供的情况下（例如，由于财务和资源限制），是要继续进行还是暂停调查问题。
--* 如果是，请继续 SO4.5.1。
--* 如果不是，请转至 SO4.6.4。
--)))
--|SO4.6.4|暂停问题并记录原因|问题协调员|(((
--* 已知错误及其相关问题将会暂停
--* 更新问题和已知错误（暂停状态）的状态、优先级和计划。
--* 确定必须审核问题和已知错误以进行其他操作的日期。
--*
--)))
--|SO4.6.5|是否需要 RFC？|问题协调员|(((
--* 确定解决方案是否必须通过正式变更过程进行实施。
--* 如果是，请转至 SO4.6.6。
--* 如果不是，请继续 SO4.6.7
--)))
--|SO4.6.6|授权提交RFC|问题协调员|(((
--* 授权并通知相关人员准备 RFC 的创建。按照“变更管理”定义的过程进行操作
--)))
--|SO4.6.7|是否需要服务请求？|问题协调员|(((
--* 确定解决方案是否必须通过标准请求执行过程进行实施。
--* 如果是，请转至 SO4.6.8。
--* 如果不是，请继续 SO4.6.9。
--)))
--|SO4.6.8|授权提交服务请求|问题协调员|(((
--* 权并通知相关人员准备服务请求的创建。按照请求执行定义的过程进行操作。
--)))
--|SO4.6.9|计划修复|问题协调员|(((
--* 计划修正操作的实施以解决已知错误。
--* 将已知错误分配给相应的问题协调员。
--* 请继续 SO4.7.1。
--)))
--
--注：问题经理在本子流程里负责所有的工作，在实际的操作上，如准备RFC等，可以委托相关人员在工具里提交
--
--
--=== **3.4.7.（SO4.7）协助/实施并记录解决方案的实施** ===
--
--[[image:1728650674595-914.png]]
--
--详细流程描述如下:
--
--|**序号**|(% colspan="2" %)**步骤名称**|**责任人**|**说明**
--|SO4.7.1|协调修正操作|(% colspan="2" %)问题协调员|(((
--* 分配问题分析员以实施解决方案来解决已知错误
--)))
--|SO4.7.2|实施修正操作|(% colspan="2" %)问题协调员|(((
--* 问题分析员实施解决方案或修复以消除已知错误，从而防止突发事件的再度出现。
--* 完成后，通知问题协调员
--)))
--|SO4.7.3|已知错误是否已解决|(% colspan="2" %)问题协调员|(((
--* 确保已知错误已解决。
--* 如果没有解决，请转至 SO4.7.5。如果已解决，请继续 SO4.7.4
--)))
--|SO4.7.4|准备关闭已知错误|(% colspan="2" %)问题协调员|(((
--* 更新已知错误记录（所执行的记录操作）。请继续 SO4.8.1
--)))
--|SO4.7.5|记录结果和建议的操作|(% colspan="2" %)问题协调员|(((
--* 如果应用的修复未解决错误问题，将会触发该操作。
--* 记录测试结果并确定适当的操作。
--* 通知问题经理以确定后续步骤。
--* 请继续 SO4.4.9
--)))
--|SO4.7.6|变更是否被拒绝?|(% colspan="2" %)变更协调员|(((
--* 如果是，请转至 SO4.7.8
--)))
--|SO4.7.7|变更是否成功？|(% colspan="2" %)变更协调员|(((
--* 如果是（按照变更过程进行验证），则可以关闭已知错误。
--* 如果不是，请继续 SO4.7.8
--)))
--|SO4.7.8|通知问题经理/问题协调员|(% colspan="2" %)变更协调员|(((
--* 通知问题经理解决方案已失败。
--* 请继续 SO4.4.9（以确定后续步骤和适当的操作）。
--)))
--
--===   ===
--
--=== **3.4.8.（SO4.8）问题的关闭和审核** ===
--
--[[image:1728650702207-212.png]]
--
--详细流程描述如下：
--
--|**序号**|**步骤名称**|**责任人**|**说明**
--|SO4.8.1|确保问题记录信息完整|问题协调员|(((
--* 检查并确保问题记录信息完整，请将问题管理阶段更新到“问题关闭与审核”，然后继续 SO4.8.2
--)))
--|SO4.8.2|验证问题是否已解决|问题协调员|(((
--* 确保问题已解决。
--* 根据问题的性质，可能需要在指定的时间段内（例如，评估期）将问题保持打开状态。
--* 如果没有突发事件重复出现，则可以关闭此问题。
--)))
--|SO4.8.3|问题是否已解决？|问题协调员|(((
--* 如果问题已解决，请继续 SO4.8.4。如果没有解决，请重新打开已知错误并重新启动解决方案调查阶段
--* 在某些情况下，明显有另一错误阻碍了问题的彻底解决（例如，问题由多个错误造成）。
--* 在这种情况下，可能要对新的已知错误进行调查。
--)))
--|SO4.8.4|是否需要审核？|问题经理|(((
--* 确定正式的问题审核是否适用。建议优先级为1的问题的关闭必须审核。
--* 如果是，请继续 SO4.8.5。如果不是，请继续 SO4.8.8
--)))
--|SO4.8.5|执行问题审核活动|问题经理|(((
--* 启动问题审核活动，协调正式审核流程。
--* 包括涉及问题解决方案的所有相关方。
--)))
--|SO4.8.6|记录所获经验|问题经理|(((
--* 记录问题审核结果和所获经验
--)))
--|SO4.8.7|创建问题审核报告|问题经理|(((
--* 创建正式问题审核报告（以会议纪要方式）并通知利益相关者。
--)))
--|SO4.8.8|关闭问题|问题经理|(((
--* 在关闭记录前更新问题记录。
--* 确保有关问题的所有信息都完整。
--* 选择关闭代码。
--)))
--|SO4.8.9|通知利益相关者有关问题解决的信息|问题经理|(((
--* 通知利益相关者问题已解决
--)))
--
--(% class="wikigeneratedid" %)
--=   =
--
--= **4.报表和KPI** =
--
--有了有效的、适合使用的流程，还要加强相应的管理才能获得最佳效果。建议的报表如下：
--
--|**编号**|**指标名称**|**描述**|**说明**|**计算公式**
--|PB-001|按问题分类统计|统计问题各分类数量的总体情况，了解各类问题的发展趋势。|分析问题较多的类别，重点改进。|按问题分类统计
--|PB-002|按问题来源统计|统计问题各来源数量的总体情况，了解各来源问题的发展趋势|分析各来源问题所占比例，重点改进问题较多的来源。|按问题来源统计
--|PB-003|按问题优先级统计|统计各优先级，尤其是高优先级问题的分布情况和趋势分析。|找出优先级高的问题，进行原因分析和解决。|按问题优先级统计
--|PB-004|按问题原因分类统计|统计各原因问题的分布情况和趋势分析。|发现问题较多的原因，加大改进力度。|按问题原因分类统计
--|PB-005|按问题结束代码统计|统计各结束代码问题单的数量，了解各结束代码问题单的发展趋势。|分析非正常结束问题单数量的发展趋势，找到原因，提高问题的完全解决率。|按问题结束代码统计
--|PB-006|按科/个人统计问题数量，类型|统计各科室处理问题单的数量，了解发展趋势|统计各科室运维人员的工作负荷，工作能力，提供决策支持。|按室/人统计问题
--|PB-007|已关闭问题数量|统计已关闭问题单的数量。|掌握问题单关闭的数量，从而了解问题流程的执行情况。|统计已关闭问题单的数量。
--|PB-008|未解决问题的数量|统计未解决问题单的数量。|了解未解决问题的数量，从而发现运行中心问题解决的能力是否存在不足的情况，并加以改进和纠正。|统计未解决问题单的平均数量。
--|PB-009|问题平均解决时长|统计问题单从创建到关闭的平均时长。|反映问题管理流程的执行效率，督促提高问题解决时长。|统计问题平均解决时长
--|PB-010|问题平均诊断时长|统计问题单从开始分析到标记为已知错误的平均处理时间。放弃的问题不纳入统计|督促提高问题处理效率，提高运行中心问题解决能力。|统计问题平均诊断时长
--|PB-011|问题平均修复时长|统计问题单从标记为已知错误到关闭的平均处理时间。放弃的问题不纳入统计|反映问题实际解决效率。|统计问题平均修复时长
--|PB-012|问题解决总时长|统计问题单解决的实际总耗时|反映系统运维的人力投入，提供决策支持，督促减少问题的处理时间。|统计问题解决总时长
--
--
--
--= **5.问题活动积分和激励** =
--
--
--== **5.1.积分计算** ==
--
--
--=== **5.1.1.问题处理积分规则（ITSM系统维护）** ===
--
--问题分析员处理完问题后可以得到积分；对于在问题处理周期中有多个参与人员的情况，只有最后的指派人能够得到积分。
--
--问题协调人或问题经理可以在问题关闭阶段对每一个问题的指派人打分。
--
--打分的维度如下：
--
--* 按时完成（A）：0-5分  80%
--* 问题记录质量（B）：0-5分  20%
--
--每个维度的分值分为0至5分，问题最后得分为:A*0.8+B*0.2
--
--===   ===
--
--=== **5.1.2. 加分项 （人工维护）** ===
--
--除了问题处理外，IT运维人员在参与平时的问题管理活动中，如果表现突出，属于如下范畴， 也可以得到加分。加分项如下：
--
--* 提出合理化建议，有助于改进流程：加5分/条
--* 在统计时段问题处理个数超过所有问题分析人员人均处理个数20%：加5分/个
--
--===   ===
--
--=== **5.1.3.减分项 （人工维护）** ===
--
--如果个人的行为影响了流程的执行或交付的服务质量没有达到预期的质量标准，将导致积分扣减。减分项如下：
--
--* 被指派的问题重新打开：-5分/次
--* 未按计划完成问题：-3分/次
--* 用户投诉： -5分/次
--
--===   ===
--
--=== **5.1.4.个人在问题管理活动中的总积分** ===
--
--在统计时间段内，个人的总积分计算公式如下：
--
--     总结分=问题处理积分总和 + 加分项 - 减分项
--
--==   ==
--
--== **5.2.激励机制** ==
--
--
--=== **5.2.1.月/年度问题管理之星评选** ===
--
--统计个人月/年问题管理积分，从高到低排序，挑选分数最高的人作为月度问题管理之星，给予相应奖励
--
--
--=== **5.2.2.月/年度问题管理先进部门** ===
--
--统计各部门月/年度问题管理积分，从高到低排序，挑选分数最高的部门评为问题管理先进部门。
--
--

1728650644630-362.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-92.6 KB

Content

1728650674595-914.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-93.3 KB

Content

1728650702207-212.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-84.8 KB

Content

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司