20151118   淡然

续上

2.7.4      问题管理2.7.4.1              现状描述

目前问题管理暂时没有形成完善的流程，而且没有文档化。

2.7.4.1.1       已有优势

经过问卷、访谈和调查分析，可以发现某公司现有的问题管理存在以下的优势：                      ITSS培训

Ø  有问题管理的雏形，大规模同一事件发生时会追究原因；

Ø  每周检讨重大问题并追究原因；

Ø  在进行事件趋势分析中发掘问题；

Ø  在事件处理过程中识别并创建问题；

Ø  建立了简单的知识库。

2.7.4.1.2       需求与期望   

Ø  需要建立一套详细的流程，以便快速定位和解决问题；

Ø  当触发问题流程的时候，能够快速的定位问题所有人（own），并能保证升级的过程顺畅；

Ø  当问题解决的时候，能够有适当的审核机制进行问题评审，保证问题顺利解决，而且清楚问题的原因和解决方案，避免问题再次发生或者类似问题能够快速解决。

2.7.4.1.3       流程评估

通过问卷，我们得出目前问题流程的成熟度如下图：                            ITSS认证

由流程成熟度可以看出，问题管理有一定的基础，也产生了一定的产物，但是由于没有文档化和流程化，导致没有产生必要的管理信息和质量控制，对于客户支持也不是非常方便。主要体现在：

Ø  事件管理不具备对重大事件进行升级问题的接口；

Ø  没有定义分析反复出现的、潜在问题的措施；

Ø  没有一个相对完善和标准的问题管理规范文档。

2.7.4.2              差距分析及改进建议

编号	现状	改进建议
PM1	暂无文档化的问题管理流程，使用交班会形式来进行基础性的问题管理活动	建立问题管理流程，确定流程接口人制度，确定四个团队的问题入口方式：开发接口、网络、应用管理、桌面
PM2	目前的问题流程除与事件管理流程有接口外，和其他流程尚无接口	与知识库、配置、变更管理流程集成
PM3	通过日常监控和巡查措施，建立了初步的主动问题识别机制，尚不能很好地预防问题的发生	加强与日常运维等流程的融合，建立主动问题识别规范
PM4	具有初步的事件升级问题的机制，及时性和准确性还有待提高	改进事件升级问题的机制
PM5	目前对问题无任何分类和分级机制，造成问题解决安排上不合理，重大和紧急类问题不能得到优先处理	对问题进行分类和分级梳理，考虑与事件管理的分类和分级方法保持一致
PM6	尚无问题关闭和变更实施后评审制度，造成问题实施效果没有得到应有的回顾	建立问题关闭流程，建立RFC实施后评审制度
PM7	对于某个事件可能由未知的原因导致的，多个部门涉及到需要各自找问题根源，但没有相关协同工作机制，可能会造成互相推诿	这类事件即时升级为问题，并在安排一个主要团队负责该问题时，系统同时派生一个或多个协查问题工单给其他团队，便于多个团队协同工作。进一步，可以考虑成立运维管理办公室，专门负责跨部门跨项目的协调问题
PM8	目前问题流程无KPI指标                            ITSS考试	绩效指标和报表：问题解决率、已关闭的问题数量、问题流程提交RFC的数量、开放问题的平均数量、问题解决时长、未解决关闭的时间百分比、前5名问题类别、主动问题占比

待续http://www.ITILxf.com/thread-53210-1-1.html

本帖关键字：ITSS

20151118   淡然

续上

2.7.4      问题管理2.7.4.1              现状描述

目前问题管理暂时没有形成完善的流程，而且没有文档化。

2.7.4.1.1       已有优势

经过问卷、访谈和调查分析，可以发现某公司现有的问题管理存在以下的优势：                      ITSS培训

Ø  有问题管理的雏形，大规模同一事件发生时会追究原因；

Ø  每周检讨重大问题并追究原因；

Ø  在进行事件趋势分析中发掘问题；

Ø  在事件处理过程中识别并创建问题；

Ø  建立了简单的知识库。

2.7.4.1.2       需求与期望   

Ø  需要建立一套详细的流程，以便快速定位和解决问题；

Ø  当触发问题流程的时候，能够快速的定位问题所有人（own），并能保证升级的过程顺畅；

Ø  当问题解决的时候，能够有适当的审核机制进行问题评审，保证问题顺利解决，而且清楚问题的原因和解决方案，避免问题再次发生或者类似问题能够快速解决。

2.7.4.1.3       流程评估

通过问卷，我们得出目前问题流程的成熟度如下图：                            ITSS认证

由流程成熟度可以看出，问题管理有一定的基础，也产生了一定的产物，但是由于没有文档化和流程化，导致没有产生必要的管理信息和质量控制，对于客户支持也不是非常方便。主要体现在：

Ø  事件管理不具备对重大事件进行升级问题的接口；

Ø  没有定义分析反复出现的、潜在问题的措施；

Ø  没有一个相对完善和标准的问题管理规范文档。

2.7.4.2              差距分析及改进建议

编号	现状	改进建议
PM1	暂无文档化的问题管理流程，使用交班会形式来进行基础性的问题管理活动	建立问题管理流程，确定流程接口人制度，确定四个团队的问题入口方式：开发接口、网络、应用管理、桌面
PM2	目前的问题流程除与事件管理流程有接口外，和其他流程尚无接口	与知识库、配置、变更管理流程集成
PM3	通过日常监控和巡查措施，建立了初步的主动问题识别机制，尚不能很好地预防问题的发生	加强与日常运维等流程的融合，建立主动问题识别规范
PM4	具有初步的事件升级问题的机制，及时性和准确性还有待提高	改进事件升级问题的机制
PM5	目前对问题无任何分类和分级机制，造成问题解决安排上不合理，重大和紧急类问题不能得到优先处理	对问题进行分类和分级梳理，考虑与事件管理的分类和分级方法保持一致
PM6	尚无问题关闭和变更实施后评审制度，造成问题实施效果没有得到应有的回顾	建立问题关闭流程，建立RFC实施后评审制度
PM7	对于某个事件可能由未知的原因导致的，多个部门涉及到需要各自找问题根源，但没有相关协同工作机制，可能会造成互相推诿	这类事件即时升级为问题，并在安排一个主要团队负责该问题时，系统同时派生一个或多个协查问题工单给其他团队，便于多个团队协同工作。进一步，可以考虑成立运维管理办公室，专门负责跨部门跨项目的协调问题
PM8	目前问题流程无KPI指标                            ITSS考试	绩效指标和报表：问题解决率、已关闭的问题数量、问题流程提交RFC的数量、开放问题的平均数量、问题解决时长、未解决关闭的时间百分比、前5名问题类别、主动问题占比

待续http://www.ITILxf.com/thread-53210-1-1.html

本帖关键字：ITSS