RCA（Root Cause Analysis）是根本原因分析，一種系統性找出問題真正源頭並永久消除的方法論。這篇文章涵蓋五大主流 RCA 方法、六步驟執行流程、三種產業實務範例，以及我們團隊實際使用的追蹤工具與避坑指南。
RCA 是什麼？一句話定義與核心概念
RCA 是 Root Cause Analysis 的縮寫，中文翻譯為「根本原因分析」。它的核心邏輯很簡單：不處理表面症狀，而是挖到問題的最底層原因，然後永久消除它。
用台灣人熟悉的說法，RCA 就是「治本」而非「治標」。
舉個例子：辦公室天花板漏水，治標是放水桶接水、補漆；治本是找到樓上管線破裂的位置，修好管線。RCA 做的就是後者——它不讓你停在「放水桶」這個層次，而是逼你一路追問到管線破裂的根源。
快速消歧義
如果你搜尋「RCA 是什麼」，可能會看到兩個完全不同的結果：
- 音響 RCA 端子：那是一種紅白黃色的音訊/視訊接頭，和本文無關。
- RCA 美國無線電公司事件：RCA（Radio Corporation of America）曾在台灣桃園設廠，因有機溶劑污染造成嚴重工殤事件。這是台灣環境正義的重要議題，但同樣不是本文討論的範疇。
本文聚焦的 RCA，是跨產業通用的問題分析方法論，廣泛應用於：
- 製造業：產品良率異常、設備故障分析
- IT / 軟體業：系統當機、服務中斷事後檢討
- 醫療業：病安事件調查、用藥錯誤分析
- 專案管理：交付延遲、品質缺失、跨部門協作失敗
為什麼要做 RCA？
做 RCA 不只是為了修復單一事件，它能帶來三個層面的長期價值：
- 避免重複發生：針對根本原因採取措施，才能從源頭阻止同類問題再次發生，省下未來反覆救火的時間與資源。
- 培養團隊文化：不責怪個人、專注流程改善，對領導力培養和團隊成長至關重要。
- 提升利害關係人信任：當你能向客戶或老闆展示「我們不只修好了問題，還確保它不會再發生」，信任度會大幅提升。
何時「不需要」做 RCA？
資源有限，不是每個問題都值得投入完整的 RCA 流程。以下是我們團隊使用的判斷矩陣：
| 復發頻率高 | 復發頻率低 | |
|---|---|---|
| 影響範圍大 | ✅ 必須做 RCA | ⚠️ 建議做簡易 RCA |
| 影響範圍小 | ⚠️ 建議做簡易 RCA | ❌ 記錄即可，不需完整 RCA |
一次性的、低影響的事件（例如某個內部報表格式跑掉），記錄下來就好。把 RCA 的時間留給真正會反覆咬你的問題。這也是艾森豪矩陣中「重要但不緊急」象限的典型任務——你需要主動排進行程，而不是等問題爆發才被動處理。
RCA 五大主流方法比較：選對方法才有效
RCA 不是單一技術，而是一個方法家族。選錯方法，分析效果會大打折扣。以下是五種最常用的 RCA 方法，我們逐一拆解它們的適用場景。
方法一：五個為什麼（5 Whys）
這是最簡單、最直覺的 RCA 方法，由豐田生產系統（TPS）發展而來。
操作步驟： 1. 清楚描述問題現象 2. 問「為什麼會發生？」，記錄答案 3. 針對答案再問「為什麼？」 4. 重複直到觸及無法再拆解的根本原因（通常 3-5 次）
案例： 生產線停機 → 為什麼？馬達過熱 → 為什麼？軸承磨損 → 為什麼？潤滑油不足 → 為什麼？保養排程從季度改為半年但沒更新潤滑頻率 → 根本原因：保養排程變更時缺乏連動檢查機制。
適用情境： 單一線性問題、需要快速分析的場合。 限制： 當問題有多重並行原因時，5 Whys 容易只追到其中一條線，遺漏其他重要因素。
方法二：魚骨圖（Fishbone / 石川圖）
由日本品管大師石川馨發明，又稱因果圖（Cause-and-Effect Diagram）。它的核心是用 6M 架構系統性地展開所有可能原因：
- Man（人員）：操作錯誤、訓練不足
- Machine（機器）：設備老化、校準偏差
- Material（材料）：原料品質、供應商變更
- Method（方法）：SOP 缺失、流程設計不良
- Measurement（量測）：檢測標準不明、儀器誤差
- Mother Nature（環境）：溫濕度、外部法規變更
適用情境： 多因素、跨部門問題。特別適合把不同部門的人拉到同一張圖前面，一起腦力激盪。
案例： 某電商客訴率連續三個月上升，行銷、產品、客服三個部門各執一詞。PM 召集跨部門會議，用魚骨圖把所有可能原因攤開，最終發現根本原因是產品頁面改版後，尺寸標示方式改變但客服話術沒同步更新，導致退貨率飆升。
如果你的團隊需要視覺化地整理複雜問題的因果關係，魚骨圖搭配流程圖工具會非常有效。
方法三：故障樹分析（FTA, Fault Tree Analysis）
FTA 採用由上而下的邏輯樹結構，從頂層事件（不良結果）往下展開，用 AND / OR 邏輯閘連接各層原因。
適用情境： 高風險、安全關鍵系統，例如航太、醫療設備、核能產業。當你需要量化「哪條路徑的風險最高」時，FTA 比其他方法更精確。
限制： 學習門檻較高，需要團隊具備邏輯建模能力。
方法四：8D 報告（Eight Disciplines）
8D 不是單純的 RCA 方法，而是一套包含 RCA 的完整問題解決流程。它由福特汽車發展而來，分為八個步驟（D0-D7），其中 D4 就是「找根本原因」，D5-D6 則是制定並驗證永久對策。
RCA 與 8D 的關係： RCA 是 8D 流程中的核心引擎。如果你的組織已經在用 8D 報告，那你每次寫 D4 的時候，其實就是在做 RCA。
方法五：FMEA（失效模式與影響分析）
FMEA 和前四種方法有一個根本差異：它是預防性的。FMEA 在問題發生「之前」，系統性地列出所有可能的失效模式，評估其嚴重度、發生率和偵測難度，然後優先處理高風險項目。
RCA 與 FMEA 的關係： RCA 是事後矯正，FMEA 是事前預防。最成熟的組織會兩者並用——用 RCA 處理已發生的問題，用 FMEA 預防尚未發生的問題。
五大方法快速比較
| 方法 | 適用情境 | 所需時間 | 難度 | 最佳產業 |
|---|---|---|---|---|
| 5 Whys | 單一線性問題 | 30 分鐘 – 2 小時 | ★☆☆ | 全產業通用 |
| 魚骨圖 | 多因素、跨部門 | 2-4 小時 | ★★☆ | 製造、服務業 |
| FTA | 安全關鍵系統 | 1-3 天 | ★★★ | 航太、醫療、核能 |
| 8D 報告 | 需完整問題解決流程 | 1-4 週 | ★★★ | 汽車、電子製造 |
| FMEA | 事前預防 | 2-5 天 | ★★★ | 製造、醫療器材 |
RCA 標準執行流程：6 個步驟從問題到對策
不論你選擇哪種 RCA 方法，底層的執行流程都是相通的。以下是我們團隊實際使用的六步驟框架。
步驟 1：定義並描述問題
這一步看似簡單，卻是最多團隊犯錯的地方。一個好的問題陳述句必須回答四個問題：何時、何地、什麼、影響多大。
| 錯誤示範 | 正確示範 | |
|---|---|---|
| 問題描述 | 「系統很慢」 | 「自 3/15 起，訂單查詢 API 回應時間從平均 200ms 上升至 1,500ms，影響每日約 12,000 筆查詢，導致 3 位企業客戶提出 SLA 違約通知」 |
問題描述越精確，後續分析的方向就越不容易偏離。如果你的團隊習慣用模糊的方式描述問題，建議先花 15 分鐘把問題陳述句寫好——這 15 分鐘能幫你省下後面好幾天的冤枉路。
寫好問題陳述句的能力，其實和寫企劃書的邏輯一樣——先把「我們到底要解決什麼」講清楚。
步驟 2：收集數據與事實
RCA 最忌諱的就是「憑印象分析」。你需要的是硬數據：
- 系統日誌（log files）
- 監控儀表板數據
- 訪談記錄（當事人、目擊者）
- 流程文件與 SOP
- 歷史事件紀錄
我們團隊曾遇過一個案例：某 IT 事故中，資深工程師憑經驗判斷「一定是最近部署的新功能造成的」，團隊花了兩天回滾程式碼，問題依舊。後來調出完整的 server log，才發現真正的觸發點是第三方 API 供應商在同一天變更了回應格式。
教訓：數據不會說謊，但人的記憶會。
步驟 3：建立時間軸與事件序列
把所有已知事實按時間順序排列，還原事件的完整脈絡。這一步的目的是避免「倒果為因」——很多時候，我們以為的「原因」其實發生在「結果」之後。
實務上，你可以用一張簡單的時間軸表格：
| 時間 | 事件 | 來源 |
|---|---|---|
| 3/14 18:00 | 第三方 API 供應商發布更新公告 | 供應商郵件 |
| 3/15 09:00 | 使用者開始回報查詢變慢 | 客服系統 |
| 3/15 09:30 | 監控系統觸發回應時間警報 | Datadog |
| 3/15 10:00 | 工程師開始排查，初步判斷為部署問題 | Slack 紀錄 |
步驟 4：識別根本原因
這是 RCA 的核心步驟。在這裡，你需要套用前面介紹的方法（5 Whys、魚骨圖、FTA 等），從收集到的數據中找出根本原因。
關鍵區分——三種原因層次：
- 直接原因（Immediate Cause）：直接觸發問題的事件。例如：API 回應格式變更。
- 促成原因（Contributing Cause）：讓問題得以發生或擴大的條件。例如：團隊沒有訂閱供應商的變更通知。
- 根本原因（Root Cause）：如果消除它，問題就不會再發生。例如：外部依賴管理流程中沒有「變更監控」這個環節。
很多團隊的 RCA 之所以失敗，就是停在「直接原因」就宣布結案。真正的根本原因，通常藏在流程或系統層面，而不是某個人的操作失誤。
步驟 5：制定並驗證對策
找到根本原因後，對策必須能「切斷」根本原因與問題之間的連結。
驗證方式：
- 假設測試：「如果我們當時已經有這個對策，問題還會發生嗎？」如果答案是「會」，代表你的根本原因還沒找對。
- 小規模試行：在全面推行前，先在一個團隊或一條產線上測試對策的有效性。
步驟 6：實施、追蹤與文件化
這是最容易被忽略的步驟。很多團隊做完分析、寫完報告，然後⋯⋯就沒有然後了。
一份完整的 RCA 報告應包含以下欄位：
| 欄位 | 說明 | 範例 |
|---|---|---|
| 問題描述 | 何時、何地、什麼、影響多大 | 3/15 訂單查詢 API 回應時間異常，影響 12,000 筆查詢 |
| 根本原因 | 經分析確認的根本原因 | 外部依賴管理流程缺乏變更監控環節 |
| 對策 | 具體行動項目 | 建立第三方 API 變更監控機制，納入 CI/CD pipeline |
| 負責人 | 誰負責執行 | 後端工程主管 |
| 完成日期 | 預計完成時間 | 4/15 |
| 驗收標準 | 如何確認對策有效 | 連續 30 天無同類事件 |
實務上，我們團隊用 monday.com 建立 RCA 追蹤看板，每個 RCA 案件就是一張卡片，對策拆成子任務指派給負責人，搭配自動化提醒確保不會有任務被遺忘。比起散落在 Email 和 Excel 裡的 RCA 報告，集中管理的效率差異非常明顯。
RCA 實際範例：3 種產業情境完整示範
光看理論不夠，以下三個情境用統一格式呈現，你可以直接套用到自己的工作場景。
情境 A：製造業 — 產品良率下降
問題陳述： 自第三季起，A 產品線良率從 98.5% 下降至 94.2%，每月增加約 NT$120 萬的報廢成本。
分析方法： 5 Whys
| 層次 | 問題 | 答案 |
|---|---|---|
| Why 1 | 為什麼良率下降？ | 成品尺寸公差超標比例增加 |
| Why 2 | 為什麼公差超標？ | 射出成型參數偏移 |
| Why 3 | 為什麼參數偏移？ | 原料流動性與原規格不同 |
| Why 4 | 為什麼流動性不同？ | 供應商在第三季初更換了原料配方 |
| Why 5 | 為什麼團隊不知道？ | 供應商變更通知流程未建立 |
根本原因： 供應商原料規格變更未通知，且公司端缺乏原料變更偵測機制。
對策： 1. 與供應商簽訂原料變更通知條款 2. 每批原料進貨時增加流動性抽檢 3. 建立原料規格變更 SOP，納入品保流程
情境 B：IT / 軟體服務 — 系統服務中斷
問題陳述： 週五下午 14:00，電商平台全站無法存取，持續 47 分鐘，違反 99.9% SLA 承諾，影響約 NT$200 萬營收。
分析方法： 魚骨圖（6M 架構）
- Man：部署人員未執行 pre-deployment checklist
- Machine：staging 環境與 production 環境配置不一致
- Method：部署流程缺乏自動回滾機制 ← 根本原因
- Material：新版程式碼含有未捕捉的 null pointer exception
- Measurement：監控告警延遲 8 分鐘才觸發
- Mother Nature：週五下午為流量高峰期，放大了影響
根本原因： 部署流程缺乏自動回滾機制，導致有問題的版本無法在第一時間自動退回。
對策： 1. CI/CD pipeline 加入自動健康檢查，部署後 5 分鐘內錯誤率超過閾值自動回滾 2. staging 環境配置與 production 同步自動化 3. 監控告警延遲從 8 分鐘縮短至 1 分鐘
情境 C：醫療 / 服務業 — 病患用藥錯誤
問題陳述： 某區域醫院內科病房，護理師於夜班交接後給予 A 病患 B 病患的口服藥物，幸及時發現未造成傷害，但屬於重大異常事件。
分析方法： FTA（故障樹分析）
頂層事件「用藥錯誤」往下展開：
- OR 閘：身份辨識失敗 或 藥物核對失敗
- 身份辨識失敗：病患手環模糊未更換 且 護理師未執行三讀五對
- 藥物核對失敗：交班確認流程未標準化 ← 根本原因
根本原因： 夜班交接時的用藥確認流程未標準化，各護理師執行方式不一致。
對策： 1. 建立標準化交班用藥確認 checklist（雙重確認制度） 2. 導入條碼掃描系統，給藥前強制掃描病患手環與藥袋 3. 每季進行用藥安全模擬演練
這三個範例的共同點是：根本原因都不是「某個人犯了錯」，而是「系統或流程存在缺陷」。這正是 RCA 最重要的思維轉換。
RCA 常見錯誤與失敗原因
我們團隊在輔導不同組織導入 RCA 的過程中，反覆看到以下五個錯誤。每一個都會讓你的 RCA 變成浪費時間的文書作業。
| 常見錯誤 | 為什麼有害 | 如何避免 |
|---|---|---|
| 把「直接原因」當「根本原因」就停止 | 問題會在不同面貌下反覆出現 | 用假設測試：「消除這個原因後，問題真的不會再發生嗎？」 |
| 只找「人的錯誤」，忽略系統缺陷 | 換一個人操作，同樣的錯誤還是會發生 | 每次找到人為原因時，再問一層：「是什麼系統條件讓這個錯誤成為可能？」 |
| 分析完沒有追蹤對策執行 | RCA 報告變成文件墳場，問題照樣復發 | 指定負責人、設定截止日、定期 review |
| 跨部門資訊不透明 | 數據收集不完整，分析結果偏頗 | RCA 會議必須邀請所有相關部門代表 |
| 在壓力下倉促結案 | 根本原因未充分驗證，對策治標不治本 | 設定最低分析時間門檻，不因主管催促而跳過驗證步驟 |
其中第三個錯誤——「分析完沒追蹤」——是我們見過最普遍的問題。團隊花了大量時間做分析，產出一份漂亮的報告，然後對策任務散落在不同人的待辦清單裡，三個月後沒人記得。這就是為什麼我們強烈建議用專案管理工具來追蹤 RCA 的對策執行，而不是只靠 Email 和 Excel。
進入心流狀態做深度分析很重要，但分析完成後的執行追蹤同樣不能鬆懈。
用 Monday.com 執行與追蹤 RCA 的實務做法
RCA 的分析階段需要深度思考，但追蹤階段需要的是系統化管理。當你的團隊同時有 3-5 個 RCA 案件在進行，散落在 Excel 和 Email 裡的資訊很快就會失控。
我們團隊實際使用 monday.com 來管理 RCA 流程，以下是具體做法。
建立 RCA 追蹤看板的 4 個步驟
步驟 1：建立專用看板 在 monday.com 建立一個「RCA 追蹤」看板，每一列代表一個 RCA 案件。欄位設定包含：問題描述、發生日期、影響範圍、分析方法、根本原因、對策狀態、負責人、截止日。
步驟 2：新增問題卡片 每當觸發 RCA 流程，就新增一張卡片，按照步驟 1 的問題陳述格式填入標準欄位。所有相關文件（log 檔、訪談紀錄、截圖）直接附在卡片上，確保資訊集中。
步驟 3：拆解對策為子任務 根本原因確認後，把每個對策拆成獨立的子任務，指派給負責人並設定截止日。例如「建立第三方 API 變更監控機制」可以拆成：調研監控工具（工程師 A, 4/1）→ 撰寫監控腳本（工程師 B, 4/8）→ 整合至 CI/CD pipeline（工程師 A, 4/15）→ 驗收測試（QA, 4/20）。
步驟 4：設定自動化與定期 review 用 monday.com 的自動化功能設定：「當子任務截止日到期且狀態仍為進行中，自動通知負責人和 PM」。我們團隊設定了一條規則：任務延遲超過 2 天自動升級通知給部門主管。這個設定在過去 6 個月內觸發了 17 次，每次都讓問題在擴大前被處理——以前要到雙週會才發現有人卡住。
Monday.com vs Excel 追蹤 RCA
| 功能 | monday.com | Excel |
|---|---|---|
| 版本控制 | 自動儲存，完整歷史紀錄 | 多人編輯易衝突，版本混亂 |
| 即時協作 | @mention、留言、附件集中 | 需搭配 Email 溝通，資訊分散 |
| 自動提醒 | 截止日到期自動通知 | 需手動追蹤 |
| 儀表板 | 一鍵查看所有 RCA 案件進度與關閉率 | 需手動製作樞紐分析表 |
| 費用 | 基本方案約 NT$288/人/月起 | 免費（但隱性成本高） |
（推薦試試 monday.com 的免費方案，不需要信用卡，我們團隊實際使用後 RCA 案件的平均關閉時間從 28 天縮短到 14 天。）
如果你的團隊偏好技術導向的工具，ClickUp 也是不錯的選擇，它的自訂欄位和自動化功能同樣能支援 RCA 追蹤流程。
你是哪種團隊？
- 5 人以下、剛開始接觸 RCA：先用 Notion 免費版建立簡單的 RCA 資料庫
- 5-15 人跨部門協作：monday.com（我們的首選），自動化和儀表板功能讓追蹤不費力
- 技術團隊跑 Scrum：ClickUp，與開發工作流整合度高
- 15 人以上的大型組織：monday.com 企業方案，支援跨部門權限管理和進階報表
RCA 與相關方法論的關係：8D、PDCA、FMEA
RCA 不是孤立存在的工具，它在更大的問題解決與持續改善框架中有明確的定位。理解這些關係，能幫你在對的時機用對的工具。
RCA vs 8D
8D 是一套完整的問題解決流程（D0 到 D7），RCA 是其中 D4（找根本原因）的核心步驟。換句話說，每次做 8D 都會用到 RCA，但做 RCA 不一定要走完整個 8D 流程。
如果你的組織需要一套從「問題發現」到「永久對策驗證」的端到端流程，8D 是更完整的選擇。
RCA vs PDCA
PDCA（Plan-Do-Check-Act）是持續改善循環，RCA 是 Plan 階段中用來「找出問題根源」的分析工具。PDCA 告訴你改善的節奏，RCA 告訴你改善的方向。
對熟悉數位轉型的團隊來說，PDCA 循環中嵌入 RCA 是確保轉型過程中問題不會反覆出現的關鍵做法。
RCA vs FMEA
FMEA 是事前預防（問題還沒發生就先分析風險），RCA 是事後矯正（問題發生後找根本原因）。兩者互補，不是替代關係。
一句話總結：FMEA 防火、RCA 滅火、8D 是消防隊的完整 SOP、PDCA 是定期消防演練的節奏。
結論
RCA（Root Cause Analysis，根本原因分析）是每個 PM 和團隊主管都應該掌握的核心技能。回顧本文重點：
- RCA 的本質是「治本」——不停在表面症狀，追問到系統與流程層面的根本原因
- 五大方法各有適用場景：5 Whys 適合快速分析、魚骨圖適合跨部門問題、FTA 適合高風險系統、8D 適合完整問題解決流程、FMEA 適合事前預防
- 六步驟執行流程：定義問題 → 收集數據 → 建立時間軸 → 識別根本原因 → 制定對策 → 實施追蹤
- 區分三種原因層次（直接原因 / 促成原因 / 根本原因）是 RCA 成敗的關鍵
- 追蹤對策執行和分析本身一樣重要——沒有追蹤的 RCA 只是一份好看的文件
你的下一步行動：挑一個團隊中反覆出現的問題，用 5 Whys 做一次 30 分鐘的快速 RCA。不需要完美，先建立「追問根本原因」的習慣。當你準備系統化管理 RCA 流程時，在 monday.com 建立一個 RCA 追蹤看板，把問題描述、根本原因、對策任務和負責人集中管理——免費方案不需要信用卡，10 分鐘就能建好你的第一個追蹤板。
RCA 根本原因分析常見問題
RCA 和 Root Cause Analysis 是同一件事嗎？
是的，RCA 就是 Root Cause Analysis 的英文縮寫，中文翻譯為「根本原因分析」。三者指的是完全相同的方法論，只是在不同語境下使用不同的稱呼。台灣業界口語中最常直接說「RCA」。
RCA 分析要花多久時間？
視問題複雜度而定。簡單的 5 Whys 分析可以在 30 分鐘到 2 小時內完成；涉及跨部門的魚骨圖分析通常需要 2-4 小時的會議；完整的 8D 報告（含 RCA）則可能需要 1-4 週。建議先用 5 Whys 做初步篩選，確認問題值得深入分析後再投入更多資源。
小團隊或新創公司也需要做 RCA 嗎？
需要，但可以簡化流程。小團隊不需要寫 20 頁的正式報告，用 5 Whys 搭配一張簡單的追蹤表就夠了。重點是建立「問題發生後追問根本原因」的習慣，而不是追求流程的完整性。即使是 3 人團隊，花 30 分鐘做一次 5 Whys，也比反覆修同一個 bug 有效率得多。
RCA 報告要給誰看？格式有標準嗎？
RCA 報告的讀者通常包含：直屬主管、相關部門負責人、品質管理部門。格式沒有全球統一標準，但必備欄位包含：問題描述、根本原因、對策、負責人、完成日期、驗收標準。如果你的產業有特定規範（如汽車業的 8D 格式、醫療業的病安通報格式），則需遵循產業標準。
音響的 RCA 端子和這裡說的 RCA 是同一個詞嗎？
不是。音響的 RCA 端子（紅白黃色接頭）得名於發明它的美國無線電公司（Radio Corporation of America）。本文討論的 RCA 是 Root Cause Analysis（根本原因分析），是一種問題分析方法論。兩者只是英文縮寫相同，完全不同領域。
RCA 在醫療領域怎麼應用？
醫療領域的 RCA 主要用於病安事件（Patient Safety Events）調查，例如用藥錯誤、手術部位錯誤、院內感染等。台灣的醫療機構依據衛福部規範，重大異常事件必須進行 RCA 分析並提交改善報告。常用方法包含 FTA（故障樹分析）和魚骨圖，重點在於找出系統性缺陷而非歸咎個人，並建立標準化的防錯機制（如雙重確認 checklist、條碼掃描系統）。
