本文重點
- 補貨觸發點的定義
- 基本計算範例
- 三種 ROP 模式
§ 01補貨觸發點的定義
補貨觸發點（Reorder Point，ROP）是一個庫存水位值，當某品項的庫存數量降至這個水位時，應立即發出採購訂單進行補貨。
設定 ROP 的邏輯很直觀：在訂單到貨之前，還需要消耗多少庫存？
如果前置時間是 10 天，平均每天消耗 50 個，那麼從發出採購訂單到物料入庫，預計會消耗 500 個。所以當庫存降到 500 個時，就應該下訂單——等物料到貨時，庫存恰好耗盡。
加上安全庫存作為緩衝（應對需求高峰或前置時間延誤），就得出完整的 ROP：
ROP = 日均需求 × 前置時間（天）+ 安全庫存
§ 02基本計算範例
情境：
- 品項：液壓密封件 A 型
- 日均消耗量：15 個/天
- 補貨前置時間（下單到入庫）：12 天
- 安全庫存（已依統計方法計算）：60 個
ROP = 15 × 12 + 60 = 180 + 60 = 240 個
意思是：當液壓密封件 A 型的庫存降到 240 個時，立即發出採購訂單。訂單到貨時，庫存預計剩下安全庫存 60 個（在正常消耗情況下）。
§ 03三種 ROP 模式
模式一：固定 ROP（Static ROP）
計算一次後維持不變，定期（例如每季）重新審查和更新。最常見的做法，適合大多數穩定需求的品項。
優點：簡單，易於管理，可以不需要 ERP 系統。 缺點：參數設定後如果不及時更新，在需求或前置時間改變後可能失效。
模式二：動態 ROP（Dynamic ROP）
依照最新的需求數據和前置時間，自動更新 ROP 值。通常需要 ERP 或庫存管理系統的支援。
優點：隨時反映最新狀況，無需人工定期審查。 缺點：需要高品質的數據和 ERP 支援；如果系統參數設定不當，可能產生頻繁的小額採購訂單（因 ROP 隨需求小幅波動而觸發）。
模式三：時段式計劃 ROP（Time-phased ROP / MRP 邏輯）
不是依庫存水位觸發，而是依未來已知的需求計劃（如生產排程）倒推補貨時點。這是物料需求計劃（MRP）的基本邏輯。
優點：對已知需求最精準，可以避免安全庫存的過度佔用。 缺點：需要準確的生產計劃和 BOM 數據；對需求不確定的品項效果差。
台灣中小製造業最實際的選擇是固定 ROP，配合定期人工審查更新。
§ 04定期審查 vs 連續審查
設定 ROP 之後，還需要決定「何時檢查庫存水位是否已觸發 ROP」。
定期審查（Periodic Review）： 每週（或每天）集中檢查所有品項的庫存水位。如果某品項在本週庫存低於 ROP，就在本週發出採購訂單。
適合情境：庫存記錄以人工更新為主，無法即時掌握庫存變動；採購訂單集中在固定時間處理（例如每週二固定採購日）。
風險：在兩次審查之間，如果庫存跌破 ROP，補貨動作會延遲到下次審查才觸發。審查間隔越長，延遲風險越高，需要的安全庫存也越多。
連續審查（Continuous Review）： 每次有庫存異動（出庫、入庫），立即更新庫存帳，並即時判斷是否觸發 ROP。一旦庫存降至 ROP，當下立即發出採購訂單。
適合情境：ERP 系統有即時庫存追蹤能力；A 類關鍵物料（缺料成本高，值得即時監控）。
好處：反應最快，安全庫存需求最低（因為不需要覆蓋審查間隔期的風險）。
§ 05ROP 失效的三個常見原因
原因一：庫存數據不準確
ROP 的觸發依賴知道「目前實際庫存是多少」。如果倉庫帳不準確（有未記錄的出庫、帳物不符、在途庫存沒有扣帳），ROP 可能在「帳上」有庫存時失效，導致缺料。
解決方法：先改善庫存記錄準確性（定期循環盤點、出庫即時記錄），再建立 ROP 系統。庫存帳不準確是 ROP 系統失效的第一名原因。
原因二：前置時間波動
固定 ROP 假設前置時間是一個常數（或可用平均值代表）。如果實際前置時間波動很大（例如供應商有時 7 天、有時 14 天），基於平均前置時間計算的 ROP 在最差情況下可能不足。
解決方法：在安全庫存計算中納入前置時間標準差（見安全庫存計算文章的方法三），而不是假設前置時間是固定值。
原因三：需求集中或間歇性
ROP 的邏輯假設消耗是連續且平均的（每天消耗日均量）。如果需求是集中的（例如每個月月底一次性領用大批量）或間歇性的（有幾週完全沒有消耗，然後突然大量消耗），固定 ROP 的表現很差。
解決方法：對間歇性或集中需求的品項，改用定期訂貨或 MRP 邏輯；或者提高安全庫存以吸收需求不可預測性。ROP 並不適合所有物料。
§ 06建立補貨觸發點清單
對沒有 ERP 的企業，最實際的 ROP 管理方法是一張 Excel 表格，稱為「補貨觸發點清單」：
| 欄位 | 說明 |
|---|---|
| 物料編號 | 品項識別碼 |
| 品名 | 描述 |
| 單位 | 數量單位 |
| ABC 分類 | A/B/C |
| 日均需求 | 過去 90 天平均每天消耗量 |
| 前置時間（天） | 下單到入庫的平均天數 |
| 安全庫存 | 計算值或設定值 |
| ROP | = 日均需求 × 前置時間 + 安全庫存 |
| 目前庫存 | 手動或系統更新 |
| 需補貨？ | =IF(目前庫存 <= ROP, "是", "否") |
| 每次訂購量 | MOQ 或 EOQ |
| 上次補貨日期 | 維護用 |
| ROP 最後更新日 | 維護提醒 |
| 下次計劃審查日 | A 類每季、B/C 類每年 |
每次採購人員進行庫存檢查時，只需更新「目前庫存」欄，「需補貨？」欄即自動判斷。
§ 07何時更新 ROP
ROP 設定後需要定期維護，否則隨著時間推移，它反映的是過去的狀況而非現在的。
應立即觸發 ROP 審查的情況：
- 供應商更換或前置時間發生顯著改變（例如從 10 天延長到 15 天）
- 產品需求量顯著增加（新客戶、新訂單）或顯著減少（客戶縮減訂單）
- 季節性需求高峰前（可能需要臨時調高 ROP）
- 品項進入生命週期末期（需求可能下降，ROP 應同步調低）
定期審查建議：
- A 類物料：每季更新一次（使用最新 3 個月的消耗數據）
- B 類物料：每半年更新一次
- C 類物料：每年更新一次
§ 08台灣 ERP 系統的 ROP 設定現況
台灣中小製造業普遍使用的 ERP 系統（鼎新 ERP、遠擬等）都有 ROP 觸發補貨的功能，稱為「安全庫存觸發點」或「再訂購點」。
但根據實際觀察，這類系統中的 ROP 設定普遍存在以下問題：
- 建置系統時填入的初始值，從未更新過： 有些公司的 ERP 中，ROP 設定已有五年以上未更新，完全不反映現在的需求量和供應商前置時間
- 所有品項套用同樣的公式或倍數： 例如「安全庫存統一設為月均需求的 30%」，沒有依物料重要性和需求特性差異化設定
- 補貨觸發通知沒有人看： ERP 產生了補貨建議，但採購人員沒有養成定期查看的習慣
即使系統有完整的 ROP 功能，如果沒有人維護參數、沒有人執行觸發後的採購動作，功能形同虛設。
建立 ROP 管理的關鍵，不只是計算出正確的數字，還包括誰負責定期審查參數、誰負責在觸發後跟進採購、出現缺料時如何檢討是 ROP 設定問題還是執行問題。沒有配套的責任機制，再完善的 ROP 設定都難以持續發揮效用。