供應商打來電話，說這批料要晚 20 天。
採購員的動作是有固定順序的：先查這個料還夠幾天用，再看在製的單子有沒有它，然後問計畫哪些成品要停，最後翻客戶訂單看哪幾家的交期會砸。這四步走完，通常兩個小時過去了，中間還要打三四個電話——因為庫存、在製、客戶訂單分別躺在三個人的電腦裡。
Infor 在 11 月 12 日發布的材料裡，把這四步寫成了一條鏈路：Claude 順著那個延遲的零部件，穿過生產訂單、子件、成品，一路找到受影響的客戶交付；然後給出兩個選項，一個是按急需數量下加急採購單、原單保留覆蓋其餘需求，另一個是另找供應商或替代料。採購員看完，批准其中一條，交易以他本人的 M3 身份執行。
很多人把這條新聞讀成「Claude 能操作 ERP 了」。我覺得重點在別處：它先算出這張單會牽連誰，然後才允許動。
一、三條工作流，一個共同動作
Infor 與 Anthropic 的這次合作叫 Infor Industry AI for Claude，目前只對部分 Velocity Suite 客戶開放，公開的配置指南寫的是 M3。首批放出來的角色只有三個：生產計劃員、採購員、客服代表。這個克制值得注意——不是「全公司都能用」，是「三個崗位、三件事」。
| 角色 | 會問什麼 | 要先追的鏈條 | 允許改什麼 |
|---|---|---|---|
| 生產計畫員 | 哪些生產訂單有風險？是缺料、產能還是人手 | 已發料、可用庫存、在途採購能否趕上；換產能方案是否可行 | 重排生產訂單日期、創建計畫採購單 |
| 採購員 | 這家晚 20 天，會砸到哪些客戶 | 延遲件 → 生產訂單 → 子件 → 成品 → 客戶交付 | 下加急採購單（原單保留）、調整採購單 |
| 客服代表 | 客戶要提前，到底行不行 | 各倉成品庫存、已被佔用量、生產能否補上缺口 | 更新計畫訂單日期、重新分配庫存 |
三條工作流表面各不相同，底層是同一個動作：先把牽連關係攤開，再挑一條改動最小的路。客服那條最能說明問題——客戶要提前一天，倉庫裡確實有貨，但貨已經被另一張訂單佔了。系統要做的不是「有沒有貨」，而是「把貨挪過來會傷到誰」，然後把這個被傷到的訂單也擺到檯面上，讓客服當著客戶的面決定。
這是 ERP 智能體與聊天機器人的分界線。聊天機器人回答「有沒有貨」；ERP 智能體回答「有貨，但動了會影響 A 客戶週四的那一單，你要不要動」。前者的錯誤是一個數字，後者的錯誤是一串連鎖反應。
二、要設計的不是提示詞，是角色劇本
Infor 的架構分成兩半：一個走 MCP 的連接器，經 Infor ION API Gateway 把選定的 M3 交易暴露出來；一個依角色提供指令與看板的外掛。工具呼叫以登入使用者的身分執行，單一登入和既有角色權限決定這個人能看哪些記錄、能做哪些交易。
真正體現設計功力的是管理員那一層。管理員可以裁剪返回給 Claude 的欄位，可以逐個關掉交易工具；把會改記錄的工具省略或禁用，就等於配成了唯讀。寫權限打開時，每一次變更都要一次顯式批准。透過連接器執行的動作，記錄留在 Infor 裡面。
翻譯成實施語言，這四件事分別是：可裁的欄位、可關的工具、必過的確認、可查的紀錄。四件湊齊，一個角色才敢放到生產環境裡。
這裡有個容易被跳過的問題：誰來寫這份角色劇本？不是 IT，是業務。計畫員每天要回答的三個問題、採購員判斷替代料的四條經驗、客服承諾交期時的兩條底線——這些東西不在任何一份需求文件裡，只存在人的習慣裡。把它們寫出來，比調模型難得多，也值錢得多。
能改多少，取決於能算清多少。一個算不清影響面的智慧體，給它寫權限就是在放大事故範圍。
三、這次發布裡沒有數字
翻遍 Infor 的公告，找不到一個效果數字。Oldcastle APG 的副總裁 Jessica Vincent 的表態停在「可以讓員工更容易找到相關業務數據，同時滿足公司的治理要求」。公告裡也明確寫了，沒有這家客戶部署後的實測結果。三條工作流的公開演示排在 12 月 3 日。
這不是黑點，反而是這個階段該有的樣子。2026 年下半年，ERP 廠商的智能體大面積從「預覽」走向「部分客戶可用」，能拿出實測數字的很少，原因也簡單：真正跑起來的樣本還不夠多，跑夠三個月能算帳的更少。凡是發布會上直接給出「效率提升 40%」的，基本都能追到一次內部試點或者一個精心挑選的場景。
對甲方來說，這意味著盡調方式要換。不要問「效果怎麼樣」，要問三件事：這個動作在哪個介面裡被批准、批准頁上顯示哪些欄位、批准之後系統裡留下什麼紀錄。這三個問題答不上來的供應商，功能演示再順也別急著簽。
四、回到 Odoo：影響面其實是查得出來的
Odoo 裡沒有叫「影響面」的按鈕，但支撐它的資料結構是現成的。做製造業實施的人對這幾條鏈路不陌生：
- 上下游追溯：
stock.move上有move_orig_ids與move_dest_ids，一層層串起來就是「這張採購單 → 這道工序 → 這個成品 → 這張銷售單」的完整鏈條。委外業務裡，組件發到分包商庫位的那一段也在這條鏈上。 - 供需缺口：產品的預測報表（Forecasted）將在手、在途、已分配、待出一次攤開，比「庫存數量」這一個欄位有用得多。
- 日期聯動：確認銷售訂單時，Odoo 會按路線產生採購或生產建議，計畫日期隨之前後移動。改一個日期，動的是整條鏈上的多個日期。
- 留痕：在欄位上開啟
tracking=True，每次變更都會寫進 chatter，誰改的、改前改後是什麼，都查得到。
所以給 Odoo 加一個「影響面查詢」的能力，不需要重寫 ERP，需要的是三樣東西按順序搭起來：
| 層次 | 智能體能做什麼 | 必須留給人的動作 |
|---|---|---|
| 只讀 | 按訂單號、客戶、物料查上下游鏈路，輸出受影響的單據清單 | 判斷這份清單是否完整（有沒有漏掉不走系統的部分） |
| 起草 | 生成加急採購單草稿、重排建議，列出改動前後的差異 | 逐條看差異，尤其是數量和日期 |
| 執行 | 直接確認單據、改承諾日期、調動已分配庫存 | 每一次都要點確認，並留下批准人 |
第三層是最容易出事的地方，因為它看起來最省事。一個直接呼叫確認動作的智慧型代理，出錯時不會報錯，只會安靜地把庫存佔了、把交期改了，然後在一週後的客戶投訴裡被發現。Infor 的處理方式是「逐筆顯式批准」，這個做法不新鮮，但值得照抄：把確認鍵做成智慧型代理流程裡唯一不能自動化的部分。
五、三條可以在下週就做的事
第一，把「影響面查詢」當成第一個交付物，而不是最後一個。先讓智能體只會查、只會列出受影響的單據，跑兩週，讓業務同事挑錯。挑出來的錯，就是後面寫角色劇本的素材。
第二，給每個角色寫一張三欄的表：會問什麼、要追什麼、允許改什麼。第三欄留空的角色，先別上寫權限。這張表比任何一份 AI 規劃都更能約束專案範圍。
第三，把批准頁當成產品來做。批准頁上要能看到：改的是哪張單、改前改後差在哪、會牽連哪些單、上一次類似改動是誰批的。四行資訊，決定這個人敢不敢點。
回到開頭那個電話。真正讓人頭疼的從來不是「料晚了 20 天」這個事實，而是這個事實要在四個系統、三個人之間傳遞兩小時，還沒人敢保證傳全了。智能體在這裡的價值，不是替採購員做決定，是把那兩小時裡該看的東西一次擺齊，讓決定在十分鐘內做出，並且事後能說清是誰做的。
至於它能不能改單，那是後面的事。先讓它學會算牽連。
資訊來源：ERP News（2026-11-12，Infor 與 Anthropic 合作公告及 M3 配置指南整理）、Infor 官方發布材料。文中涉及 Odoo 的技術說明基於公開文件與實施經驗，具體實現依版本與業務配置而定。
廣州眾諦信息 · 企業數字化觀察 · 2026-11-13
