用ChatGPT預測IT備品庫存水準

簡而言之： 把十二個月的出庫紀錄連同日期、據點、料號一起匯出，補上供應商實際到貨週期和每個料件的關鍵性分級，然後讓ChatGPT執行程式碼來算再訂購點，而不是用文字估一個出來。一個下午就能拿到分據點、站得住腳的再訂購點。但它不會對「你還沒遇過的那次故障」發出任何預警。

備品庫存是那種人人都靠記憶解決的問題。現場工程師知道分公司特別耗電源模組；維運經理記得上次檳城有台交換器壞了、換新花了三週。兩個人合起來維持著一套管用的心智模型——直到那個人休假、或者資產規模翻倍、或者財務問起為什麼有幾百萬的東西躺在貨架上。

能取代這套心智模型的算術並不難，就是任何一本營運教科書都會講的標準庫存數學。真正卡住團隊的是：資料躺在從沒有人彙總過的出庫匯出裡，而這套計算要按料件、按據點重複做一遍——這恰恰是那種永遠排不進本週優先順序的瑣碎活。

這是ChatGPT的一個好用途，但有一個關鍵前提決定了產出到底值不值錢——下面會講。

備品庫存出問題的兩種方式

它們的方向相反，這正是直覺處理不好它們的原因。

沉澱的資本。 為一個你已經不再服務的資產規模買的備品、已經淘汰的型號、或者某個糟糕月份之後恐慌性下的單。它在損益表上看不見，在盤點時一目了然：整架整架十八個月沒動過的元件，其中一些原廠已經不再支援了。

你恰好沒有的那個件。 一個分公司癱了，替換件在四天快遞之外，而你賣出去的SLA是次工作日到場。這是昂貴的那一種失敗——不是因為件本身貴，而是因為停機對客戶的代價，以及它對你信譽的代價。

團隊總會朝著「最近哪一種更痛」的方向過度修正。一次嚴重缺件，會帶來接下來一整年的超量採購；一次盤點沖銷，會讓庫存一直吃緊到下一次停機。做這套算術的意義不在於精確本身——而在於讓這個鐘擺停下來。

該餵給模型什麼——以及它到底在算什麼

你實際需要哪些資料？

比多數人以為的要少，但形狀必須對。

按料件、按據點、帶日期的消耗歷史。 至少十二個月，因為季節性和據點間差異在更短的視窗裡是看不見的。資料來源就是你的出庫紀錄——每一次為某張工單或某個任務領用備品。數量和日期要緊，工單內文不要緊。

每個料件的供應商到貨週期。 不是型錄上的數字，而是你實際觀測到的、從下單到件真的躺上貨架的時間，如果你在亞洲跨境調件，還要包含清關。這是整件事裡最少被記錄的一個數字，也是最能改變答案的那個。

每個料件的關鍵性分級。 兩到三級就夠。一個壞了會讓據點停擺的件，需要的服務水準和一個外觀件不同；沒有這個分級，模型會把筆電充電器和核心交換器電源當成同一個問題。

據點脈絡。 有哪些據點、每個據點大致多少裝置、以及某個據點能否由附近的中心倉在SLA內涵蓋。集中存放的件可以涵蓋多個據點；要求四小時內到場的件不行。

輸入就這些。值得注意的是裡面沒有：客戶名稱、工單描述、工程師姓名、價格。把它們去掉——它們增加風險，對計算毫無貢獻。

為什麼「讓ChatGPT給個再訂購點」是統計問題，不是提示詞技巧

下面這個前提，決定了後面一切的品質。

再訂購點等於「到貨週期內的平均需求」，加上「按需求波動性和你想守住的服務水準確定的安全庫存」。這是算術——而一個被要求用文字估它的語言模型，會產出一個看起來很像樣、但並非任何計算結果的數字。它會「大致正確」到足以危險的程度。

解法是讓模型去寫程式並執行，而不是憑自己的印象作答。把CSV傳上去，要求它按料件、按據點計算：到貨週期視窗內的平均需求、該需求的標準差、給定服務水準下的安全庫存、由此得到的再訂購點，以及建議訂購量。要求它輸出中間數值而不只是結論，並說明它對你的資料做了哪些假設。

由此帶來兩件事，兩件都要緊。你能核對過程——中間欄位讓一個稱職的人可以確認這套數學是真的算出來的，而不是敘述出來的。以及你能改一個假設、幾秒內重跑，而真正的洞見就在這裡：看著目標服務水準從95%移到99%時你的庫存金額如何變化，比任何單一的推薦數字都更有用。

模型在算術之外真正體現價值的地方，是圍著它的那些雜事：讀懂你格式不一的料件描述並把等價件歸組、發現某個據點三月份消耗翻了三倍、標出那些歷史資料太少、算出來也沒有意義的料件。

一個實際例子——十二個月出庫資料變成分據點的再訂購點

一家MSP用一個中心倉加兩個區域中心倉，維護著三個國家、22個據點的硬體。出庫匯出大約4000列：日期、據點、料號、數量、工單號。到貨週期由採購單獨提供一張表，服務經理用一個下午把料件打上三個關鍵性等級。

第一輪是診斷性的，不是處方性的。 按料件看消耗，會呈現出熟悉的形狀：少數料件貢獻了大部分動銷，而一條長尾裡的料件一年只動過一兩次。長尾才是有用的發現——對這些料件而言，任何預測都沒有意義，決策是一個政策問題（備一件當保險，還是接受那個到貨週期），而不是一個計算問題。

再訂購點這一輪只涵蓋真正在動的料件。 對每一個：它自己到貨週期內的平均需求、波動性、按其等級服務水準的安全庫存、再訂購點、訂購量。通常有兩個結果會讓人意外：動得快的便宜件需要的緩衝比預期少，因為它們的需求很穩定；而個別動得慢的關鍵件需要的更多，因為長到貨週期會把哪怕不大的波動也放大。

分據點看，會改變總量。 把22個據點的需求加總起來，數字看著挺舒服；一拆開，圖景就變了，因為集中存放的件滿足不了一天路程之外那個據點的四小時SLA。真正重要的產出不是「每個料件一個再訂購點」，而是「每個料件放在哪裡」的決定——而那個決定取決於你的服務承諾，不是你的消耗資料。

最後用庫存金額對比收尾。 目前持有 vs 模型建議持有，按等級看。現實的結果不是一筆戲劇性的節省，而是一次再分配：從被過度緩衝的快動件裡抽出資本，投到那幾個一直被悄悄涵蓋不足的關鍵件上。

AI輔助預測 vs 庫存管理系統 vs 工程師直覺

多快能拿到一個站得住腳的數字 — AI輔助預測勝出。一個下午，對上一次系統導入，而且不需要引入任何新工具。
處理格式不一的料件描述和雜亂匯出 — AI輔助預測明顯勝出。把「PSU 650W」、「650w電源」和一個料號歸成同一個品項，正是它擅長的。
解釋一個數字為什麼是這個數 — AI輔助預測勝出，前提是你讓它把過程攤開。直覺沒法向財務長解釋自己，而多數系統只會顯示一個門檻值。
知道資料裡沒有的東西 — 工程師直覺勝出，而且這不是一個小類別：某個據點即將擴張、某個型號快到生命週期終點、某個供應商其實一直不太可靠。
讓庫存日常保持準確 — 一套庫存管理系統完勝。預測設定的是門檻值；系統追蹤的是餘額與門檻的關係，並在你跨過去時告訴你。
不用靠人記著就能對結論採取行動 — 系統勝出。與庫存異動掛鉤的自動低庫存告警，才是把一個算出來的再訂購點變成一張真的下出去的訂單的機制。

誠實的建議是把兩者結合：用預測來定門檻，然後把這些門檻放進一個持續盯著庫存水準的東西裡。躺在表格裡的再訂購點，是一個沒人會去看的數字。

預測會在哪裡失效

四個地方，而知道它們，幾乎就等於會用這套方法了。

沒有歷史的料件。 新硬體沒有消耗紀錄，算術無從下手。用原廠的故障率指引和它所取代型號的表現來做參考，並把這些數字明確標註為估計值，而不是讓它們和算出來的數字並排躺在同一欄裡。

接近生命週期終點的料件。 一個你正在退役的平台上的料件，需求會下降——但可取得性下降得更快，而「最後一次採購」的決定，是關於退役排程的判斷，不是一次預測。

存在一個主導據點。 如果單一大據點貢獻了大部分消耗，那麼加總的統計量描述的只是那個據點，別的什麼都不是。把它單獨建模。

一個壞批次。 一次韌體缺陷或一批瑕疵品會製造出一個需求尖峰，而那不是規律。把它留在歷史裡，它會抬高之後每一次的推薦值。要求它把離群值辨識出來，然後有意識地決定要不要剔除——這是一個判斷，而且應該是一個自覺做出的判斷。

把這件事做對——營運資料、供應商條款，以及什麼時候該讓IT介入

三點實務問題。

清楚匯出裡都有什麼。 出庫紀錄通常帶著工單號，而工單號可能牽出客戶名稱、據點地址，偶爾還有終端使用者姓名。做預測你只需要日期、料號、數量和一個據點識別碼。在檔案離開你的環境之前把其餘的都剝掉，使用商業版或企業版，並核對該層級目前的資料處理與訓練條款，而不是想當然——消費者層級通常不同，條款也會變。

供應商條款是商業敏感資訊。 到貨週期和起訂量隱含著你談下來的地位。揭露它並非災難，但值得有意識地做決定，而不是看都不看就把採購表貼進去。用一個供應商代碼取代供應商名稱，你什麼也沒損失。

預測是小的那一半。 把庫存放在對的地方、在中心倉之間調撥、把工程師實際消耗的和領出去的對上、並在告警變成停機之前把單下出去，才是營運上的工作——而這正是我們的AI+支援服務和託管IT支援所承擔的。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室。當這件事作為一項託管服務來運行、而不是作為一份你自己反覆做的分析時是什麼樣子，我們在亞洲備品管理與硬體維護那篇裡講過。