正如我们在 首先 和 附议 在本系列文章中，评估 ITIL 环境中的问题管理质量并非易事。从提出正确的问题到确定应使用哪些指标来衡量绩效，有许多变量需要考虑。在本文中，我们将深入探讨在确定问题根源时所涉及的 "魔法"。
问题分析的基本组成部分
有许多方法可以找到问题的根源，有些方法显然比其他方法更成功。然而，如果没有一个标准的框架，不同的人自然会有不同的方法。任何一组故障排除者的效率都是沿着钟形曲线下降的。大多数故障排除专家可以自信地得到任何工作。表现良好的人对大多数任务都很擅长，但有改进的余地，而那些故障排除声誉不佳的人可能需要帮助。
Kepner-Tregoe（KT）问题分析方法是在20世纪50年代研究和定义的，并在此后的几十年里不断完善和测试。显然，这是在计算机无处不在的许多年前，更不用说在ITIL代表什么了。
有人认为，像KT这样的方法不可能适合今天的IT行业，因为在KT方法刚被研究出来的时候，IT和ITIL都不存在。我们有必要仔细看看问题分析的KT方法，以做出更合适的判断。问题分析的主要步骤包括： 1:
- 描述问题
- 列出可能的原因
- 评估可能的原因
- 证明真正的原因
- 超越修复的思考
对于这些步骤中的每一步，都有明确的意图和适当的子步骤，以帮助通过问题的措辞，以及在记录答案以获得正确的数据。所有这些输入都会进入问题分析的思考过程。这一切都在没有任何特定产品或问题的情况下完成，它与ITIL非常相似，适用于所有类型的IT组织。问题分析是一种为许多不同的问题寻找根本原因的方法，而不考虑行业或技术。
问题分析的三个触发因素
尽管KT的方法适用于任何类型的问题，但KT对 "问题 "一词有一个非常具体的定义，与ITIL非常吻合。根据KT，在我们触发问题分析过程之前，有三个标准必须是真实的。
实际绩效和期望绩效之间应该有差距。这就是我们所说的偏差。(例如，机器不工作，而机器应该工作）。
偏差的原因是未知的（例如不是已知的错误）。
必须有了解偏差的需要（例如，能够采取行动）。
通过一套明确的步骤来寻找根本原因，故障排除者可以开始沟通并记录在这个过程中已经做了什么以及还需要做什么。下图给出了一个例子，说明如何以收集的数据为模型来描述一个问题的症状。
在下一篇也是最后一篇文章中，我们将探讨问题分析如何为有效衡量 ITIL 问题管理的绩效提供核心框架。
