約束理論 Theory of Constraints

什麼時候該用它？

約束理論（TOC）最適合在你明明很忙但產出卻沒有等比增加的時候拿出來。如果團隊每個人都在加班，backlog 卻越來越長、交付速度沒有變快——問題幾乎一定出在你不知道瓶頸在哪裡。

• 開發效能停滯：Sprint velocity 上不去，加人也沒用，怎麼回事？
• 轉換率優化：購物車加入率不錯但結帳完成率很低——漏斗的瓶頸在哪裡？
• 跨部門協作卡住：行銷、產品、工程都很忙，但專案就是推不動
• 營運成本飆升但產出沒增加：每個部門都在「優化」，但整體效能沒提升
• 供應鏈或物流延遲：客訴集中在交期，但不確定問題出在哪個環節

框架結構

約束理論的核心觀點：系統像一條鏈條，強度由最弱的一環決定。與其讓每一環都變強，不如找到最弱那環，專注打通它。

五步聚焦法（Five Focusing Steps）

這是 TOC 的核心操作流程：

Step 1：辨識瓶頸（Identify the Constraint）

找出系統中限制整體產出的那個環節。判斷方式：

• 它前面的東西在堆積（WIP 越來越多）
• 它後面的東西在等待（下游閒置）
• 整個系統的產出速率 ≈ 這個環節的處理速率

Step 2：壓榨瓶頸（Exploit the Constraint）

在不增加資源的前提下，讓瓶頸的每一分鐘都在處理最有價值的工作。

• 減少瓶頸的停機時間
• 確保瓶頸不處理低優先級的工作
• 不要讓瓶頸等待其他環節

Step 3：配合瓶頸（Subordinate Everything Else）

讓所有其他環節配合瓶頸的節奏。

• 非瓶頸環節的速度不需要最大化——它們只需要「夠快」
• 控制進入系統的工作量（不要讓非瓶頸環節製造更多半成品堆在瓶頸前面）

Step 4：提升瓶頸（Elevate the Constraint）

如果前三步做完還不夠，才考慮投入資源擴大瓶頸的能力。這通常意味著花錢——加人、加設備、加系統。

Step 5：回到 Step 1（Prevent Inertia）

瓶頸打通後，新的瓶頸會在別處出現。回去重新找，不要假設問題已經解決。

鼓-緩衝-繩（Drum-Buffer-Rope，DBR）

TOC 的執行機制：

• 鼓（Drum）：瓶頸的產出速率，決定整個系統的節拍
• 緩衝（Buffer）：在瓶頸前面放一個緩衝區，確保瓶頸永遠有工作可做
• 繩（Rope）：控制原料投入系統的速率，與瓶頸同步，避免 WIP 爆量

蒸發雲（Evaporating Cloud）

TOC 的衝突解決工具。當兩個團隊或兩個目標看似矛盾時：

1. 畫出共同目標
2. 畫出兩個對立的需求
3. 畫出各自導致的行動（看起來互相矛盾）
4. 質疑連結兩端的假設——通常衝突來自錯誤的假設，而非真正不可調和

來源與歷史

• 1984：以色列物理學家 Eliyahu Goldratt 出版商業小說《目標》(The Goal)，用故事講述約束理論，全球銷量超過 700 萬冊
• 1990：Goldratt 創立 Avraham Y. Goldratt Institute，開始將 TOC 推廣到更多產業
• 1997：出版《關鍵鏈》(Critical Chain)，將 TOC 應用到專案管理，挑戰傳統甘特圖方法
• 2004：David Anderson 將 TOC 概念帶入軟體開發，影響了後來 Kanban 方法的誕生（WIP 限制就是 TOC 思維）
• 2010 年代至今：TOC 的 WIP 限制和瓶頸思維被 DevOps 運動大量採用，《鳳凰專案》(The Phoenix Project) 致敬《目標》，成為 IT 管理經典

真實案例：亞馬遜物流中心的瓶頸突破

亞馬遜在 2013 年 Prime Day 前夕發現物流中心的出貨速度跟不上訂單量。傳統做法是「全面加人加設備」，但亞馬遜用 TOC 思維重新分析：

1. 辨識瓶頸：不是揀貨、不是包裝，而是「分揀站」——所有包裹匯集到分揀站等待配送路線分配，這裡的處理速度決定了整體出貨量
2. 壓榨瓶頸：讓分揀站 24 小時不停機（輪班制）、優先處理 Prime 會員訂單、減少分揀站的非核心工作
3. 配合瓶頸：控制揀貨和包裝的速率——故意讓前面慢下來，避免分揀站前堆滿等待的包裹（減少混亂）
4. 提升瓶頸：投入 Kiva 機器人（現更名為 Amazon Robotics），讓分揀效率提升約 4-5 倍

結果：物流中心的日處理量從平均 100 萬件提升到超過 300 萬件。而且投資集中在瓶頸上——如果亞馬遜把同樣的預算平均分配到每個環節，效果會差很多。到 2024 年，亞馬遜全球有超過 75 萬台倉儲機器人，但最初的決策就是 TOC 的「找瓶頸，打瓶頸」。

使用步驟

Step 1：畫出你的系統流程

把從「需求進入」到「價值交付」的每個環節畫出來。電商場景就是：需求 → 設計 → 開發 → QA → 部署 → 上線。或者：流量 → 瀏覽 → 加購 → 結帳 → 出貨。

Step 2：量測每個環節的吞吐量和等待時間

看數據。哪個環節前面堆最多待處理的東西？哪個環節的處理時間最長？哪個環節後面的人在等？那就是你的瓶頸。

Step 3：先壓榨、再配合

不要急著加資源。先問：瓶頸環節有沒有在浪費時間做不重要的事？其他環節有沒有在製造更多壓力給瓶頸？調整這些就能免費提升產出。

Step 4：有意識地投資

如果壓榨和配合做完還不夠，再決定投入資源。但只投入在瓶頸上——不是每個部門都要加預算。

Step 5：重新找瓶頸

舊瓶頸打通後，馬上去找新瓶頸。系統永遠有瓶頸，只是位置會移動。這不是做完一次就結束的事。

這樣做 vs 避免這些

這樣做

• 用數據找瓶頸——看 WIP 堆積量、等待時間、吞吐量，不要用感覺判斷
• 先做免費的改善（壓榨 + 配合），再考慮花錢的改善（提升）
• 讓非瓶頸環節「慢下來」是對的——不要讓每個人都追求 100% 利用率
• 持續循環——瓶頸會移動，這個框架不是一次性的

避免這些

• 不要「每個部門都優化一點」——這是 TOC 最核心的反直覺觀點：只有優化瓶頸才有意義
• 不要把「最忙的人」跟「瓶頸」搞混——忙不代表是瓶頸，要看整個系統的流向
• 不要在打通瓶頸前就加速前面的環節——你只會製造更大的堆積
• 不要忽略「慣性」——打通舊瓶頸後，團隊可能還在用舊的做法，沒有跟上新的節奏