汽車零件供應鏈 AI:BOM 與供應商文件自動化、斷鏈預警落地劇本

上季我們進了一家 Tier-1 車用零件廠。它不缺系統,ERP、PLM、SRM 都上了,問題是每次車廠一句「這顆料換供應商、換料號」,採購和工程要花三到五天翻文件、對 BOM、追替代料。而汽車業一張整車 BOM 動輒上萬個零件,牽一髮動全身。

真正卡住的不是決策,是資料。決策的原料散在 PDF、Excel、掃描件、email 附件裡,沒人有時間把它們變成可查詢、可預警的結構化知識。這就是汽車供應鏈 AI 該切入的地方,不是取代採購,是把採購從搬運工變回判斷者。

先把 BOM 和供應商文件「讀」進系統

多層 BOM 是整套場景的地基。車用零件的 BOM 常是三到五層的樹狀結構:一個總成拆成子總成,再拆到原材料與電子料,每一層都掛著料號、用量、供應商、替代料、認證狀態。麻煩在於,這些資訊有一半不在 ERP 裡,而在供應商寄來的文件中。

我們實際處理的文件大致是這幾類,每一類的擷取重點都不同:

技術上這是一套 RAG 知識系統加擷取管線:文件進來先做版面解析與 OCR,把表格結構還原,再用模型把欄位對應到 BOM 主檔的 schema。這裡有個我們踩過的雷,別讓模型「自由發揮」去猜料號對應。車用料號格式各家不同,一個字元錯位就是錯料。我們的做法是讓 AI 擷取,但把料號、用量這種關鍵欄位強制走規則校驗與人工覆核,信心分數低於門檻就丟回人工佇列。Demo 裡跳過這步很漂亮,上線跳過這步會出事。

從擷取到「斷鏈預警」的那一段才是價值

把文件變成結構化 BOM,只是完成了一半。客戶真正要的是:當某個供應商出狀況,系統能在採購還沒收到正式通知前,先告訴他「哪幾台車、哪幾張訂單會受影響,替代方案是什麼」。

這需要把三張圖疊在一起。第一張是 BOM 的物料展開,知道每顆料往上追會影響哪些總成與車型。第二張是供應商關聯圖,一個料號背後可能有主供與備供,備供的認證狀態、產能、交期都在前面擷取的文件裡。第三張是外部訊號:交期變更 email、原物料價格、甚至某地區的物流中斷新聞。

我們用 Agentic 工作流把這條鏈接起來。舉一個真實觸發的例子:某天系統從一封供應商 email 裡讀到「A 料交期延後四週」,它自動沿 BOM 向上展開,算出影響到兩款正在量產的車型、本月三張生產訂單;接著查替代料主檔,發現 B 供應商有合格替代料,但 PPAP 認證三個月前過期。於是推播給採購的不是一句「A 料延後」,而是一張含影響範圍、替代選項、以及「認證需重新啟動」這個卡點的行動卡。採購當天就決策,不是一週後才發現產線要停。

before 是缺料通知靠人肉轉發、平均反應兩到三天;after 是關鍵訊號自動展開影響面、附替代建議,反應壓到數小時內。這中間省下的不是工時,是產線停機的錢。

落地劇本:別想一步到位

我們給車用客戶的導入順序通常是三步,每一步都要能單獨產生價值,否則撐不到下一步。

第一步只做 BOM 與供應商文件的擷取與查詢,目標是讓工程和採購「問一句話就查到料」,先把資料底盤打穩,並在這階段養出料號校驗的準確率。第二步接上影響展開,能回答「這顆料出事會影響什麼」,但先不自動決策,只做預警與影響分析,讓人核對系統判斷對不對。第三步才開放替代建議與部分自動化行動,而且一定保留人工簽核閘門,尤其牽涉認證與合約條款的環節。

這套順序背後是一個判斷:汽車供應鏈的錯誤成本太高,寧可慢一階,也不要為了 Demo 好看而讓系統在沒把握的地方自作主張。真正決定專案成敗的,往往不是模型多強,而是料號對得準不準、認證邏輯懂不懂、採購願不願意每天打開它。

這也是我們做事的方式:工程師直接進場,坐在採購和工程旁邊,把 BOM 主檔、供應商文件、認證規則一條一條對齊到能上線、有人真的每天在用,而不是交付一個漂亮的 Demo 就收工。系統上線且有人在用,這個場景才算真的落地。