四種語言、一張工單、五份紀錄

重點： 一家日本製造企業的新加坡區域辦公室，要支撐另外四個東協國家的團隊。工單用英語、日語、泰語和印尼語提交，而報給東京總部的月報必須是日語。這個辦公室一直靠善意，以及一位如今已成為單點故障的雙語行政同事撐著。解法不是再招幾個多語人才，而是：一套紀錄、一個系統、一種被明確定義的紀錄語言。

製造出這個問題的結構：把新加坡當作東協區域辦公室

相當多日本總部的製造企業，是透過新加坡區域辦公室來營運東南亞業務的。理由都說得通，而且多半是商業上的：區域財務職能設在這裡，資金與法人架構在這裡最清晰，區域業務主管可以駐在這裡，而外派的日籍管理者在這裡不必面對本區域其他外派地的語言與子女就學摩擦。區域辦公室協調著馬來西亞、泰國、越南、印尼、往往還有菲律賓的工廠、業務團隊和經銷商。

從 IT 角度看，這個結構有意思的地方在於：它是一個協調實體，而不是一個總部。它對區域有權限，但對總部沒有；它對區域負責任，卻未必對每個國家有預算權。它向上回報給東京，橫向對接各廠區主管，向下管理各國團隊——而這三個方向，用的是不同的語言。

總部很少看得見這一層。從東京看過去，畫面很簡單：新加坡有一個區域辦公室，它有一套 IT 安排，月報準時到達。月報傳達不出來的，是產出這份月報所耗費的人力，也傳達不出來這套「IT 安排」其實是五套安排、五家廠商、五種工單格式和五組彼此不同的假設。

這是一個結構問題，不是人的問題，這一點值得說準確。這個情境裡沒有人做得不好。區域 IT 經理是稱職的。各國廠商單看也都過得去。新加坡那位雙語行政同事把整件事撐住了，而且撐得不錯。真正的失效模式在於：這個結構沒有單一紀錄，也沒有一種被定義好的、承載這份紀錄的語言——下面每一個問題，都是從這兩項缺失裡長出來的。

情境：新加坡的 75 個人，和他們背後的四個國家

來看一個說明性的複合情境——不是某個具名客戶，而是從這一細分市場反覆出現的專案型態裡提煉出來的模式。一家在東京上市的日本精密製造企業，透過一個約 75 人的新加坡區域辦公室營運東協業務：區域業務、應用工程、一個小型的財務與人資職能，以及一支常年在路上的區域品保團隊。

新加坡背後是四個更小的國家團隊。吉隆坡約二十人，主要是業務和服務工程師。曼谷十五人，掛靠著一段經銷商關係和一個小型服務據點。胡志明市十二人，成長很快，是最新設立的實體。雅加達十八人，含倉儲職能。這些辦公室都沒有專職 IT。每一個都有一家在地廠商，在不同時間、按不同條款、由當時管著那個國家的人各自談下來的。

真正讓語言問題變得棘手的，是人員組成。日籍外派管理者坐在區域辦公室的頂端，也坐在其中一兩個國家辦公室裡。新加坡員工用英語工作，非正式場合常用華語。馬來西亞員工用英語和馬來語。泰國員工壓倒性地用泰語——這是「大家都會英語」這個假設崩得最厲害的國家。越南員工用越南語，英語程度因職務和世代差別很大。印尼員工用印尼語和英語。

然後是回報線。東京要求每月一份日語 IT 報告。不是附在英文簡報後面的翻譯摘要，而是一份用日語寫的、使用總部慣用詞彙、達到總部習慣的細節程度的報告。新加坡辦公室裡沒有任何人的職務說明裡寫著這件事。它由那位雙語行政同事在每個月月底，從五個來源手工拼出來的試算表裡做出來。

這個結構真正製造出來的問題

• 工單品質在受理環節就垮掉了。 當提單人在時間壓力下用第二語言描述問題時，描述品質會下降。「登不進去」可以是密碼忘了、帳號過期、授權沒續、條件式存取政策擋掉、MFA 裝置換過了，也可以是網路鏈路斷了。用母語描述時，這個區別通常在第一句話裡就說清楚了；用第二語言時不會——於是故障處理的第一個小時花在弄清楚到底發生了什麼，而不是修它。把這個乘以四個國家，它就是壓在每一張工單上的一筆固定稅。
• 升級到東京，需要一項沒有歸屬的翻譯工作。 當某件事需要總部關注時——預算核准、資安事件、影響全球範本的系統變更——必須有人寫一份日語摘要。這項工作沒有掛在任何人名下。它落到「誰有空且能做」的人頭上，而實務上這意味著每次都是同一個人。
• SLA 時鐘跨三個時區和五套假日行事曆。 日本、新加坡和中南半島時間只差一兩個小時，這讓時區問題看起來微不足道，也因此掩蓋了真正的問題：國定假日行事曆完全不同。泰國的節日、馬來西亞各州的節日、印尼的國定假日、越南的春節、日本的黃金週和盂蘭盆節，還有新加坡自己的行事曆。如果各方對「哪些小時算數」沒有共識，四小時回應承諾就沒有意義。
• 五家廠商就意味著五份紀錄，以及沒有區域檢視。 每家國別廠商都有自己的工單系統、自己的嚴重等級定義、自己對「已解決」的理解，以及自己的報告格式。要回答「上一季整個區域提了多少次密碼重設」，就必須有人做手工作業。同樣，也沒有辦法看出同一個反覆出現的故障已經在三個國家出現過，因為沒有人在同時看這三份紀錄。
• 月報是手工拼出來的。 五份匯出、一張試算表、一個人、每月兩天。這份報告的準確度，只能達到五個互不一致的來源所允許的程度；而且如果那個人不在，別人重現不出來。
• 單點故障是一個人，而且所有人都知道是誰。 那位雙語行政同事並不是 IT 專業人員。他／她把這件事接下來，是因為做得了，也因為總得有人做。如果他／她離職，區域 IT 職能不會平緩退化——它會直接停止產出東京實際在讀的那份東西。

博迅的觀點：翻譯是症狀，五份紀錄才是病

面對這種局面，直覺反應是按語言去招人：找一個會日語和泰語的，加一個懂印尼語的，再招一位雙語協調員把報告從行政同事手裡接過來。這個反應可以理解，但它不管用，理由值得直說：語言問題是紀錄問題的下游。

如果五家廠商維護著五套彼此獨立的工單系統，那麼再強的語言能力也變不出一個區域檢視。你招來的那位多語人才，會變成一名坐在五套互不相容的資料集之間、成本相當高的翻譯；等他休假，問題原樣回來。你只是讓那個單點故障變得更熟練了，並沒有讓它不再是單點。

真正能改變結果的兩件事，都是結構性的。

跨五個國家的一套工單紀錄系統，且無論工單是用哪種語言提交的，紀錄都是完整的。 母語受理極其重要——它正是避免上面那種工單品質崩塌的手段——但它的目的是產出一份好紀錄，而不是它本身就是目的。一張用泰語提交的工單，最終應該落進同一個系統，帶著與新加坡那張英文工單相同的嚴重等級分類法、相同的歸類方式、相同的處理欄位。這樣一來，區域檢視就變成一次查詢，而不是一個專案。

一種被定義的紀錄語言，和一種被定義的報告語言，各自有指定負責人。 這兩者通常不是同一種語言。紀錄可以是英語，而報給東京的報告是日語；這是一種正常且可運作的安排。不可運作的是兩者都不定義，於是紀錄漂移成「工單碰巧是用哪種語言來的就用哪種」，而報告由「覺得自己該負責的人」產出。把報告義務連同指定負責人和節奏一起寫進服務合約，整件事就不再依賴善意。

關於我們自己的涵蓋能力，與其誇大，不如說清楚。博迅的 7×24 全球服務台（GSD）從中國、香港和馬來西亞的分散式中心運作，每年處理約 15,000 起事件與服務請求，90% 的來電在 40 秒內接起，由 150 多名持有 70 多個領域認證的服務台人員支撐，提供華語、粵語和英語支援。日語支援透過博迅日本區域辦公室交付——這正是我們今天為一家日本總部精密製造企業在東京與大阪提供日英雙語受管 IT 的那套安排。東協各市場的在地語言支援在當地交付，這正是我們為一家區域金融集團在新加坡、吉隆坡和雅加達營運統一服務台的模式，該專案以一份可問責的 SLA 取代了三家各自為政的在地廠商。這就是它誠實的形態：一個有明確核心語言集的中央服務台，由當地能力和日本辦公室能力向外延伸，而所有這些都寫進同一份紀錄。

實際會發生什麼變化

• 一套紀錄系統，配合適合各國的受理方式。 使用者可以用自己習慣的語言，透過電話、郵件、網頁聊天或入口網站提單，最終落進一個分類法一致的系統。博迅的服務台可與 ServiceNow、SDP、Jira 及其他主流 ITSM 平台整合，所以如果總部已經指定了平台，區域服務台是寫進那個平台，而不是在它旁邊另起一套。
• 一種被定義並寫下來的紀錄語言。 通常是英語作為工單紀錄語言，因為它是全區域的公約數，而且總部讀得懂。重點不在於選了英語，而在於這是一個決定，不是一次意外。
• 被定義的報告語言、節奏和負責人。 月度 SLA 指標報告本來就是標準 ITIL 服務範圍的一部分。如果東京要讀的那份報告必須是日語，那它就是一項有負責人、有交付日期的交付物，而不是某位行政同事在每月最後一個週五做的人情。
• 把假日和時區行事曆做進涵蓋模型，而不是在故障時才發現。 哪些國家過哪些節、每個節日當天有什麼等級的涵蓋，以及當某一天在泰國是國定假日、在新加坡是正常上班日時，回應承諾到底怎麼算。我們那個區域金融服務專案之所以採用統一的 8×5×4H 承諾，正是因為另一種做法——五套各自的在地理解——根本沒辦法管理。
• 每個國家有指定的升級負責人，需要動手的地方有註冊在案的駐點工程師。 區域服務台可以遠端解決大部分事情，但雅加達倉庫裡壞掉的一台交換器需要有人到現場。博迅在涵蓋 19 個國家的版圖內維持註冊在案的現場派遣工程師，其中包括新加坡、馬來西亞、泰國、越南、印尼、菲律賓和日本，因此派遣屬於同一套安排的一部分，而不是另外打給某家廠商的電話。
• 第三方廠商協調被納入服務範圍。 當故障出在電信業者、房東的大樓網路或某個軟體廠商那裡時，追這件事是 ITIL 服務範圍裡明確包含的，而不是又退回給區域辦公室。這一點在五國結構裡比在任何別的地方都更重要，因為它恰恰是最消耗區域 IT 經理時間的那類工作。

三種區域 IT 支援做法，老實地對比

• 每個國家一家廠商。 受理時用在地語言、有在地關係、有人能很快到現場。代價是：五種工單格式、五套嚴重等級定義、五種報告風格、沒有區域檢視、無法跨市場辨識故障模式，還有一份必須手工拼出來的月報。它之所以成為預設安排，是因為它是一個國家一個國家累積起來的——沒有人是把它當作一種設計選出來的。
• 只用英語的區域服務台。 一個系統、一套分類法、一份報告、立刻具備區域可見度，而且營運成本比五家廠商低不少。代價是：受理環節的品質損失，且集中在英語最不普及的市場——在這個版圖裡，最明顯的就是泰國和越南。使用者會繞開一個他們覺得難用的服務台，一年之內，國家層級的影子 IT 安排就會重新冒出來。
• 多語言區域服務台（博迅模式）。 在承載主要工單量的語言上做母語或接近母語的受理、跨五國一套分類法一致的工單紀錄系統、一種被定義的紀錄語言、把總部語言報告作為有指定負責人的合約交付物、把假日與時區行事曆做進涵蓋承諾，以及在同一份協議下的當地派遣。代價是：它要求區域辦公室去做一些至今一直迴避的決定——紀錄語言是什麼、東京那份報告歸誰、各國假日當天回應承諾怎麼算——而且它是一段商務關係而不是五段小合約，有些總部需要被說服。

接下來該怎麼做

真正的診斷問題不是「我們需要支援多少種語言」，而是：如果寫東京報告的那個人明天辭職，別人能不能僅憑系統就做出下個月的報告？ 如果答案是不能，那麼問題出在紀錄上，不在語言上；再招一位雙語協調員只會把它往後推，而不是解決它。

博迅自 2007 年起在亞洲交付受管 IT，2021 年起總部設於新加坡，而且今天同時在跑這一模式的兩半——為一家日本總部精密製造企業提供日英雙語受管 IT，以及為一家跨新加坡、馬來西亞和印尼營運的區域集團提供帶當地派遣的統一多國服務台。你可以在受管 IT 支援頁面上看到方案結構和每一檔包含的內容，查看 7×24 多語言服務台和受管服務的細節，或者直接聯絡我們，聊聊你那五個國家現在到底是什麼狀況。

常見問題

你們的工程師真的會說日語、泰語和印尼語嗎？

誠實且具體的回答是：博迅的中央 7×24 全球服務台從中國、香港和馬來西亞的中心運作，工作語言是華語、粵語和英語。日語支援透過我們的日本區域辦公室提供——我們今天正是以這種方式，為一家日本總部製造企業在東京與大阪交付日英雙語受管 IT。東協各市場的在地語言支援在當地交付，我們跨新加坡、吉隆坡和雅加達營運的統一服務台就是這樣組織的。比起聲稱每種語言有多少名母語者，我們更願意把這個結構講清楚，因為決定你的使用者能不能用一種自己用得順的語言得到回應的，正是這個結構。

工單能不能用一種語言提交、用另一種語言回報？

可以，而且對一個五國區域辦公室來說，這通常是正確的設計，而不是一種妥協。受理用使用者工作時使用的語言，因為那才能產出對故障的準確描述。工單紀錄用單一的、被定義好的語言維護，這樣區域檢視才是一次查詢而不是一次手工作業。報給總部的報告用總部的語言產出，作為合約交付物。三種語言、三種用途，每一種都是有意選定的。

五個國家的國定假日你們怎麼處理？

在合約開始之前就把行事曆做進涵蓋承諾，而不是在故障發生時才發現。實務上這意味著：約定哪些國家過哪些節、每個節日當天有什麼等級的涵蓋，以及當某一天在一個市場是國定假日、在另一個市場是正常上班日時，回應承諾怎麼計量。這也是單一區域協議比五份在地協議更好營運的原因之一——假日這個問題被書面地回答一次，而不是被暗示著回答五次。

我們是不是每個國家都需要一家廠商？

你需要的是每個國家都有能力，而不是每個國家都有一段獨立的商務關係。這個區別很重要，因為在地關係通常不是問題所在——碎片化才是。博迅在涵蓋 19 個國家的版圖內維持註冊在案的現場派遣工程師，這個情境裡的五個市場全部在內，因此現場工作發生在同一份協議下、寫進同一個工單系統、對著同一份 SLA。這正是我們為一家區域金融集團做出的改變：用一份可問責的 SLA，取代了新加坡、馬來西亞和印尼的三家各自為政的在地廠商。

我們總部讀的那份報告由誰來寫？

在範圍劃分得當的安排下，由服務商來寫，用總部的語言，按約定節奏，作為一項有名有姓的交付物。月度 SLA 指標報告本來就是我們服務台服務的標準 ITIL 範圍的一部分。真正的變化不在於「有一份報告」——你們今天已經有了——而在於產出它這件事不再是一位熱心行政同事承擔的無歸屬任務，而變成有負責人、有交付日期、底層資料集一致的東西。

這和我們日本本部現有的內部 IT 怎麼配合？

它位於內部 IT 的下方，而不是旁邊。在這種型態的專案中，總部 IT 職能通常保留全球架構、資安政策、應用系統歸屬和廠商策略，而區域安排負責終端使用者支援、事件與問題管理、現場派遣以及區域報告。實務上的兩個整合點是：ITSM 平台——如果東京指定 ServiceNow、Jira 或 SDP，區域服務台就寫進那個執行個體；以及升級路徑——它需要在雙方各有一名指定負責人。把這兩點定好，這件事的建置工作就完成了大半。

相比五家在地廠商，區域涵蓋的成本如何？

按單項條目比，通常是現有安排看著更划算，因為五份小額在地合約單看都不貴，而隱性成本落在 IT 預算之外——落在每月花在拼報告上的那幾天、落在每張工單開頭因語言歧義損失掉的那些小時、落在區域 IT 經理追第三方廠商的時間裡。反映現實的比較應當把這些算進去。除此之外，價格取決於人數、涵蓋時段，以及各市場需要多少現場派遣；方案結構和每一檔包含的內容列在我們的受管 IT 支援頁面上，而一個劃定範圍的數字需要先聊清楚你們實際的國別分布。