外資軟體企業中國IT支援指南

簡而言之： 一家歐洲軟體企業按同一套全球標準運行IT，並理所當然地認為中國的兩個辦事處只是這套標準下多出來的兩個站點。而從上海與北京實際收到的工單，恰恰都是這套全球標準從未預料到的問題——沒有人願意用英語提工單的服務台、從未真正量測過的跨境網路連線，以及不管總部政策怎麼寫、都實實在在壓在本地主體身上的合規義務。

一家歐洲企業軟體公司的全球IT總監，收到上海辦公室行政經理的一則訊息：員工已經不再向歐洲服務台提交工單了，問題反而是——或者根本沒有——在群組聊天裡用中文非正式地被解決掉的，誰碰巧知道辦法誰就順手處理了。總監的第一反應，是提醒大家工單系統是有存在意義的。但更值得追問的問題是：一個45人的辦公室，一開始為什麼會不再使用它。

本文寫給的正是這樣一位總監，或者任何一家歐洲、北美科技或軟體企業中，負責IT、且公司業務已經擴展到一間約45人的上海總部辦公室與一間約15人的北京銷售辦公室之後的那個人。這是一個具代表性的綜合場景，而非具名客戶——但這種模式，是Brocent反覆遇到的，因為它與公司自身的歷史高度相近。Brocent於2007年在北京成立，自2016年起設有香港辦公室，2021年起總部設於新加坡；其相當一部分客戶，正符合這個畫像——一家在亞洲唯一的據點就是中國的外資科技公司，被地球另一端的總部遠端管理著。

這個產業：亞洲唯一據點就是中國的軟體企業

總部設在歐洲的企業軟體、開發者工具、工業軟體與專業SaaS公司，進入亞洲市場時往往只開設一間辦事處，而這間辦事處通常落在中國，而不是新加坡或日本，因為中國聚集著最大規模的潛在企業客戶、系統整合合作夥伴，某些情況下甚至是公司自身的交付與工程人才儲備。由此產生的辦事處，很少只是一個小型銷售前哨。它常常是一個真正的交付或研發據點——工程師、實施顧問、客戶成功團隊——與規模較小的商務團隊並肩工作，因為母公司發現，在中國本地建立產品與交付能力，比每個專案都從歐洲派人飛過來更有效率。

一到兩年內，第二個辦事處往往會隨之而來——如果第一個在上海，幾乎總是落在北京，反之亦然——因為中國的企業軟體銷售，集中在為數不多的幾座城市，那裡聚集著買方、政府關係與系統整合合作夥伴。結果就是兩間相距幾百公里的辦事處，共同覆蓋公司在整個亞洲業務的交付與銷售——而它們從來沒有被真正當作「IT站點」來規劃過。它們是招聘決策的產物，而不是基礎設施決策的產物；IT職能往往是最後一個意識到——公司現在擁有的是一個真正的中國業務，而不是幾名恰好人在中國的遠端員工。

具體場景：兩座城市60人、一位行政經理，以及一個完全對不上的時區

這個綜合場景是這樣的：上海總部辦公室約45人——工程、實施、客戶成功，以及一個綜合行政職能——加上北京銷售辦公室約15人，多為商務與合作夥伴對接人員，大部分時間都在見客戶，而不是坐在工位上。兩地都沒有專職的IT人員。最接近本地IT的角色，是上海的一位行政經理，她同時負責租約、快遞與茶水間補給，並且把「Wi-Fi斷了就聯繫供應商」當成了一項非正式的額外職責。其餘一切——身分驗證、終端政策、服務台、安全工具、協作辦公套件——都由歐洲總部的一支小型IT團隊所有並營運。

這支團隊本身能力過硬，他們建立的全球標準也確實紮實：統一的身分提供者、一致的終端配置、一套協作辦公套件、一套工單系統、一套在全球統一執行的安全政策。問題出在時鐘上。上海與北京，依季節不同，比歐洲總部大約領先六到八個小時，這意味著兩間辦事處完整的工作日，要麼落在歐洲團隊上線之前，要麼落在他們下班之後。上海一台筆記型電腦早上9點身分驗證失敗，這張工單最快也要等到歐洲團隊快到中午才能被接手——而到那時，上海的員工要麼已經找到了變通辦法，要麼當天就放棄了，要麼已經在群組聊天裡問了同事。這三種結果，沒有一個會體現在任何服務台指標上——這正是為什麼這個問題能在歐洲那頭保持隱形這麼久的原因。

真實問題一：服務台必須真正能用中文運作

歐洲服務台用英語運作，因為英語是公司其餘部分的工作語言。上海相當一部分工程與交付人員，以及不少北京銷售團隊成員，英語流利到足以完成工作，卻未必自在到能夠在時間壓力下、用第二語言，向一位素未謀面的坐席精確描述一個技術問題。實際結果不是大家求助無門——而是大家悄悄不再提問了。一個用中文兩分鐘就能說清楚的工單，最終被擱置、非正式地繞開解決，或者拖到問題變大之後才被上報。這不是訓練問題，也不是紀律問題。這是一個語言與時區疊加的問題，單靠一個全球統一的服務台，無論營運得多好，都無法獨自完全解決——這正是為什麼一個真正能夠在中國工作時間、用中文運作的7×24小時服務台，而不只是按歐洲時鐘運作的英語服務台，能夠改變問題在演變成大問題之前被上報的數量。

真實問題二：跨境網路表現必須實測，而不能想當然

歐洲IT團隊搭建協作辦公套件、VPN與監控工具時，假設的是一種相對均一的全球網路體驗，因為這個假設對公司其他海外辦事處都成立。但它對中國辦事處未必同樣成立，而誠實的原因，並不是某個具體服務被封鎖、也不是某個頭條式的頻寬數字——而是中國與全球網際網路其他部分之間的跨境連線，會因路由、因一天中的時段、因具體涉及哪個雲端區域與服務而表現不同，並且這種表現還會隨時間變化。唯一負責任的做法，是停止假設、開始實測：針對上海與北京團隊實際依賴的具體應用，從這兩間辦事處、在人們實際使用的時段進行測試，並根據實測結果來設計架構，而不是套用在新加坡或東京辦事處行之有效的那一套。有一個值得了解、而非憑空猜測的事實：在中國大陸，Microsoft 365是作為一項獨立營運的服務提供的（歷史上透過一家持牌本地營運商營運，通常被稱為「世紀互聯」），這與大多數歐洲團隊熟悉的全球版Microsoft 365租戶，在營運層面存在真實差異——這不是要迴避該平台的理由，而是一個理由：在假設某個具體工作流程與全球版表現一致之前，先針對中國辦事處實際需要的場景加以測試。

真實問題三：終端管理與軟體發布要跑在一條表現不同的連線上

一套圍繞歐美使用者群設計、從一組雲端節點向公司所有筆記型電腦推送作業系統更新、安全修補程式與應用程式套件的全球終端管理平台，會遇到與協作辦公套件相同的實測問題。同樣的修補套件，在歐洲或美國辦事處能在一夜之間悄無聲息地完成分發，對一台透過更長、更多變路徑拉取的上海或北京裝置而言，表現可能就不一樣——同樣，原因不是某個具體環節被封鎖，而是實際交付體驗需要從中國辦事處實測，而不能憑其在其他地方的表現來推斷。切實可行的解決辦法，通常是架構性的而非戲劇性的：為大體積安裝套件設置本地快取或區域分發節點，把修補視窗安排在對齊中國工作時間而非歐洲時間，以及按辦事處而非單一全球平均值來報告終端合規率——後者往往會悄悄掩蓋掉一個中國特有的問題。這正屬於基礎設施部署的範疇——一次性把分發架構做對，而不是逐一辦事處地救火處理修補合規率低落的問題——這類工作屬於IT基礎設施部署覆蓋的範圍。

真實問題四：歐洲總部沒有一套處理硬體採購與發票的流程

一支歐洲財務團隊知道如何處理一家歐洲IT供應商開出的發票。但它通常沒有一套建立起來的流程，去在中國採購一台筆記型電腦、一台顯示器或網路設備，也不熟悉「發票」——即中國合法主體在採購中據以正確入帳與報銷所必需的官方稅務發票，它絕不只是一張外語收據，而是一種受監管的特定單據類型，有其自身的合規要求。如果放任不管，結果通常是兩種失效模式之一：要麼上海的某人用私人信用卡墊付購買設備，然後花上好幾個月，為一張財務不知道該如何處理的發票爭取報銷；要麼硬體採購悄悄陷入停滯，因為沒有人有把握自己做的是對的，於是員工被迫將就使用老舊設備，時間長得遠超公司在其他任何地方所能容忍的程度。這兩者都不是技術問題。它們都是流程問題——而一個已經真正了解本地採購與發票實務如何運作的中國本地合作夥伴，能夠將其吸收為服務中的常規一環，而不是讓它持續成為上海辦事處與歐洲財務職能之間的摩擦點。

真實問題五：等保與個資保護義務壓在本地主體身上，與總部政策無關

公司的全球資訊安全政策是在歐洲制定的，幾乎肯定以GDPR為參照，而且這確實是一份寫得不錯的政策。但它單獨存在，在中國是不夠的。網路安全等級保護制度（等保，MLPS）與《個人資訊保護法》（PIPL），把義務實實在在地繫著在營運上海與北京辦事處的中國法律主體身上——包括資料分類與系統定級要求、視所涉系統而定的安全評估與備案義務，以及在跨境資料傳輸方面與GDPR有實質差異的規則。一份歐洲隱私政策，無論寫得多好，都無法履行這些義務，「我們的全球政策已經涵蓋了這一點」，這種說法在中國監管機構面前站不住腳。這是全球標準與本地現實之間差距最大的領域之一，一旦出錯，帶來的是實實在在的監管風險，而不只是讓某個使用者感到不便——這正是為什麼它應該被納入持續的服務關係，歸屬於管理型IT安全服務之下，而不是被當作一次性的法律專案，等文件歸檔完畢就被擱置遺忘。

通常是什麼最終迫使企業面對這個問題

處在這種狀況的企業，很少會主動發起一次對中國IT架構的檢視。往往是某件具體的事，把它推上了議程。有時是本文開頭描述的那一幕——工單悄悄從官方佇列中消失、以群組聊天裡的非正式修復重新出現，這種模式最終被總部某人注意到並提出疑問。有時是一份客戶或合作夥伴的盡職調查問卷，尖銳地問到在中國的資料處理與合規情況，而誠實的回答令人難堪。有時是一次安全事件，或一次險些釀成事故的經歷，暴露出從來沒有人真正驗證過全球安全體系在中國辦事處的實際表現。而有時，僅僅是因為成長——一個最初只有三人、從上海覆蓋市場的北京辦事處，長成了一支15人的團隊，而曾經對三個人管用的臨時安排，如今在十五個人面前明顯失靈了。

Brocent的觀點：失效模式是想當然，而不是疏忽

誠實的定性是這樣的：一家在亞洲唯一據點就是中國的歐洲或北美軟體企業，很少是因為疏忽而對不起自己的中國辦事處。管理層通常是在乎的，全球IT標準通常也確實過硬。真正的失效模式，是想當然地認為這套標準可以原封不動地套用到中國——而實際上，有幾件具體的事——語言、時區、跨境網路表現、本地採購與發票、以及一套截然不同的合規體制——如果不經過刻意調整，是無法直接照搬過去的。

Brocent的看法，源自公司2007年在北京成立、並自那以後一直為這類外資科技公司提供IT服務的經歷：可行的答案，既不是拋棄全球標準、為中國另起爐灶，也不是假裝全球標準完全不需要調整。而是一份簡短、經過刻意選擇並形成文件的「中國例外清單」——只制定一次、寫下來，並由一位真正在當地對此負責的人所有——涵蓋那些確實需要有所不同的少數幾件事：服務台如何在中國工作時間、用中文運作，終端發布如何針對中國連線做架構設計，本地採購與開票如何運作，以及等保與個資保護義務如何被切實履行。凡是不需要不同的，一律原樣保留總部所搭建的樣子。這與大多數處在這種境地的企業實際最終得到的東西——沒有文件、總部完全不知情、由上海辦事處裡恰好在那一週解決了問題的人獨立發明出來的非正式變通辦法——是完全不同的兩回事。

真正全面的中國IT支援，實際上涵蓋哪些內容

有五件事，把一份真正彌合了歐洲全球標準與中國實際營運之間差距的支援安排，與一份悄悄留下缺口的安排區分開來。

一個能在中國工作時間、用中英雙語運作的服務台。 上海與北京的員工，應當能夠用自己表達最精確的語言提交工單，在自己實際工作的時段內提交，並且不必等到歐洲那頭醒來就能得到回應。僅此一項，往往就能把此前隱形的相當一部分問題浮出水面，因為它同時消除了人們悄悄不再上報問題的兩大主要原因。

覆蓋兩座城市的本地駐點回應能力。 上海與北京相距足夠遠，「我們覆蓋中國」必須意味著兩座城市各自真實的到場回應能力，而不是一名恰好常駐某一城市、把去另一城市當作特殊出差的工程師。任何一座城市出現的網路、硬體或辦公室搬遷問題，都需要真正的本地回應，而不能因為沒人為兩座城市都做預算，就預設只提供遠端支援。

針對真實連線設計的終端與修補管理。 與其把同一套全球分發架構原封不動地推給中國、然後寄望順利，不如實測上海與北京的實際情況，並根據實測結果調整快取、分發節點與修補排程——當中國辦事處進入考量範圍時，這種先量測、後設計的原則，本就應當適用於管理型IT雲端服務的整體架構。

規範的本地採購與發票開立。 硬體與設備第一次就針對中國主體正確採購、開票並入帳，歐洲財務團隊無需摸索一套陌生流程，上海員工也無需自己先行墊付費用。

將合規義務作為服務的一部分來處理，而不是一個附帶專案。 隨著系統與資料流的變化，持續檢視並維護等保定級與個資保護義務，而不是僅在一次法律專案中處理一遍，然後隨著業務成長而悄悄過時。

在同一套安排下管理上海與北京這兩間辦事處，而不是兩套各自臨時拼湊的方案，也是在兩地統一管理身分驗證、安全政策與報告體系更為一致的方式——這正是覆蓋兩座城市、納入同一份SLA的管理型IT雲端服務，往往能夠取代原本各自為政的兩套本地臨時方案的地方。

一位向總部彙報的本地雇員 vs 一家臨時應急的本地維修商 vs 一家以「文件化中國例外清單」交付全球標準的管理型IT合作夥伴（Brocent模式）

一位向總部彙報的本地雇員 ——確實在現場安排了一個真實的人，對語言與在場性有實實在在的幫助，但單一雇員就是單點故障：休假、生病或離職都沒有覆蓋，沒有正式的升級路徑，也很少同時具備網路工程、終端管理、安全與合規的全部技能廣度。它還往往演變成一個總部所知有限的、非正式的第二IT部門。
一家臨時應急的本地維修商 ——處理偶發的物理問題很好用——印表機、佈線、辦公室搬遷——但結構上是被動回應型：沒有7×24小時覆蓋，不對終端機群或安全態勢負責，不具備合規能力，也無人對上海與北京辦事處是否真正達到公司其他地方同等的標準負責。
一家以「文件化中國例外清單」交付全球標準的管理型IT合作夥伴（Brocent模式） ——凡是不需要改變的，原樣保留總部設計的樣子；對少數確實需要、且經過刻意選擇的不同之處，逐一妥善處理：在中國工作時間運作的雙語服務台、覆蓋兩座城市的現場回應、針對真實網路路徑調校的終端發布、本地採購與開票，以及持續管理的等保／個資保護義務。取捨在於，紙面上它比一位本地雇員的成本更高——而誠實的答案是，一位本地雇員從一開始就沒有真正覆蓋過同等的範圍。

常見問題

「中國IT支援」實際上包含哪些全球服務台無法提供的內容？

它包含的，是一個不分語言、不分時區的全球服務台在結構上就無法獨自提供的東西：一個能在中國工作時間、用中文運作的服務台，而不只是按歐洲時鐘運作的英語服務台；真正能夠觸及上海與北京兩地的本地駐點回應，而不是把中國當成一個據點來對待；已經從這兩間具體辦事處實測過、而不是想當然地假設與其他地方一致的網路與終端表現；帶有正確發票開立的本地硬體採購；以及一份純歐洲安全政策所無法履行的等保／個資保護合規義務。它不會取代全球標準——它填補的是這套標準無法原封不動照搬過去的那幾處具體缺口。

我們需要先有一個中國主體，才能在本地採購IT支援嗎？

在大多數情況下，是的——一個已註冊的本地主體，通常是讓本地硬體採購（透過發票系統正確開票）以及大多數在本地簽約的IT服務變得順暢可行的前提，也正是等保與個資保護義務實際所依附的那個主體。已經在中國有員工、卻尚未正式設立本地主體的公司，應當把這一點列為最先需要與法律和財務顧問一起釐清的問題，因為它決定了哪些東西可以在本地採購與簽約，哪些在過渡期內必須走母公司這條路徑。

我們應該如何測試全球協作辦公工具在每間辦事處的實際表現是否足夠好？

針對上海與北京員工日常真正依賴的具體應用——視訊會議、檔案同步、身分驗證與VPN路徑，以及對其工作至關重要的任何SaaS平台——從這兩間辦事處、在人們實際使用的時段進行測試，持續觀察若干天，而不是只做一次性檢查。將結果與同樣應用在歐洲或美國辦事處的表現相比較，並把任何有實際意義的差距，當作一項設計輸入來處理，而不是一件需要忍受的一次性不便。避免在未針對具體辦事處實測之前，就假設某項服務受到還是沒受到影響——跨境網路表現會隨時間、隨路由而變化，這正是為什麼在這件事上，實測勝過假設。

等保與個資保護的責任在我們自己，還是在服務商？

法律責任在於營運上海與北京辦事處的中國主體，實際上也就是公司自身，而不是任何外包服務商——一家管理型IT合作夥伴無法代替你承擔這份法律責任。一家有能力的合作夥伴能做的，是讓你處於可辯護地位所需的營運工作：系統定級、與等保要求對齊的持續安全管控，以及支持個資保護合規的資料處理實務，作為服務的持續一環來交付，而不是一次性專案。最終的責任歸屬，以及定級與備案的簽核確認，仍然應當由你自己的法律顧問參與把關。

一家服務商能否用一份SLA同時覆蓋上海與北京？

可以，對這個規模的公司而言，這通常是更為一致的選項，因為兩間辦事處共享身分驗證、安全政策、終端標準與報告體系，而單一服務商能夠避免管理兩家互不溝通的本地供應商所帶來的協調成本。這份SLA仍然應當、也理應體現出：上海與北京是兩個各自獨立的現場地點，各有自己的回應承諾，而不是假裝「中國」是地圖上的一個點。

如果我們之後再開設第三座中國城市的辦事處，會有什麼變化？

比大多數公司預期的要少——前提是前兩間辦事處已經按有文件記錄的方式建立起來，而不是靠臨時拼湊的應急辦法。服務台、身分與安全基線、採購與開票流程，以及合規框架，在設計上大多是可以延展的，而不需要從零重建——第三座城市主要新增的，是另一個現場回應據點，以及（如果辦事處規模足夠大）它自己的本地網路實測，沿用已經在上海與北京驗證過的「先量測、後設計」方法，而不是假設表現自然會一致。

讓中國IT支援，真正匹配業務實際運轉的方式

一間上海總部辦公室與一間北京銷售辦公室，並不只是歐洲搭建的全球IT標準之下多出來的兩個站點——它們運行在不同的語言裡、不同的時鐘上、跑在一條必須實測而非假設的網路連線上，並且處在一套無論總部政策怎麼寫、都實實在在壓在本地主體身上的合規體制之下。這不意味著要推倒重來。它意味著一份簡短、經過刻意選擇並形成文件的清單，寫明中國究竟需要在哪些地方有所不同，由一位真正對此負責的人所有，疊加在一套已經在其他地方做得足夠好、並將繼續保持這份水準的全球標準之上。

Brocent自2007年在北京成立以來，一直為在中國營運的外資科技與軟體公司提供支援，也與數十家在亞洲唯一據點就是中國、正努力按一套從未真正為它們量身打造過的歐洲標準運轉的公司，進行過完全一樣的對話。如果這聽起來正是貴公司今天所處的狀況，歡迎聯繫我們，從貴公司上海與北京辦事處的實際需求出發展開對話，而不是從一份範本開始。