概念地圖・DMAIC
作者 山姆（謝冠生）・喵喵書評創辦人
發布 最後更新
分類：管理
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
DMAIC：五步，把問題連根解決
同一個問題老是重複發生——出貨常出錯、良率總是拉不上去——多半是因為大家憑感覺救火，沒有一套章法。DMAIC 是六標準差的核心流程，用五個步驟，逼你靠數據把問題連根拔起：定義（Define）、衡量（Measure）、分析（Analyze）、改善（Improve）、控制（Control）。它最狠的紀律是——先量清楚、找到真因，才准動手改。
五個步驟，各自把關一件事
DMAIC 的骨架，是一條「先搞懂、再動手、最後守住」的紀律。它最反直覺的地方，是逼你在改善之前，先花大把力氣去量、去分析。先用一張表看完。
| 步驟 | 它逼你做 | 常見的偷懶 |
|---|---|---|
| D 定義 | 用數據把問題講具體，設定目標。 | 問題模糊，全程失焦 |
| M 衡量 | 建立現況基準，蒐集可靠數據。 | 沒基準，改了也不知有沒有效 |
| A 分析 | 從數據裡挖出真正的根本原因。 | 憑直覺猜兇手 |
| I 改善 | 針對真因對症下藥、驗證有效。 | 藥沒對症，白忙一場 |
| C 控制 | 把新做法標準化，防止回彈。 | 沒守住，過陣子打回原形 |
怎麼跑才治得了本：三個判準
DMAIC 最怕跑成「開一堆會、做一堆表，問題照舊」。下面三個判準，幫你把五步跑出真效果。
「定義」要用數據，別用形容詞。把問題從「品質不好」講成「退貨率從 2% 升到 5%、集中在某條產線」，整個專案才有明確的靶。定義得越具體、越可衡量，後面四步才有依據。第一步含糊，後面全跟著飄。自問：我要解的這個問題，講得出數字、範圍、發生在哪嗎？
先量再改，是 DMAIC 的鐵律。人的本能是一發現問題就衝去改，但 DMAIC 硬要你先「衡量」——建立一個現況基準。因為沒有基準，你事後根本說不清改善到底有沒有用、用了多少。忍住那股立刻動手的衝動，先把數據量準，是這套方法最值錢的紀律。自問：我改之前，有沒有一個「現在是多少」的準確數字，好讓我事後對照？
別跳過最後那步「控制」。大多數改善的成果會慢慢回彈——熱度一過，人就滑回舊習慣。「控制」這一步，就是把有效的新做法標準化、寫進流程、設好監控指標，讓成果鎖得住。少了它，你辛苦五步的成果，過幾個月就打回原形。自問：我這次的改善，有沒有變成一個「就算我不盯，也不會走樣」的固定機制？
拿 DMAIC 解一個問題：網購倉庫老是出貨錯
光講框架很抽象，套一次就懂。假設一家網購倉庫「出貨錯誤率偏高」，用 DMAIC 跑一輪。
- D 定義：出貨錯誤率 3%，客訴多半是「寄錯商品」，目標壓到 1% 以下。
- M 衡量：量一週的錯誤，發現集中在「同款不同尺寸」和「尖峰時段」。
- A 分析：挖出真因——揀貨只核對品名、沒掃條碼；尖峰又沒有第二人覆核。真正的根
- I 改善：導入條碼掃描比對、尖峰時段加一道出貨覆核。
- C 控制：把掃描設成系統強制步驟，每天看錯誤率儀表板，一回彈就示警。鎖住成果
跑完一輪你會發現，真正的關鍵，是中間那步「分析」——當數據指出「錯誤集中在同款不同尺寸、尖峰時段」，根因才浮出來：問題出在揀貨流程本身沒有防呆，員工用不用心反而是其次。如果一開始就憑感覺「大概是員工太粗心」，衝去辦教育訓練，錯誤率大概不會有太大改善。DMAIC 最務實的地方就在這：它用「先量、再挖真因、才動手」的紀律，逼你別再對著症狀瞎忙，而是把力氣花在那個一改就見效的根上。以上為說明結構用的示意情境，僅供理解框架之用。
這套流程，什麼時候會騙你
DMAIC 很嚴謹，但它有三個邊界。不知道，就會把它套到不對的問題上。
- 它為「可衡量、會重複」的問題而生。DMAIC 擅長優化一個已經存在、有數據、反覆發生的流程問題。面對一個全新的、還沒有數據的創新探索，或需要天馬行空的發想，它那套嚴謹的量化紀律反而綁手綁腳。
- 它又重又慢，小題大作會拖垮效率。完整跑一輪 DMAIC 要投入不少人力和時間。碰到一個五分鐘就能修好的小問題，還煞有介事地走完五個階段，等於殺雞用牛刀，反而拖累了該有的敏捷。
- 它優化流程，卻不問流程該不該存在。DMAIC 的第一步「定義」，預設了你要解的那個問題是對的。它會忠實地幫你把一件事做得更好、更有效率——就算那件事，本身根本沒有做的價值。
用痛點的眼光，再看一次 DMAIC
DMAIC 是一台強大的「把事做對」引擎——它用數據和紀律，把一個已知的問題解到極致，讓良率、錯誤率、成本都優化到位。但用《痛點》的角度看，它有一個藏在第一步裡的假設：它預設了你「定義」的那個問題，是一個對的問題。這正是它最大的盲點。DMAIC 擅長「把現有的事做得更好」，卻回答不了「這件事到底該不該做」。你完全可以用一套無懈可擊的 DMAIC，把一個根本沒人要的產品，良率提升到 99.99%——每個數字都漂亮，整件事卻毫無意義。所以 DMAIC 真正該搭配的，是啟動它之前的那個提問：我打算優化的這條產線、這個流程，它通往的產品，真的有一群人在痛、在等嗎？先用《痛點》確認你優化的是「對的事」，再用 DMAIC 把這件對的事「做到對」。優化引擎負責把事做對，痛負責替你選對，到底要優化哪一件事。
關於 DMAIC，常被問到的幾件事
DMAIC 五個階段分別是什麼？
D 定義（Define，把問題與目標講清楚）、M 衡量（Measure，蒐集現況數據、建立基準）、A 分析（Analyze，從數據找出根本原因）、I 改善（Improve，針對真因對症下藥）、C 控制（Control，把成果標準化、防止回彈）。它是六標準差用來改善既有流程的核心方法。
DMAIC 和 PDCA 有什麼不同？
兩者都是「持續改善」的循環，精神相通。PDCA（計畫—執行—查核—行動）比較輕、彈性大，適合日常、快速的小改善。DMAIC 更重、更依賴數據和統計工具，適合複雜、需要嚴謹分析的大問題。可以粗略理解為：PDCA 是隨手改善的日常習慣，DMAIC 是正式立案、動用數據的改善專案。
為什麼「衡量」一定要在「改善」之前？
因為沒有事前的基準數據，你就無法客觀判斷改善到底有沒有效、效果多大。很多人憑感覺改一通，最後只能說「好像有變好」，卻拿不出證據。先量準現況，改完再量一次對照，成效才說得清楚。這個「先量再改」的紀律，正是 DMAIC 區別於憑感覺救火的關鍵。
小公司、非製造業用得上 DMAIC 嗎？
用得上，只要問題是「可衡量、會重複」的。餐廳的出餐時間、電商的客訴率、客服的回應速度，都能用 DMAIC 來改善。重點是學會它的思路：先把問題量化定義、找到真正的根因、對症下藥、再把成果守住，而不必執著於照搬那些統計工具。這套思路，比任何單一工具都值錢。
想把「持續改善」變成組織的日常本能？《豐田模式》的拆書談的正是那套「反覆追問、把每個問題都當改善機會」的現場文化；若你想看懂「到底該優化哪個環節、才不會瞎忙」，《目標》的拆書會用一個工廠的故事，帶你抓住決定整體產出的那個關鍵瓶頸。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。