利用根本原因分析法处理常见问题

ZDNet网络频道原创文章 转载请注明出处

对于训练有素的事件响应团队来说，记录、管理支持以及事件响应的最终目标都是确定原因以以防止复发，不过这不一定是会实现的。在本文中，我们将通过一个非常简单的方法——根本原因分析法对进程进行分析。这并不需要特别的培训，只要一点点的努力和足够的常识。

在第一部分，我们先创建一个简单的根本原因图，为下面的分析做准备。

为什么要担心根本原因？

很多公司组织，甚至包括受过良好训练的反应团队，都可能出现未能防止意外事件发生的情况，这是因为他们关注的只是表面的问题，而不是本质。例如，如果只是因为交换故障导致付款延迟，很多组织只会看看如何排除交换的故障。但实际上交换故障只是表面现象，而不是本质原因。在本文中，我们的目的，就是确定在什么时间和地点，在哪种情况下会发生这种事件。

在很多情况下，根本原因是一个失败的控制、程序或者由于工作人员技术的问题导致的先期状况的发生。在直接原因的影响下，先期状况会导致引发了一系列后果。在图一中，就显示了一个例子。第二号事件发生的根本原因和影响因素。防止第二号事件复发的最好办法，就是改变在第二号事件上发生的事件。换句话说，在一连串的事件之前变更程序或条件通常是优于直接管理的效果。

在我们的交换失败的例子中，该组织可能会发现，根本的原因是缺少损坏或者变更状态下的管理模式。确定这一根本原因不仅可以防止交换失败再次发生。还将有助于防止其它不相关的故障。

图一：根本原因概念图

建立一个简单的根本原因图

建立一个根本原因图有很多方法。被大部分根本原因培训者所采用的最流行的方法是鱼骨图（Fishbone）或者石川图（Ishikawa）。一个简单的鱼骨图是如图二所示，而图三显示的是一个更复杂的分析图（childrensmercy.com）。

图二：简单的鱼骨图

图三：复杂的鱼骨图

然而，我们大多数人的技术知识不能也不倾向于花时间建立复杂的决定/分析框架。我们所需要的是可以很快地找到根本原因更直接的方法，这样才能在工作的时间尽快地到达下一个用户或者出现问题的系统那里。

八步骤问题解决法包含了解决事故问题的八个方法步骤，其中就包括了根本原因分析和预防复发。第四步（D4类）就是根本原因分析，一个很简单的办法。重要五个简单的问题，就可以确定问题的基本原因，或者主要影响因素。尽管，很多八步骤问题解决法的使用者实际上不图形化回答，但我更喜欢这么做。在下面的第二部分，我们将讨论，图让问题变得更加容易理解。

让我们看一个真实世界的例子，如图四所示。在这次事件中，一个由供应商的桌上电脑控制的重要生产系统被取代。结果生产系统立刻崩溃，导致生产过程的中断。

图四： 八步骤问题解决法的五个为什么根本原因图

公司按照行动后审查（AAR）程序成立了根本原因分析小组，以确保全面和客观地记录事件。首先，分析主持人问了第一个原因。为什么事件会发生呢？两个近期的原因已查明。首先，更换的系统没有被正确配置。其次，用户反馈问题的报告没有及时起作用。小组同意这两个原因应该分别处理。它们似乎属于不同的原因和后果链。在我们的例子中，我们将关注造成更换的系统没有被正确配置的原因。

主持人继续问第二个原因。为什么系统会配置不当？这导致答案来回沟通了三次。这里的假设是，这是导致问题发生的根本原因。但当问完了五个为什么而根本原因还并不明显的时间。小组必须重新进行这个程序，寻找可能会被忽略的因素。

象行动后审查（AAR）程序一样，根本原因分析必须摆脱指责。每个参与者必须了解他或她的参与将不会导致纪律处分或同事的嘲笑，管理部门必须支持这些说法。

在第二部分中，我们将讨论如何确定一个或一个以上的根源以及怎样决定要怎么做了。