|
20150731 淡然 续上
3.2.4. 问题优先级 优先级是问题管理的一个关键要素，优先级决定处理问题的顺序及所需的资源。在某公司B2B服务中，问题优先级可分为四级：P1（最高）、P2（高）、P3（中）、P4（低）。当然优先级为最高的问题也将作为重大问题来进行处理。 为方便服务支持对于问题优先级的判断，某咨询公司建议从问题的影响范围和问题紧急程度两维来进行优先级定位。 问题的影响范围主要是指受问题关联事件影响的客户数量和范围，在某公司B2B业务中，问题影响范围定义具体如下： 表 3‑6 问题影响范围 ITSS考试[td] 编号
| 影响范围
| 描述
| 1
| Very High
| 关联的事件影响整个公司的业务
| 2
| High
| 关联的事件影响一个部门的业务
| 3
| Medium
| 关联的事件影响一个团队的业务
| 4
| Low
| 关联的事件影响一个人的业务
|
问题的紧急程度是指解决问题所需要的速度，通常问题发生设备或系统对业务的关键程度，以及其对应事件的频发程度等因素相关。在某公司B2B业务中，问题紧急程度定义具体如下：
表 3‑7 问题紧急程度 [td] 编号
| 紧急程度
| 描述
| 1
| Very High
| 关键设备或重大事件反复发生
| 2
| High
| 重要设备或事件复发率高 （每天/每周）
| 3
| Medium
| 一般设备或事件复发率中等（每月/每季度）
| 4
| Low
| 日常设备或事件复发率较低 （每年）
|
结合问题发生时的影响范围和紧急程度，可以通过下表确定问题的优先级：
表 3‑8 问题优先级矩阵 优先级
| Very High
| High
| Medium
| Low
| Very High
| P1
| P1
| P2
| P3
| High
| P1
| P2
| P3
| P3
| Medium
| P2
| P3
| P3
| P4
| Low
| P3
| P3
| P4
| P4
|
3.2.5. 问题时限 为了更好的控制问题的解决，整个流程被分解成几个组成部分。每个流程的阶段都设定了目标时间。问题的目标时间与事件的明显不同，这是由于两个管理流程目标不同决定的，通常事件比问题的目标时间更严格。 需要说明的是，通常问题解决时间可由问题经理召集问题提交人及问题分析专家共同协商确定。以下时限定义供实际流程执行时参考： 表 3‑9 问题时限 [td] 问题目标时间点
| 问题分派
| 问题找到 根本原因
| 问题找到解决方案
| 问题得到解决
| P1
| 1个工作日
| 3个工作日
| 2个工作日
| 5个工作日
| P2
| 1个工作日
| 5个工作日
| 5个工作日
| 10个工作日
| P3
| 1个工作日
| 10个工作日
| 10个工作日
| 20个工作日
| P4
| 1个工作日
| 15个工作日
| 15个工作日
| 30个工作日
|
3.2.6. 问题状态 问题状态代码表明问题所处的处理状态，问题状态如下： 表 3‑10 问题状态 [td] 编号
| 代码
| 描述
| 1
| 新建
| 问题被识别并创建
| 2
| 分派
| 问题已被分派给问题分析专家
| 3
| 处理中
| 问题分析专家接受并开始处理问题
| 4
| 已找到原因
| 问题分析专家通过分析诊断，找到导致问题发生的根本原因
| 5
| 已提交方案
| 问题分析专家在找到问题根本原因后，进一步分析并提交问题的解决方案或变通方法
| 6
| 已批准方案
| 问题经理批准解决方案、返回问题分析专家进行方案实施
| 7
| 已提交变更
| 问题分析专家提交RFC，监控和等待RFC实施完毕
| 8
| 挂起
| 问题信息不完整，或在某些情况下阻止问题分析专家对问题的处理，挂起的原因为： l 等待问题提交人进一步提供信息 l 等待开发部门发布新版本 l 等待其他厂商/第三方处理
| 9
| 已解决
| 问题解决方案或变通方法已经落实，问题已得到解决
| 10
| 关闭
| 问题请求人已对问题处理结果进行了确认，并同意关闭问题
|
3.2.7. 问题结束代码 问题结束代码说明了问题是在何种情况下关闭的，结束代码如下： 表 3‑11 问题结束代码 [td] 编号
| 代码
| 描述
| 1
| 根本解决
| 通过彻底的解决方案解决问题
| 2
| 变通方法
| 无法找到彻底的解决方案，通过变通方法解决问题
| 3
| 无法重现
| 对于问题请求人上报的问题，问题分析专家无法进行重现
| 4
| 无法解决
| 未找到问题的根本原因，没有解决方案，或涉及过大的成本及资源，目前无法实施解决方案，也无变通方法
| 5
| 取消
| 由于问题为重复或者无效问题，相应问题单被问题经理评审后取消 ITSS认证
|
3.2.8. 问题提交人角色 问题提交人角色用来标明哪些人员有权限向问题管理提交问题，具体定义如下表所示：
[td] 编号
| 代码
| 描述
| 1
| 事件一线人员 (包括热线和现场)
| 一线人员在事件处理过程中上报的问题
| 2
| 事件二线人员
| 二线人员在事件处理过程中上报的问题
| 3
| 问题分析专家
| 问题分析专家在主动分析事件记录时，上报所遇新问题
| 4
| 配置管理员
| 配置审计后发现帐实不一致情况可上报问题
| 5
| 其他运维人员
| 运维人员在日常操作活动中发现上报的问题；
|
3.2.9. 处理是否超时 每个优先级别都各自定义了问题解决期限，“解决是否超时”用来标明问题的处理是否已超过了解决期限。对于响应时限等其他时限点如需标志字段，可参考下表添加： 表 3‑12 问题超时代码 [td] 编号
| 代码
| 描述
| 1
| 未超时
| 未超时
| 2
| 超时
| 问题已超出规定的解决时限
|
3.2.10. 知识信息项 知识记录应包含如下信息项，某公司B2B服务团队可以在此基础上进行扩充： 表 3‑13 知识信息项 [td] 序号
| 信息项
| 信息描述
| 操作角色
| 1
| 知识编号
| 知识记录流水号
| 系统自动分配
| 2
| 知识状态
| 知识记录的状态信息，参见“知识状态”定义
| 服务台人员 二线人员 问题分析专家 知识管理员
| 3
| 知识登记时间
| 知识记录在系统中的实际登记时间
| 服务台人员 二线人员 问题分析专家 知识管理员 （或系统自动设置）
| 4
| 知识登记人
| 知识登记人的姓名信息
| 服务台人员 二线人员 问题分析专家 知识管理员
| 5
| 知识来源
| 参见“知识来源”定义
| 服务台人员 二线人员 问题分析专家 知识管理员
| 6
| 知识分类
| 知识记录的分类，可参考事件分类定义
| 服务台人员 二线人员 问题分析专家 知识管理员
| 7
| 事件/问题描述
| 知识记录关联事件或问题的描述
| 服务台人员 二线人员 问题分析专家 知识管理员
| 8
| 原因描述
| 导致事件/问题的原因描述
| 服务台人员 二线人员 问题分析专家 知识管理员
| 9
| 解决方案
| 解决事件/问题的解决方案
| 服务台人员 二线人员 问题分析专家 知识管理员
| 10
| 变通方法
| 解决事件/问题的变通方法
| 服务台人员 二线人员 问题分析专家 知识管理员
| 11
| 关联事件单号
| 与知识记录关联的事件单编号
| 服务台人员 二线人员 问题分析专家 知识管理员
| 12
| 关联问题单号
| 与知识记录关联的问题单编号
| 服务台人员 二线人员 问题分析专家 知识管理员
|
3.2.11. 知识来源 知识来源代码用来标明知识条目的提出方式，包括以下几种： 表 3‑14 知识来源 [td] 编号
| 代码
| 描述
| 1
| 事件
| 由事件管理流程创建的知识条目，通常是由事件的解决方案/替代措施实施后创建
| 2
| 问题
| 由问题管理流程创建的知识条目，通常是由问题找到根源和解决方案之后创建
| 3
| 其他
| 其他人员在日常运维过程中创建的知识条目，比如专业技术规范、系统操作手册等
|
3.2.12. 知识状态 知识状态用来标明知识条目当前所处的状态，包括以下几种： 表 3‑15 知识条目状态 [td] 编号
| 代码
| 描述
| 1
| 新建
| 由事件/问题管理流程或者其他角色主动创建的候选知识条目，记录知识相关信息。
| 2
| 待审核
| 知识条目信息整理完毕后提交知识管理员审核 知识管理员收集与整理的候选知识条目
| 3
| 发布/使用中
| 知识管理员将审核通过的知识条目发布出去，可供相关角色进行查询和学习。 ITSS培训
| 4
| 废弃
| 知识管理员将过时的知识淘汰
|
本帖关键字：ITSS | 
转播
分享
淘帖
()