作者:admin 时间:2022-12-20
根本原因分析 (RCA) 是一个综合术语,包含一系列问题解决方法,用于确定不合格或质量问题的真正原因。 根本原因分析是定义、理解和解决问题的过程。根本原因也被描述为不符合项、缺陷或故障的根本或根本原因。此外,术语“根本原因”也可以称为因果链中的确切点,在此点上,应用纠正措施或干预可以防止不合格的情况发生。
重复问题是制造过程中浪费的根源。以机器停机、产品返工、废品增加以及“”问题所花费的时间和资源的形式出现的浪费。很多时候,我们可能认为问题已经解决,但实际上我们只是解决了问题的症状,而不是真正的根本原因。如果执行得当,根本原因分析可以识别流程或系统中导致不合格情况的故障,并确定如何防止其再次发生。执行 RCA 以确定发生了什么,为什么会发生,然后确定需要哪些改进或更改。通过正确应用RCA,可以消除重复问题。
RCA方法和工具不于制造工艺问题。许多行业正在各种情况下应用 RCA 方法,并使用这种结构化方法来解决问题。使用 RCA 的一些示例包括但不限于:
●办公流程和程序
●质量控制问题
●医疗事件分析
●基于的情况或事故分析
●工程与维护中的故障分析
●变更管理或持续改进活动
●计算机系统或软件分析
关键是RCA几乎可以应用于公司每天面临的任何类型的问题。可以使用 RCA 的另一个示例是遇到大量错误客户订单和发货的公司。可以绘制和分析该过程,并可以识别和解决问题的根本原因。最终结果是满意、忠诚的客户群和更低的公司总体成本。
根本原因分析 (RCA) 通常是更大问题解决练习中的一个步骤。在根本原因分析期间可以使用多种工具。其中一些有时可以由一个人完成,但在大多数情况下,跨职能团队(CFT)方法将获得最大的好处,并增加达到真正“根本原因”的机会。
还有几种解决问题的方法在其问题解决过程中使用根本原因分析,例如问题解决八项学科(8D),六西格玛/ DMAIC或。RCA 是每个示例中的关键步骤。
在执行 RCA 之前,明确定义问题。确定并记录以下信息:
●谁发现了问题?
●到底发生了什么?
●在过程中的哪个地方发现了问题?
●问题何时发现?
●发生多少/多久发生一次?
●如何发现问题?
接下来,团队可能需要收集数据或其他附加信息。可能还需要启动临时遏制或纠正措施。团队应审查所有收集的信息并进一步定义问题。应该根据事实和数据来定义问题。描述问题后,团队就可以开始根本原因分析阶段。
该小组应由直接了解所审查程序并负责执行任何长期纠正行动的人员组成。此外,团队应包括来自质量、工艺工程的代表,并在适当时包括来自流程下一步或其他班次的团队成员。 CFT的每个成员都将带来自己的知识和对过程和不符合项的看法。
在根本原因分析期间可以使用多种工具。本节将介绍一些工具,包括它们如何以及何时对分析有价值。第一步是使用“是/不是”分析确定问题调查中包括的内容和未包含的内容。
“是/不是”分析可以在RCA的不同点使用。在定义问题时,可以使用它来确定哪些在范围内,哪些在分析过程中将被考虑,哪些在范围之外,不会被考虑。它还可用于规划解决方案,以帮助团队决定要包含的内容和要排除的内容。Is-Is Not 分析允许团队思考问题以及问题是什么或不是什么的界限。 该工具可帮助团队保持专注。 如果问题的边界没有明确定义,团队可能会偏离最初的路径,并致力于解决无关紧要的问题。
记录“是”和“不是”问题的一部分或特征。该过程通过向团队提出各种问题来工作,例如:
●谁会受到此问题的影响?
●团队是否有权解决此问题?
●关于这个问题,我们已经知道多少?
●这会影响客户吗?
●我们真的会为此做些什么吗?
向团队提出足够的问题,直到对问题解决过程的问题/范围有一个明确的定义。
是/不是示例
石川或鱼骨图是确定质量问题最可能原因 (MLC) 的有用工具。该图有时被称为鱼骨图,因为它看起来很像鱼的骨架,其效果或问题列在最后的框中。图表的主要部分用于解决6Ms(人,材料,方法,机器,测量和大自然(环境)。这些图表通常是从右到左处理的,鱼的每个大“骨头”都分支出来,包括带有其他细节的小骨头。重要的是不要限制团队在这里集思广益。如果一个想法在图表的不同部分,只需将其列在相应的部分中,然后稍后返回。一旦团队集思广益了问题的所有可能原因,团队应该根据潜在原因的重要性和导致失败的可能性对潜在原因进行评级,并制定层次结构。从层次结构中,团队应选择要进一步调查的原因。
5 为什么方法只是简单地问“为什么”这个问题足够多,直到你通过问题的所有症状并找到根本原因。5个为什么经常在解决问题的活动中使用。它还与其他分析工具(如因果图)协调使用,但也可以用作独立工具。当答案来自对所研究问题有实践经验的人时,5个为什么是最有效的。要发现问题的根本原因,请继续问“为什么”。通过重复“为什么”,您可以找到问题的根本原因。一般的经验法则是,您应该达到第 3 到 5 个“为什么”,或者您可能只解决问题的症状,而不是实际的根本原因。5 个为什么表单有时可以有三个独立的区域(或“腿”)来解决 5 个为什么:为什么会发生,为什么没有检测到它以及为什么我们的系统失败。应该探索每个区域,每个区域可能有多个因果进展。
失效模式和影响分析 (FMEA) 是一种定义明确的工具,可以识别系统或过程中的各种失效模式。在许多公司中,如果在流程或产品中检测到重大问题,团队需要审查与该问题相关的任何现有FMEA。团队应确定故障的问题或影响是否在 FMEA 中确定,如果是,团队评估风险的准确性。如果问题未包含在 FMEA 中,则团队应添加任何已知信息,然后完成以下步骤:
●将当前问题列为设计或工艺的故障模式
●通过定义问题的严重程度或故障的影响来识别故障的影响
●列出所有可能的病因及其发生次数
●查看过程FMEA时,请查看过程流程或过程图,以帮助找到根本原因
●接下来确定逃生点,这是过程中可能检测到根本原因但未检测到的最接近点
●记录旨在预防或检测问题的任何控制措施
●列出为防止此问题再次发生而可以实施的任何其他操作,并为每个建议的操作分配所有者和截止日期
●将任何已确定的行动转移到RCA的反措施活动中
一旦团队使用上面列出的工具的任意组合确定了根本原因,他们制定适当的对策或纠正措施。此外,该小组应制定执行对策的行动计划。
对策通常分为两类:
1.短期或即时对策——一般可在1周内完成。如果不是,则应将其指定为“长期”反措施。
2.长期或性的对策——通常更复杂,可能需要额外的资源才能完成。所有“长期”对策都应该能够在不到1个月的时间内完成。如果没有,则应将其转发给持续改进 (CI) 团队进行评估,作为或黑带项目的一部分。
纠正措施由分配完成任务的团队成员明确定义并可实现。行动计划还应包含每个纠正措施的预期截止日期。人们经常发现,没有所有者或预期到期日的纠正措施很少完成。有时,对策要求多个团队成员同时或按特定顺序完成任务。行动计划应用于跟踪完成对策实施所需的各个行动项目的进展情况。
团队还应确定验证(或验证)计划。这是用来提供对反措施有效性的书面考绩。这可能需要记录数据或审计在RCA演习期间制定和实施的任何控制措施。应收集证据以验证对策或纠正措施的有效性。 此外,在采取性反措施后约30天重新组建小组是一种良好做法。小组应审查反措施的有效性,并确定自反措施实施以来是否出现问题。该团队还应审查流程(如果适用),以确保遵循所有对策。
通过确定根本原因并采取措施防止其再次发生,开发一个强大的、精心规划的根本原因分析 (RCA) 流程对公司非常有价值。在有效的RCA中吸取的经验教训通常可以延续到类似的设计或流程中。这应该启动解决问题的持续改进思维模式,并在整个公司传播。
英文版:
Root Cause Analysis (RCA) is a comprehensive term encompassing a collection of problem solving methods used to identify the real cause of a non-conformance or quality problem. Root Cause Analysis is the process of defining, understanding and solving a problem. The root cause has also been described as an underlying or fundamental cause of a non-conformance, defect or failure. Furthermore, the term “root cause” can also be referred to as the precise point in the causal chain where applying a corrective action or intervention would prevent the non-conformance from occurring.
Repeat problems are a source of waste in manufacturing. Waste in the form of machine downtime, product rework, increased scrap and the time and resources spent “fixing” the problem. Many times we may believe that the problem is resolved but in reality we have just addressed a symptom of the problem and not the actual root cause. Correctly performed, a Root Cause Analysis can identify breakdowns in your processes or systems that contributed to the non-conformance and determine how to prevent it from happening again. An RCA is performed to identify what happened, why it happened and then determine what improvements or changes are required. Through the proper application of RCA, repeat problems can be eliminated.
RCA methods and tools are not limited to manufacturing process problems only. Many industries are applying RCA methodology in various situations and are using this structured approach to problem solving. Some examples of where RCA is being used include, but are not limited to:
●Office Processes and Procedures
●Quality Control Problems
●Healthcare Incident Analysis
●Safety-based Situations or Accident Analysis
●Failure Analysis in Engineering and Maintenance
●Change Management or Continuous Improvement Activities
●Computer Systems or Software Analysis
The point is that RCA can be applied to almost any type of problem that companies face every day. Another example where RCA could be used is for a company that is experiencing a high level of incorrect customer orders and shipments. The process can be mapped, analyzed and the root cause (s) of the problems can be identified and resolved. The end result is a happy, loyal customer-base and lower overall cost to the company.
Root Cause Analysis (RCA) is usually a step in a larger problem solving exercise. There are multiple tools that may be used during a Root Cause Analysis. Some of them can sometimes be completed by one person, but in most cases a Cross Functional Team (CFT) approach will reap the greatest benefits and increase chances of reaching the true “root cause”.
There are also several problem solving methods that use Root Cause Analysis within their problem solving process, such as Eight Disciplines of Problem Solving (8D), Six Sigma / DMAIC, or Kaizen. The RCA is a critical step in each of these examples.
Before RCA can be performed, the problem must be well defined. The following information must be determined and documented:
●Who discovered the problem?
●What exactly happened?
●Where in the process was the problem discovered?
●When was the problem discovered?
●How many / How often does it happen?
●How was the problem detected?
Next, the team may want to collect data or other additional information. It may also be necessary to initiate interim containment or corrective actions. The team should review all gathered information and further define the problem. The problem should be defined based on facts and data. Once the problem is fully described the team can then begin the Root Cause Analysis phase.
The Team should be comprised of personnel that have direct knowledge of the process being examined and responsibility for implementing any permanent corrective actions. In addition, the team should include representatives from Quality, Process Engineering and, when appropriate, team members from the next step in the process or from other shifts. Each member of the CFT will bring their own knowledge and view of the process and the non-conformance.
There are multiple tools that could be utilized during a Root Cause Analysis. This section will cover some of the tools including how and when they could be of value to the analysis. The first step is to determine what is included and what is not included in the problem investigation using the Is/Is Not analysis.
The “Is/Is Not” analysis may be used at different points in the RCA. It can be used while defining the problem to determine what is in scope and will be considered during the analysis and what is out of scope and will not be considered. It can also be used when planning a solution, to help the team decide what to include and what to exclude. The Is-Is Not analysis allows the team to think about the problem and the boundaries of what it is or is not. The tool helps the team maintain their focus. If the boundary of the problem is not clearly defined the team may stray off the initial path and work on solving inconsequential problems.
Document what “Is” and “Is Not” part of or a characteristic of the problem. The process works by asking the team various questions such as:
●Who is impacted by this problem?
●Does the team have the authority to resolve this issue?
●What do we already know about the problem?
●Is this something that will impact the customer?
●Will we actually do something about this?
Ask the team enough questions until there is a clear definition of the problem / scope of the problem solving process.
Is/Not example
The Ishikawa or Fishbone Diagram is a useful tool in determining the most likely causes (MLCs) of a quality problem. The diagram is sometimes referred to as a Fishbone Diagram because it looks much like a skeleton of a fish with the effect or problem being listed in a box at the end. The main sections of the diagram are used to address the 6Ms (Man, Material, Method, Machine, Measurement and Mother Nature (Environment). The diagrams are usually worked right to left, with each large “bone” of the fish branching out to include smaller bones with additional details. It is important not to limit the teams brainstorming ideas here. If an idea is in a different section of the diagram, simply list it in the appropriate section and then go back to it later. Once the team has brainstormed all the possible causes of the problem, the team should rate the potential causes according to their level of importance and likelihood of contributing to the failure and develop a hierarchy. From the hierarchy the team should select which causes to further investigate.
The 5 Why method is simply asking the question “Why” enough times until you get through all the symptoms of a problem and down to the root cause. The 5 Whys is often used during the problem solving activities. It is also used in coordination with other analysis tools, such as the Cause and Effect Diagram, but can also be used as a standalone tool. The 5 Whys is most effective when the answers come from people who have hands-on experience of the issue being examined. To discover the root cause of a problem, keep asking “why”. By repeating “why”, you can drive down to the root cause of the problem. A general rule of thumb is that you should reach the 3rd to 5th “why”, or you may just address a symptom of the problem and not the actual root cause. The 5 Why Form can sometimes have three separate areas (or “legs”) to address the 5 Whys: Why it occurred, Why it was not detected and Why our systems failed. Each area should be explored and you may have more than one causal progression for each area.
Failure Modes and Effects Analysis (FMEA) is a well-defined tool that can identify various modes of failure within a system or process. In many companies if a major problem is detected in the process or product, the team is required to review any existing FMEAs in relation to the problem. The team should determine if the problem or effect of the failure was identified in the FMEA and if it was, how accurately the team evaluated the risk. If the problem is not included in the FMEA, the team should add any known information and then complete the following steps:
●List the current problem as a failure mode of the design or process
●Identify the impact of the failure by defining the severity of the problem or effect of failure
●List all probable causes and how many times they occur
●When reviewing a process FMEA, review the process flow or process diagram to help locate the root cause
●Next identify the Escape Point, which is the closest point in the process where the root cause could have been detected but was not
●Document any controls in place designed to prevent or detect the problem
●List any additional actions that could be implemented to prevent this problem from occurring again and assign an owner and a due date for each recommended action
●Carry any identified actions over to the counter-measure activity of the RCA
Once the team has determined the root cause using any combination of the tools listed above then they must develop the appropriate counter-measures or corrective actions. In addition, the team should develop an action plan for implementation of the counter-measures.
The counter-measures are usually divided into two categories:
1.Short-term or immediate counter-measures – generally accomplishable in less than 1 week. If not it should be designated as a “Long-term” counter-measure.
2.Long-term or permanent counter-measures – usually more complex and may require additional resources to complete. All “Long-term” counter-measures should be able to complete in less than 1 month. If not, they should be forwarded to the Continuous Improvement (CI) team for evaluation as part of a Kaizen or Black Belt project.
The corrective action must be clearly defined and achievable by the team member assigned to complete the task. The action plan should also contain expected due dates for each of the corrective actions. It is often discovered that corrective actions without an owner or an expected due date seldom get completed. Occasionally the counter-measures require tasks to be completed by more than one of the team members simultaneously or in a certain order. The action plan should be used to track progress of individual action items required to complete implementation of the countermeasures.
The team should also determine a Verification (or Validation) Plan. This is used to provide a documented performance appraisal of the counter-measures effectiveness. This could entail recording data or auditing any special controls developed and implemented during the RCA exercise. Evidence should be collected to verify the effectiveness of the counter-measures or corrective actions. In addition, it is good practice to re-assemble the team approximately 30 days after the permanent counter-measures are in place. The team should review the effectiveness of the counter-measures and determine if the problem has occurred since implementation of the counter-measures. The team should also review the process (if applicable) to assure all counter-measures are being followed.
The development of a robust, well-planned Root Cause Analysis (RCA) process can be very valuable to the company by determining the root cause and taking action to prevent it from re-occurring. The lessons learned during an effective RCA can often be carried over to similar designs or processes. This should initiate a problem solving continuous improvement mind-set to spread throughout the company.
版权所有© 国可工软科技有限公司 苏ICP备2025155226号-1