作者：admin 時間：2022-12-20
根本原因分析 （RCA） 是一個綜合術語，包含一系列問題解決方法，用于確定不合格或質量問題的真正原因。 根本原因分析是定義、理解和解決問題的過程。根本原因也被描述為不符合項、缺陷或故障的根本或根本原因。此外，術語“根本原因”也可以稱為因果鏈中的確切點，在此點上，應用糾正措施或干預可以防止不合格的情況發生。
重復問題是制造過程中浪費的根源。以機器停機、產品返工、廢品增加以及“”問題所花費的時間和資源的形式出現的浪費。很多時候，我們可能認為問題已經解決，但實際上我們只是解決了問題的癥狀，而不是真正的根本原因。如果執行得當，根本原因分析可以識別流程或系統中導致不合格情況的故障，并確定如何防止其再次發生。執行 RCA 以確定發生了什么，為什么會發生，然后確定需要哪些改進或更改。通過正確應用RCA，可以消除重復問題。
RCA方法和工具不于制造工藝問題。許多行業正在各種情況下應用 RCA 方法，并使用這種結構化方法來解決問題。使用 RCA 的一些示例包括但不限于：
●辦公流程和程序
●質量控制問題
●醫療事件分析
●基于的情況或事故分析
●工程與維護中的故障分析
●變更管理或持續改進活動
●計算機系統或軟件分析
關鍵是RCA幾乎可以應用于公司每天面臨的任何類型的問題?？梢允褂?RCA 的另一個示例是遇到大量錯誤客戶訂單和發貨的公司?？梢岳L制和分析該過程，并可以識別和解決問題的根本原因。最終結果是滿意、忠誠的客戶群和更低的公司總體成本。
根本原因分析 （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中吸取的經驗教訓通?？梢匝永m到類似的設計或流程中。這應該啟動解決問題的持續改進思維模式，并在整個公司傳播。
英文版：
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備2020030271號
中文
英文