Menu Economics

一開始，我只是想知道一道套餐到底賺多少

餐廳談成本，很容易停在一個看起來很合理的數字。

售價多少、食材多少、成本率多少。

但真的開始往下拆，我很快就發現這個問題根本沒有那麼單純。

一個套餐裡有主餐、有選項、有附餐、有每週波動的菜價，還有整間公司的共同費用。不同價格又可能來自不同地方：歷史交易、詢價紀錄、人工確認，或供應商剛剛回覆的一句話。

所以真正的問題不是：

「這個套餐成本多少？」

而是：

「我現在拿來算這個套餐的每一個數字，到底算不算數？」

如果價格是舊的、單位不一樣、來源不明，或只是某一次臨時報價，那個看起來很精準的成本率，反而可能是最危險的東西。

成本模型只是中間層，不是終點

後來我把這件事拆成幾種不同的事實。

客人實際點了什麼，來自銷售與套餐選項。

一道餐真正用了什麼，來自 BOM 與配方。

共同費用、附餐、來客，來自財務與營運資料。

材料現在多少錢，則可能來自既有價格、歷史成交、詢價結果，或供應商最新回覆。

這些資料不能一股腦塞進公式裡。

它們要先回答幾個問題：

• 這個來源是誰？
• 什麼時候生效？
• 單位是不是同一個？
• 這個價格是正式事實、暫估，還是只能參考？
• 缺資料時，是不是應該停下來問人？

所以我越來越不把 Menu Economics 當成一張報表。

它比較像一層經濟事實整理器：先把現實世界裡不同來源、不同時間、不同可信度的資料整理到可以被拿來做決策。

「照舊」這兩個字，讓我發現真正難的是語意

做到供應商報價的閉環時，很多原本看起來理所當然的說法一下子全部出問題。

例如供應商說：

「照舊。」

人一看就懂。

但系統不知道。

「照舊」是沿用上週？沿用上一次？永久沿用？這次沒報價？還是這個品項根本不用問？

所以我開始把這些東西一條一條定義清楚。

「照舊」不能被理解成永久價格。

「缺貨」跟「沒有販售」不是同一件事。

少了單位、品項或價格，就追問；不要因為模型大概猜得到，就把猜測寫進成本。

這件事讓我發現，AI 能不能理解一句話其實不是最難的。

真正難的是：

公司有沒有先決定，這句話在流程裡到底代表什麼。

供應商對話不是 chatbot，而是取得新事實的入口

做到這裡，供應商 LINE 的角色也完全變了。

它不是拿來展示「AI 可以聊天」。

而是當系統發現自己缺了一個事實時，有一條路可以往現實世界問。

訊息進來，先保留原文。

再判斷品項、價格、單位是不是完整。

不完整就追問。

完整後才形成可以被保存的報價事實，再影響相關成本與後續判斷。

而真正會改變配方、接受替代方案、做採購決定的人，仍然是主管或 Owner。

這裡有一條我一直不想越過的線：

AI 可以幫忙取得事實、整理事實、比較事實，但不能因為它很會算，就順便取得決策權。

如果停在這裡，其實還只解了一半

做到成本與供應商報價之後，我開始看到下一個很自然的問題。

如果系統已經知道：

哪一個材料價格過期了、

哪一個品項成本正在上升、

哪一個套餐的經濟性正在惡化、

以及最近實際賣掉了多少，

那它為什麼只能停在「提醒主管」？

下一步真正值得做的，不是再加一張圖。

而是把這條資訊鏈一路接到採購決策。

我現在看到的全景比較像：

Menu Economics → 詢價 → 比價 → 議價 → 銷量推算採購建議 → LINE 店長確認 → 採購單 → 廠商接單 → 待驗收 → 實收 / 退貨 → 財務 / 會計 → 實際成本回流。

成本不是另外一套系統，採購也不是另外一座島。

它們本來就在回答同一件事：

公司現在掌握了哪些經濟事實，下一步應該做什麼。

詢、比、議不是同一件事

以前講「詢比議價」，很容易一口氣帶過去。

但真的要把流程做清楚，它們其實是三種完全不同的能力。

詢價：取得未知事實

系統先知道自己缺什麼。

哪個材料沒有可信價格、哪個價格已經太舊、哪個規格需要重新確認。

這時候才形成一個詢價需求。

不是「全部再問一次」，而是只問現在缺的事實。

比價：建立共同語言

供應商 A 報一箱，B 報一包，C 含稅，D 不含稅，規格、交期、有效日也不同。

如果這些東西沒有先被標準化，所謂「最低價」根本沒有意義。

比價真正的工作，是把不同人的回答轉成同一個可以比較的世界。

議價：把資訊變成籌碼

到了議價，看的就不應該只有這次誰比較便宜。

歷史成交價、採購量、替代材料、其他供應商、套餐成本影響、供應穩定性，全部都可能成為談判條件。

系統可以把這些資訊整理好。

但最後：

跟誰買、買多少、接受什麼條件，

仍然是人的責任。

採購建議不是看庫存，而是看銷量

這裡我反而不想做傳統的「庫存低於安全量就補貨」。

餐飲業帳面庫存跟現場實際數量很容易有落差。

切修、耗損、試吃、製程、盤點誤差，本來就會讓「系統裡還有多少」和「現場真的剩多少」不是同一件事。

如果把這個數字當成採購主依據，反而會讓模型看起來很精準，實際上一直追著誤差跑。

所以我的方向比較直接：

從銷量去推下一期需要多少。

系統依品號看實際銷售與使用節奏，算出建議採購量，再把建議直接推到店長 LINE。

店長看到的不是一個複雜後台，而是一個可以確認的採購建議。

確認之後，系統才按照已經決定好的供應商與條件建立採購單並送出去。

這裡保留人的地方也很明確：

系統負責算建議，店長負責確認這次現場到底要不要照這個量買。

整條鏈也不另外發明一套物料身份。

同一個品號一路從 BOM、採購單、待驗收單、退貨單走到會計。

店長按下確認之後，採購系統才真正開始

如果流程在「系統算出建議量」就結束，那其實還稱不上閉環。

下一步要把店長確認過的建議變成真正可以履約的採購單。

採購單裡要有品號、數量、價格、交期、收貨位置與其他條件。

單成立之後，不是再靠人把內容複製到 LINE。

系統直接 push 給對應廠商。

廠商可以在線上看到自己的採購單、確認接單，後續有數量、交期或供貨異常，也都沿著同一筆單據往回更新。

我想要的不是「多一個廠商後台」。

而是讓一句：

「這批幫我叫一下。」

最後真的變成一筆有狀態、有人負責、可以一路追到底的交易。

有採購單，也不代表公司真的收到正確的東西

採購很常在下單之後失去結構。

貨來了，誰收的？

實收多少？

規格對不對？

有沒有短缺？

品質有沒有問題？

哪一個差異是廠商造成，哪一個需要公司內部處理？

所以我想把人員驗收與物料驗收直接放進同一條鏈。

採購單下出去之後，直接轉成待驗收單。

貨到現場，不需要重新建一張資料；驗收人直接在原本的品號上改成實際收貨數量。

如果需要退貨，就另外開退貨單，回指原本的採購與驗收。

我不打算在這裡再做替代品、到貨價格差異這些額外判斷。對現場來說，最重要的是把「訂了多少、實際收了多少、退了多少、誰驗的」留清楚。

這樣採購單才會從「公司打算買什麼」，一路走到「公司實際收到了什麼」。

最後一段不是 Dashboard，是會計

真正讓這件事情閉起來的，是財務。

因為報價不是成本，採購單也不是成本。

甚至貨送到了，都還不是完整的財務事實。

最後要把：

採購單、

實際驗收、

退貨單、

發票或憑證、

應付金額，

接進會計。

會計端第一步就是把 PO、驗收、Invoice 對起來。

退貨也不能只留在現場；它要一起影響最後的應付與帳務。

到了這裡，系統才知道公司最後到底用多少錢買到了多少東西。

這個實際進貨成本再回到 Menu Economics。

下一輪看套餐成本、做比價、準備議價時，用的就不只是「上次有人報多少」，而是公司真正完成過的交易事實。

所以我現在真正想接起來的是：

商品 → 採購 → 廠商 → 驗收 → 會計 → 商品。

這不是五套系統。

它是同一個經濟閉環。

我想要的是一個閉環，不是一套更大的採購後台

如果只是把採購流程全部搬進一個新後台，我反而沒有太大興趣。

我真正想要的是：

當套餐成本出現異常，系統知道是哪一個材料造成。

如果價格不可信，它知道自己缺什麼。

需要時，形成詢價需求。

供應商回答後，整理成可以比較的事實。

再把歷史成交、採購量與成本影響整理成議價情報。

銷量則直接形成下一期採購建議。

店長確認後，採購單送到指定廠商；接單、待驗收、實收與退貨都沿著同一筆交易往下走。

最後 PO、驗收、Invoice 與退貨一起進會計，形成真正的實際進貨成本。

成本模型重新計算。

下一次再看到這道套餐時，它已經不是用昨天的報價在回答今天的問題。

這才是我真正想做的東西。

Code 反而是裡面最無趣的部分

這個專案做到後來，我反而越來越不在意它最後會有幾支 API、幾張表、幾個 Agent。

那些都只是實作。

真正困難的是先把這些問題回答清楚：

什麼叫可信的價格？

什麼情況一定要追問？

「照舊」在公司裡到底代表什麼？

比價要先把哪些東西標準化？

AI 可以把事情推到哪一步？

哪一步開始一定要有人承擔？

如果這些問題沒有先被處理好，再漂亮的 Dashboard、再聰明的模型，都只是在把模糊放大。

所以 Menu Economics 對我來說，最後已經不是「一套餐成本系統」。

它更像是一張正在長大的經濟營運網路。

從一道套餐開始。

一路走到公司跟誰買、怎麼下單、廠商怎麼履約、現場怎麼驗收、會計最後認了多少成本。

然後，再回到下一道套餐。