8d培訓ppt103頁)(編輯修改稿)
2025-03-27 21:33 本頁面
【文章內(nèi)容簡介】 。 而 “ 不是 ”的信息就幫助你縮小了調(diào)查的范圍 。 “ 是 /不是 ” 數(shù)據(jù) ?描述了缺陷的范圍或程度 ?僅包含正確的信息 ?在稍候的 D4中被用來找到原因 ?是解決問題的過程中觀察階段的一部分 Using an Is/Is Not Worksheet 使用 “ 是 /不是 ” 工作表 ? 當你確定 “ 不是 ” 信息時應當： 僅包含事實，不要馬上作結(jié)論 尋找“類似的對象” —— 在外形、成分、組成、功能等等相似的對象 為每一項至少確定一個“是”，一個“不是”的信息 從現(xiàn)有的信息中獲取盡可能多的信息 D2 Summary : Describe the Problem D2 總結(jié)：描述問題 在這個部分 ， 你學會怎樣： ? 制定問題陳述 ? 解釋描述問題的過程 ? 制定一個詳細的問題描述 是 /不是 表 D3 – ―Develop an Interim Containment Action (ICA)‖ D3— “ 制定臨時處臵措施（ ICA）” ? 在永久措施制定之前， D3階段制定一個臨時措施 ? 臨時措施（ ICAs）使內(nèi) /外顧客不受問題后果的影響，同時在 D3階段， ICAs在實施之前也必須驗證 D3 Section Objectives D3 部分目標 – 確定并解釋臨時措施（ ICA）的特點 – 區(qū)別驗證和確認 – 說明如何驗證 ICA – 說明如何確認 ICA Why Develop an Interim Containment Action (ICA)? 為什么制定臨時措施 （ ICA）？ 當你制定 ICA時，你應該： ? 爭取時間以讓 8D小組可以找到引起問題的根源 ? 保護顧客不受問題的影響 ? 包含的可能是成本、質(zhì)量和時間方面的問題 Why Develop an Interim Containment Action (ICA)? 為什么制定臨時措施 （ ICA）？ 制定臨時措施有四個步驟： 1. 選擇 ICA 2. 驗證 ICA 3. 執(zhí)行 ICA 4. 確認 ICA What Is an ICA? ICA是什么 ？ ? 對問題的癥狀進行處理 ? 在實施前被驗證為有效的 ? 使用過程中是被監(jiān)控的 ? 是被文件化了的 ? 將要被永久糾正措施所取代 ? 這個過程 /操作是要增加成本的 D3 Step 1: Select an ICA D3 步驟 1：選擇一個 ICA 假如需要 ICA，你需要針對實際狀況選擇“最好 的” ICA 選擇一個 ICA： ? 確定選擇標準 ? 分析執(zhí)行 ICA的好處 ? 分析執(zhí)行 ICA的風險性 ? 使用好處和風險的最好平衡點來選擇 ICA D3 Step 2: Verify an ICA D3 步驟 2：驗證一個 ICA 當驗證一個 ICA時： ? 是在實施它以前，證明它將能保護顧客不受問題的影響 ? 提供前后的比較 ? 證明 ICA將不會產(chǎn)生任何新的故障 D3 Step 2: Verify an ICA D3 步驟 2：驗證一個 ICA 驗證的方法包括： ? 試驗 ? 演示 ? ICA與類似證明了有效的措施間進行對比 ? 先期發(fā)布的設計文件評審 D3 Step 3: Implement an ICA D3 步驟 3： 執(zhí)行一個 ICA 執(zhí)行一個 ICA –按照 PDSA的循環(huán)進行 –制定行動計劃 PDSA循環(huán)是一個制定并有效實施措施的過程 D3 Step 3: Implement an ICA D3 步驟 3：執(zhí)行一個 ICA PDSA循環(huán)的步驟如下： 1. 計劃 — 確定要采取哪個措施，以保證在規(guī)定的時間內(nèi)達到你的目標 2. 執(zhí)行 — 執(zhí)行計劃 3. 研究（監(jiān)督） — 記錄執(zhí)行的結(jié)果 4. 實踐 — 評估結(jié)果 D3 Step 3: Implement an ICA D3 步驟 3：執(zhí)行一個 ICA 行動計劃描述： ? 要達到目標需要采取什么行動 ? 誰負責完成具體的行動 ? 什么時候完成措施 D3 Step 4: Validate an ICA D3 步驟 4：確認一個 ICA 確認應該在成功的驗證之后 確認所采取的兩種形式： ? 售前的驗證 ? 售后顧客的驗證 D4 – ―Define and Verify the Root Cause and Escape Point‖ D4—―確定并驗證根本原因和遺漏點 ” ? D4階段給我們提供機會通過隔離和驗證根本原因來測試根據(jù)問題描述推導出的每種故障理論 ? 在 D4階段，使用者還要隔離并驗證流程中的某個位臵，在這里根本原因能被發(fā)現(xiàn)和控制 D4 Section Objectives D4 章節(jié)目標 ? 使用問題解決工作表去識別問題根本原因 ? 驗證問題根本原因和遺漏點 Why Define and Verify the Root Cause? 為什么要確定并驗證根本原因 ？ 識別根本原因看起來是消耗時間的，但實際上從長期來看確是更有效，因為： ? 你不必一個接一個的制定“快速解決問題的辦法” ? 你不用浪費時間和工作在控制問題造成的損害上 ? 你不需要定期的去重建顧客滿意度 ? 你可以一勞永逸解決問題 What Is the Root Cause? 什么是根本原因 ？ ? 可能的原因 — 任何原因，經(jīng)常用因果圖（魚骨圖）進行確認 ? 最可能的原因 — 根據(jù)可用的數(shù)據(jù)得到的一個理論，它可能最能解釋詳細的問題描述 ? 根本原因 — 一個被驗證了的，并且能解釋問題的原因 Identifying the Most Likely Cause? 識別最可能的原因 ？ 識別最可能的原因： ? 回顧詳細問題描述（是 /不是分析） ? 完成由狀態(tài)改變導致問題的對比分析報告（識別差異和改變） ? 確定最可能的根本原因 ? 根據(jù)問題描述測試理論 Review the Problem Description 回顧故障描述 為了識別根本起因，首先要回顧故障描述（是 /不是工作單）必須要牢記： ?根據(jù)“什么，何時，何地，影響程度如何”來進行描述
研究報告相關推薦
鄂ICP備17016276號-1