跳转到内容

商业分析指南/根本原因分析

来自维基教科书,开放的书籍,为开放的世界

什么是根本原因分析/为什么重要

[编辑 | 编辑源代码]

简而言之,根本原因分析是对特定情况的仔细检查,以确定特定问题或偏差的根本原因。商业分析知识体系 (BABOK) 将其定义为“对情况各个方面的结构化检查,以确定问题的根本原因和由此产生的影响”。根据进行的检查的严格程度,有可能识别出几层症状,然后才能找到特定情况的根本原因或原因。

何时使用

[编辑 | 编辑源代码]

根本原因分析最常与问题解决相关联,尽管它也可以应用于组织分析、差异分析、流程改进和软件错误修复。本质上,每当结果不如预期时,通常可以找到一个或多个因果关系。鉴于识别根本原因分析的一些工具可能是主观的,因此确定导致偏差的根本原因通常是一个判断问题,尤其是在所评估的系统很复杂时。

需要考虑的问题

[编辑 | 编辑源代码]

通过仔细寻找特定问题的根本原因,然后对根本原因采取一些缓解措施,问题通常就会消失。仅仅处理问题的症状,潜在的问题很可能以新的方式出现,但不会消失。例如(想出一个好的例子)。问题通常可能没有严重到需要进行严格的评估。在决定对根本原因进行多深入或多快的挖掘时,这里有一些问题需要考虑

  • 这个问题/问题的后果是什么?是头条新闻吗?危及生命还是仅仅令人讨厌?
  • 这是单独发生还是以前发生过?
  • 这种情况再次发生的可能性有多大?
  • 在问题/出现之前是否有可能作为早期预警信号的事件?
  • 在事件发生之前是否有最近的变化可能直接或间接地促成了它的发生?
  • 这是系统范围内的类型问题,还是仅限于一个办公室或部门?
  • 是否有控制措施来检测此类问题/问题?

问题来源

[编辑 | 编辑源代码]

根本原因可能相当广泛。通常是一系列的小问题,而不仅仅是一个单一的问题。以下列表改编自保罗·威尔逊等人 1993 年出版的《根本原因分析》一书。拥有一个贡献因素列表通常有助于识别实际的根本原因。

  • 培训(正式和非正式)
  • 管理方法(资源和时间表计划)
  • 变更管理(对现有流程的修改)
  • 沟通(有效或无效)
  • 外部(机构控制范围之外的因素)
  • 设计(支持工作的设备和系统)
  • 工作实践(用于完成任务的方法)
  • 工作组织(组织绩效和任务顺序)
  • 物理条件(影响绩效的因素)
  • 采购(获取必要的资源)
  • 文档(说明和程序)
  • 维护/测试(包括预防性维护)
  • 人机关系(到位警报和控制)

需要注意的是,这些潜在的根本原因可能是症状,在某些情况下,可能存在多个根本原因。

有许多工具可用于确定根本原因。每种方法将简要解释,提供一个示例图表来说明该概念,并将提供构建和解释的工具。所介绍的工具包括

  • 鱼骨图
  • 问为什么5次
  • 检查表/帕累托图
  • 相互关系图
  • RPR(快速问题解决)

鱼骨图

[编辑 | 编辑源代码]

此工具也称为石川图或因果图。它以卡鲁·石川的名字命名,卡鲁·石川在 20 世纪 60 年代在川崎造船厂开创了 TQM 流程。它从图的形状中得到它的通用名称,如图所示

要构建鱼骨图,从您要解决的问题开始,该问题位于鱼的眼睛附近。从那里,确定问题的根本原因。通常,这些是 4P 或 4M,但可以是针对特定问题有意义的东西。4P 是人员、程序、政策和工厂。4M 是人、机器、方法和材料。一个示例图表显示了“可能”导致一杯咖啡变坏的原因如下

这些图表可以用笔和纸轻松构建,还可以使用各种图表工具,例如 Visio(参见业务流程/因果图)。要分析结果,请查找常见示例。是否多次列出某些内容?在这种情况下,没有培训和劣质输入(例如,坏糖、脏杯子等)似乎是需要进一步探索的非常常见的主题。这是一个非常适合在小组环境中使用的工具。

问为什么5次

[编辑 | 编辑源代码]

虽然很容易跳到解决方案,但确定某事发生的原因通常更难。最常用的根本原因分析工具之一被称为“5个为什么”。这是基于不断问为什么的前提。使用前面图示中的脏咖啡,您可以从咖啡不好这个明显的问题开始。通过问“为什么咖啡不好”,第一个回复可能是它很淡。下一个为什么是,“为什么咖啡很淡”,回复可能是咖啡不够。在问“为什么咖啡用量不够”时,回复可能是我们用完了。不断地问“为什么”,直到你找到可能的根本原因。为了说明这个概念,请参见下图

在华盛顿特区的杰斐逊纪念堂可以找到使用此工具的真实示例。美国国家公园管理局注意到,这座纪念碑的腐蚀速度比其他华盛顿特区纪念碑更快。通过问为什么5次,他们能够找到问题的根源,如下所示

  • 为什么纪念碑腐蚀得更快?因为它被清洗得更频繁。
  • 为什么纪念碑被清洗得更频繁?因为有很多鸟粪。
  • 为什么纪念碑上有更多的鸟粪?因为鸟儿非常喜欢这座纪念碑。
  • 为什么鸟儿更喜欢杰斐逊纪念碑?因为纪念碑内外有许多肥蜘蛛。
  • 为什么有很多蜘蛛?因为纪念碑周围有许多在晚上飞来飞去的昆虫。
  • 为什么有更多的昆虫?因为纪念碑的照明吸引了更多的昆虫。

在评估解决这个问题的各种方案(例如杀虫剂、特殊涂层、不同的灯光等)时,小组会确定不同的重点领域。在本案例研究中,公园管理局选择将每晚的灯光开启时间延迟一个小时。这一改变使鸟粪问题减少了 90%。

使用这种技术时,可以遵循不同的路径并得出不同的解决方案。如果发生这种情况,在确定适当的解决方案时,可以考虑几个因素,例如小组能够控制的内容。在杰斐逊纪念堂的案例中,他们有能力控制照明,并选择了一个无需成本的方案来解决问题。

此技术也用于需求收集,特别是在采访主题专家时。请参见“记录和管理需求”部分。

检查表/帕累托图

[编辑 | 编辑源代码]

有一句老话:“凡是能被测量的,就能被做到。”在根本原因分析中,结合创建简单的检查表来收集来自观察或事件的数据,并将数据绘制到帕累托图上,可以帮助确定问题区域。在没有数据的情况下,经常被认为或显而易见的问题会让你走上错误的道路。通过观察和记录特定时间段内事件发生的频率,可以确定相对严重程度。请参见下面的示例检查表。

收银员 卡纸 输入的信息错误 交易取消 资金不足 总数
A 4 2 2 9
B 10 5 3 2 20
C 3 2 5
D 3 1 1 1 6
总数 21 10 6 3 40

在构建检查表时,只需简单地确定要计数的内容,然后在它们发生时计数即可。在合理的时间段后,只需将发生的次数加起来。在本例中,识别的错误表明卡纸(纸张和设备问题)和操作员输入的信息错误。对于卡纸,可能是打印机有问题,也可能是要打印的材料有问题(重量、材料、涂层等)。为了解决这个问题,需要进行多次试验测试,以帮助识别真正的根本原因。对于“输入的信息错误”,可能只需对收银员 B 进行重新培训,或在后台添加一些编辑检查,以查找常见的错误。在所有情况下,最好先关注你直接控制范围内和环境中的项目,然后再尝试用技术解决问题。收集完数据后,可以使用称为帕累托图的强大工具来记录结果。帕累托图显示了问题或事件的相对重要性,其基础是 80% 的问题源于 20% 的原因。80-20 规则的基础是意大利经济学家维尔弗雷多·帕累托,他注意到 80% 的土地为 20% 的人所有。通过应用上述检查表的结果,下面是一个示例图表

请注意,该图有两个纵轴。左边的纵轴提供发生次数的相对计数,而右边的纵轴则关注总发生次数的累积%。通过将问题解决工作集中在最大数量上,总错误将显著减少。

相互关系图

[编辑 | 编辑源代码]

互相关系图是另一个有价值的工具,它有助于比较相关问题,以确定哪些是驱动因素(根本原因)以及哪些受到其他因素的影响(症状)。这项练习最好在有各种视角的小组环境中进行。矩阵可能需要一些时间才能完成,但通常会在完成后提供有价值的见解。使用症状/根本原因列表,创建一个矩阵(我们这里使用一个 5x5 的示例),然后在右侧添加 3 个额外的摘要列。

在本例中,我们将关注非有效会议的原因,5 个潜在的症状或根本原因是:没有议程、缺乏引导、会议上的人不对、少数人主导发言时间和重复讨论相同内容。在本例中,症状因小组和组织而异,毫无疑问,通过小组的意见,有可能提出更多项目。数量较少是为了演示如何构建、引导和评估结果。下面是一个已完成的矩阵

编辑说明:插入表示不良会议互相关系图的表格

对于每个已识别的问题,询问小组每个项目对另一个项目的影响。从 A. 缺乏议程到 B. 缺乏引导开始,询问小组,A 驱动或影响 B,还是 B 影响 A?通常,如果你有引导者,你通常也会有议程,因此在这种情况下,在 A 行/B 列上放置一个“向上箭头”表示 A 对 B 的影响,在 B 行 A 列上放置一个“向上箭头”表示 A 对 B 的影响。你会放置一个“向内箭头”表示 A 对 B 的影响。接下来,你将查看缺乏议程和会议上的人不对。虽然你可以“提出”一个弱论点,即如果你有一个议程,那么很明显你召集了错误的人参加会议,但这还有其他驱动因素——因此在这种情况下,我们将放置一个“-”连字符,表示没有关系。对于每对项目,矩阵将收到一个关系标记。完成后,就该加起来。将所有指向内部的箭头(被影响的项目)为每行相加,并将总和报告到“向内”列中。将所有指向向上的箭头(影响项目的项目)为每行相加,并将总和报告到“向外”列中,然后将向内和向外都相加。在评估结果时,寻找“向外”数量最多的项目作为你的根本原因。在本例中,缺乏引导者会导致重复讨论相同内容(一次又一次地开会)。此工具也非常适合确定关键流程以及根本原因。而不是列出问题或问题,而是记录所有流程并用字母表示,并评估哪些流程影响或直接影响其他流程。

快速问题解决 (RPR)

[编辑 | 编辑源代码]

此技术专门设计用于识别 IT 问题的根本原因。虽然它与 ITIL 问题管理流程一致,但它要求问题能够被复制,并且该方法旨在一次专注于一个症状,直到确定根本原因。该方法包括三个步骤:1) 发现 2) 调查和 3) 修复。在发现阶段,重要的是获取尽可能多的有关问题的信息(问题是什么,何时发生,在什么环境中,频率等),并确定我们要解决的问题是什么。调查阶段侧重于能够复制问题,以便可以识别导致问题的原因。在这种情况下,有必要开发和执行诊断数据捕获工具,以便可以获得结果来识别导致问题的原因。一旦确定了根本原因,就可以通过查看诊断数据来跟踪其发生的位置。找到问题后,需要开发和实施修复方案,并验证解决方案。

根本原因分析是解决问题的关键组成部分。如果你没有处理问题的根本原因,那么这个问题很可能不会消失。通过治疗症状,问题通常以不同的方式表现出来,提供了一组新的症状。由于解决问题的时间和资源有限,最好拥有几种工具来寻找根本原因。

参考文献

[编辑 | 编辑源代码]

编辑说明:按照格式规则编译并添加列表

华夏公益教科书