[Problem Management]
[问题管理]
-----------------------------------------------------------
[Goal/Mission of Problem Management]
To minimize the adverse effect on the business of Incidents and Problems caused by errors in the infrastructure and to proactively prevent the occurrence of Incidents, Problems and Errors.
[问题管理的任务和目标]
将IT基础架构内由错误引起的事件和问题对业务的负面影响减到最小，并预防这些相关的事件、问题和错误的再度发生。
说明：为了达成目标，“问题管理”力求找到引发事件的根源，然后才着手改善或纠正这种情况。
[分析与理解]
这同样是一个比较抽象的定义，我们将该定义分解为几个部分，以便于我们从中找到有助于证明实施ITIL必要性的内容：
  • “将事件和问题对业务的负面影响减到最小并将事件和问题出现的频率降到最低”
       这本是一个充满“争议”的焦点，因为IT部门习惯于将工作重心放在性能而不是质量上，放在提供支持而不是消除问题上。例如，服务台在首次接到电话时就设定了性能目标，如严重问题的解决，却并未对减少问题设定目标。这样下去的结果就是服务台人浮于事，并没有设法减少发生潜在问题的次数，导致客户受到影响。
       对于“问题管理”，还没有一个评估问题降低率的行业标准，通常都是采用30%和70%的比例关系设定。所以确定是否有通过“问题管理”减少问题发生次数的明确目标很重要。
  • “着手改善或纠正这种情况”
       通常我们可以采取的措施包括：“解决方案”、“遍历操作”，这是服务台快速处理事件所必需的。  
       那我们先来看看“解决方案”：
       服务台和二线支持小组能否对解决方案做出明确的说明？
       在确定了解决方案后能否立即对其进行传达？
       他们将信息输入CMDB还需要输入知识管理信息库？
       如果对上面的任何一个问题不能给出确定回答的话，那么我们可能并未真正开始着手进行改善。
       再来看看“遍历操作”：
       相信在很多公司，大多数情况下，如果服务台在接到电话时就可以迅速解决事件的话，就不会努力去寻找事件发生的本源。那么我们是否需要“问题管理”，并调查全部事件以确定长期解决方案呢？也许从服务台日志中查找最频繁发生的事件，并估算消除这些事件所带来的收益时，才会休会到“问题管理”的好处。
  • “引发事件的根源”
       该目标要素与上面的要素密切相关。真正的“问题管理”来自确定问题发生的根源，然后确定消除该问题的开销与从中获益或节约效果相比划得来。（有时服务台直接处理频繁发生的事故比消除该问题的开销还要少一些，因此人们常会误解该问题的根源。）
       一项调查显示，服务台所遇到的所有事件中30%到50%都是询问如何操作。在这类事件中，直接提供技术支持是可行的，但是我们缺乏这方面的知识。因此突显创建知识库和常见问题集的重要性。透过现象看本质，问题的根源在于客户缺少培训，这就为我们的工作指明了方向，这就是我们从中获得的益处。
  • “防止问题再度发生”
       同样与上面目标要素密切相关，但此处关注的是时机的选择和如何作出决定。首先，我们是否具有一个无论何时何地都应该减少事故的策略呢？如果没有，那么我们就有理由实施“问题管理”了。其次，我们何时决定减少事故呢？是在第一次发生时就将其彻底消除，还是等到问题多得无法应付时再将其彻底消除呢？如果我们还不能关注每个新的问题，就说明我们还没有进行有效的“问题管理”。
  • “既主动又被动”
       主动的“问题管理”即通过复查/分析事件数据库，或者复查所有变更记录或新增系统，以防止发生问题。目前极少数公司是这样做的。
       被动的“问题管理”即问题发生后再思量对策以做处理。目前大多数公司都是这样做的。
       从被动应付到主动出击，这正是需要实施“问题管理”的理由之一，利用“问题管理”提升客户体验。
“问题管理”通常在IT部门会被忽视，而从中可以获得最高回报的ITIL却会被重视。因此我们要借助于ITIL，制定并实施一套有力的“问题管理”方案。