新加坡 IT 支援服務：共享服務中心

簡短答案： 共享服務中心是一個處理型營運，不是一個商務辦公室。它的 IT 負荷由財務行事曆而不是人數驅動，它的使用者坐在新加坡、它的客戶卻坐在另外十個市場，而它的關鍵系統大多屬於別人。按「平均的一天」設計的支援，一定會在真正要緊的那幾天失靈。

一家歐洲生活風格零售集團的新加坡共享服務中心，其區域 IT 經理曾直白地對我們說：「每月十四號，沒有人的 IT 工單是緊急的。到了第二個工作日，每一張工單都緊急，而且每次都是同樣那四十個人。」

這句話幾乎包含了「共享服務中心的 IT 支援」為什麼不同於「同等規模的區域總部的 IT 支援」的全部原因——也解釋了為什麼一份完全合理的按使用者計費支援合約，可以在十一個月裡顯得夠用，在剩下的一個月裡顯得不夠用。

以下是一個具代表性的複合情境，不是某個具名客戶。它以下文所述的博迅真實專案工作為基礎，所提到的每一項服務機制都是博迅實際在做的事。文中沒有虛構任何價格數字、統計數據或客戶名稱。

共享服務中心的 IT 支援，究竟哪裡不一樣？

搜尋「新加坡 IT 支援服務」，你會看到一個基本上假設了同一種客戶型態的市場：員工在新加坡、做新加坡的業務、按新加坡的上班時間工作。區域總部、業務辦公室、基金、代理商、中小企業。這個假設被嵌進了支援的界定與定價方式的深處，深到通常沒人把它說出來。

共享服務中心在四個具體的地方打破了這個假設，而每一個都有明確的營運後果。

它的工作量是週期性的，不是穩定的。 商務辦公室的需求曲線相當平坦；處理中心有月結、季結和年結，而「安靜的星期二」和「當月第二個工作日」之間的差別不是邊際性的。

它的使用者在內部，客戶卻在外部——在別的國家。 當新加坡的應付帳款專員進不了某個系統時，感受到影響的是馬來西亞的一家供應商或泰國的一位店長。一個新加坡桌面問題的爆炸半徑涵蓋整個區域。

它的工作日在兩端都被拉長。 支援從日本到印度的市場，代表最早和最晚的那幾個小時不是邊緣狀況；相當一部分工作恰恰發生在那時。

它的關鍵系統大多不屬於自己。 ERP 是總部的。HR 系統是總部的。銀行入口網站屬於銀行，稅務入口網站屬於政府，市場專屬系統屬於各個市場。共享服務中心的 IT 團隊要為一整組它並不掌控的系統的可存取性負責。

這四件事沒有一件是罕見的。合起來，它們產生了一種標準界定對話不會浮現出來的支援樣貌——因為沒有人會問：「你們的行事曆長什麼樣？」

情境：新加坡的 110 個人，電話另一頭的十三個市場

設想一家歐洲生活風格零售集團的新加坡共享服務中心。大約 110 人，為十到十三個亞太市場承擔財務、人資行政、採購支援和商品營運。集團的商務總部在歐洲；門市從日本一直分布到澳洲；而新加坡的這棟樓，是交易真正被處理的地方。

財務是最大的職能——應付、應收、公司間對帳，還有一個小型控管團隊負責產出區域合併報表。人資行政處理跨市場的薪資輸入、到職文件和福利管理，而這些市場的規則確實各不相同。採購支援管理採購單與供應商主檔。商品營運維護區域的商品資料、定價和配貨。

他們的技術足跡並不出奇，也很典型：所有協作用 Microsoft 365，一套由歐洲總部擁有的 ERP 實例，一套集團 HR 系統，一個資料倉儲與報表層，幾個用於稅務和法定申報的市場專屬入口網站，每個市場各自的銀行入口網站，以及一個他們使用但不擁有的門市系統介接。

新加坡當地的 IT 人員是兩個人。其餘的一切——服務台、端點管理、網路、升級到集團歐洲 IT 部門——由一家外包服務商交付。

這個結構完全合理。它也有一個恰好在每月四五天裡現形的失效模式。

共享服務中心特有的四種失效模式

尖峰負荷由行事曆驅動，不由人數驅動

一份按 110 個使用者界定的 IT 支援合約，是按平均值界定的。但共享服務中心的需求並不在使用者之間、也不在日期之間平均分布。在當月第二、第三和第四個工作日，大約四十名財務人員正在同時做他們這個月裡風險最高、時間框最緊的工作，而且同時在敲打同一批系統。

一次密碼重設在十四號只是小小的困擾，在第二號卻是一起真正的營運事件，因為當事人有一個硬性的結帳期限，還有一排市場在等他。工單的技術嚴重度完全沒變。業務嚴重度則完全變了。

現實後果是：對這種樣貌來說，「平均回應時間」幾乎是一個沒有意義的指標。真正重要的是在那四天裡的回應時間——那幾天承載了不成比例的業務份量——而如果你的服務商不知道那是哪幾天，他們就無法為之排班。

你的使用者在內部，你的客戶卻是別的國家

在一般辦公室裡，IT 問題給遇到它的那個人帶來不便。在共享服務中心，新加坡的一個 IT 問題會以「另一個市場的服務失敗」的形式浮現。那位在等採購單核准的泰國店長，不知道也不在乎延遲來自新加坡的 VPN 問題；他知道的是自己的貨沒訂上。

這改變了「已解決」的意涵。關掉新加坡的工單不是事件的終點，因為下游有一個已經延誤的承諾，而總得有人去溝通。停在工單邊界上的支援，把更難的那一半工作留給了共享服務中心自己。

工作日在兩端被拉長，而且不是出於自願

支援全區域的市場，代表新加坡的共享服務中心實際上從清早就為其東側的市場開門，一直開到傍晚為其西側的市場服務。這不是一個 7×24 營運，買一個 7×24 也是浪費——但它同樣絕不是一個朝九晚六的營運，而大多數合約預設買的恰恰就是朝九晚六。

這些「縫隙時段」同時也是風險最高的時段，因為它們是本地涵蓋最薄的時段。早上七點半發生的問題——新加坡的 IT 人員還沒到，而日本和韓國市場已是上午過半——正是「跟隨日光服務台」存在的理由。博迅的 24×7 多語言服務台是一個以 ITIL 為基礎的全球服務台，由中國大陸、香港和馬來西亞的分散式中心營運，每年處理約 15,000 起 IT 事件與服務請求，擁有 150 多名持有 70 多個領域認證的服務台人員，90% 的來電在 40 秒內被接起。對共享服務中心而言，相關的屬性不是這些數量本身，而是「在本地團隊涵蓋不到的時段裡，一線回應是存在的」。

關鍵系統清單上大多是別人的系統

這是最常讓「把共享服務中心當一般辦公室來界定」的服務商吃驚的一種模式。問哪些系統是業務關鍵，答案是：集團 ERP，由歐洲管理。集團 HR 系統，同上。十個銀行入口網站，各有各的驗證和權杖機制。若干政府申報入口網站，各有各的憑證要求、瀏覽器敏感性和假日行事曆。還有幾個市場專屬應用，其供應商只說當地語言。

因此，共享服務中心的 IT 職能在「存取、整合與對接」這門生意裡的成分，遠大於在「系統管理」這門生意裡的成分。它的很大一部分工單不是「我們的系統壞了」，而是「我們進不去別人的系統，需要有人跨越組織邊界去推動這件事」。

只能修自己所管理之物的支援，大概只能解決共享服務中心實際提出的一半問題。針對第三方問題的供應商對接，必須是明確寫進服務範圍的一項，而不是一種人情。

博迅怎麼看待共享服務中心的支援

建模行事曆，而不是平均值

我們向一家共享服務中心索取的第一樣東西不是使用者數，而是一份行事曆：哪些天是結帳日、哪些週是發薪週、季末合併落在什麼時候、各市場的法定申報期限在哪一天，以及其中哪些是真的動不了的。

然後這份行事曆應當成為排班、變更排程與升級門檻的真實輸入。具體來說：結帳日不落任何基礎架構變更。修補視窗按這份行事曆規劃，而不是按一份通用維護計畫。並且允許優先順序定義隨行事曆移動，使得某一類例行工單在結帳期間被更緊急地對待。

這些在技術上都不難。它需要的是「知道」，而大多數服務商從來沒被告知過。

跑兩個時鐘：服務台時鐘與市場時鐘

共享服務中心的支援模式需要對兩套不同的時間明確表態。服務台時鐘是新加坡員工上班的時間。市場時鐘是每一個被支援的市場期待獲得服務的時間。它們並不相同，而兩者之間的縫隙正是事件變貴的地方。

有用的設計是分層的：新加坡工作日內的本地涵蓋，邊緣時段的跟隨日光一線，再加上一條成文規則，說明一線在那些時段可以獨立解決什麼、什麼必須等本地團隊。這是一個真正的區域營運模式，也是博迅新加坡樞紐存在的很大一部分原因——區域是以新加坡為樞紐來支援的，而不是把它當成眾多辦公室之一。

從同一門生意的門市端學到的東西

博迅與一家向亞洲擴張的歐洲生活風格零售集團的合作在這裡直接相關，因為那是同一種企業型態的另一面。那個專案的內容是統一門市 IT 並提供一個橫跨歐非中東與亞太時區的跟隨日光服務台，連接歐洲總部與大中華區的新零售門市——門市網路與 POS 連線部署、門市硬體的現場故障修復派遣、集中式資產與保固管理，以及新門市的統一上線與高度照護期支援。

可以移轉到共享服務中心這一側的教訓，關於的是「橋」。一個歐洲總部和一個亞洲營運之間存在真實的交接問題——不同的時間、不同的升級文化、不同的「緊急」定義——而服務商增加的價值，往往在於營運這條接縫，而不在於任何一項具體的技術任務。共享服務中心永遠住在這條接縫上。

規模也重要。在另一個專案裡，博迅為一家全球奢侈時裝品牌在 13 個國家的 153 家零售門市同時部署了 Cisco Meraki 交換器、防火牆和無線基地台，包含集中採購、門到門物流、在每個地點進行 Ekahau 無線網路勘查、交付前技術預組態、現場安裝與使用者驗收測試，以及一個協調所有排程的專案管理辦公室。它與共享服務中心的相關性不在硬體，而在於：區域一致性首先是一門專案管理學科，其次才是技術。

服務語言與紀錄語言

一個服務十幾個市場的共享服務中心，有一個單一市場辦公室沒有的語言問題。英語幾乎總是紀錄語言——工單、文件、報表。但電話那頭來自某個市場的人，可能用另一種語言舒服得多，而用第二語言進行的一線互動，在可測量的意義上更慢、更容易出錯。

我們的看法是：這兩件事應當分開、有意識地決定。保留一種紀錄語言，讓工單歷史、SLA 報表和知識庫保持連貫且可稽核。允許服務語言在服務台確實能支援的範圍內變化。行不通的是讓服務語言悄悄變成紀錄語言，因為六個月後就沒有人能跨整個資產群跑出一份報表了。

區域服務台、本地服務台，還是混合？

三種模式的比較

只有本地服務台： 支援範圍限定在新加坡上班時間和新加坡員工。最容易採購，也最容易究責，因為只有一個團隊、一個時鐘。它在一天的兩端系統性地表現不足，而對共享服務中心來說，不成比例的風險恰恰住在那裡。
只有區域／跟隨日光服務台： 涵蓋完整的市場時鐘，只要有任何一個被支援的市場在工作，就有一線回應。在可用性上，以及在「使用者在內部、客戶是別的國家」這個問題上都很強。在實體性和本地性上較弱——總還是得有人走到新加坡的某張辦公桌前，而遠端服務台做不到這件事。
混合，也就是大多數共享服務中心真正需要的： 涵蓋市場時鐘的跟隨日光一線，加上新加坡工作日內的本地在場，用來處理一切實體性的、需要脈絡的，以及結帳期的湧入。決定這個模式成敗的不是涵蓋圖，而是「一線獨立解決什麼、升級什麼」的書面定義——因為這裡的含糊會把每一起邊緣時段事件都轉換成一次延遲。

真正決定該選哪一種的因素

你的風險有多少落在新加坡上班時間之外？ 數事件，不要數員工。如果相當一部分影響業務的事件發生在新加坡時間上午九點前或下午六點後，那麼無論本地服務台多優秀，只有本地服務台在結構上就是錯配的。
你的資產有多「實體」？ 筆電、會議室、印表機、辦公網路和新人設定都需要人手。資產越實體，本地成分越重要。
你的工單量裡有多少是第三方存取問題？ 如果比例高，供應商對接能力比深度系統管理更重要，而且你應當明確把它寫進範圍。
你的行事曆有多陡？ 一家有真實結帳期尖峰的企業，需要一家願意為每月四天彈性調整的服務商。這是一場商務對話，而它提前談遠比事後發現有效得多。

前九十天的實用形狀

如果你正在為一家共享服務中心重新界定 IT 支援——或者第一次界定它——我們建議這樣的順序。

第一到第二週：建立行事曆與系統地圖。 記錄結帳週期、薪資週期、各市場的法定期限以及尖峰日。另外，列出每一個業務關鍵系統，並標明由誰管理：你、集團，還是第三方。這兩份文件對支援品質的貢獻，會超過任何一項技術決策。

第三到第四週：定義兩個時鐘。 明確服務台時鐘和市場時鐘，並把縫隙時段明確標出來。決定一線在那些時段裡可以獨立解決什麼。

第五到第八週：把邊界釘住。 寫下到集團 IT 的升級路徑，以及針對第三方入口網站和供應商的對接流程。這是整個計畫裡最不光鮮、回報卻最高的一段工作，因為共享服務中心的工單真正卡住的地方就在這裡。

第九到第十二週：演練一次結帳。 讓這套支援模式帶著更高的關注度走過一個完整的月結，並復盤什麼排了隊、為什麼。觀察一次真實的結帳，比一季的 SLA 報表教給你的更多。

在整個過程中，讓端點與身分的基本功並行推進——協作層用託管雲端與 Microsoft 365 服務，並對「誰能存取什麼」保持清晰視野，尤其當這一整組系統大多屬於別人的時候。

成本的形狀，而不是數字

我們不會編造數字。博迅的託管 IT 支援方案是按使用者月費的分級方案，並公布分市場價格，新加坡市場是按當地原生定價，而不是從區域平均值換算而來。即時數字在該頁面和價格頁上。

對共享服務中心特別值得理解的是：按使用者定價是一個合理的基準，但對這種樣貌來說是一個不完整的模型，因為它給平均值定價，而不是給尖峰定價。真正推動共享服務中心支援成本的兩個變數是：涵蓋視窗——市場時鐘比服務台時鐘多出多少——以及結帳期的湧入是靠彈性擴充處理，還是乾脆讓佇列變長。這兩件事都值得在簽約時明確定價，而不是在第一季裡發現。

關於新加坡更廣的成本圖景，我們已發布的新加坡 IT 支援成本指南和託管 IT 與自建團隊的比較涵蓋了市場的一般形狀。

常見問題

就 IT 支援而言，共享服務中心和區域總部有什麼不同？

區域總部是一個商務營運——業務、行銷、管理——需求曲線相當平坦，出問題時後果大多是本地的。共享服務中心是一個處理型營運，需求由行事曆驅動出現尖峰，後果落在別的市場，工作日被拉長，而關鍵系統清單大多由別人管理。同一座城市、同樣的人數，支援樣貌卻有實質差別。

新加坡的共享服務中心需要 7×24 支援嗎？

通常不需要字面意義上的 7×24，但幾乎總是需要多於朝九晚六。誠實的檢驗方法是把一季裡「影響業務的事件」實際發生的時間畫出來。多數共享服務中心會發現，自己需要的一線涵蓋大致從日本工作日開始到印度工作日結束，同時在新加坡上班時間內具備完整的本地能力——也就是跟隨日光的一線，而不是一支全天候的本地團隊。

我們的 ERP 由歐洲總部管理。那本地服務商還剩下什麼可做？

剩下很多，而且正是決定共享服務中心能否日常運轉的那部分：端點與身分、本地網路、Microsoft 365、跨第三方系統組合的存取管理、能把集團系統問題正確路由給集團 IT 而不是壓在自己手上的一線分流、供應商對接，以及所有實體性的工作。服務商在 ERP 邊界上的職責是準確且快速地升級——這要求他知道邊界在哪裡，而這是一項文件工作。

支援應該怎樣圍繞月結安排？

三件事。在結帳視窗內凍結基礎架構變更。允許優先順序定義移動，使某些例行工單類別在結帳期間被更緊急地對待。並且為那幾天提前約定產能，而不是依賴「盡力而為」。這三件事都要求服務商知道你的行事曆——也就代表你得把行事曆給他們。

服務台應該用當地語言還是英語運作？

把服務語言和紀錄語言分開。保留英語作為紀錄語言，使工單歷史、SLA 報表和知識庫在各市場之間保持連貫、可稽核。允許服務語言在服務台確實能支援的範圍內變化——博迅的服務台以普通話、粵語和英語運作。會失敗的是讓服務語言悄悄變成紀錄語言。

我們已經外包了，而且基本可用。最值得改的一件事是什麼？

幾乎總是行事曆和邊界地圖。把結帳行事曆和一份系統歸屬清單交給你的服務商，然後以書面形式約定一線在縫隙時段裡可以獨立解決什麼。這兩份材料通常能修好的「感受到的支援問題」，比升級一個服務等級還多，而它們的成本只是某個人兩天的注意力。

博迅支援這類營運嗎？

支援。博迅自 2021 年起總部設於新加坡，並把它作為區域樞紐營運，擁有以 ITIL 為基礎的多語言全球服務台、與 ServiceNow、SDP、Jira 等主流平台的 ITSM 整合、每月 SLA 指標報告，以及涵蓋全區域的現場派工。上文描述的零售專案——為歐洲生活風格零售集團橫跨歐非中東與亞太的跟隨日光服務台，以及為奢侈時裝品牌在 13 國 153 家門市的 Meraki 部署——正是同一套營運肌肉用在同一產業的門市端。