ITSS问题管理的阶段分析方法
本帖最后由 monicazhang 于 2015-7-20 13:56 编辑20150720 淡然
续上
1.11 问题管理中的角色
流程往往跨越组织内的不同功能，因此对于必须执行的流程中的活动，定义相关联的责任是重要的。为了保持灵活性，建议使用角色这个概念。角色被定义为责任、活动和授权的集合，在本章，定义了流程中相应角色很简要的例子。角色被分配给组织内的人或组，根据角色和组织的情况，这种分配可以全职或兼职。 ITSS培训
1.11.1 问题管理员
问题管理负责所有的问题管理活动，具有以下明确的责任：v 开发和维护问题控制流程；v 回顾问题控制流程的效率和效果；v 制作管理信息；v 管理问题支持职员；v 为支持工作分配资源；v 监控错误控制的效果，并给出改良建议；v 开发和维护问题和错误控制系统；v 回顾主动问题管理活动的效率和效果。建议服务台管理和问题管理员的角色不要组合在一起，因为这两个角色存在利益冲突。
1.11.2 问题支持
问题支持有被动和主动两方面的责任，如下：* 被动责任v 识别问题（例如通过分析事故数据）；v 根据影响调查问题，直到解决或错误被识别；v 对清楚的错误，提出变更请求；v 监控知名错误解决的进展；v 对未解决的问题/知名错误，向事故管理职员建议与之相关事故的最佳的可用临时措施； ITSS认证v 帮助处理主要事故，识别根本原因；* 主动责任v 识别趋势和潜在的问题源（通过回顾事故和问题分析）；v 提出变更请求防止问题的重复发生；v 防止问题跨越多个系统出现。
1.12 附录
1.12.1 附录
A、问题/错误分类的代码结构例子
1.12.2 附录
B：Kepner&Tregoe分析
Charles Kepner 和 Benjamin Tregoe开发了一个分析问题很有用的方法。他们讲，问题分析应该是一个系统化的问题解决流程，应该最大化地利用知识和经验。他们将问题分析划分为下面五个阶段：
1、定义问题2、描述问题的识别、位置、时间和大小3、确立可能的原因4、测试最可能的原因5、核实真正的原因
根据时间和可用的信息，这些阶段实现的规模可大可小。即使在只有有限的信息可用，或者时间压力很大，采取结构化的方法来分析问题，提高成功的机会也是值得的。
* 定义问题
因为调查是基础问题的定义，因此定义必须精确地陈述已经出现的与协定的服务水平的偏差。经常在问题定义期间，最可能的问题原因已经显示。注意不要直接给出结论，这可能从开始就将调查引导到错误的方向。在实践中，因为复杂的IT基础架构以及不清晰的服务水平协议，问题定义经常是一个困难的任务。
* 描述问题
以下方面用于描述问题，也就是问题“是”什么：v 识别－哪一部分不能很好地起作用？问题是什么？v 位置－问题出现在哪儿？v 时间－问题从什么时候开始出现？问题出现的频率怎样？v 大小－问题的大小怎样？多少部分受到影响？
“是”的状况取决于这些问题的答案。下一步是调查在相似的环境中哪些相似的部分还在正确地起作用。据此，问题的答案可以描述为“哪些部分表现同样的问题但还在起作用？”
然后可能在两个环境中有效地调查相应的不同点，而且，过去的变更（可能是引起不同的原因）会被识别出来。
* 确立可能的原因
上面提到的不同点列表以及变更最可能含有问题的原因，因此可能的原因可以从列表中提取出来。
* 测试最可能的原因
每个可能的原因需要被评定，确定是否是问题所有症状的原因。
* 校验真正的原因
剩下的可能的原因必须被核实是问题的源泉。只要以一种方式来证明这点就行－例如，通过实施变更或替换部件。解决这个被快速而简单核实的原因。 ITSS考试
本帖关键字：ITSS
页:
[1]