ITIL 问题管理技术

问题管理流程可以通过一个优秀的服务台工具来强制执行，但用于调查和诊断的技术应根据组织的不同而有所变化。建议调查技术应根据组织需求灵活调整，而非过于死板。

由于问题可能以各种形式和规模出现，不可能每次都坚持使用一种技术来找到解决方案；相反，结合多种技术将产生最佳效果。一个简单的 LAN 连接问题可能通过快速的头脑风暴解决，但网络或 VoIP 问题可能需要更深入的分析。

以下是您可以在组织的问题管理流程中实践的几种技术。

头脑风暴

通过在部门之间建立对话，您可以获得多种视角和新信息，从而产生许多潜在解决方案。

要进行高效的头脑风暴会议，您需要一名主持人。主持人负责以下事项：

• 引导会议方向
• 记录获得的见解
• 突出需要采取的措施
• 跟踪讨论的交付成果
• 防止会议耗时过长

当使用诸如石川分析法和五个为什么方法等协作式问题解决技术时，头脑风暴会议会更高效。这些技术将在本节后面讨论。

Kepner-Tregoe方法

Kepner-Tregoe (K-T) 方法是一种问题解决和决策技术，因其逐步逻辑解决问题的方式而被广泛应用于多个领域。它非常适合用于主动和被动问题管理中的复杂问题解决。

该方法遵循四个过程：

• 情况评估：评估和澄清情境
• 问题分析：连接原因与结果
• 决策分析：权衡备选方案
• 潜在问题分析：预测未来

然而，问题分析是唯一与 IT 问题管理相关的部分，它包含五个步骤。

定义问题

确定问题的真实本质本身可能是一个问题。由于问题管理本质上是协作工作，全面定义问题可以消除任何参与成员可能存在的先入为主的观念，节省大量时间。

例如，如果某组织服务器上的自动数据备份失败，问题可以定义为：

服务器上的备份失败

该定义确实描述了与正常情况的偏差，但需要更多的问题和信息。一个好的定义模型应当明确且易于理解。

为消除歧义，上述定义可以更新为：

11 月 15 日服务器 #34-C 上的数据备份失败

该定义更为清晰，避免了员工重复提问。然而，该定义仍可进一步完善。假设数据备份失败的原因可归因于某事件，如应用了新补丁；那么初步的问题分析无疑会指向该事件。

为节省时间和精力，我们将定义更新为：

11 月 15 日服务器 #34-C 在工程师 Noah 应用补丁 3.124 后数据备份失败

这个详细的定义消除了冗余问题的空间，并提供了大量关于问题可能所在位置的信息。初始定义上花费的额外时间节省了宝贵的时间和精力，为分析提供了逻辑方向，并消除了对问题的任何先入为主的观念。

描述问题

下一步是详细描述问题。K-T 方法提供了需要针对任何问题提出的问题，以帮助识别可能的原因。

以下问题有助于描述任何问题的四个部分：

• 问题是什么？
• 问题发生在哪里？
• 问题发生的时间？
• 问题发生的程度？

这些问题中的每一个都需要两种类型的答案：

是：例如，“问题是什么？”或“问题在哪里？”

和

可能是但不是：例如，“问题可能在哪里，但实际上不是？”

这个练习有助于比较并突出业务流程中偏离正常性能的是什么、在哪里、何时以及如何发生。

确定可能的原因

上一步中对正常性能与偏离性能的比较有助于筛选问题的可能原因。将所有信息汇总到一个表格中有助于进行比较。

当信息汇总在一起时，会显现出新的可能原因。对于我们的示例问题，根本原因可以缩小为：

三级工程师知识传递不充分导致的程序错误。

无论问题是什么，都可以基于相关比较进行合理的可能原因分析。

测试最可能的原因

倒数第二步是筛选可能的原因并进行测试，然后再得出结论。每个可能的原因都应回答以下问题：

如果 _______ 是此问题的根本原因，它是否解释了问题是什么以及问题可能是但不是的情况？

同样，将所有信息填入表格中是有益的。

验证真正原因

最后一步是排除所有不太可能的原因，并为最可能的原因提供证据。通过此验证，就可以提出问题的解决方案。没有可能根本原因的证据，则不应尝试解决方案。

石川分析法，或称鱼骨图分析

Ishikawa 分析使用鱼骨框架列举问题的因果关系，可结合头脑风暴会议和五个为什么方法使用。使用 Ishikawa 图执行 RCA 的简便性不应让你低估其处理复杂问题的能力。

开始分析时，定义问题并将其作为鱼骨的鱼头。画出鱼脊骨，并添加问题可能来源的类别作为鱼骨的肋骨。

通常，最容易从服务管理的四个维度开始分类：合作伙伴、流程、人员和技术。然而，这些类别可以是与你的问题、环境、组织或行业相关的任何内容。

一旦这些类别形成鱼骨的肋骨，开始将可能的原因附加到每个类别。每个可能的原因也可以分支出详细说明该原因发生的理由。这可能导致一个四到五级因果关系的复杂图表，进而深入到问题的根本原因。

建议根据需要将密集的肋骨拆分成更多肋骨。或者，将空肋骨与其他合适的肋骨合并，保持鱼骨图清晰易读。此外，应确保肋骨上填充的是原因，而不仅仅是问题的症状。

该分析同样是协作努力，需要一名主持人有效引导头脑风暴会议。每位参与者都有机会参与，提供问题的全面视角。

帕累托分析

帕累托原则观察到大约80%的结果来自大约20%的原因。此观察适用于广泛主题，包括问题管理。

在尝试减少组织中发生的事件数量时，应用帕累托分析非常高效，优先考虑事件的原因，有助于基于影响和概率管理问题。

该分析通过从帕累托表生成帕累托图来进行。帕累托表包含所有问题分类的累计计数。帕累托图是显示各种问题分类频率累计百分比的条形图。

创建帕累托图，请遵循以下步骤：

• 从你的服务台工具收集问题工单数据。
• 根据各种属性将数据重新建模为类别。
• 创建帕累托表，以查找一段时间内每个分类问题的频率。
• 计算每个类别中问题发生的频率。
• 生成按降序排列的累计频率百分比。
• 在图表上绘制数据，创建帕累托图。

最重要的步骤是将数据重新建模为可计数的分类和属性集合。

此图有助于识别应优先解决的问题，以显著减少服务中断。该分析通过提供问题类别的优先级，与 Ishikawa 和 Kepner-Tregoe 方法互补，而其他方法则分析根本原因。

重要的是要记住，80/20 规则只是提示可能的原因，有时可能不正确。

五个为什么技术

五个为什么是一种简单的 RCA 技术。它定义问题陈述，然后反复询问为什么，直到发现问题的根本原因。为什么的次数不必限于五次，可根据问题和情况调整。

五个为什么技术补充了许多其他问题解决技术，如 Ishikawa 方法、帕累托分析和 K-T 方法。

以服务器数据备份失败的前例，应用五个为什么技术。

上述迭代过程揭示了缺乏标准化格式，这导致了数据备份失败的问题。

对我们来说，上述示例是方法的简单执行。在实际场景中，下一个问题取决于上一个问题的答案，因此必须与对问题领域有深入了解的利益相关者合作。

通过采用 K-T 方法的部分内容以及 five whys 技术，例如在验证答案之前为每个答案提供证据，可以确保问题解决会议中的精确分析。

其他技术

除了五大主要技术外，还有许多其他技术，各有其独特优势。总体而言，问题调查是结合适合具体情况的多种技术进行的。问题管理社区中常见的其他技术包括时间顺序测试、故障树分析、故障隔离方法、假设检验和痛点价值分析。随着组织问题管理流程的成熟，值得花时间学习多种技术。