正常运行时间元素根本原因分析

正常运行时间元素的根本原因分析(Rca)是一个包罗一切的术语，它包含了各种方法和工具来预测潜在的问题、因素、缺陷或事件，这些问题、因素、缺陷或事件可能对企业、其价值流、员工的安全或政府法规的合规性产生负面影响。

根本原因分析是更普遍的问题预防、问题解决过程的一部分，也是风险管理[RI]、可靠性[RE]、损失消除[OPX]和持续改进[CI]的组成部分。

正因为如此，根本原因分析是企业可持续性和持续改进工作的核心构建块之一。需要注意的是，根本原因分析本身不会产生任何结果;它必须成为更大的质量改进问题解决努力的一部分，并将从中获得的知识转化为行动。

正常运行时间要素可靠性框架和资产管理系统欧洲杯德国意大利竞猜

围绕根本原因分析存在许多误解，极大地限制了这一过程所能提供的价值。

RCA的真理包括:

• RCA旨在防止可能导致问题的问题或事件，而不是事后进行事后分析，
• 它可用于评估业务和工作流程、程序和惯例，以确定固有的风险和损失，以及实物或资本资产，
• 所有的因果因素和强迫功能都应该被清楚地识别出来，而不仅仅是假定的根本原因
• 并不是所有事情都需要正式的RCA，但是即使在简单的问题解决练习中，逻辑和思维过程也是可行的。

根本原因分析过程

下面的图1提供了RCA流程的高级视图。而这些分析的主要来源或驱动因素是管理风险、损失和保持可靠性。当怀疑价值流或工作过程可能偏离最佳状态时，可以并且经常会提出额外的请求。无论启动源是什么，执行步骤都是相同的。

图1:正常运行时间元素根本原因分析欧洲杯德国意大利竞猜

可靠性工程的RCA

虽然顶级的评估可以，而且通常是由可靠性工程师完成的，但是当需要一个完整的、正式的RCA时，需要一个由可靠性工程师和与目标系统或过程相关的涉众以及主题专家组成的临时跨功能团队来提供更广阔的视角。这些团队被分配到特定的流程、业务或制造，并有1 - 3周的时间完成他们的任务。团队成员被分配特定的任务，如收集图纸，规格等，以加快时间表。在整个评估过程中，团队会进行简短的更新和解决问题的会议。解决问题的课程应限制在每节不超过四小时，以使参与者获得最大的利益。这是高强度解决问题活动的最长持续时间。4小时后，精神疲劳开始减少生产投入。

详细的根本原因分析过程

根本原因分析(RCA)是企业可靠性、风险管理和损失消除过程中不可或缺的一部分。在这三个关键领域的正常任务序列中，它是在那些被临界分析认为是关键的价值流和基础设施系统上执行的。正常的顺序是从最关键的开始，然后依次递减，直到所有资产都被评估完毕。

RCA的目的是识别可能存在于过程、程序、实践以及资本资产中的早期问题，这些问题可能会产生影响企业或其价值流的风险、损失或失败。根本原因分析不局限于资本或实物资产。

当用于评估业务或工作流程(如计划或调度)时，它与评估有形资产时一样有效。

图2:详细的根本原因分析过程欧洲杯德国意大利竞猜

详细的根本原因分析过程

1. 选择系统或资产:选择资产时，资产的相对关键度排序由临界分析(Ca)。业务和工作流程的选择是基于它们的重要性，或者因为组织中的某些人怀疑它们。
2. 收集信息:对于物理资产评估，这些信息包括功能规格、供应商或交货规格、安装图纸、调试文件、操作和维护程序。对于业务和工作流程，它包括价值流和流程图，以及流程预期可交付成果的详细描述。
3. 设计评审:这应该是RCA和RCFA中的第一步，并提供基线或基准参考，这对于评估中的其余步骤是非常宝贵的。设计评审包括但不限于质量平衡;单点故障;材料选择;元件选择及上浆;输入边界条件;输出边界条件;并设计操作包络。
4. 识别内在问题:在大多数情况下，设计评审将识别可能单独或综合导致风险、损失或可靠性问题的固有问题。每一个都应该清楚地识别和记录。
5. 量化风险和问题:对上一步中确定的设计问题列表进行量化，以更好地定义它们在未来某个时候发生的严重性和概率。
6. 应用程序检查对申请进行彻底的评估是这个过程的下一步。根据大量研究，平均27%的资产故障是由误用引起的，例如资产在其设计范围之外运行。
7. 找出差距和问题应用程序评审将反映设计评审，并进行差距分析，以确定和量化设计和应用程序之间的差异(如果有的话)。
8. 准备风险评估:该任务将在设计-应用评估中获得的知识结合起来，评估潜在风险，并制定风险评估，量化累积风险和发生概率。
9. 确定纠正措施:针对上述步骤中发现的每个问题，编制了一份纠正措施清单，并按相对风险进行了排名。
10. 准备成本效益分析:在风险分析提交执行管理层考虑和批准之前，需要进行成本效益分析。分析应以单项为基础，以便每项建议都能独立于总建议进行评估。
11. 提交建议供批准:风险评估、建议的纠正措施和成本效益分析提交行政领导团队批准。
12. 执行MOC流程:如获行政领导小组批准，所提议的更改必须经过变更管理确保所有的变更都有完整的文件记录，bom和图纸的变更，以及满足任何技能和/或培训要求。
13. 实施更改:实施所建议的变更，最好是在测试或控制区域，以确认它们将达到预期的结果而不会产生其他问题。
14. 跟踪变化和结果:直到所做的任何更改都达到了预期的结果，RCA才算完成。此步骤跟踪结果，并监视更改的不利影响。
15. 更新MOC文件:如果变更产生预期结果且无副作用，则更新所有MOC文件，如图纸、bom、工单等，并对结果进行注释。如果没有达到预期，则将项目路由到RCA-9。
16. 制度化的变化:应该再次评估这些变化，以确定它们在组织其他领域的潜力。如果是这样，更改将遵循已建立的MOC流程进行实现。

有效使用根本原因分析

根本原因分析通常不能坐在会议室、办公室或电脑前进行。虽然该过程确实需要工作组会议，以及个人和小组访谈，但该过程的核心是收集事实数据，这些数据可用于隔离、识别和量化可能导致所调查的系统或过程异常行为的真正原因。要做到这一点，调查人员或团队必须卷起袖子，把自己弄脏。

RCA流程需要亲身实践的访谈、检查、测试和评估过程，这些过程只能在工厂或现场完成。理论评估有其地位，但要有效地使用RCA过程，调查人员必须清楚地了解被调查系统的设计和运行动态，确认参与被调查事件的人员可能提供的任何和所有因素、假设或假设。

RCA的有效使用需要纪律和一致性。每次调查都必须彻底，必须遵循过程中定义的每个步骤。也许分析中最困难的部分是将事实与虚构区分开。人类的本性决定了参与业务或工作流程或以资产为中心的系统的每个人都受到他或她的经验的制约，他们的自然倾向是根据这种制约筛选输入数据。这也包括调查人员。然而，这往往会导致先入为主的想法和看法，破坏RCA过程的有效性。

对于调查者或调查小组来说，重要的是把他们的看法放在一边，把分析建立在纯粹的事实基础上，不做任何假设。通过访谈和其他数据收集过程进入分析过程的任何假设都应明确说明。如果这些假设不能被证实或证明，它们就必须被抛弃。

尽管各种类型的根本原因分析在目的和定义上似乎存在差异，但有一些一般原则可以被认为是普遍的。

根本原因故障分析不是一个单一的、定义好的方法

现有的RCA有几种类型或哲学。根据它们的应用领域，大多数可以分为四个非常广泛的类别:基于安全的、基于生产的、基于过程的和基于资产故障的。

1. 执行基于安全的RCA，以查找与职业安全、健康和环境有关的事故原因。
2. 执行基于产品或生产的RCA，以确定与产品相关的质量不良、生产和其他制造问题的原因。
3. 执行基于流程的RCA是为了识别与流程(包括业务系统)相关的问题的原因。
4. 基于资产故障的RCA用于工程和维护领域的资产或系统的故障分析。

RCA流程包括八个步骤:

1. 定义问题:听起来很简单，但很少是这样。缺乏准确的数据和工厂人员的失忆往往使无法确定真正的问题。在大多数情况下，可用的最佳信息将确定症状，但很少确定问题。
2. 收集数据和证据:意见很重要，但在RCFA调查中毫无价值。能够确认问题的准确数据和其他证据不仅有帮助，而且对于找出问题的真正原因是必要的。
3. 比较设计数据和应用程序数据:据统计，27%的与资产相关的可靠性问题是由超出设计的操作范围的资产操作引起的。在许多情况下，问题的根本原因可以通过简单的比较来解决。
4. 确定可能的因果因素:因果因素不是事件或事件的实际触发因素，而是单独或共同导致根本原因的作为或不作为。石川或因果图(也称为鱼骨图)是这种目的的理想选择。
   
5. 把原因和因果因素分开:到这一步的所有步骤，都指向这一步。从所有可能的，甚至可能的原因和根本原因中分离出真正的根本原因从来都不是一件容易的事。在大多数情况下，最终决定将取决于对一系列假设的检验，并通过排除过程得出最有可能的原因。
6. 提出解决方案和建议RCFA的目的是解决和消除事件、事件或故障。开发一个可行的、具有成本效益的解决方案需要集中精力，这可能需要QA、法规遵从和利益相关者的投入。任何最终解决方案都必须符合变更管理(MOC)程序。
7. 实施建议:一旦建议的解决方案经过MOC流程的全面审查，并得到行政领导团队的批准，就可以实施更改。首选的方法是在大规模实现之前进行小规模的实现，以测试和验证解决方案。
8. 跟踪建议的解决方案以确保有效性:上述步骤的一个关键部分是开发和包含将量化解决方案有效性的特定性能指标。纠正措施的安装应受到密切监控和评估，以确保达到预期的结果。

根本原因分析工具

• 设计评审所有的设计都有一些固有的问题，这些问题单独地或结合在一起可能会在未来的某个时候导致一个问题、事件或失败。设计评审评估针对这些问题的设计，以及验证资产或系统的操作信封。这个信封定义了资产可靠性和可持续性可接受的边界条件。所得结果为所有其他RCA和RCFA方法提供了基础。
• 应用程序检查:类似于设计评审，但重点是应用程序的安装和边界条件。比较设计和应用程序边界条件的差距分析将解决相当大比例的资产相关问题。
• 5为什么分析：一种发现问题根源的解决问题的技巧。这种技术可以帮助用户通过简单地多次询问“为什么”来快速找到问题的根源，直到根本原因变得明显。
• 障碍分析一种调查或设计方法，涉及追踪目标受到危险不利影响的途径，包括确定任何可能或应该防止不良影响的失败或缺失的对策。
• 故障树分析一种调查和分析技术，用于以逻辑的、树状结构的层次结构记录和显示发生给定结果所必需的和足够的所有行为和条件。
• 导致映射-一种简单而有效的分析、记录、交流和解决问题的方法，以显示个体因果关系是如何相互联系的。
• 因果分析也被称为石川图或鱼骨图，它确定了一个结果或问题的许多可能原因，然后将想法分类为有用的类别，以帮助制定适当的纠正措施。图的设计看起来像鱼的骨架，因此被命名为“鱼骨”图。
• 变化分析:在发生变化的情况下，系统地寻找可能的风险影响和适当的风险管理策略。这包括更改系统配置、修订操作规程或策略、执行新的或不同的活动等情况。
• 失效模式及影响分析(FMEA):一种技术，用于检查资产、流程或设计，以确定可能发生故障的方式及其对所需功能的潜在影响，并随后为最高优先级的风险确定适当的缓解任务。
• 故障树分析:该分析工具从最后的故障或事件开始构建，并逐步跟踪导致前一个原因的每个原因。这种情况会一直持续下去，直到无法再追溯下去为止。一旦完成了故障树并检查了逻辑流，就可以确定哪些更改将防止具有显著结果的原因或事件序列再次发生。
• 事件序列分析:将导致事件或事件的每个步骤或行动图表化。每个步骤或行动都有时间戳，确定导致行动的任何假设或促成因素。该图扩展到触发器事件或事件之外，映射为解决事件而采取的操作。

每个可靠性领导者应该知道的

根本原因(RCA)和根本原因故障(RCFA)分析被不正确地使用，无论何时讨论它们的互换性都会造成许多混乱。后者，根本原因故障分析(RCFA)更常用，但提供的好处较少:

• 根本原因分析(RCA):执行RCA是为了防止事故、事件或故障发生的可能性。就像设计故障模式和影响分析(DFMEA)用于在设计过程中消除潜在的或固有的缺陷一样，RCA用于整个操作/维护阶段，以预测和预防可能导致问题的原因。
• 根本原因故障分析(RCFA):使用许多与RCA相同的技术和工具，它仅在事件、事件或故障发生后执行。其目的是防止同一事件、事件或故障的再次发生，在大多数情况下不考虑资产中固有的其他问题。

由于所涉及的时间和工作水平，许多组织不执行正式的或完整的RCA，很少执行RCFA。相反，当强制事件(如受伤、环境远足或其他违反法规的行为)迫使他们使用RCFA时，使用仅限于RCFA。在这种情况下，监管机构要求进行全面的RCFA分析，并必须在事件发生后24小时内开始全面、详细的调查。

根本原因分析不是一种放之四海而皆准的方法。

实现RCA有许多不同的工具、过程和理念。作为一种优化工具，RCA是非常有价值的。它的框架和分析方法，如Ishakawa图和PFMEA，非常适合识别由不适当的设计、操作或维护引起的内在因果因素或强制功能。有了这些先验知识，就可以采取措施预防这些因素，维持资产组合的可靠性、性能并延长使用寿命。

组织必须不断改进流程，降低成本，减少浪费，以保持竞争力。为了改进任何过程、失败/问题，包括潜在的失败，都需要使用工具和技术进行分析，以制定和实施纠正措施。从简单的清单到复杂的建模软件，各种方法、技术和工具都是可用的。它们可以有效地引导我们采取适当的纠正措施。应用持续改进工具可以优化工作流程，并帮助任何组织改进其结果，无论其规模或业务环境类型如何。

RCA是一个在许多情况下引入组织改进的过程，持久的改进，最重要的是，一个学习过程，以彻底理解关系，原因和结果，以及解决方案。通过实践RCA，我们消除了对可能原因的行动，并将响应延迟到确定结果的实际根本原因的最后负责时刻。

重点:

• RCA是一种问题预防方法;RCFA是一种解决问题的方法。
• 两者都使用循序渐进的方法，从而发现潜在或实际事件、事件或失败的根本原因和因果因素，以及它们的因果因素。在许多情况下，单独或综合的原因和结果是其他问题或问题，也是可以预防的。
• 执行RCA的主要目的是分析潜在的问题或事件，以识别:
• 如何防止设计运行参数的退化?
• 如何消除因果因素或强迫作用?
  • RCA可以帮助将反应性文化转变为前瞻性文化，在问题发生之前解决问题。
  • 为了有效，RCA和RCFA必须系统地执行;需要跨职能团队的努力，并分配固定的时间限制。

参考文献

安德森，比约恩，费格豪格，汤姆。根本原因分析．密尔沃基:ASQ质量出版社，2006
Gulati,拉梅什。维护和可靠性最佳实践．纽约:工业出版社，2012
拉丁裔，罗伯特·J.;拉丁裔，肯尼思·C.;拉丁裔，Mark A。根本原因分析:为最终结果提高绩效。博卡拉顿:CRC出版社，2002年
莫布里，r·基思。根本原因分析，2^nd编著。波士顿:Butterworth-Heinemann, 2002
莫布里，r·基思。维护和可靠性工程师的经验法则。波士顿:Butterworth-Heinemann, 2008
莫布里，R.基思维修工程手册，8^th纽约，麦格劳-希尔出版社，2014年
南希·R·塔格质量工具箱．密尔沃基:ASQ质量出版社，2005