最近發現很多朋友在寫8D報告時遇到很多問題，那咱們就來再說一說怎么來用8D吧。8D流行起來，要說1987年，福特汽車公司首次用書面記錄下

最近發現很多朋友在寫8D報告時遇到很多問題，那咱們就來再說一說怎么來用8D吧。

8D流行起來，要說1987年，福特汽車公司首次用書面記錄下8D法，在其一份課程手冊中這一方法被命名為TOPS（Team Oriented Problem Solving）即 “團隊導向問題解決法”，從此8D方法被廣泛應用，但其實8D問題解決的思路是由美國國防部在1974年創立后來被發揚起來的。

一開始8D是有8個步驟的，后來又加了個D0（緊急反應行動ERA），這個D0是做什么的呢？主要是為了看此類問題是否需要8D來解決，很多公司出了問題就用8D，覺得這是個好工具，這么想沒毛病，但是這是需要花費資源的，很多培訓資料也都提出來，一般三類問題做8D：一直重復發生的問題；比較重大的質量問題；客戶要求回復的投訴。

而我的理解，復雜的問題，需要跨部門分析時再進行8D，還有就是系統性的問題，避免再次發生時使用8D。因為8D要做好是要小組一起下功夫的，勢必需要一些資源（人員/經費/時間等）。我相信大部分人是找到了問題原因和解決方案再返過來編寫報告的。

D0在很多材料里除了判定是否進行8D，還要做一個緊急反應措施（ERA），我覺得這個不是很合理，我們在這個階段會有一個初步的原因分析，如果問題簡單明了，我們可以進行ERA，后續就不需要8D了，如果客戶強制要求我們寫8D，那我們可以寫在D3這個步驟里，畢竟是后寫（編唄），如果我們初步找不到原因，那我們定義要做8D，這樣我們按照順序也可以在D3的時候進行ERA，這樣邏輯也不沖突，綜上，我覺得一份8D報告中，是不應該體現D0這一個步驟的，這一個步驟應該是現場人員思維達成一致的體現。

開始正題，大家可以想想看，有多少人是自己一個人就完成了8D報告的，你覺得你一個人就把問題解決了還需要做一個8D報告嗎？成立團隊，首先一定要把和這個問題相關的人拉進來，這個很重要，否則對于問題描述可能會得不到詳細的信息，另外就是一些有經驗的相關人員，畢竟解決的是重大的、系統的問題。很多資料對這塊擴展了不少，比如DICS，各種風格的人相互配合，我覺得這些倒不重要，D1完全和D2可以一起完成，甚至可以先D2再D1。

說實話，D2是我認為最重要的一條，要用量化的術語詳細說明與該問題有關的內/外部顧客抱怨，如什么、地點、時間、程度、頻率等，我們最常用的就是5W2H法，我見過很多問題描述寫的都是什么壞了，這讓人看了從哪下手呢？最起碼我們要知道什么東西出了什么問題，要搞清楚對象和缺陷，描述出來可以讓人明確問題是什么，問題不是什么。

只有搞清楚了問題，我們后面才能避免做無用功，也是為什么D1的時候要把相關人員拉進來，確定了范圍，我們也能有針對性地做出D3的決定和后續的分析方向。在描述問題時，我們盡量多使用照片和視頻作為輔助，才能更直觀地來了解問題。

有的人用4W3H來描述問題，也非常地好，畢竟有時候Why沒有那么直觀，描述問題一定要客觀，如果一開始你就感覺到了結論，你描述問題的現象就會偏向你結論的方向。

保證在永久糾正措施實施前，將問題與內外部顧客隔離，這時候我們可以根據問題嚴重程度進行ERA，一般的措施有100%挑選，停產，返工返修，召回，補料等等。及時的處理會讓客戶滿意。

需要注意的就是不要等著原因分析完再進行圍堵措施，那如何做出正確的遏制行動就非常重要，一定要秉承從客戶的角度出發來對策。

可從上面這幾個方面來進行圍堵，避免遺漏。

識別和試驗所有的潛在原因，將問題描述中提到的造成偏差的一系列事件或環境或原因相互隔離測試并確定產生問題的根本原因。大部分的報告采用的都是魚骨刺圖，其實我們還可以使用樹圖，關聯圖、排列圖等等。

在做原因分析的時候，一般采用的先是頭腦風暴法，從人/機/料/法/環，從發生/流出/系統，從各個工序，從各種原因類別……

找到這么多原因，下一步怎么辦呢，從個人經驗來講，團隊會議上一定要排出優先級來，我們有有經驗的隊員，初步識別出排列靠前的因素，然后進一步分析下去，這塊就用上我們嘴上常說的5Why方法了，也就是刨根問底兒：

刨到最根本的原因后，我們就要驗證，這里可以仿真模擬，也可以故障再現，確保原因識別正確。經常編8D的人，肯定會分析人員責任心差，操作失誤，設備故障了，未能監督到位等等。其實原因分析會耗費很多時間，就是為了找到根本的原因，以杜絕類似問題再次發生。

找到了原因就好說了，根據原因我們開始選擇糾正措施，我們可以理解為D3在糾正（為消除已發現的不合格所采取的措施），D5這塊是糾正措施（消除已發現的不合格或其他不期望情況的原因所采取的措施）。

這一條和D4的方法一樣，最終篩選出需要采取的措施，并要進行確認，實施的措施能夠解決問題，且不能產生新的問題。

其實在這一步就要明確出糾正措施，大家善用的方法是德爾菲法或試驗、試產等。德爾菲法亦稱 “專家意見征詢法”，主要是采取專家意見，但要注意：

1． 吸收專家參與預測，充分利用專家的經驗和學識；

2． 采用匿名的方式，能使每一位專家獨立自由地作出自己的判斷；

3． 預測過程幾輪反饋，使專家的意見逐漸趨同。

一般在看別的寫的報告時，我主要看的還是D2、D4和D5，這幾塊其實就是報告的核心內容了。

到了這一步就沒啥可說的了，按照計劃實施糾正措施：

也可以做甘特圖，主要還是不要忘記確認結果，要確保措施落地。

提出預防建議，并橫向展開，更新CP、PFMEA、SOP等標準文件，大部分人搞不清楚這塊和D6怎么寫，直接點就是D6解決的是問題本身，描述了解決方法但還沒有到更新文件的步驟，D7要從兩個角度考慮，該問題的解決思路更新相關的指導文件，如CP，SOP等，再者就是更新FMEA，橫展到類似產品中去。這塊再回顧一下和糾正措施的區別：

糾正措施（消除已發現的不合格或其他不期望情況的原因所采取的措施）；

預防措施（消除潛在的不合格或其他不期望情況的原因所采取的措施）。

扁鵲的故事大家應該都聽過，他說：大哥治病是在病人發病以前，這時候病人都不知道自己有病，大哥下藥就把病情扼殺在萌芽中，即使他的醫術不被世人所理解，但在我們家，都認為他的醫術很高明（這就像是預防措施，干了沒人看得到）；我的二哥治病是在病情剛剛顯現的時候，這個時候病人的病情還不是很嚴重，病人也沒有什么痛苦，二哥一劑藥下去就可以藥到病除，所以很多人都認為二哥只是治小病很靈（這就像是過程控制，避免走偏發生批量）；而我治病，是在病情已經很嚴重的時候，病人已經受到了很多的疼痛的折磨（這就是糾正了，大部分人喜歡看這個）。

最后這條實在沒啥寫的，國內不流行這個。很多培訓資料都把這條改成了經驗總結，我是不太認可。就應該好好地獎勵一下嘛，要培養大家團隊協作的意識嘛。工作中除了困擾大家多時的問題，最好還是別用8D，不然光自己擱那編報告就得燒死多少腦細胞，拿出來的報告也讓人不忍直視。