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

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