用Gemini把IT工單積壓變成派工計畫

簡而言之： 把ManageEngine ServiceDesk Plus裡的未結工單匯出來，把工單內文連同你的SLA時限、據點清單和備品狀況一起給Gemini，讓它先把「遠端可解決」和「必須到場」分開，再把要到場的工作按路線聚成幾趟出車。它幾分鐘就能排出這一週的計畫。但它沒法把一名工程師變到二線城市那個分公司的附近去。

每一個多據點IT維運團隊都有同一個每週二重現的問題：四十來張未結工單，其中一部分需要有人到現場，而必須有一個人來決定這週誰去哪裡。這個決定是對著一張表格、憑著「哪幾個據點離得近」的記憶、再加上「哪個SLA最快要爆」的粗略感覺做出來的。

它做得不好——不是因為這個人不上心，而是因為這是一個小型組合最佳化問題，卻要由一個手上還壓著六件別的事的人在時間壓力下解掉。結果就是：工程師路過一個據點去另一個據點、兩週之內為同一棟樓跑兩趟，以及一張P2工單悄悄地拖老了，因為從頭到尾都沒人看出來它其實需要到場。

這件事很適合語言模型，因為難點大半在於讀懂非結構化的工單內文、把它變成一個結構化的判斷。而一如既往，真正難的那部分，不是排計畫。

為什麼現場出車總是湊得很差

三個原因，而且是結構性的，不是個人問題。

訊號埋在散文裡。 工單裡沒有任何一處會寫「需要到場」。它寫的是「印表機有摩擦異音」，或者「使用者說3號會議室的網路孔不通」。必須有人逐條讀、逐條推斷。而在時間壓力下，凡是看起來不那麼緊急的，這個推斷就被跳過了。

地理是靠記的，不是建模的。 排計畫的人記得住那些大據點，但對「哪兩個工業區的單元其實只隔十分鐘」就不那麼可靠了——而浪費掉的路程恰恰累積在這裡。

各個限制互相糾纏。 SLA時限、備品可得性、工程師技能、據點可進入時段、路途時間，這是五個限制；靠眼睛去最佳化，意味著只最佳化其中一個、其餘的聽天由命。而這一個幾乎總是「最快要爆的那個SLA」——這正是為什麼這套計畫從結構上就是被動的。

該自動化的兩個決定——需不需要到場，以及什麼時候去

把它們分開。它們失敗的方式不同，需要的輸入也不同。

從工單內文裡區分「遠端可解決」和「必須到場」

ServiceDesk Plus可以匯出未結工單清單——工單號、據點、分類、優先順序、建立時間、SLA到期時間，以及描述和處理紀錄。真正要緊的是描述，而它恰恰是任何篩選器都無從下手的部分。

把工單內文給Gemini，要求它對每一張工單給出三種輸出之一：遠端可解決、需要到場、資訊不足——外加一行理由和一個信心度。第三類才是讓這套方法真正可用的東西。一個被逼著二選一的模型，會在含糊的那些工單上猜；而含糊的那些，恰恰是猜錯要付出「白跑一趟」或「SLA爆掉」代價的地方。讓它能說出「描述裡沒寫這台裝置能不能開機」，然後把這條派給一通電話，而不是派一輛車。

有兩個改進值得花力氣。給它你自己的例子——二十張你已經分好類、並寫明理由的工單——因為你們這個資產規模的慣例，比任何關於IT支援的通用知識都更要緊。以及，要求它標出那些內文暗示著更大底層問題的工單：同一層樓來了四張關於網路斷線的工單，那是一次到場加一台交換器，而不是四次到場。這種跨整個積壓量的模式辨識，一個逐張讀工單的人類規劃者是很少會做的。

排出計畫——SLA時限、據點、備品、技能

現在換一組輸入。第二個決定幾乎不需要工單內文，而需要全部的營運脈絡：這些要到場的工單分別屬於哪些據點、據點之間的路途時間或距離、每張工單的SLA時限、所需備品是否有貨以及在哪裡、工程師的可用性與技能，還有據點的進入限制——比如某個資料中心要求提前48小時報備。

要求它給出一份建議排程：哪位工程師、按什麼順序去哪幾個據點、哪一天、每一趟能關掉哪些工單——以及至關重要的一項：哪些工單沒有被涵蓋，以及為什麼。這份未涵蓋清單才是最有價值的產出。它把「我們進度落後了」變成「這四張工單本週無法滿足，因為那個據點的可達範圍內沒有工程師」——這是一場帶著證據的人力對話，而不是一種感覺。

要求它寫出自己的假設，以及每一個決定是被哪個限制卡住的。「B據點排在週四，因為備品週三才到」是一份調度員可以去反駁的計畫；一張光禿禿的時間表不是。

一個實際例子——一週的積壓變成四趟出車

一個零售IT團隊支援著一個都會區加兩個鄰省的34家門市和兩個配送中心，手上有三名現場工程師。週一的積壓是46張未結工單。

分類這一輪把它們大致分成遠端可解決、需要到場、資訊不足三堆。遠端那一堆比團隊預想的要大，這是常見結果——好幾張被描述成硬體故障的工單其實是設定問題，只是當初根本沒有被好好分診過。資訊不足那一堆變成了服務台的一份外撥清單，其中約一半在電話裡就解決了，直接從出車計畫裡消失。

聚類這一輪處理剩下的。九家門市需要到場；其中三家彼此相距二十分鐘以內，而在上一週的計畫裡，它們是被分在三個不同的日子去的。模型提出四趟：兩趟單日多店路線、一趟卡著備品到貨的配送中心、以及一家路途較遠、值得單獨跑一趟的門市——因為那裡有兩張工單已經開了十一天。

未涵蓋清單是兩張工單，都在同一家偏遠門市，都不緊急，都標明了理由：本週沒有任何一條工程師路線能在不放棄一個更近的SLA的前提下抵達那個位置。這才是值得拿到的發現。它不是一次排班失敗——它是一個涵蓋事實，而且每隔幾週就會在同一家門市重現一次。

規劃者實際做的事是推翻其中大約五分之一。模型不知道某家店的店長在休假、某位工程師不該被派到之前有過客訴的據點、或者那個配送中心更希望上午十點前到訪。花十分鐘改一份草案，和花一小時從頭排一份計畫，是兩件不同的事。

AI輔助派工規劃 vs 現場服務管理軟體 vs 派工合作夥伴

讀懂非結構化工單內文、判斷要不要到場 — AI輔助規劃明顯勝出。這恰恰是FSM工具根本不去做、而人做得不一致的那部分。
不引入新系統就拿到一份可用計畫的速度 — AI輔助規劃勝出。一次匯出加一段提示詞，對上一個採購週期。
路線最佳化與即時調度機制 — FSM軟體勝出。專門做這件事的工具會做真正的最佳化、支援工程師行動端簽到、並在行程變動時重排。
讓計畫真的被執行 — FSM軟體勝出。躺在文件裡的計畫是一個建議；系統裡的計畫是一批帶狀態的已指派任務。
抵達一個你根本沒人的據點 — 派工合作夥伴勝出，而且沒有別的選項能競爭。排計畫變不出一個你在那座城市並不存在的工程師。
合約化的到場保證 — 派工合作夥伴勝出。4小時緊急或次工作日到場的SLA是有人為之背書的承諾；而計畫只是一個意圖。

有用的讀法是：AI輔助規劃以很低的成本解決了分診與併趟的問題，FSM軟體解決執行的問題，而兩者都不解決涵蓋的問題。多數感覺自己有「排班問題」的團隊，其實同時混著這三種問題，而搞清楚真正在花你錢的是哪一種，是值得的。

計畫假設成立、而現實不成立的地方

四個假設，而它們都會例行破裂。

假設這一天不會變。 早上九點來一張P1，整份計畫就得重寫。計畫真正的價值不在於它能扛住現實的衝擊，而在於讓重寫變得便宜——知道哪兩個任務受限最少，才讓你能在五分鐘內重排。

假設工單描述的就是問題本身。 使用者回報的是症狀。一張「螢幕不亮」最後查出來是擴充座壞了，那是另一個備品、另一種技能，很可能還是第二次到場。

假設有人進得去。 據點進入是現場IT裡最一貫被低估的限制——門禁審批、陪同人員、房東的貨梯預約、一個換班時段不放訪客進去的工廠現場。

假設備品在系統說的那個位置。 一份建立在「分部認為自己有貨」之上的計畫，是一份會在現場失敗的計畫，而工程師就站在那兒。對計畫所依賴的那些備品，請核實可得性，而不是相信那個數字。

把這件事做對——工單資料、據點進入，以及什麼時候該讓IT介入

在你匯出任何東西之前，有三點實務問題。

工單內文裡全是個人資料。 描述和處理紀錄裡帶著使用者姓名、聯絡電話、座位位置，偶爾還有業務資料的截圖。只匯出你需要的欄位——工單號、據點、分類、優先順序、日期、描述——並在檔案流向任何地方之前把姓名和聯絡方式去掉或做假名化。分類依據的是症狀，不是報修的人是誰。使用商業版或企業版，並核對你實際所在層級目前的資料處理與訓練條款，而不是想當然。

據點資訊本身是實體安全資訊。 一份帶著地址、可進入時段和具名聯絡人的客戶據點清單，本身就是一份值得保護的文件。在你上傳的檔案裡用據點代碼，把對照表留在本地。

計畫是容易的那一半。 讓每一個據點的可達範圍內都有一名帶著對的技能、對的備品的工程師，並且在一個能滿足你簽下的SLA的日子裡到場，才是難的那一半——而這正是現場IT派工所要解決的：按需工程師，以及涵蓋100多個國家的4小時或次工作日合約化到場。我們的AI+支援服務和託管IT支援分列在它的兩側。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室——包括那些自有涵蓋恰好用盡的二線城市據點。同樣「先把工單內文結構化」的套路，值得和從支援工單起草缺陷報告那篇對照著讀。