# 庫存補貨能力演進：操作方案提案

> **證據邊界：Synthetic / Proposed。** 本文沉澱的是一個可演練的 FDE 案例，不是任何企業的現況證據或授權。所有角色、數字與系統名稱都只表示資料和決策應有的形狀。缺少的企業事實一律標示為 `missing` 或 `unverifiable`。

## 1. 要改善的營運結果

### 使用者與痛點

主要使用者是補貨規劃人員。現行簡化流程在庫存低於固定安全量後才發出通知。這種規則很可靠，但它只能描述「現在庫存低」，無法提前回答：按照目前銷售速度、下一次供貨時間與即將發生的活動，商品會不會在新貨到達前進入缺貨風險？

案例要改善的不是通知速度，而是讓人更早取得可解釋、可審閱的補貨選項。第一階段的行動只到「產生進貨單草稿」；只有未來 access 與 control evidence 完整時，正式進貨單才可由具名人員核准，並由受治理的系統行動寫入。

### 指標

| 指標 | 定義 | 現況 | 提議目標 |
| --- | --- | --- | --- |
| 可預防缺貨暴露 | 已能提前看見、但未及時處理的缺貨風險商品日數 | `missing` | shadow 後由流程負責人接受 |
| 建議採納率 | 人員未作重大修改便接受的建議比例 | `missing` | 只作學習訊號，不追求盲目提高 |
| 人工修改率 | 數量、時間、供應商或理由被修改的比例 | `missing` | 穩定工具發布後應下降 |
| 提前發現時間 | 從第一次可看見風險到預計缺貨日的時間 | `missing` | 足以涵蓋採購與交期 |

指標的數字目標目前不可驗證，不能用 demo 數字代替流程負責人的接受。

## 2. 現況流程診斷

### 正常路徑

1. 系統讀取目前庫存。
2. 庫存低於安全量時發出通知。
3. 補貨人員查看通知並決定是否採購。

### 例外與重工

- 銷售突然變快時，人員通常要另外查看銷售報表。
- 促銷即將開始時，固定安全量可能太晚才反映壓力。
- 供應商實際交期比名目交期長時，通知發生後可能已來不及。
- 在途量延誤或庫存資料過舊時，表面數字會讓人得到錯誤安全感。
- 人員可能在試算表重做相同計算，但修改理由沒有被結構化保存。

### 核心問題

真正缺少的不是另一則通知，而是一個能把來源、定義、預測、限制、人工判斷與後續行動串起來的學習迴路。固定程式擅長執行已知規則；它不會自動發現「每次促銷前，人員都做同一種修正」值得成為下一版工具。

這份診斷尚未由真實流程負責人和使用者確認，因此狀態是 `proposed`。

### Process-readiness decision

目前尚未 readiness-ready：現況診斷與目標流程沒有真實 process owner／affected users 的接受證據；normal、exception、escalation 的 handoff 與負責人尚未具名；歷史 baseline 也為 `missing`。因此目前只能提出條件性方案，AI selection 維持 `deferred`。只有這些流程證據補齊後，才能驗證下文所描述的 AI 步驟是否真的比重新設計後的非 AI baseline 更有價值。

## 3. 先改善流程，再選技術

即使還沒有 AI，也應先做四項改善：

1. **統一補貨審閱入口。** 不讓人員在庫存報表、銷售報表、郵件與試算表間來回找資料。
2. **定義同一套名詞。** 清楚區分現有量、可用量、保留量、在途量、需求、交期與補貨建議。
3. **保留人工決策理由。** 接受、修改或拒絕時，記錄改了什麼以及為什麼。
4. **分開建議與執行。** 分析結果可以快速試驗，正式進貨仍保留核准、稽核與復原控制。

這些改變會讓 AI 與未來工具都使用同一個工作流程，也避免把混亂流程藏在 prompt 裡。

## 4. 目標操作流程：雙迴路

### A. 營運迴路

```text
排程觸發
  → 取得允許的庫存、銷售、促銷、在途與供應商證據
  → 檢查來源、權限、語意版本、品質與新鮮度
  → 呼叫目前已發布的分析與預測工具
  → AI 整理未結構化脈絡、比較矛盾證據並解釋異常
  → 產生補貨建議與進貨單草稿
  → 人員接受、修改或拒絕並記錄理由
  → 僅在未來 access 與 control evidence 完整後，由經授權的系統行動提交正式進貨單
```

缺資料、來源過期、工具結果衝突或政策不存在時，系統應中止自動草稿或清楚降級，交給具名人員處理；AI 不得把缺少的企業規則補成看似合理的答案。

### B. 演進迴路

```text
蒐集建議、工具結果、人工修改、結果偏差與例外
  → AI 找出重複模式和可能的能力缺口
  → 提出流程、語意、規則、模型、工具或控制變更候選
  → 在可重播資料或 shadow 中比較新舊方法
  → 負責人接受或拒絕候選
  → 開發、測試並發布版本化能力
  → 營運迴路改用新版本；持續觀察下一個缺口
```

這裡的「自我進化」是受治理的能力演進，不是 AI 自行修改正式程式。AI 主動發現與提議；人類接受政策與風險；軟體交付流程負責測試、發布和回復。

## 5. 商品 A 的簡化示例

| 已知資料 | 示例值 | 意義 |
| --- | ---: | --- |
| 現有庫存 | 120 件 | 高於固定安全量 80 |
| 最近七日平均銷售 | 10 件／日 | 約可支持 12 天 |
| 去年同期平均銷售 | 18 件／日 | 存在季節性壓力線索 |
| 供應商交期 | 10 天 | 現在才採購已接近風險邊界 |
| 在途庫存 | 50 件 | 仍需確認到貨日與可靠性 |
| 下週促銷 | 有 | 影響幅度尚未被證明 |

傳統規則只看見 `120 > 80`，因此不通知。新的流程會指出：庫存覆蓋時間與供應商交期很接近，而且促銷與同期銷售提供額外風險訊號。AI 可以提出一個有範圍、有理由、有不確定性的建議，例如「請審閱補貨 100–140 件」。但這只是示例形狀；真實數量必須由已接受的資料、政策或模型產生。

## 6. 介入選擇與責任

| 保留的工作 | 介入方式 | 原因 |
| --- | --- | --- |
| 每日或事件觸發檢查 | 確定性排程 | 穩定、可觀察、可重試 |
| 取得資料與檢查權限 | 確定性軟體 | 權限不能由模型猜測 |
| 庫存覆蓋、門檻與採購限制 | 版本化規則工具 | 可測試、可重播、可共用 |
| 需求預測 | 統計或 ML 工具 | 預測應有版本、評估與誤差 |
| 組合文字脈絡與解釋異常 | AI | 語言理解與跨證據綜整具有增量價值 |
| 發現重複人工修正 | AI 輔助分析＋人類判斷 | AI 找模式，人類決定是否代表政策 |
| 核准補貨政策與進貨單 | 人類 | 需要營運責任與例外判斷 |
| 正式寫入採購系統 | 受治理系統行動 | 必須授權、稽核、冪等且可復原 |

### AI-fit 結論

目前 AI selection 是 `deferred`，因為真實流程、handoff、exception owner 與 baseline 尚未被確認。若 process-readiness evidence 補齊，AI 在早期探索與持續演進階段可成為條件性 `justified` 的候選：它可能處理尚未完全結構化的脈絡、整理相互矛盾的證據、解釋建議並找出反覆出現的人工修正。

AI 不負責穩定公式、權限、政策執行或正式寫入。當某項分析被證明穩定，應下沉成工具；AI 的責任上移到例外與下一輪改善。是否比非 AI baseline 帶來增量價值，目前仍為 `unverifiable`，需要 shadow 比較。

## 7. 從探索到工具化的提升契約

不是每個 AI 發現都值得寫成程式。候選能力至少要回答：

1. 是否在足夠多次決策中重複出現？
2. 是否能定義輸入、輸出、來源、責任人與失敗行為？
3. 是否能以資料重播，並和目前方法比較？
4. 是否有正常、邊界、缺資料和衝突案例？
5. 是否由政策或流程負責人接受？
6. 是否有版本、監控、回復和退役方式？

通過後，能力可被提升為例如：

```text
forecastDemand(productId, horizon, contextVersion)
estimateSupplierLeadTime(supplierId, asOfDate)
assessInventoryPressure(productId, asOfDate)
recommendReplenishment(productId, policyVersion)
preparePurchaseOrderDraft(recommendationId)
```

每個工具都應回傳結果、理由碼、來源證據、資料新鮮度、工具或模型版本與不確定性。AI、dashboard 和 workflow 應使用同一個工具，而不是各自重寫定義。

## 8. 第一個可交付垂直切片

### 使用者可見結果

先為 10–30 個選定商品建立每日唯讀審閱清單。第一切片只使用可重播的非 AI baseline，例如安全庫存、庫存覆蓋天數與已接受的交期規則。每項包含來源、資料時間、規則版本、主要原因與資料缺口；人員可記錄判斷、修改與理由。這個切片先證明資料、定義、流程與回饋紀錄可信。

### 第一切片包含

- 一個合成或已獲准的唯讀資料 snapshot。
- 最小語意定義：商品、可用庫存、需求、在途、交期、建議和草稿。
- 固定排程與資料品質檢查。
- 一個可重播的非 AI baseline。
- 人工審閱與修改原因紀錄。
- 不提交的進貨單草稿。

### 明確延後

- 自動核准或提交進貨單。
- 全商品與全供應商覆蓋。
- AI 對額外脈絡的綜整與解釋實驗。
- AI 自行發布規則、模型或程式變更。
- 沒有真實授權證據的 ERP／採購系統整合。

### Readiness 後的條件性 AI shadow

只有真實流程負責人與使用者接受現況診斷、目標流程、handoff、exception ownership 與 baseline 後，才建立下一個 AI shadow 工作包。它在同一批資料與決策上，將未結構化脈絡綜整、異常解釋和缺口發現與第一切片的非 AI baseline 比較；仍不提交正式進貨單。若沒有可量測的增量價值，AI 不進入營運迴路。

## 9. 權限與控制

提議的 application form 是「human-approved recommendation with draft」。真實 access decision 為 `missing`。

若未來要提交正式進貨單，必須另行證明：具名核准人、最小權限、輸入驗證、金額與數量限制、供應商限制、稽核紀錄、冪等鍵、重試行為、取消或補償方式，以及失敗時的人工接手流程。

AI 的禁止自治範圍包括：自行新增供應商、變更付款條件、接受新政策、核准自己的建議、提交正式訂單，或直接修改已發布工具。

## 10. 驗證與推出

### 測試集合

- 正常消耗且無促銷。
- 目前庫存高，但交期與季節性造成未來壓力。
- 在途資料過期。
- 供應商名目與實際交期矛盾。
- 缺少促銷影響證據。
- 最小訂購量與建議量衝突。
- AI 無法取得足夠證據時正確 abstain。
- 相同草稿重試時不產生第二張正式訂單。

### 推出順序

1. 用歷史資料重播傳統安全庫存規則。
2. 以非 AI baseline 進行唯讀 shadow，確認流程、資料與人工理由紀錄可用。
3. Readiness 通過後，在同一資料上加入條件性 AI shadow，記錄人員決策與理由。
4. 選一個高頻且可測試的修正，固化為第一個工具版本。
5. 比較工具化前後的準確性、修改率、延遲與例外。
6. 只有控制證據完整時，才評估正式進貨單寫入。

所有門檻目前都是 `proposed`，必須由真實 acceptance owner 接受。任何來源、權限或主要輸入缺失都阻擋正式寫入。

## 11. 證據帳本

| 主張 | 狀態 | 目前依據 | 限制 |
| --- | --- | --- | --- |
| 固定安全庫存無法表達所有未來壓力 | `proposed` | 案例問題陳述 | 需由真實流程與資料確認 |
| AI 適合整理未結構化脈絡與人工理由 | `proposed` | 職責設計 | 需與非 AI baseline 比較 |
| 穩定分析應提升為版本化工具 | `evidenced`（專案方法） | FDE capability reuse 與 Prove and Evolve 原則 | 不證明特定工具已通過企業驗證 |
| 正式進貨單寫入已獲授權 | `missing` | 無企業授權或控制證據 | 僅能建立不提交的草稿 |
| 商品 A 應補貨 100–140 件 | `unverifiable` | 只有合成示例 | 不得當作真實決策使用 |
| 方案能降低缺貨或人工時間 | `unverifiable` | 尚無 shadow 或 production 結果 | 不得宣稱商業成效 |

## 12. 下一個負責行動

由真實補貨流程負責人召集補貨人員、資料 owner 與 FDE delivery owner，選定 10–30 個商品，確認現況 normal／exception／escalation 路徑、資料來源、修改原因分類，以及四週 shadow 的基線與接受門檻。

完成條件是：流程負責人接受一份技術中立的目標流程，所有必要來源與權限有直接證據，且第一個唯讀 shadow 工作包可以被交付團隊重播。達成以前，本方案保持 `proposed`。