企業架構實務（五）：用 PPTI 分析好味餐飲的訂單履約能力

好味餐飲的事故表面上像是資料庫撐不住：會員日活動開始後，訂單請求一度升到平日午餐尖峰的七倍，OneFood 的連線池隨後耗盡，App、官網與部分門市 POS 一起逾時。

但資料庫恢復後，31 名財務、客服、資訊與門市人員仍花了六個小時比對交易。問題已經超出效能範圍：好味缺少一項能在尖峰與例外情境下穩定完成、也能說明結果的訂單履約能力。

這篇使用前一篇整理的 PPTI 工作模型，分析更新後的好味餐飲數位轉型情境。PPTI 在這個系列裡是自訂的現況診斷方法，不屬於 TOGAF、CMMI 或 ITIL 的正式評鑑表。它的作用是把 People、Process、Technology、Information 放回同一項業務能力，讓分數能被證據挑戰。

先把能力邊界切清楚

這次的主評估對象是「訂單履約」。多通路只描述它目前的營運情境，不另列一項能力。評估從 POS、App、官網或外送平台接受訂單開始，到顧客取得可理解的履約結果為止。客服、門市與財務能否查明這段流程的結果，是能力是否完成的驗證條件；財務日結與跨店總帳對帳不在本輪範圍。

付款、庫存、廚房與對帳會影響訂單履約，但它們仍保有自己的責任與成熟度。這一輪把它們當成相依能力，不把整條交易鏈硬壓成一個大分數。

類型	能力	本輪處理方式
主評估能力	訂單履約	評估 People、Process、Technology、Information
相依能力	付款處理	觀察付款核准、回呼、退款與訂單狀態的交接
相依能力	庫存可售量管理	觀察批次更新、負庫存與尖峰容量競爭
相依能力	廚房履約	觀察廚房單建立、重複單與取消
相依能力	交易查明與例外處理	觀察付款逾時、重複單與狀態不明時，客服、財務與營運如何查明結果

評估基線是 2026 年 8 月 28 日，主要觀察期間是基線日前 90 天；個別證據仍以各自的期間與 owner 為準。半年事故與八個月發布紀錄則作為較長期的補充證據。

訂單履約已跨門市與線上通路持續運作，因此能力生命週期暫列 Established。策略角色先以 Core 試算，但這只是工作坊假設。後面會用其他權重檢查結論是否穩定。

訪談用來找衝突，不直接產生分數

門市說逾時後只能請顧客重試，客服卻有一份「先查付款」的手冊；維運看得到資源異常，卻不知道哪個業務步驟占住連線；財務能在日結後補出結果，但顧客要的是當下答案。

Utility 與 Warranty 在這裡是服務關注點，不拿來分類受訪者。每個角色都可能同時談到功能是否可用、容量是否足夠，以及資訊能不能被信任。

受訪觀點	訪談證據	主要關注
門市與客服	`INT-01`、`INT-02`	逾時後能不能判斷付款與訂單結果，現場是否有可執行的例外流程
財務與營運	`INT-03`、`INT-04`	對帳何時完成、活動規則如何交付，以及例外由誰負責
工程與維運	`INT-05`、`INT-06`	跨模組規則、交易追蹤、容量競爭、恢復與變更風險
資料與資安	`INT-07`	資料 owner、帳號 owner、存取範圍與稽核責任

訪談可以指出要查哪裡，成熟度仍要回到可回查的事實。門市只能請顧客重試，可能是流程不存在，也可能是既有流程沒有被工具與訓練接住；這兩種問題的改善方式不同。

用 evidence register 裁決四個維度

依照第四篇的最低證據規則，第 1 至第 2 級至少需要一筆可歸屬的事實證據。下表沿用情境中的 evidence register；期間、owner、抽樣方式與交叉檢查結果要以該 register 為準。「已驗證」只表示案例資料足以支持這次裁決，與外部認證無關。

維度	可回查證據	裁決	狀態與信心	下一個檢查
People	`E-PPL-01` 顯示 14 名相關人員中只有 2 人能獨立追查跨模組問題，且沒有指定備援；`INT-05` 說明知識集中位置	`1 Initial`	已驗證；中信心	由資訊主管補上能力矩陣、備援責任與實際值班紀錄
Process	`E-PRC-01` 顯示三個單位各有操作文件，40 筆抽樣中有 26 筆依單位作法處理，但沒有端到端 owner	`2 Managed`	已驗證；中信心	由客服與營運共同定義例外流程，連續抽樣三個月確認執行情況
Technology	`E-TEC-01` 記錄半年 11 件 P1／P2 事故與 110 分鐘平均復原時間；`E-TEC-02` 顯示跨模組回歸仍需 4 至 5 個工作天	`1 At Risk`	已驗證；高信心	用 `GAP-02` 定義服務目標，再以 `GAP-04` 的壓力測試驗證隔離與容量
Information	`E-INF-01` 顯示各單位已有局部狀態文件與對帳作法，但跨訂單、付款、廚房仍沒有共同 owner 或穩定識別	`2 Managed`	已驗證；中信心	抽樣 `GAP-01`，確認重試、付款、訂單與廚房單能否關聯，再定義共同狀態與 owner

Process 與 Information 已經有部門級作法，因此高於完全臨時處理，得到 2 分。這不表示結果良好；跨部門仍靠電話、群組訊息與試算表，還沒有達到組織級 Defined。

People 與 Technology 則停在 1 分。關鍵知識沒有備援，事故會跨通路擴散，恢復指標又只算系統重新上線，這些證據還不足以證明基本控制能穩定重複。

觀點差異要保留，裁決仍回到同一份證據

以下的工作坊初評是本文為了示範觀點差異設定的感知結果，不是從 18 份訪談自動換算而來。門市與客服對 Process、Information 的感知初評都是 1；IT 的感知初評則是 2，理由是已經有手冊、對帳與監控。真實評估還要記錄每題的填答者、樣本數、中位數與分布。這兩組回答先保留，不直接當成成熟度。把 E-PRC-01 與 E-INF-01 放上桌後，評估小組裁決這兩個維度符合「部門級管理，但跨域不一致」的 2 分描述。

這輪補充帶來的變化不在四維數字跳動，而在證據狀態：

階段	Process、Information	CHS
尚未整理成 evidence register	待驗證，不能產生成熟度分數	不可用於排名
加入相關訪談，並完成 `E-PRC-01`、`E-INF-01` 交叉檢查	裁決為 2，理由與資料可回查	可做診斷試算，仍不可跨能力排名

這個過程沒有把兩邊平均成 1.5。原始回答、角色與分歧仍保留在 register，成熟度則依共同 rubric 和證據裁決。訪談用來暴露落差；事實證據負責決定目前能站在哪一級。

INT-04 的活動交付觀察會接到後面的變更與知識移轉；INT-07 與 E-SEC-01 則保留為資安與資料權限的邊界訊號，交給 IT Score 的 CISO 活動。本輪沒有把存取治理當成訂單履約的獨立成熟度分數。

CHS 只是摘要，權重依情境調整

CHS 把四個維度的成熟度彙整成一個摘要，方便快速判讀。它不是新的評估維度，也不能取代 People、Process、Technology、Information 的分數。

不同企業、不同階段重視的維度可能不同，權重應依業務目標與風險設定。這個案例先用 Core 權重試算；如果換一組合理權重就讓 CHS 跨級變動，表示摘要對權重敏感，判讀時要回到四維分數與業務目標，不能只看 CHS 排優先順序。

改善順序要接回業務目標

這次不按最低分排序。改善順序同時考慮事故影響、兩年目標、工作依賴與目前能取得的證據。

改善焦點	現況證據	對應目標	下一個驗收條件
交易識別與狀態責任	`E-INF-01`、`GAP-01`	結果不明交易在 30 分鐘內查明；營運資料 5 分鐘內可查	抽樣時能沿同一個識別查到付款、訂單與廚房歷程，並確認兩項時間目標
例外流程與 owner	`E-PRC-01`、`INT-01`～`INT-03`	人工核對降至每月 50 筆以下	付款成功但回應逾時、重複廚房單與外送平台重送，都有處理人、時限與補償規則；案件抽樣能查回這些紀錄
尖峰隔離與恢復	`E-TEC-01`、`GAP-02`、`GAP-04`	局部異常時，未受影響的門市與通路仍能接單	在混合負載壓力測試與故障演練中，未受影響的門市與通路仍能接單，並留下服務目標與恢復證據
變更與知識移轉	`E-PPL-01`、`E-TEC-02`、`INT-04`	一般活動與規則在 10 個工作天內完成驗證並上線	關鍵規則有備援 owner，核心交易流程有可重複的自動化回歸與回復證據，發布紀錄能支持 10 個工作天目標

這個順序仍沒有宣布「一定要拆微服務」。交易識別、狀態模型與責任還沒釐清時，拆服務只會把模糊邊界搬到更多服務之間；壓力測試若證明共用資料庫和整體部署無法滿足服務目標，才有足夠證據討論隔離或遷移。

從這個案例能學到什麼

這個案例最先教的是能力邊界。OneFood 是應用程式，訂單履約是業務能力，付款、庫存與廚房履約則是相依能力。這幾個層次混在一起，分數就很難解釋。

評分能不能成立，取決於證據門檻。受訪者說法很重要，但它先告訴我們「要去哪裡查」，不會自動把成熟度往上或往下推。部門手冊、案件抽樣、事故紀錄與技能盤點，才讓 Process 2、Information 2、People 1 與 Technology 1 可以被回查。

CHS 只是摘要。它會隨權重改變，低分也不會自動翻譯成換平台。能進入 roadmap 的內容，應該是業務目標、能力缺口、相依關係與下一個驗收條件。

12:14 OneFood 恢復服務，只代表系統重新接受請求。訂單履約要等到交易可以被辨識、解釋與處理，才算真的恢復。這也是這次 PPTI 分析最值得留下的判斷。