# FDE 情境至行動方法

> 本文件為閱讀用繁體中文譯本；英文版 [FDE-Scenario-to-Action-Method.md](FDE-Scenario-to-Action-Method.md) 是維護中的來源文件。

本方法是**全深度參考方法**，供需要更深入建模、保證、驗證，或使用者明確要求交付協助的案例使用。FDE 營運分析的預設產出仍然是五段式營運解法：問題與成果、現行工作診斷、目標工作流、介入與 AI 適配決策及其證據界線，以及下一個當責行動。本方法提供的是選用技巧；它的階段、工件與關卡不是一份通用的交付檢查表。

本方法的研究依據見 [可用於 FDE 的系統分析方法（繁中）](docs/zh-TW/research/system-analysis-methods.md)，其中保留 ISO、OMG、NIST 與 SEI 的官方來源連結。

## 何時使用本方法

只有在核心分析顯示存在由實質不確定性、風險、授權、持久性、價值主張或明確要求所造成的需要時，才取用其中最小的相關部分。通用案例可以使用清楚標示的參考假設；它們永遠不建立目標企業的事實、驗收、存取、發布授權或價值。實作只在被另外要求時才開始。

## 全深度設計目標

當案例需要受治理的發布或提升權限時，分析應在提出該主張之前回答下列問題：

1. 哪個營運成果與決策真正重要？
2. 現行流程中有哪些可避免的延遲、返工、模糊或風險，以及在選擇技術之前，目標流程應該變成什麼樣子？
3. 哪些業務事實、狀態與關係使結果成立？
4. 哪些來源證據與語義定義支撐結果？
5. 哪些決策邏輯、風險控制與品質取捨限制它？
6. 在增加權限前，如何證明它有價值？

## 協作釐清

當營運問題模糊到無法進入六個階段時，先把它釐清成一棵依相依關係排序的決策樹。FDE 自行調查搆得到的事實與證據，其餘向持有它們的角色索取；當責的參與者決定意圖、政策、權責歸屬、取捨與驗收。向知情的角色詢問一項事實，不等於請他做決策。使用者明確要求比較、重新檢視或擴展分析時，那是已經交辦的工作：FDE 依現有證據所能支撐的深度執行它，其餘標記 `missing` 或 `unverifiable`，並且把分析的權限與變更政策、開通存取或操作系統的權限分開。只問當前的**前沿**：前置條件已經確定的決策。每個決策都附上以既有證據為基礎的建議答案，記錄答案與理由，然後重新計算前沿。

釐清完成的條件是：每個實質分支都已決定、有證據支撐，或被明確標記為 `missing` 或 `unverifiable`，且沒有任何下游決策建立在未定的前置條件之上。結果要能指出有邊界的營運成果、使用者、流程或案例位置、決策或行動，以及下一個當責負責人。它產出的是適用階段的輸入；它本身不是情境核准、企業驗收，也不是實作授權。

## 選用的六階段參考流程

```text
界定 → 描繪工作 → 建模意義 → 明確決策 → 確保控制 → 證明與演化
```

| 階段 | 主要問題 | 方法依據 | 選用工件 | 條件式關卡 |
| --- | --- | --- | --- | --- |
| 1. 界定 | FDE 應改善哪個有邊界的成果？ | ISO/IEC/IEEE 29148 需求工程 | 已核准的情境紀錄 | 負責人接受範圍、限制、基線、目標與驗收條件 |
| 2. 描繪工作 | 在選擇技術之前，哪些工作應該被移除、簡化、標準化或重新指派？ | BPMN／CMMN | 經驗證的現行與目標流程或案例模型，含瓶頸、變更假設與介入候選 | 流程負責人與受影響使用者接受現況診斷、目標路徑、交接、例外歸屬與變更假設 |
| 3. 建模意義 | 穩定的業務事實與允許的生命週期變化是什麼？ | UML 結構／狀態建模；ISO/IEC 11179 登錄模式 | 具版本的物件、關係、狀態、指標與來源定義 | 已具備負責人、識別、定義、狀態與血緣 |
| 4. 明確決策 | 要根據哪些輸入提出何種建議或行動？ | DMN | 具名決策服務及規則／測試集 | 測試覆蓋正常、邊界與升級結果 |
| 5. 確保控制 | 哪些存取、行動與品質風險必須控制？ | NIST RMF；SEI ATAM | 風險／控制紀錄與品質情境決策紀錄 | 控制、核准、取捨與復原需求均已明確 |
| 6. 證明與演化 | 最小有用切片在真實營運條件下是否可行？ | ISO/IEC/IEEE 15288 | 垂直切片證據與變更紀錄 | 驗收條件通過；偏差有明確後續責任 |

## 階段說明

### 1. 界定

從已核准的[情境紀錄契約](schemas/fde-scenario.schema.json)開始，而不是「做一個 Agent」的請求。紀錄應包含營運負責人、使用者角色、流程節點、決策或行動、基線、目標、所需來源、語義參照與驗收條件。

**規則：**若沒有可辨識的決策、行動或可量測結果，該工作仍屬研究，尚非 FDE 交付情境。

### 2. 描繪工作

對重複且具規範性的流程使用 BPMN，例如交接、計時、審批與系統整合；當下一個工作取決於例外情況的演變事實而非既定順序時，使用 CMMN 式案例模型。

先驗證現行的正常、例外、升級與返工路徑。找出等待、重複查核、權責不清、語義或證據落差，以及沒有降低實質風險的控制。接著設計技術中立的目標流程：消除不必要的工作、簡化交接、標準化政策與意義、釐清決策權與例外歸屬，並修補證據或資料落差。

記錄變更假設，以及能顯示重新設計是否有幫助的基線。在選擇能力或 AI 之前，流程負責人與受影響的使用者必須接受或修正這份診斷與目標流程。缺少該證據時，目標流程維持 `proposed`。

只有在這個流程整備決策之後，才標示候選的 **FDE 介入節點**。在選定的節點上，FDE 可以取得上下文、提供建議、要求核准，或執行已核准的受控行動。比較流程變更、資料或語義修補、確定性軟體、使用者介面支援、AI 協助與受治理行動，選出最簡單而充分的介入。不要把每個流程步驟都當成技術或 AI 機會，並且把 `no AI` 當成一個完整的決策。

### 3. 建模意義

請分別建立三種模型，而非將它們混在同一張圖：

| 模型 | 回答的問題 | 例子 |
| --- | --- | --- |
| 結構模型 | 有哪些業務事物，彼此如何關聯？ | 訂單、客戶、例外、供應商 |
| 狀態模型 | 哪些生命週期狀態與轉換是允許的？ | 已建立 → 受阻 → 已分流 → 已解決 |
| 語義登錄 | 術語、指標、規則與來源映射代表什麼，誰治理？ | `OrderException`、分流週期時間、權威訂單來源 |

每項可重用語義資產都應有穩定識別、定義、負責人、來源、狀態／版本與複核歷程。流程順序不能取代生命週期狀態模型；來源欄位名稱不能取代業務定義。

### 4. 明確決策

若 FDE 對具影響性的事項提出建議、排序、核准或路由，應將它寫成具名決策服務。當政策必須被檢視與測試時，DMN 式決策表尤其適合。

| 決策元素 | 必要說明 |
| --- | --- |
| 決策名稱 | 正在做出的具體決策 |
| 輸入 | 已定義物件、狀態、指標、政策與來源版本 |
| 邏輯 | 規則、門檻、優先順序或具理由的建議邏輯 |
| 輸出 | 建議、路由、說明或所請求的行動 |
| 負責人 | 對決策政策負責的角色或人員 |
| 升級處理 | 證據不足、規則衝突或信心不足時的處理方式 |

決策邏輯必須與呼叫它的流程、以及呈現它的 UI 或 Agent 分離，讓同一決策能被看板、工作流或 Agent 重用。

### 5. 確保控制

在取得敏感上下文或執行持久性行動前，先評估風險。按比例採用 NIST 風險模式：分類情境與行動、選取控制、測試控制、取得所需授權，並持續監控證據。

在選定實作細節前，以品質情境記錄重要取捨，例如來源新鮮度、授權延遲、說明完整度、語義變更影響、復原時間與可用性。

**規則：**FDE 在取得寫入權前，必須先證明唯讀證據可信。受控行動必須具名、符合權限、在需要時經核准、可稽核、具冪等性且可復原。

### 6. 證明與演化

先發布最小端到端切片，通常是單一核准情境的一個唯讀查詢。它應回傳：

```text
結果 + 語義定義版本 + 來源證據 + 新鮮度狀態 + 存取決策
```

當結果影響營運時，讓新舊流程並行。比較結果、差異原因、例外、使用者介入與業務指標。被接受的偏差必須成為流程、語義資產、決策邏輯、控制或應用的變更，而非未記錄的權宜作法。

## 全深度工件組

只在選定的深度確有需要時才使用下列工件。它們不是每個情境的最小分析套組。

| 工件 | 建立階段 | 維護者 | 使用前提 |
| --- | --- | --- | --- |
| 情境紀錄 | 界定 | 業務負責人與 FDE | 任何交付工作 |
| 現行與目標流程／案例模型、瓶頸證據、變更假設與介入候選 | 描繪工作 | 業務翻譯官／流程負責人 | 能力或決策支援設計 |
| 物件、關係、狀態、指標與來源定義 | 建模意義 | 本體與資料負責人 | 上下文解析 |
| 決策服務與測試 | 明確決策 | 政策／決策負責人 | 建議或行動 |
| 風險／控制與品質情境紀錄 | 確保控制 | 資安、隱私、架構與業務負責人 | 發布或提升權限 |
| 垂直切片證據與變更紀錄 | 證明與演化 | FDE 交付負責人 | 擴大或自動化 |

## 條件式保證關卡

| 關卡 | 何時適用 | 問題 | 受限或允許的下一步 |
| --- | --- | --- | --- |
| G1 — 情境核准 | 真實情境需要負責人驗收或界定交付範圍 | 成果是否有邊界、有負責人且可量測？ | 在已接受的範圍內建模工作與意義 |
| G2 — 語義落地 | 解法依賴共用定義或有來源的上下文 | 必要事實、狀態、指標、來源與負責人是否已定義？ | 只建置或驗證必要的唯讀上下文路徑 |
| G3 — 證據已證明 | 發布或決策支援的主張取決於面向使用者的證據 | 使用者是否可取得已授權、新鮮且可說明的結果？ | 在其證據界線內支援建議型或共用的結果 |
| G4 — 決策已受控 | 解法會提出具影響性的建議、核准或路由 | 具影響性的邏輯是否可測試且受治理？ | 啟用有邊界的核准或決策工作流 |
| G5 — 行動已授權 | 解法會產生持久性行動或提升權限 | 存取、核准、稽核、冪等性與復原控制是否經測試？ | 只允許已授權的受控回寫 |
| G6 — 價值已證明 | 案例主張生產、影子或持續的營運價值 | 證據是否符合已接受的條件？ | 支持該價值主張，或選定下一個有邊界的實驗 |

## 本方法可資參考的解決方案模式

當案例確有需要時，本方法可以為下列解決方案模式提供參考：

```text
情境紀錄
  → 情境登錄模組
  → 本體資產模組
  → 上下文解析模組
  → 決策支援模組
  → 行動執行模組
```

它們不是本專案的模組，也不是必須執行的路線圖。它們是目標營運能力的可能設計，只在適合該案例時才選用。

## 全深度工作坊順序

| 工作坊 | 參與者 | 產出 |
| --- | --- | --- |
| 情境界定 | 業務負責人、使用者、FDE 交付負責人 | 已核准情境紀錄與基線／目標 |
| 工作與意義 | 流程負責人、受影響使用者、領域專家、資料／本體負責人 | 已接受的現行／目標流程模型、瓶頸與變更假設、介入候選、最小語義資產集合 |
| 決策與控制 | 決策負責人、資安／隱私負責人、架構負責人 | 決策服務輪廓、風險／控制紀錄、品質情境、首切片驗收測試 |

面對確實需要這種深度的真實案例，先界定營運問題，並且只挑選它的下一個當責決策所需要的工作坊與關卡。不要因為使用了本方法，就推論自己已獲得建置、發布、存取企業資料或執行行動的授權。