你清楚问题管理流程的ITSS执行框架和原则
本帖最后由 monicazhang 于 2015-8-28 15:09 编辑20150828 淡然续上
2 流程详细说明 本章节的主要内容及用途如下所示：
提供了流程的指导方针，供日后某公司相关项目中的流程设计和日常工作中使用。 提供了流程的关系图，指出了在某公司的整个服务管理体系中，本流程与其他流程的关系，即：本流程有哪些输入，同时也提供哪些输出。 提供了流程的执行框架体系，指出了本流程应该具有的一些主要活动，从而供日后实施项目的细化、归纳。 ITSS考试 [*]提供了主要的考核指标，指出了如何对本流程进行衡量，在日后的实施项目中，应该对这些指标进行细化和实现。
2.1 指导原则 为了给某公司的问题管理流程提供方向，必须定义一些指导原则。这些原则可以为所有的流程活动服务，也可以仅仅服务于某一个动作。指导原则的定义基于ITIL的最佳实践，同时根据某公司的具体情况进行调整，从而满足某公司的实际需求。下面列出某公司问题管理流程的指导原则：方针 1:应该建立唯一的独立问题管理流程，在整个某公司企业范围内应该与突发事件管理流程相对独立。
最佳实践：
鉴于热线支持与突发事件管理流程和问题管理流程的特性区别(以时效性为指导和以服务质量为指导),其流程活动应该由不同的人员来实行。如果由于环境的限制，由同样的人员来进行问题管理和热线支持/突发事件管理的话，应该特别确认当执行热线支持/突发事件管理时，应该侧重帮助客户快速的恢复服务，而当执行问题管理时，应该特别侧重主动的潜在问题发现。 一定要发现问题的原因。 [*]问题的修正实施必须满足业务的要求。
启示：
热线支持/突发事件管理和问题管理是有着不同目标的独立管理流程。 [*]问题管理会需要较多的人力投入、培训和对于变更管理的考虑。
方针 2: 所有的问题及其解决方案应该被录入统一的问题管理数据库
最佳实践：
所有的问题都应被录入。 问题的解决过程必须被文档化，问题的状态应该被记录。 [*]应该文档化问题的解决方法。
启示：
需要工具来支持问题管理的本指导原则。 [*]需要对相应的IT人员提供培训。
方针 3:问题管理流程负责基于从热线支持/突发事件管理数据库和其他渠道所收集数据的“根本原因分析”和“趋势分析”。
最佳实践:
必须主动发现系统和应用问题。 应该录入和分类突发事件从而帮助发现潜在的问题。 应该记录突发事件的解决方法。 [*]应该对于基于突发事件的报表进行分析。
启示:
问题的解决方案应该经过测试并且其解决过程中遵循变更管理流程。 [*]需要监控工具来采集所需的IT基础架构、运维、业务数据及其相关关系。
2.2 流程关系图 图2 问题管理流程与其他管理流程关系问题管理的主要工作是从突发事件管理等流程提供的信息中通过分析，发现潜在的问题，并通过变更管理流程解决问题。
[*]突发事件管理
问题管理流程需要通过建立周期回顾的方式察看突发事件的历史纪录，从中进行趋势分析。当某种趋势或是问题征兆被发现时，就需要创建一条相应的问题记录。相反，当热线支持和突发事件管理尝试解决以突发事件时，就会查找问题管理数据库以发现相应的解决方法。
[*]运维管理
运维管理为问题管理提供用于分析的运行统计数据、服务绩效指标和事件信息。
[*]可用性管理
问题管理为可用性管理揭示可能会影响服务可用性的潜在隐患并指出需要增加预防性维护力度的方面。
[*]配置管理
问题记录应该和CMDB内纪录的配置项信息紧密相联系，此外问题管理流程以及其相关流程都应该可以访问涉及的CMDB内的配置信息记录；同时配置管理为问题管理提供用于影响分析和问题“根本原因”分析所需要的配置信息；问题管理也为CMDB的修正提供反馈。
[*]变更管理
对于错误的修正需要通过提起变更请求的方式发起，问题管理通过变更管理流程定期的了解到相关变更的进行状态。
[*]上线管理
问题管理通过发起变更请求来实现问题的解决，同时变更需要通过上线版本的成功部署和验证来实现，从而原先发起变更的问题和已知错误才可以被关闭；同时上线管理也为问题管理提供本上线版本内尚未解决的已知错误信息。2.3 流程执行框架 本章节所提供的活动需求，主要是根据最佳实践，同时结合某公司的具体情况，对本流程的活动进行高层描述，并对主要活动进行罗列，解释等等，相关ITSP项目在进行问题管理流程的具体设计时，应该考虑这些活动，并且在功能上加以实现和扩展。本章节将通过表格的形式表达，每一个活动都包含以下内容： ITSS认证
编号：唯一流程活动编号 管理活动：管理活动简述 [*]描述：流程活动的具体描述
图3问题管理流程总览
编号
管理活动描述
5.2.1
发现问题 通过分析IT基础架构和管理流程的运行信息来发现潜在的问题，需要分析的信息包括：
突发事件信息：包括报表、重大事件回顾、分类统计、趋势分析等等； 问题管理信息：包括报表信息、日程回顾等； 运行管理信息：包括运行报表、服务指标统计、事件信息等； 上线管理信息：包括新的系统版本上线手册等； [*]知识库系统：包括已建立的内部知识库信息，以及外部的相关信息。
5.2.2
记录问题记录问题信息、分类并且为该问题的解决安排资源，其主要活动包括：
创建问题纪录：根据事前模板，输入问题基本信息； 设置问题的影响范围：根据约定和对于问题情况的判断，确定其影响范围； 设置问题紧急性：根据约定和对于问题情况的判断，确定该问题解决的紧迫程度； 设置问题处理优先级； [*]指派相应的技术或支持人员负责分析和解决问题。
5.2.3
追踪原因追踪问题潜在的“根本原因”，其主要的活动包括：
诊断问题：隔离问题且对于问题的原因进行调研； 创建规避措施：在发现问题潜在原因后，根据经验或专家的建议提出意见制定规避措施，并创建相应文档； 更新知识库：当发现问题的潜在原因并提出规避措施后，需要更新相应的知识库(新的或更新的已知错误纪录)； [*]更新问题纪录：问题管理的流程由此发展到了错误控制的阶段。
5.2.4
制定解决方案制定结构化的解决方案来防止问题所导致突发事件的重复发生，其主要活动包括：
开发和推荐针对问题的修复：通过与不同的专家组进行讨论研究来制定各方都可以接受的问题修复； 推荐的问题修复的审核：问题涉及的配置项负责人在评估问题修复的细节后决定是否赞同该修复方案； 回顾和验证推荐的问题修复：验证所推荐的问题的修复方案，如果方案有问题，则需要原先的问题潜在原因分析； [*]更新问题纪录：更新问题记录中的相关信息，更新相应的已知错误纪录。
5.2.5
提交变更请求提交变更请求从而启动通过变更修复已知错误的实施，其主要活动包括：
提交变更请求：更具解决方案的要求提交变更请求，提供所需的信息； 纪录错误解决的过程：跟踪问题解决的过程，并将进程状况及时通报给相关的人员； 协调变更请求的处理优先级：与变更经理协调，根据问题/错误的影响和业务的要求确定变更处理的优先级； [*]更新问题纪录：追踪变更的处理进程，更新问题纪录。
5.2.6
关闭错误纪录在完成实施后回顾后，关闭问题、错误记录：
回顾实施的解决方案：主要是确认所发现的潜在问题是否已被解决； 更新知识库：将详细的错误描述和处理方法输入知识库； [*]关闭问题/错误纪录：关闭问题/错误纪录
2.4 流程主要考核指标 定义考核指标应考虑的因素可以从以下几个方面来考虑：
所有的考核指标必须具有“可测量性”，即所有的考核指标的数据都是可以采集到的，当然，推荐采用自动化的工具进行收集及显示。 考核指标可以用来反映流程的执行进度，即做了多少工作。 [*]考核指标可以用来反映流程的执行质量，即所完成工作的效果如何。
建议的考核指标 （注：带有*号的为重要指标）问题管理设定如下考核指标，可以按照每天、每月、每年进行统计。
*在统计期内问题和已知错误的数量以及根据状态、服务、影响和类型的分类比例。 统计期内各种类型处理问题的数量以及解决方法的细节。 统计期内各种类型处理已知错误的数量以及解决方法的细节。 *统计期内各种类型的问题解决的比例。 当前的尚未解决的已知错误数目及相关的变更请求状态。 在根源问题发现之前或已知错误确认之前所发生的相关问题的数量和影响大小。 统计期内已投入到搁置问题解决的资源投入和需要解决该类问题的所需再投入资源的预期数量，包括人力资源（以人天、人时计）和资金要求。 *在某一系统上所采用的规避措施的数量。 *自从生产系统上线以来的应用问题数量。 统计期内用于问题分类和分配所用的平均时间和最多时间。 统计期内不同类型问题用于发现“根本原因”的平均时间。 统计期内不同类型问题用于找到彻底解决方案的平均时间。 *统计期内不同类型问题和已知错误解决的平均时间，主要适用于表征流程活动的总体效率和技术支持部门的响应能力。 问题的“难度”（指处理该问题所需的在技能要求、组织协调、管理上所需的努力，通常为事后的评估）级别的统计，包括结合数量根据处理人员、类型、服务的分类统计。主要目的是为更好的了解和掌握人员的工作负荷和能力以及系统和运维的薄弱点。 已知错误解决用于实施变更请求的平均时间。 关联到已知错误的突发事件的比例。 *重复发生的问题数量。 ITSS培训 [*]用于突发事件管理的花费努力和问题管理花费努力的比较，主要是用于研究流程的成熟度，需要仔细的选择标称所花费努力的指标，例如平均解决时间、处理的记录数或提交的变更请求数等等。
待续http://ITIL-foundation.cn/thread-52336-1-1.html本帖关键字：ITSS
页:
[1]