Architecture Journal
情境故事：好味餐飲的數位轉型起點
案例說明
這是一個虛構案例。所有公司名稱、人物、數字與事故皆為虛構，不代表任何真實企業。
| 項目 | 內容 |
|---|---|
| 案例版本 | 0.5 |
| 基線日期 | 2026-08-28 |
| 公司 | 好味餐飲集團，以下簡稱「好味」 |
故事從一個午餐尖峰開始
好味從一家街邊餐廳起家，十二年內發展成擁有三個品牌、42 家門市的餐飲集團。 早期那套只負責門市結帳與日結的系統，也一路跟著公司長大。工程團隊陸續把會員、 優惠券、線上點餐、庫存、廚房出單、外送串接與營運報表加進去。大家仍叫它 「POS 系統」，實際上它早已是整家公司最重要的交易核心。
2026 年 5 月 8 日星期五，好味推出會員日活動。上午 11:30，行銷部向 8 萬名會員推送「午餐第二件半價」優惠。四分鐘後，建立訂單、計算優惠、查詢狀態等訂單相關請求一度升到平日午餐尖峰的七倍。
當時有三項工作同時使用正式資料庫。優惠模組會在每次結帳時讀寫優惠券使用次數； 11:30 排程的庫存批次正在更新各門市的可售數量；營運人員則開啟活動報表，直接查詢 即時銷售資料。批次更新與報表查詢使資料庫回應變慢，OneFood 內等待查詢結果的交易 持續占用資料庫連線。幾分鐘後，OneFood 的連線池耗盡，線上點餐與門市 POS 開始逾時。
現行結帳流程會依序建立待付款訂單、呼叫付款服務商、寫回付款結果，再建立廚房單。 這些步驟會分別留下紀錄，付款服務商核准交易後，OneFood 仍須更新後續狀態。 這次事故中，有些請求在付款核准後、狀態寫回前逾時；有些則已建立廚房單，卻沒有 把結帳結果回傳給顧客。顧客再次送出結帳請求時，每次重送都會取得新的請求編號， 客服與門市無法立即判斷兩次請求是否來自同一次結帳。因此，有些門市收到兩張內容 相同的廚房單，也有顧客只看到信用卡扣款，卻在 App 或官網查不到已成立的訂單。
事故從效能下降發展成全面中斷：
| 時間 | 現象 |
|---|---|
| 11:30 | 會員推播送出，庫存批次與活動報表查詢開始執行 |
| 11:34 | 訂單相關請求一度達平日午餐尖峰的七倍 |
| 11:41 | 資料庫回應時間上升，OneFood 的資料庫連線開始排隊 |
| 11:46 | App、官網與部分門市 POS 大量逾時，客服開始接到查詢 |
| 12:03 | 維運人員重啟 OneFood，所有門市、App 與官網停止接單；外送平台仍可送出訂單，但 OneFood 無法正常接收 |
| 12:14 | OneFood 恢復服務，外送平台積壓的訂單陸續匯入，門市開始核對交易狀態 |
維運人員當時只能看到主機、JVM 與資料庫指標，無法判斷是哪個模組先出問題，也看不出一筆交易在訂單、付款、庫存與廚房之間走到哪一步。十一分鐘是系統完全停止服務的時間；在此之前已有十多分鐘大量逾時，恢復後也仍有訂單等待確認。
當天下午，共有 31 名財務、客服、資訊與門市人員參與處理，前後花了六個小時比對訂單、付款與廚房單。事故留下的初步數字如下：
| 影響 | 數字 |
|---|---|
| 超過三分鐘才確認結果的訂單 | 3,842 筆 |
| 疑似重複送出的訂單 | 217 筆 |
| 付款成功但訂單狀態不明 | 63 筆 |
| 出現負庫存的門市 | 18 家 |
| 直接退款、補償與估計流失營收 | 新臺幣 126 萬元 |
| 人工對帳與客服處理工時 | 186 小時 |
表中的訂單是從效能下降到恢復後清查期間受影響的交易，不只計算十一分鐘的全面中斷；各類別也可能重疊，例如付款狀態不明的訂單也可能超過三分鐘才確認結果。
公司正面臨什麼成長壓力
公司輪廓
| 項目 | 現況 |
|---|---|
| 門市 | 42 家直營門市，分布於北、中、南部 |
| 品牌 | 3 個品牌，共用會員、採購、部分菜單與中央廚房 |
| 員工 | 約 650 人，其中資訊團隊 24 人 |
| 會員 | 約 120 萬名註冊會員 |
| 訂單通路 | 門市 POS、App、官網、兩家外送平台 |
| 訂單占比 | 門市 60%、自有線上通路 22%、外送平台 18% |
| 尖峰負載 | 平日午餐尖峰每五分鐘約新增 300 筆訂單，產生約 1,800 次訂單相關系統請求；活動開始後，請求量一度達平日七倍 |
| 周邊系統 | 金流、電子發票、ERP、物流、簡訊與外送平台 |
董事會已核准兩年成長計畫：門市從 42 家增加到 80 家，推出一個只做外帶與外送的新品牌，並開放第一批加盟店。80 家包含首批 10 家加盟店，其餘新增門市仍由好味直營。
營運團隊預估，門市增加後，尖峰流量與支援案件會同步增加。行銷團隊準備為新品牌 設計獨立的菜單、價格與活動規則；負責加盟籌備的團隊則開始盤點加盟店可查看的資料、 可執行的作業，以及總部與加盟經營者各自負責的範圍。
管理團隊開始擔心，現有系統不只可能撐不住下一次活動，還可能成為公司成長速度的上限。
老闆希望公司變成什麼樣子
事故檢討會上，執行長林若晴說：
兩年內我們要開到 80 家店，也要能快速測試新品牌。系統不能再決定公司可以長多快。午餐尖峰出問題時，更不能所有通路和門市一起停下來。
管理團隊將期待整理成五項可以被觀察的業務結果：
| 業務目標 | 現況 | 兩年內希望達成的結果 |
|---|---|---|
| 支援展店與加盟 | 新門市設定與驗證平均需要 15 個工作天 | 5 個工作天內完成，不必等待專屬版本上線 |
| 加快新品牌與新通路上線 | 新品牌約需 6 個月，新通路約需 4 個月 | 新品牌 8 週、新通路 4 週內推出第一版 |
| 降低尖峰營運風險 | 局部異常可能拖垮全部通路 | 未受影響的門市與通路仍可接單；結果不明的交易在 30 分鐘內查明 |
| 縮短產品試驗週期 | 需求提出到上線通常需要 6 至 8 週 | 一般活動與規則變更在 10 個工作天內完成驗證並上線 |
| 提高交易資訊可信度與時效 | 每月約 320 筆交易需人工核對；營運報表隔日上午才完整 | 人工核對降至每月 50 筆以下；營運資料在 5 分鐘內可查 |
財務長補上一個限制：轉型期間不能讓公司停止接單。董事會每半年檢視一次投資，下一階段預算必須說明前一階段改善了哪些業務結果，以及還有哪些風險沒有降低。
董事會沒有指定改造手段，只要求任何方案都不能中斷日常營運，而且每一筆投資都必須說明解決了哪個業務痛點，以及公司要如何確認結果真的變好了。
不同角色看到的問題
事故檢討後，各角色提出了自己的目標、困擾與顧慮。
| 角色 | 主要目標 | 現在最痛的事 | 最擔心的轉型風險 |
|---|---|---|---|
| 執行長 | 展店、新品牌與營收成長 | 系統限制商業速度 | 花大錢後只換技術，業務結果沒有改善 |
| 營運長 | 門市穩定、出餐效率與標準化 | 各通路狀態不同，門市靠電話處理例外 | 新舊系統並存讓第一線更混亂 |
| 行銷長 | 快速設計活動與會員經營 | 每次優惠都要排進核心系統版本 | 投入改造後，活動上線速度仍沒有改善 |
| 財務長 | 對帳、退款與投資回報 | 訂單、付款、發票資料經常需要人工核對 | 改造期間影響結帳與稽核 |
| 門市店長 | 正確接單、備餐與交付 | 看不到訂單卡在哪裡，也無法自行復原 | 網路或中央服務異常時無法營業 |
| 廚房人員 | 按正確順序收到可製作的餐點 | 重複單、缺料單與臨時取消干擾出餐 | 新流程增加操作步驟 |
| 顧客 | 快速知道價格、付款與取餐狀態 | 逾時後不知道該等、重試還是聯絡客服 | 不同通路的價格、點數與狀態不一致 |
| 客服與財務 | 查到完整交易歷程並處理例外 | 需要跨五個畫面與試算表拼出真相 | 改造後仍無法取得一致的交易資訊 |
| 加盟經營者 | 在授權範圍內管理門市與掌握營運狀況 | 現有流程與權限都是依直營門市設計 | 看不到自己的必要資料，或看到不屬於自己的會員與他店資料 |
| 資訊團隊 | 安全地交付並快速定位事故 | 所有改動都碰同一套程式與資料庫 | 改造範圍超過團隊可以承擔的程度 |
訪談裡，每個人都只看得到一段流程
事故後，好味在 2026 年 6 月 9 日至 6 月 20 日訪談 18 人，包括 4 位門市店長、3 位客服人員、2 位財務人員、3 位營運與行銷人員、2 位後端工程師、2 位平台與維運工程師，以及 2 位資料與資安人員。
下表保留各角色的代表性說法。這些內容是受訪者觀點，還不是已確認的事實；進入成熟度評估前，仍須和系統紀錄、流程文件及營運數據交叉檢查。
| 識別碼 | 受訪角色 | 代表性說法 |
|---|---|---|
INT-01 | 門市店長，4 人 | 「畫面轉太久時，我們多半請顧客再試一次。付款有沒有成功，門市端看不到，只能打給客服。」 |
INT-02 | 客服人員，3 人 | 「客服手冊寫的是先查付款，但我們要開三個後台，再請財務確認。尖峰時電話通常比系統快。」 |
INT-03 | 財務人員，2 人 | 「每日結帳最後做得完，但不是當下就知道答案。有些差異要等外送平台或發票資料隔天進來。」 |
INT-04 | 營運與行銷人員，3 人 | 「活動規則最後還是要排 OneFood 版本。需求如果接近上線才改，通常得找熟悉優惠和訂單的人一起看。」 |
INT-05 | 後端工程師，2 人 | 「單一模組不難，難的是優惠、訂單、付款、庫存一起改。沒有一個畫面能告訴我們同一筆交易走到哪裡。」 |
INT-06 | 平台與維運工程師，2 人 | 「我們看得到主機、JVM 和資料庫，但事故剛發生時通常只能先排除，不知道是哪個業務步驟把連線吃完。」 |
INT-07 | 資料與資安人員，2 人 | 「帳號名單有保留，但有些帳號沿用太久。看得出哪個程式在連，未必找得到現在的業務負責人。」 |
訪談沒有形成一致答案。門市認為逾時後只能重試，客服手冊卻要求先查付款；維運知道系統資源何時異常，卻看不到顧客的交易停在哪一步；財務可以在日結後補出結果，但顧客與門市需要的是當下答案。這些落差是後續分析的線索，不是誰對誰錯的投票。
訪談之外，還有哪些資料可以回查
工作小組在基線日前整理出下列證據。每一筆都標示觀察期間、資料 owner 與目前能支持的結論，避免把一次事故、半年平均值與受訪者印象混成同一種證據。
| 識別碼 | 期間或日期 | 可回查內容 | 目前觀察 | 資料 owner |
|---|---|---|---|---|
E-PPL-01 | 2026-07-31 | 訂單領域技能盤點 | 14 名後端、平台與資料庫人員中，2 人能獨立追查優惠、訂單、付款與庫存的跨模組問題；7 人能處理單一模組；5 人需要他人陪同。兩位跨模組人員沒有指定備援 | 資訊主管 |
E-PRC-01 | 2026-06-01～2026-07-31 | 40 筆付款或訂單狀態異常案件抽樣 | 26 筆依客服、財務或維運各自的操作文件處理；14 筆改用電話、群組訊息或試算表協調。三個單位有自己的作法，但沒有共同的端到端流程 owner | 客服主管 |
E-TEC-01 | 2026-03-01～2026-08-28 | P1／P2 訂單相關事故紀錄 | 共 11 件，其中 6 件涉及共用資料庫壅塞或外部整合逾時；平均復原時間約 110 分鐘。紀錄以主機、應用程式與資料庫恢復為結束點，沒有計算交易何時完成清查 | 維運主管 |
E-TEC-02 | 2026-01-01～2026-08-28 | 發布與測試紀錄 | 正式版平均六週發布一次；最近 5 次發布都花 4 至 5 個工作天執行跨模組人工回歸，其中 1 次失敗後回復整個版本 | QA 主管 |
E-INF-01 | 2026-06-01～2026-08-28 | 對帳紀錄、狀態文件與報表排程 | 每月平均約 320 筆交易需要人工核對；訂單、付款與廚房各有自己的狀態說明，沒有共同資料 owner；重送請求無法穩定對回同一次結帳 | 財務主管 |
E-SEC-01 | 2026-07-15 | 正式資料庫非人員帳號清單 | 17 個批次、報表或整合帳號中，6 個可以寫入超過 20 張正式資料表，4 個沒有可確認的現任 owner；目前沒有固定的定期複核週期 | 資安主管 |
E-EA-01 | 2026-08-28 | 架構文件盤點 | 現有文件包含部署圖與外部系統清單，但沒有核准的業務能力地圖、目標架構、過渡狀態或淘汰條件 | 企業架構負責人 |
E-CIO-01 | 2026-01-01～2026-06-30 | 每月 IT 營運報告 | 報告固定追蹤主機可用率、事故數、服務案件與基礎設施成本，尚未追蹤展店時間、交易查明時間、人工對帳量或活動交付週期 | CIO 辦公室 |
這批資料仍不足以完成所有判斷。工作小組把缺口留在清單上，而不是用推估值補滿：
| 識別碼 | 待確認問題 | 需要的下一份證據 |
|---|---|---|
GAP-01 | 同一位顧客重試時，有多少請求其實來自同一次結帳？ | 通路請求、金流交易、訂單與廚房單的關聯抽樣 |
GAP-02 | 各通路可接受的延遲、可用率與降級方式是什麼？ | 經業務 owner 核准的服務目標與門市離線作業規則 |
GAP-03 | 加盟店完成履約真正需要哪些會員、付款與跨店資料？ | 加盟流程、資料分類與最小權限矩陣 |
GAP-04 | 活動尖峰下，報表、庫存批次與訂單交易各自占用多少容量？ | 同時執行三種工作負載的壓力測試與資料庫等待分析 |
GAP-05 | 新流程或工具上線後，門市與客服是否真的會照新方式處理？ | 培訓完成率、流程演練與實際案件抽樣 |
現況：一套系統承擔整家公司
單體系統 OneFood
好味的核心系統叫做 OneFood。它原本是門市 POS 後端，現在也承接 App、官網與外送平台送入的訂單，並包含下列模組：
| 模組 | 主要責任 |
|---|---|
| Menu | 品牌、門市菜單、價格與上下架時段 |
| Promotion | 優惠券、組合價、會員日與使用限制 |
| Order | 購物車、訂單、取消與狀態 |
| Payment | 付款請求、回呼、退款與日結 |
| Inventory | 原料、餐點可售量與門市調撥 |
| Kitchen | 廚房單、製作佇列與出餐狀態 |
| Member | 會員、等級、點數與消費紀錄 |
| Delivery | 外送平台訂單與配送狀態 |
| Reporting | 營運、財務與活動報表 |
這些模組雖然在程式碼裡有不同套件，卻被一起建置、一起部署，也直接讀寫同一套關聯式資料庫。報表工具、批次程式與部分外部整合還會繞過應用程式，直接查詢或更新資料表。
目前的權限清單顯示，部分批次與報表帳號可以直接存取大量正式資料表。資料庫操作 紀錄保留了帳號與時間，卻沒有標示每次異動所屬的業務作業或負責單位。
flowchart LR
Channels["POS／App／官網／外送平台"] --> Monolith["OneFood 單體應用<br/>菜單、優惠、訂單、付款、庫存、廚房、會員、外送、報表"]
Monolith --> DB[("共用交易資料庫")]
Reports["報表與批次作業"] --> DB
Monolith --> Payment["金流服務商"]
Monolith --> Invoice["電子發票"]
Monolith --> ERP["ERP／物流"]
Monolith --> Messaging["簡訊／推播"]交付與營運方式
- 團隊依前端、後端、資料庫與維運分工，沒有端到端負責單一業務能力的團隊。
- 正式版平均每六週發布一次。部署需要兩小時維護時段，失敗時通常回復整個版本。
- 自動化測試以單元測試為主，跨模組回歸仍由 QA 手動執行，完整回歸約需五個工作天。
- 過去一年的變更紀錄顯示，一項優惠規則平均會改動六個模組。
- 正式環境只有主機、JVM 與資料庫監控，沒有跨通路、模組與外部服務的交易追蹤；近半年事故的平均復原時間約為 110 分鐘。
- 兩位資深工程師理解優惠、訂單、付款與庫存交錯的規則，大部分緊急變更都需要其中一人參與。
- ERP、電子發票、金流與外送平台仍是未來數年要保留的外部系統，不能假設它們會一起改造。
未來希望支援的業務情境
管理團隊沒有指定系統該怎麼實作，而是描述未來希望支援的業務情境：
- 開設新門市時，營運人員能在五個工作天內完成菜單、價格、權限與設備設定，不需要等待一次專屬的系統改版。
- 推出新品牌或新通路時，團隊可以沿用既有的會員、訂單與營運能力，同時保留新品牌自己的菜單、價格與活動規則。
- 加盟店開始營運時，加盟經營者只能查看自己門市的銷售與營運資料；總部仍能執行跨品牌管理，而非履約所需的會員個人資料不會提供給加盟店。
- 行銷推出大型活動時，系統能承受短時間內快速增加的訂單；即使部分功能發生異常，仍不會讓所有門市與通路一起停止服務。
- 顧客完成下單後，無論使用 POS、App、官網或外送平台，都能清楚知道訂單、付款與取餐進度，不必因畫面逾時而猜測是否要重新操作。
- 門市遇到異常時，店員能看見問題發生在哪一筆訂單、目前由誰處理，以及門市是否仍能繼續接單與出餐。
- 客服、營運與財務查詢交易時，可以看到一致且可追查的訂單歷程，不必再從多個畫面與試算表拼湊答案。
- 一般活動或規則需要調整時，改動不會牽連整套系統，團隊能在十個工作天內完成驗證並上線。
轉型期間的現實限制
- 42 家門市不能因轉型長時間停業，日常接單與出餐必須繼續。
- 42 家既有門市的 POS 前台軟體與設備至少還會使用三年，轉型期間仍須正常接單與出餐。
- ERP、電子發票、金流與外送平台不會配合好味同時改造。
- 資訊團隊只有 24 人，目前是兩個交付小組與一個平台／維運小組。
- 門市對系統延遲與狀態不一致的容忍度很低，不能把所有例外都丟給第一線人工判斷。
- 財務仍必須完成每日結帳，並說明訂單、付款、退款與發票之間的差異。
- 加盟經營者只能存取自己門市的資料；會員個人資料、付款資料與跨店營運資料仍由總部負責管理與稽核。