製造業老系統怎麼接 AI：不換 ERP，先從報表和工單開始

製造業談 AI，最容易卡在一句話上：

“我們的系統太老了。”

ERP 跑了十年，MES 是幾年前外包做的，倉庫系統和裝置臺賬各管各的，生產報表還在 Excel 裡拼。你想接 AI，供應商往往會說：先上新平臺，先做資料中臺，先把系統 重構一遍。

聽起來正確，落地很重。

對大多數製造企業來說，真正可行的第一步不是換 ERP，也不是重做 MES，而是選兩個 最容易見效的入口：

報表和工單。

為什麼製造業更難“直接上 AI”

製造企業的資訊系統通常有三個特點。

第一，系統多。

銷售訂單在 ERP，生產計劃在 MES，庫存和出入庫在 WMS，裝置維修在工單系統，質檢 資料可能在 Excel 或獨立工具裡。一個問題的答案，經常要跨三四個系統。

第二，系統老。

很多系統是多年以前按當時流程定製的。能跑，但沒人敢大改。介面不完整，欄位命名 混亂，文件早就過期。

第三，流程重。

製造業的每一步都牽涉真實成本：停線、返工、庫存積壓、交期延誤、裝置故障、質量 異常。AI 不能像個人工具那樣隨便試錯。

所以製造業接 AI，不能一開始就追求“全自動智慧工廠”。那會太大，也太危險。

更好的路線是：先讓 AI 在現有資料上幫人看得更快、查得更準、提醒得更及時。

第一個入口：報表，不是為了更好看，而是為了更快問問題

很多製造企業每天都在做報表：

• 訂單交付情況；
• 庫存週轉；
• 生產計劃達成率；
• 裝置停機時間；
• 不良率；
• 工單關閉率；
• 採購到貨異常。

這些報表通常有兩個問題。

第一，太慢。資料要匯出、清洗、合併、再做透視表。等報表出來，問題已經發生好幾天。

第二，只能回答固定問題。老闆問“為什麼這個客戶的訂單又延期了”，報表往往只能 顯示延期，卻不能順著訂單、庫存、生產和採購繼續追問。

AI 接入製造業報表的第一價值，不是生成漂亮圖表，而是讓管理者能自然語言追問：

“這周延期訂單主要卡在哪個環節？”

“哪些物料庫存低於安全線，但未來兩週有生產需求？”

“過去 30 天停機最多的裝置是哪幾臺，原因是什麼？”

“哪些供應商的到貨延遲正在影響生產計劃？”

這些問題不是簡單聊天。AI 需要在許可權之下查詢 ERP、MES、WMS 或工單資料，把結果 聚合起來，再給出解釋。

這一步可以完全只讀，不改任何生產系統，卻能立刻提升管理效率。

第二個入口：工單，因為它連線了現場問題和管理動作

製造業的工單非常適合做 AI 試點。

因為工單天然有結構：

• 誰提交；
• 哪臺裝置；
• 什麼問題；
• 嚴重程度；
• 當前狀態；
• 負責人；
• 處理記錄；
• 關閉原因；
• 是否影響生產。

AI 在工單上的第一批能力很實用：

• 自動總結裝置歷史故障；
• 識別重複發生的問題；
• 根據描述推薦故障分類；
• 找出超時未處理工單；
• 彙總某條產線的高頻異常；
• 幫主管生成維修週報；
• 從歷史記錄裡找相似案例。

這些能力不像“預測性維護”那麼遙遠。只要有工單資料，就能先做。

而且工單比 ERP 核心資料風險低。第一階段讓 AI 只讀工單、總結問題、提醒超時， 通常更容易通過內部審批。

第三步才是自動化，不要一開始就讓 AI 改生產系統

製造業最怕系統亂動。

所以 AI 接入時，自動化一定要分層：

第一層，只讀分析。

AI 查詢報表、總結工單、識別異常，不寫入系統。

第二層，建議動作。

AI 建議升級某個工單、提醒某個負責人、關注某個供應商，但需要人確認。

第三層，低風險自動化。

例如裝置故障工單超過 4 小時未響應，自動提醒主管；同類問題 7 天內重複出現 3 次， 自動標記為復發風險；備件庫存低於閾值，自動生成採購建議。

第四層，高風險審批。

涉及生產計劃調整、採購下單、庫存鎖定、客戶交期承諾、裝置停機等動作，必須有人 確認和審計。

這條路徑聽起來保守，但它更適合製造業。現場系統不是演示環境，穩比炫重要。

不換 ERP，怎麼讓 AI 讀懂 ERP？

很多人以為接 AI 必須先換系統。其實不一定。

更輕的做法是：連線現有 ERP 或資料庫，把關鍵資料建模成 AI 能理解的物件。

比如先建這些物件：

• 銷售訂單；
• 生產訂單；
• 物料；
• 庫存；
• 採購訂單；
• 供應商；
• 裝置；
• 工單；
• 質檢記錄。

物件建好以後，AI 不需要直接面對一堆表名和欄位名。它看到的是“訂單、物料、庫存、 工單、裝置”這些業務概念，以及它們之間的關係。

同時，許可權也要跟上：

• 車間主管只能看本車間；
• 採購只能看供應商和採購資料；
• 銷售不能看敏感成本欄位；
• 老闆可以看彙總；
• AI 不能越過使用者本人的許可權。

這一步做好，AI 才能進入真實製造業務，而不是停留在檔案問答和報表截圖分析。

一個務實的 30 天試點

如果一家制造企業想 30 天內驗證 AI 價值，可以這樣做：

第 1 周：選場景。

不要全廠鋪開。選一個報表場景和一個工單場景。例如“延期訂單分析”和“裝置維修 工單總結”。

第 2 周：連線資料。

連線 ERP/MES/WMS/工單系統中的必要表或 API。只讀連線即可。

第 3 周：建模物件。

把訂單、物料、庫存、裝置、工單這些物件建出來，補上欄位含義、關係和許可權。

第 4 周：上線只讀 AI 助手。

讓管理者用自然語言問報表，讓裝置主管查詢工單和歷史故障。先不寫入生產系統。

如果第一個月能減少報表整理時間、縮短異常定位時間、讓主管更早發現問題，這個 試點就已經有價值。

之後再討論自動提醒、自動升級、自動生成任務，而不是一開始就把目標定成“AI 自動 排產”。

製造業 AI 落地的關鍵，不是模型，而是邊界

製造企業最需要的不是一個會說漂亮話的 AI。

它需要的是一個知道自己能看什麼、不能看什麼，能查哪些資料、不能改哪些資料， 每一步都有審計的 AI。

所以製造業接 AI，有幾條底線：

• 資料先只讀；
• 許可權繼承現有系統；
• 高風險動作必須確認；
• 關鍵操作必須審計；
• 不要求業務系統一次性遷移；
• 從報表和工單切入，而不是從核心交易寫入開始。

這條路線不花哨，但更容易落地。

ObjectOS 的做法：給老系統加一層 AI 能讀懂的業務結構

ObjectOS 的目標不是讓製造企業推倒重來。

ERP、MES、WMS、工單系統都已經在跑，裡面有真實業務和多年資料。更務實的方式，是 把這些系統連線起來，把關鍵表和 API 建模成物件，再讓 AI 在許可權之下查詢、分析、 建議和觸發低風險流程。

這相當於給老系統加了一層 AI 能讀懂的業務結構。

老系統繼續跑，資料不搬家，AI 先從報表和工單開始，逐步進入生產、供應鏈和裝置 管理。

製造業的 AI 不必從宏大的“智慧工廠”開始。

它可以從一個很具體的問題開始：

“這周哪些訂單會延期，原因是什麼？”

再從另一個問題繼續：

“哪些裝置故障正在重複發生，應該先處理哪幾個？”

能把這些問題答好，AI 就已經開始進入業務現場了。