【8D Report】八大步驟完整教學：範本、範例與五大常見錯誤

8D Report 是製造業處理客戶投訴與品質異常的標準結構化方法，透過八個步驟，從組建團隊到結案，系統性地找出根本原因並建立永久對策。這篇指南將帶你走過完整的 8D 流程，提供可直接參考的範本與範例，並拆解台灣工廠最常犯的錯誤。

撰寫 8D 報告時，根本原因的分析最好以數據與現場證據支持，而不是只靠推測。結案後定期檢視對策是否真的有效，才能避免同樣的問題再次發生。

什麼是 8D Report？

8D Report（Eight Disciplines Report）是一套以團隊為核心的結構化問題解決方法論。它的核心精神很簡單：找出根本原因（Root Cause），而非只處理表面症狀，並建立永久對策防止問題再發。

這套方法的起源可以追溯到美軍的 MIL-STD-1520 規範，後來由福特汽車在 1987 年將其系統化推廣為「Team Oriented Problem Solving（TOPS）」，也就是今天我們熟知的 8D。經過數十年的演進，8D 已經成為全球製造業、電子業、汽車供應鏈的標準品質管理語言。

在台灣，8D Report 的重要性更為具體——如果你在電子代工廠、PCB 廠、汽車零件供應商工作，幾乎一定遇過這個場景：日系或歐美客戶發來一份 NCR（不合格品報告），要求你在期限內回覆一份完整的 8D Report。這份報告不只是「交差了事」的文件，它是客戶評估你的品質管理能力、決定是否繼續合作的關鍵依據。

一句話定位：8D Report 是客戶投訴與品質異常的標準回覆語言。

適用產業涵蓋汽車、電子製造、半導體、醫療器材、消費品 OEM/ODM——基本上，只要你的公司有供應鏈關係，就有機會需要寫 8D。

時間軸：美軍 MIL-STD-1520 軍規起源、福特汽車 1987 年系統化推廣 TOPS、全球汽車業 QS-9000/IATF 16949 納入要求、現今製造業與電子業全球標準

什麼時候該用 8D Report？使用時機與判斷標準

不是每個品質問題都需要啟動 8D。8D 是一套需要跨部門投入資源的方法論，用在不對的地方反而浪費時間。

典型的 8D 觸發條件包括：

• 客戶正式投訴（Customer Complaint），尤其附帶 NCR 或 CAR（Corrective Action Request）
• 重大製程異常，例如批量不良率突然飆升
• 產品召回或市場退貨
• 內部重工率超過設定門檻（例如 PPM > 500）

不適合用 8D 的情況：

• 單純的操作失誤，原因已經很明確（例如作業員按錯按鈕，重新訓練即可）
• 一次性人為疏失，沒有系統性再發風險
• 問題原因已知且已有現成對策，只需執行即可

我們建議用一個簡單的二維矩陣來判斷：問題嚴重度 × 再發可能性。當兩者都高時，毫無疑問啟動 8D；當嚴重度高但再發可能性低，可以用簡化版的矯正措施報告；當兩者都低，一般的異常處理單就夠了。

舉個實際例子：某 PCB 廠收到客戶通知，連續三批出貨的 PPM 超過 200，而且缺陷模式一致（都是銅面氧化）。品保主管在 24 小時內判斷——嚴重度高（影響客戶產線）、再發可能性高（連續三批）——立即啟動 8D 流程。

至於 8D 和其他問題解決工具的差異：PDCA 適合持續改善、A3 適合精實管理的日常問題、DMAIC 適合需要統計分析的大型專案。8D 最適合的場景是「需要快速回應客戶投訴，同時建立永久對策」的情境。

8D Report 八大步驟詳解

以下逐步拆解 8D 的每個步驟。每個 D 都有明確的目的和產出，跳過任何一步都會讓整份報告的邏輯鏈斷裂。

D1：組建問題解決團隊（Team Formation）

8D 的第一步不是分析問題，而是先把對的人找齊。一個有效的 8D 團隊需要跨職能組成：品保負責數據收集與客戶溝通、製造工程師了解製程細節、產品工程師掌握設計規格、採購在供應商相關問題時不可或缺。

團隊中有兩個關鍵角色要區分清楚：

• Champion（贊助者）：通常是廠長或品保經理，負責提供資源、排除障礙，但不參與日常分析
• Team Leader：實際帶領團隊執行每個步驟的人，通常是資深品保工程師或製程工程師

台灣中小型製造業常見的困境是「人手不足」。我們的建議是：最精簡的 8D 團隊至少 3 人——品保 1 人（兼 Team Leader）、製程工程師 1 人、產線主管 1 人。人少沒關係，但每個人必須清楚自己負責哪些步驟的產出。

D2：問題描述（Problem Description）

問題描述是整份 8D Report 的基礎。描述得越精確，後續的根因分析就越有方向。

最有效的框架是 5W2H：

• What：什麼缺陷？（焊接不良、尺寸偏移、外觀刮傷…）
• Where：在哪裡發現？（客戶端組裝線、出貨檢驗、製程中…）
• When：什麼時候發生？（哪個批號、哪個時間段）
• Who：誰發現的？（客戶 IQC、內部 OQC…）
• Why：為什麼是問題？（違反哪個規格、造成什麼影響）
• How：如何發現的？（目視檢查、X-ray、電測…）
• How many：影響數量多少？（不良數 / 總數 = 不良率）

最常見的錯誤是描述太模糊。 比較以下兩種寫法：

• ❌「品質不好，客戶退貨」
• ✅「批號 A2024-0312 的 IC 基板，客戶端 SMT 回焊後發現 BGA 焊點空洞率超過 25%（規格 ≤ 15%），影響 500 pcs，客戶端 X-ray 檢出」

另一個實用工具是 Is / Is Not 分析——列出「問題是什麼」和「問題不是什麼」的對照，幫助團隊縮小調查範圍。例如：問題「是」發生在 A 產線，「不是」發生在 B 產線，那差異點就是調查方向。

D3：暫時圍堵措施（Containment Actions）

D3 的目的很明確：在找到根本原因之前，先保護客戶不受影響。 這是最有時間壓力的步驟，通常需要在 24-48 小時內完成。

常見的圍堵措施包括：

• 庫存隔離：將可疑批號的在庫品全部隔離，禁止出貨
• 出貨暫停：暫停相關產品的出貨，直到確認安全
• 100% 全檢：對在製品和庫存品進行全數檢驗
• 客戶端庫存確認：聯繫客戶，確認已出貨但尚未使用的庫存狀態

關鍵提醒：D3 必須包含「圍堵有效性驗證」。 你不能只說「已執行全檢」，還要提供數據證明圍堵措施有效——例如全檢後的不良品數量、客戶端確認的庫存狀態。

舉個例子（假設情境）：某汽車零件廠在 D3 階段的做法是，48 小時內完成三件事——(1) 倉庫系統鎖定所有相關批號，禁止出庫；(2) 派品保人員到客戶端協助篩選已出貨庫存；(3) 將全檢結果（檢出 23 pcs 不良 / 總檢 2,000 pcs）回報客戶。這樣客戶才會相信你的圍堵是有效的。

D4：根本原因分析（Root Cause Analysis）

D4 是整份 8D Report 最核心的步驟，也是客戶最在意的部分。

主要分析工具包括：

• 魚骨圖（Ishikawa / 特性要因圖）：從人、機、料、法、環、測六大面向展開可能原因
• 5 Why 分析：連續追問「為什麼」，直到觸及系統或流程層面的根因
• 故障樹分析（FTA）：適合複雜問題的邏輯樹狀分析

這裡有一個台灣工廠最常混淆的重點：你必須區分「發生原因（Occurrence Cause）」和「流出原因（Escape Cause）」。

• 發生原因：問題為什麼會產生？（例如：錫膏印刷參數設定錯誤，導致錫量不足）
• 流出原因：問題為什麼沒被攔截，流到客戶端？（例如：首件檢查未執行，SPC 管制圖未監控）

很多 8D Report 被客戶退件，就是因為只寫了發生原因，沒有分析流出原因。客戶的邏輯是：「就算問題發生了，你的檢驗系統為什麼沒攔住？」兩者都要回答。

根本原因的驗證同樣重要。你不能只靠推論，要用數據證明。例如：如果你判斷根因是「回焊爐第三區溫度偏低」，就要拿出溫度記錄數據，證明異常批次的溫度確實低於規格。

D5：永久對策（Permanent Corrective Actions）

D5 的對策必須分別針對 D4 找出的發生原因和流出原因。

針對發生原因的對策範例：

• 修正錫膏印刷參數，並將新參數寫入 SOP
• 導入防呆（Poka-Yoke）設計，例如參數鎖定功能，防止作業員誤改

針對流出原因的對策範例：

• 建立強制首件確認機制，未完成首件確認則系統不允許量產
• 增加 SPC 管制圖的監控頻率

對策評估時要考慮三個維度：有效性（能否真正解決問題）、可行性（技術和成本上是否可行）、副作用風險（會不會引發新問題）。

在制定對策時，善用流程圖來視覺化新的作業流程，能幫助團隊更清楚地理解對策的執行邏輯。

D6：永久對策實施與驗證（Implementation & Validation）

D6 是把 D5 的對策落地執行，並用數據驗證效果。

每個對策都需要一份執行計畫，包含：

• 責任人：誰負責執行？
• 完成日期：什麼時候完成？
• 驗證方法：怎麼證明對策有效？

驗證指標的設定要具體。常見的指標包括：

• PPM（百萬分之不良率）：對策實施後的 PPM 是否降至目標值以下
• Cpk（製程能力指數）：製程穩定性是否達標（通常要求 Cpk ≥ 1.33）
• 客訴件數：後續是否有相同問題的客訴

舉個例子（假設情境）：某電子廠在 D5 導入 SPC 管制圖作為流出原因的對策，D6 的驗證是連續追蹤 3 個月的數據——第一個月 PPM 從 1,200 降至 150，第二個月降至 30，第三個月為 0。這樣的數據才能讓客戶信服。

實務上，追蹤多個對策的執行進度和驗證結果，用 Excel 很容易出現版本混亂的問題。管理這類多步驟追蹤任務時，可以用 monday.com 建立追蹤看板，每個對策設定責任人和截止日，狀態一目了然——這在後面的工具管理段落會詳細說明。

D7：預防再發（Preventive Actions）

D7 的重點是水平展開（Horizontal Deployment）——把這次學到的教訓推廣到其他可能有相同風險的製程或產品線。

具體做法包括：

• FMEA 更新：將這次的失效模式和對策新增到 FMEA（失效模式與效應分析）中，提高該風險項目的嚴重度評分
• Control Plan 更新：在管制計畫中加入新的檢驗項目或頻率
• SOP 更新：修訂相關作業標準書，確保新的作業方法被文件化

8D 與 FMEA 的連動關係是這樣的：每一份 8D Report 結案後，都應回饋到 FMEA 中。如果你的 FMEA 從來沒有因為 8D 而更新過，那就代表你的預防機制已經斷裂。

水平展開的範圍判斷：問自己「其他產線 / 其他產品 / 其他供應商，有沒有相同的風險因子？」如果有，就要把對策推廣過去。

D8：團隊表彰與結案（Team Recognition & Closure）

D8 是最常被跳過的步驟，但它對組織學習至關重要。

正式結案的三個條件：

1. 客戶書面確認接受 8D Report
2. 驗證數據達標（D6 的指標持續達成）
3. 所有文件更新完成（FMEA、Control Plan、SOP）

結案後，最重要的動作是知識管理——將這份 8D 案例建入公司的知識庫。下次遇到類似問題時，團隊可以直接參考歷史案例，不用從零開始。

台灣職場文化的提醒：很多公司覺得「問題解決了就好」，不重視 D8 的團隊表彰。但研究顯示，適當的認可能顯著提升團隊下次參與 8D 的積極度。不需要大張旗鼓，一封感謝郵件、一次會議上的公開肯定就夠了。

建立團隊的領導力文化，讓成員感受到參與 8D 是被重視的貢獻，而非額外負擔。

用 monday.com 追蹤 8D 問題解決流程（內建 8 步驟欄位）

D1 到 D8 八個步驟拆成可指派的任務——進度即時更新、根本原因分析欄位、預防措施追蹤，比 Word 報告更容易維護。

免費建立 8D 工作流 →

8D Report 範本結構與填寫說明

一份標準的 8D Report 文件應包含以下欄位結構：

Header 資訊區：

• 報告編號、發行日期、修訂版次
• 客戶名稱、客戶投訴編號（CAR/NCR 編號）
• 產品名稱、料號、批號
• 問題發現日期、報告完成目標日期

各 D 欄位區（D1-D8）：

• 每個 D 都有獨立欄位，包含描述、負責人、完成日期
• D4 通常需要附上分析工具的圖表（魚骨圖、5 Why 表格）
• D5/D6 需要對策清單，每條對策有獨立的責任人和驗證方法

簽核區：

• Team Leader 簽核、Champion 簽核、客戶確認欄

常見的格式有 Excel、Word 和 PPT。Excel 最普遍，因為方便嵌入數據表格和圖表；PPT 適合需要向客戶做簡報的場合；Word 則適合需要大量文字描述的複雜案例。

中英文欄位對照（對應外資客戶需求）：

填寫品質的 6 大要素

不管你用什麼格式，一份高品質的 8D Report 必須具備：

1. 心態正確：以解決問題為目標，不是應付客戶交差
2. 數據支撐：每個欄位都要有可量化的證據，不能只寫「已改善」
3. 根因深度：至少追溯到系統或流程層面，不能停在「人員疏失」
4. 對策具體性：每條對策有責任人、有期限、有驗證方法
5. 時間軸清晰：D3 圍堵完成時間、D6 對策完成時間必須明確標示
6. 客戶語言：用客戶能理解的術語，避免內部行話或縮寫

寫 8D Report 時，如果你需要整理複雜的企劃書式的結構化文件，同樣的邏輯框架也適用——先定義問題、再分析原因、最後提出對策。

8D Report 實際範例解析

以下用一個電子製造業的客訴案例，完整示範一份 8D Report 的填寫邏輯。

情境： 客戶反映 SMT 焊接不良，退貨 500 pcs，要求 30 天內提交完整 8D Report。

D1 — 團隊組成： 品保工程師（Team Leader）+ SMT 製程工程師 + SMT 線長，共 3 人。Champion 為品保經理。

D2 — 問題描述（5W2H）：

D3 — 暫時圍堵措施：

• 24 小時內暫停相關批號出貨
• 倉庫隔離所有 9 月份生產的同型號產品（共 3,200 pcs）
• 100% X-ray 全檢，檢出不良品 87 pcs（不良率 2.7%）
• 聯繫客戶確認已出貨未使用庫存 1,500 pcs，客戶端進行全檢

D4 — 根本原因分析：

使用 5 Why 分析：

發生原因追溯：

• Why 1：BGA 焊點空洞率超標 → 錫膏量不足
• Why 2：錫膏量不足 → 鋼板印刷參數偏移（刮刀壓力設定錯誤）
• Why 3：刮刀壓力設定錯誤 → 換線後未依 SOP 重新設定參數
• Why 4：未依 SOP 設定 → SOP 中未明確規定換線後的參數確認步驟
• 根因：SOP 缺少換線後參數確認的強制步驟

流出原因追溯：

• Why 1：不良品流出到客戶端 → 出貨前未檢出
• Why 2：出貨前未檢出 → 首件 X-ray 檢查未執行
• Why 3：首件檢查未執行 → 當天趕出貨，線長跳過首件確認
• Why 4：線長可以跳過 → 系統無強制首件確認的防呆機制
• 根因：缺乏首件確認的系統防呆機制

D5 — 永久對策：

D6 — 驗證結果： 對策實施後連續 4 週追蹤：

• 第 1 週：PPM = 50（仍有零星不良，持續調整）
• 第 2 週：PPM = 0
• 第 3 週：PPM = 0
• 第 4 週：PPM = 0
• Cpk 從 0.85 提升至 1.67，達標

D7 — 預防再發：

• 水平展開至其他 3 條 SMT 產線，同步導入參數鎖定和首件確認機制
• 更新 FMEA：新增「換線後參數未確認」失效模式，RPN 評分從 120 提升至 280
• 更新 Control Plan：增加首件 X-ray 檢查為必要管制項目

D8 — 結案： 客戶於 11/2 書面確認接受 8D Report，案件正式結案。8D 案例建入公司品質知識庫。

這個範例中，客戶最在意的是 D4 的根因分析（是否找到真正的根因）和 D5 的永久對策（對策是否具體可執行）。如果這兩個欄位寫得不夠深入，報告幾乎一定會被退件。

8D Report 常見錯誤與品質評估

以下是台灣製造業最常犯的 5 大錯誤：

錯誤 1：根因停在「人員疏失」

這是最致命的錯誤。「作業員疏忽」不是根本原因——客戶會問：「為什麼你的系統允許作業員疏忽？」根因必須追溯到系統或流程層面，例如「SOP 缺少防呆步驟」或「訓練制度未涵蓋此操作」。

錯誤 2：D3 圍堵措施與 D5 永久對策混淆

D3 是「暫時止血」，D5 是「根治」。「100% 全檢」是圍堵措施，不是永久對策。如果你的 D5 寫的還是「加強檢驗」，客戶不會接受——因為檢驗只能攔截不良品，不能防止不良品產生。

錯誤 3：只寫發生原因，漏掉流出原因

前面已經強調過，這裡再次提醒：客戶要看到兩條根因鏈——「為什麼發生」和「為什麼沒攔住」。兩者缺一不可。

錯誤 4：對策沒有驗證數據

D6 欄位只寫「已改善」或「已完成」，沒有任何數據佐證。客戶需要看到具體的驗證指標：PPM 數值、Cpk 數值、追蹤週數。沒有數據的對策等於沒有對策。

錯誤 5：D7 水平展開完全空白

很多工程師覺得「這個問題只發生在這條線，不需要展開」。但客戶的思維是：「如果 A 線會發生，B 線為什麼不會？」即使評估後認為不需要展開，也要在 D7 中說明評估過程和結論，而非留白。

8D Report 品質自評表

在提交給客戶之前，用以下 10 項標準自我檢核：

如果 10 項中有 3 項以上未通過，建議修改後再提交。被客戶退件不只浪費時間，還會影響供應商評分。

在進行這類品質自評時，建立清晰的判斷框架很重要。如果你對優先順序的判斷感到困難，可以參考艾森豪矩陣的思維方式，先處理「重要且緊急」的項目。

用 Monday.com 管理 8D Report 流程

為什麼 8D 需要數位化工具管理？

傳統的 8D 管理方式是 Excel 表格 + Email 往返。這在案件量少的時候勉強可行，但當你同時處理 5 個以上的客訴案件時，問題就來了：

• 版本混亂：品保寄了 V3，製程工程師手上還是 V1，客戶收到的不知道是哪個版本
• 責任追蹤困難：D5 的 4 條對策分別由不同人負責，誰完成了、誰延遲了，要一個一個問
• 跨部門協作低效：品保要催製程、催設備、催 IT，每天花大量時間在「追進度」而非「解決問題」
• 歷史案例查詢困難：兩年前有個類似案例，但 Excel 檔案散落在不同資料夾，找不到

這些痛點在推動數位轉型的製造業中尤其明顯。

Monday.com 如何對應 8D 流程

用 monday.com 建立 8D 追蹤系統時，可以這樣對應：

看板結構設計：

• 每個客訴案件 = 一個 Item（項目）
• 欄位（Column）設定：客戶名稱、產品料號、批號、目前階段（D1-D8）、Team Leader、Champion、截止日期、狀態（進行中/待驗證/已結案）
• 群組（Group）可按客戶分類，或按月份分類

核心功能應用：

1. 指派責任人：D5 的每條對策可以建立子任務（Sub-item），分別指派給不同負責人，每個人只看到自己的待辦事項
2. 自動化提醒：設定自動化規則——「當截止日期前 2 天，自動通知責任人」。例如 D3 圍堵期限到期時自動通知品保主管，逾期就不必等到週會才被發現。
3. 儀表板（Dashboard）：一個畫面同時看到所有進行中的 8D 案件，哪些在 D3 階段、哪些卡在 D4、哪些即將到期，品保主管不用逐案詢問
4. 與客戶共享進度：monday.com 的 Guest 權限功能，可以讓客戶即時查看 8D 進度，不用每次都靠 Email 回報。這對提升客戶信任感非常有效
5. 知識庫建立：結案的 8D 案件不刪除，歸檔到「已結案」群組，未來遇到類似問題可以直接搜尋歷史案例

Excel 管理 vs. Monday.com 管理 8D 流程

（推薦試試 monday.com 的免費方案，不需要信用卡。）

快速上手：3 步驟建立 8D 追蹤看板

1. 建立新看板：登入 monday.com，選擇「空白看板」或從範本開始
2. 設定欄位：新增「客戶名稱」「產品料號」「目前階段（D1-D8）」「責任人」「截止日」「狀態」等欄位
3. 設定自動化：建立「截止日前 2 天自動通知」和「狀態變更時通知 Champion」兩條基本規則

如果你的團隊同時也需要管理其他類型的專案任務，monday.com 的看板功能可以讓你在同一個平台上管理 8D 案件和日常工作。

如果你的團隊偏好更技術導向的工具，ClickUp 也是不錯的替代選項，它的自訂欄位和自動化功能同樣能支援 8D 流程管理。

結論

8D Report 不只是應付客戶的文件，它是一套讓組織從每次品質異常中學習、持續進步的方法論。

全文重點摘要：

• 8D 的核心是找到根本原因並建立永久對策，而非只處理表面症狀。用嚴重度 × 再發可能性的矩陣判斷是否需要啟動 8D
• D4 根因分析必須區分「發生原因」和「流出原因」——這是台灣工廠最常犯的錯誤，也是客戶退件的首要原因
• 每個對策都要有責任人、期限和驗證數據，「已改善」三個字不是驗證
• D7 水平展開是防止系統性問題的關鍵，結案後務必更新 FMEA、Control Plan 和 SOP
• 數位化工具能大幅提升多案件管理效率，從 Excel 升級到專案管理平台是品保團隊的必要投資

你的下一步行動：

1. 用本文的 6 大要素檢核表，回頭檢視你最近一份 8D Report 的品質
2. 確認你的 D4 是否同時包含發生原因和流出原因
3. 如果你正在同時管理多個客訴案件，試試用 monday.com 建立數位化的 8D 追蹤看板——免費方案就能開始，10 分鐘建好你的第一個追蹤系統

每一份高品質的 8D Report，都是下一次客訴不再發生的保證。

免費領取 8D 報告範本（Word）

D0–D8 完整架構：5W2H 問題描述、5 Why 根本原因分析表、暫時與永久對策、效果確認與水平展開，附一份完整填寫範例。輸入 Email，下載連結立即寄到你的信箱；之後我們偶爾會寄給你實用的專案管理教學與範本，隨時可退訂。

8D Report 常見問題

8D Report 要用英文還是中文寫？

原則是以客戶要求為準。外資客戶（尤其歐美系）通常要求全英文；日系客戶有時接受中文但關鍵欄位需附英文；台灣內部客戶則多用中文。

以下是 8D 關鍵術語的中英對照，寫英文版時可直接參考：

8D Report 要在多久內提交？

業界慣例是分階段提交：

• D3 圍堵措施：24-48 小時內回覆客戶（這是最緊急的）
• 完整 8D Report（D1-D8）：通常 30 天內，部分客戶要求 14 天

不同客戶的要求差異明顯：

• 日系客戶：對時效要求極嚴格，D3 通常要求 24 小時內，完整報告 14-21 天。格式要求也較嚴謹，偏好固定模板
• 歐美客戶：時效相對彈性（30 天），但對根因分析的深度要求更高，會追問「為什麼你認為這是根因？數據在哪裡？」

不管哪種客戶，D3 的速度是建立信任的關鍵。即使完整報告需要時間，快速的圍堵回應能讓客戶知道你在積極處理。善用時間管理的技巧，在高壓時限下保持專注力和產出品質。

8D 和 PDCA、DMAIC 有什麼不同？

結論：8D 最適合「需要快速回應客戶，同時建立永久對策」的場景。 如果問題規模大到需要 3 個月以上的統計分析，考慮 DMAIC；如果只是日常的小改善，PDCA 就夠了。

沒有製造業背景，可以用 8D 嗎？

8D 的邏輯框架——定義問題、分析根因、制定對策、驗證效果、預防再發——是通用的。服務業處理客訴、軟體開發處理 Bug、甚至日常生活中解決重複出現的問題，都可以借鏡 8D 的思維。

但要注意，8D 的工具和術語（魚骨圖、FMEA、SPC、Cpk）在製造業情境最成熟。如果你在非製造業環境使用，需要調整工具選擇和驗證方式。例如軟體開發可以用 8D 的框架處理重大 Bug，但 D6 的驗證指標會從 PPM 變成「Bug 復發率」或「回歸測試通過率」。

如果你對結構化的問題解決方法有興趣，也可以參考商業模式九宮格等框架，它們同樣強調系統性思維。

引用本文：《【8D Report】八大步驟完整教學》，，