干货：掌握RCCA（根因改善活动），质量工作更有效

大家好，欢迎来到IT知识分享网。

RCCA （ Root Cause Corrective Actions根因改善活动 ）是一种质量问题处理的 过程方法，它从事故本身入手， 利用故障树图原理，通过分析根本原因 ，逐步制定临时遏制 措施、纠正措施、预防措施等，最终达到 解决质量问 题， 杜绝事故重复发生的 目 的 。

RCCA 对于形成完整的问 题分析处理报告提交给客户或进行内 部知识库管理，都起到重要的作用 ，推动了过程的持续改进。

1 RCCA 背景

传统思维里， 人们对于出 现的质量问题， 倾向 于急于解决，急于下定论， 采用 “创可贴”式的权宜之计解决，导致问题原因分析失败， 达不到从根本上解决问题，杜绝问题再次发生的目 的。

常见问题分析失败的原因主要有：

（ 1 ） 问题的定义不准确。
（ 2 ） 停止在表面的原因分析阶段。
（ 3 ） 过多关注问题责任人的指定。
（ 4 ） 视野狭隘， 只关注单方面的原因的寻找。
（ 5 ） 过于武断地分析原因、解决问题。
（ 6 ） 未对事实进行分析， 采用先入为主的解决方案。
（ 7 ） 受分析人员知识结构和范畴的限制。
（ 8 ） 根据经验或专业知识进行猜测，而没有依据事实开展分析。
（ 9 ） 受经验影响，使用以前实用的解决方案。
（ 10 ） 思维随大流。
（ 11 ） 没有验证成功的方法。

RCCA 工具力 求高效地识别问题的 根本原因 ， 并与FMEA（ Failure Mode and Effect Analysis ，失效模式和效果分析）工具关联使用 ，这也与 ISO 9001 和 IRIS （国 际铁路行业标准） 质量体系标准中要求的对与产品和过程相关的缺陷进行分析，找出 根本原因，确保纠正措施的实施有效性，吸取经验教训并进行持续改进的理念不谋而合。

2 RCCA 过程流程

RCCA 是一种处理质量问题的过程方法，是一个为了识别并找出 问题的根本原因，防止类似的问题重复发生而制定并实施纠正预防措施的过程。结合 8D 方法，确定其过程流程如下图所示。

RCCA流程图

针对 RCCA 过程流程中的这 5 个部分， 分8个步骤进行实施。

（ 1 ） 确定问题的内 容。
（ 2 ） 成立多功能分析小组。
（ 3 ） 清晰并准确地描述问题。
（ 4 ） 收集与问题相关联的数据和信息。
（ 5 ） 分析事故的所有原因。
（ 6 ） 确定根本原因。
（ 7 ） 彻底解决问题，确保不再发生。
（ 8 ） 跟踪解决效果，确保根本原因已解决。

3 RCCA 实施过程

RCCA 的实施过程主要从以下 5 个部分详细说明，明确各个部分实施的具体方法和注意事项。

3．1 问题定义

问题定义是 RCCA 过程中的起始环节。事故是否被清晰地描述，事故本质是否被理解，将直接影响问题的原因分析及最终的成功解决。问题定义主要包括：确定的事故内 容及其清晰的事故描述；组建专业的、高效的多功能问题解决团队。

3．1．1 事故描述

我们把组织内 外部“发生了 什么 问题， 有了 什么 故障”称为事故， 事故主要包括：顾客投诉／反馈、审核发现的问题及开口项、现场故障、产品失效、特殊事件等。

事故的定义，需把握以下 4 个关键因素。

（ 1 ） 问题或事故是什么，包括：我们不希望此问题再次发生，怎么被发现和传递的，相关照片和图标的说明。
（ 2 ） 事故发生在哪里，即事故发生的地址和其他相关的地点。
（ 3 ） 事故什么时候发生的，即事故发生的日 期和时间，是否为重复发生，是否具有一定的倾向性或规律性。
（ 4 ） 事故等级的确定，根据事故损失及潜在风险、可能带来的不良后果确定事故等级。

事故是后续整个团队需要关注和处理的，是否不失真地被清晰描述显得尤为关键。事故的描述应做到简明扼要、集中在一个关键问题上，突出事故时间、地点、内容、数量等信息， 并能正确地反映事故的本质。事故的描述不应包括导致事故发生的原因、后续的计划、对于事故发生的相关解释等。事故正确的描述范例如下表 所示。

事故描述范例

3．1．2 RCCA 小组

问题的处理不是一个人埋头苦干，独立开展，而是需要根据事故本身，组建专业的 、高效的 多功能问题解决团 队，称为“ RCCA 小组”。

RCCA 小组是一组致力于同一目标，并对团队富有责任心的个人所组成的团队。RCCA 小组的组建要求如下：

（ 1 ） 小组成员规模为 5～10人。
（ 2 ） 小组成员必须由 不同部门、不同知识结构的成员组成，确保小组的多功能性。
（ 3 ） 组长不由 专家或领导来担任，选择一位不会影响团队分析结果的人来组织和领导团队。
（ 4 ） 小组成立时，明确团 队纪律以确保问题处理的顺利进行。
（ 5 ） 制订计划，确定问题处理计划的安排和实施。

RCCA 小组分为固有团队和专业团队。 固有团队由问题的利益相关方组成， 他们对导致问题出 现的各个因素有直接的责任关系， 并有义务解决相关问题； 而专业团队除包含固有团队成员外， 还包含一些专业的支持人员 ， 他们推动根本原因的分析和纠正措施的实施。 他们各自 的特点如下表所示。

固有团队和专业团队的特点

RCCA 小组的成员不局限于此， 可以根据问题处理和解决的进展情况进行更新和拓展， 以保证根本原因的分析和纠正措施的实施。

3．2 收集和验证数据

根据小组计划， RCCA 小组需要进行与事故相关的数据的收集。

RCCA 过程中数据的收集， 不同于传统意义上的收集， 更要对收集的数据进行验证， 确保其有效性。

RCCA 过程中数据的收集需要注意以下事项：

（ 1 ） 收集的数据来源于事故发生前、发生时和发生后。
（ 2 ） 目 光狭窄、有思维定势或先入为主的人员将影响数据的收集过程。
（ 3 ） 事故发生后， 需尽快进行数据收集， 不能拖， 不能等， 否则难以获取准确的信息和数据。
（ 4 ） 数据的收集可能会多次进行， 但最初的收集将影响整个数据的分析过程。

在RCCA 过程中， 将数据信息分为： 客观数据信息、人员 信息、书面数据信息等。 这些数据信息可以是直接获得的， 也可以是经过简单的推断（根据经验或感官） 得出 的 ； 而且可以是不同形式的， 如：声音、作业记录、气味等。但是无论哪种数据信息， 都是我们得出 事故最终结论的基础， 都需要我们对其有效性进行评估和验证。

数据信息类别及相应数据收集的注意事项， 如下表 所示。

不同信数据息收集注意事项

数据信息收集完成后，需要对数据信息进行验证。验证可以通过外部资源支持、经验推断和内 部讨论等方式进行， 验证的内容主要包括：

（ 1 ） 获得的数据信息是否已经更新。
（ 2 ） 数据信息是否可靠。
（ 3 ） 数据信息是基于事实的情况还是主观的的判断。
（ 4 ） 提供数据信息的人员背景怎样。
（ 5 ） 数据信息之间是否存在矛盾。

其实往往在实际过程中， 收集数据信息完成后， 我们已经能够对事故进行风险评估， 并采取紧急的措施遏制事故的进一步发展， 将损失降至最低。

3．3 根本原因分析和确定

找到问题和事故发生的根本原因 ， 对防止其重复发生， 彻底解决问题起到关键作用。

3．3．1 问题原因的定义

原因是引 起事物变化的必要因素，可以是一组环境或条件，引 起了一个状况的出 现或一个事故的发生。事故发生后，我们所要关心、确定的是为什么会发生这个事故， 是什么因素直接导致事故发生， 什么因素对事故发生起到关键作用 以及什么是根本的因素。 为此， 我们将问题原因分为直接原因 、关键原因和根本原因 3 类， 分别定义如下。

直接原因： 直接导致和触发了 事故的发生， 事故成因链中的第一个原因。

关键原因： 导致事故的发生， 但其本身并不会导致事故的直接发生， 事故成因链中的第二个原因。

根本原因 ： 导致了事故的发生， 但如 果纠 正了 此原因 ， 将会防止该事故或类似事故的再次发生， 事故成因链中的最后一个原因。

3．3．2 原因分析工具

质量问题原因分析的工具很多， 如因果图、 5Why 方法、故障树图等。 因果图又称“鱼刺图”， 如下图所示，

因果图（鱼刺图）

其考虑了 整个过程的各个领域， 而不仅限于自己所熟悉的领域， 因此因果图能够将所有相关因素联系起来，并将所有参与者融入其中， 采用头脑风暴进行分析。但是因果图使整个分析过程变得很复杂，可能受分析人员限制忽略了一些因素，而且没有对原因进行很好的归类。

RCCA 过程中对于原因 的分析采用 故障树图 进行，并借助5Why 的方法， 形成事故的成因链，包含直接原因、关键原因和根本原因。 绘制故障树，可以借助 X－mind 、 Mindmanager 等软件进行，但不管怎样，在绘制故障树前，必须对潜在可能的 原因 进行排除。 在对潜在可能的原因进行排除时， 应用到前面收集到的数据和信息。

3．3．3 根本原因的确定

RCCA 中主要采用故障树图进行根本原因的确定， 常见的故障树如下图所示，

常见故障树图

图注： ① 箭头方向代表因果关系；
② 直接原因一般只有 1 个， 关键原因可能有很多个， 需要用收集到的信息和数据进行排除。
③ 对故障树中的每个原因， 重点询问两个问题： 为什么会发生这个问题， 为什么没有发现该故障或问题。

描述了故障树的成因链及绘制原则。

通过故障树图， 可以看出根本原因是事故成因链中的最终的原因， 但并非最重要的原因 。 找到根本原因之前， 问为什么的次数， 即关键原因的层次数， 取决于问题的复杂程度， 故制定了界定根本原因的原则如下：

（ 1 ） 根本原因是特定的潜在原因。
（ 2 ） 根本原因是那些可以明确定义和识别的。
（ 3 ） 根本原因是那些需要从管理上予以控制和解决的。
（ 4 ） 根本原因的解决， 能够打破成因 链， 防止问题的再次发
（ 5 ） 根本原因确定后， 利 用 倒 推法进行验证， 以彻底解决问题。

常见的根本原因如：不适当 的指导说明 文件、 不适当 的工具、不清楚的指导和要求等， 切忌寻找操作者的错误和问题。

3．4 制定和实施纠正措施

RCCA 流程中将纠正措施分为： 临时纠正措施（也叫 遏制措施）、纠正措施和预防性纠正措施， 定义和实施效果如下表 所示。

纠正措施的定义和实施效果

在制定和实施纠正措施时， 应注重预防性纠正措施的制定和实施， 形成一个有效的解决方案， 同时更新 FMEA 和控制计划。 一个有效的方案， 将能防止问题再次发生， 这里定义评估有效方案的原则如下：

（ 1 ） 能够防止问题的再次发生， 彻底破坏了 成因链。
（ 2 ） 方案不会导致其他新的问题发生， 成为其他问题的诱因。
（ 3 ） 在组织内 部是可以解决和控制的， 即方案是受控的。
（ 4 ） 实施方案的成本合理。
（ 5 ） 能够让所涉及的员工充分参与， 获得广泛的关注。

在实际过程中， 针对根本原因制定的措施， 可能需要高层管理者的支持， 但是不管怎样， 不能忽视问题、放弃纠正。 同时， 实施纠正措施， 还需注意以下几点：

（ 1 ） 实施纠正措施的人员需要明确指定， 并在指定后改进方案才能被实施。
（ 2 ） 不能把纠正措施安排给 RCCA 小组以外的其他人员。
（ 3 ） 纠正措施的实施需要有相关记录。
（ 4 ） 如果当时实施了纠正措施， 是否能防止问题的发生。

3．5 控制成功

控制成功阶段是 RCCA 流程中最后一个环节， 主要包括： 跟踪纠正措施， 评估纠正措施的有效性， 确保根本原因 已 被消除；

审核业务流程， 确保管理的持续改进； 分享经验和教训。

3．5．1 跟踪纠正措施

纠正措施制定后， 需要检查各个措施是否按时、按要求完成了 。 对纠正措施的跟踪主要有以下要求；

（ 1 ） 指定纠正措施的跟踪负责人。
（ 2 ） 纠正措施的完成情况需要说明， 并采用 绿、黄、红三色进行标识， 绿代表已经按时有效完成； 黄代表按时有效完成有风险， 但采取了 相应的急救措施； 红代表按时有效完成有风险， 无相应的急救措施。

3．5．2 评估纠正措施

评估纠正措施主要是评估纠正措施是否在控制问题的重复发生上起到了有效的作用， 是否达到了 预期的效果。 评估纠正措施主要有以下要求：

（ 1 ） 如果纠正措施与之前所制定的有所区别 ， 需要找出 原因。
（ 2 ） 如果实施过程中， 有更好的措施， 需要更新之前所制定的措施， 并验证。
（ 3 ） 对纠正的对象需要进行定期的再验证， 以确保纠正措施依然有效。
（ 4 ） 如果评估纠正措施未达到预期要求， 应返回进行重新分析， 并制定纠正措施。
（ 5 ） 有效的纠正措施应进行文件化和制度化。

3．5．3 审核业务流程

审核业务流程， 主要是通过管理的过程， 识别和确认改进的机会， 做到持续改进， 优化现有流程， 固化成功的流程， 起到举一反三的作用。

3．5．4 分享经验和教训

在控制成功阶段， 一方面必须保证改进的成果一直保持着，不回 到 老的 方法上， 而且还要将过程中 获得的 经 验和 教训 与RCCA 小组成员 ， 甚至是其他成员 进行分享， 进行改进知识的管理， 建立知识库， 有利于其他人员 或新近人员 在后续实施改进过程中参考借鉴。

4 RCCA 应用

RCCA 作为一种问题的解决思路和工具， 可应用 在各类问题或事故的解决上， 特别是针对顾客抱怨的处理， RCCA 可形成完整的 8D 报告， 告知客户 组织的改进和持续改善。 这里重点介绍RCCA 在处理顾客抱怨上的应用。

8D 报告汇集了 RCCA 各个过程的信息， 并将其告知客户 。在RCCA 的 不同 阶段， 可反馈客户 该问 题的 具体进展 ， 因 此 可利用 RCCA 的 不同 阶 段信息 回 复 客户 。 基本的 回 复 步 骤要 求 如下：

（ 1） 在48 小时以内 ， 进行初始回复， 反馈组织的临时纠正措施。
（ 2 ） 后续根据 RCCA 的流程和进展情况， 更新 8D 报告， 进行问题的过渡回复。
（ 3 ） RCCA 完成后， 提供汇集 RCCA 过程的 所有信息， 更新8D 报告， 进行问题的终期回复。着眼于客户 开展的问题解决流程如下图所示， 除回复的步骤外， 该流程可应用于其他内 部问题或事故。

着眼于客户的持续改进流程