为软件企业上海与北京两地办事处提供的中国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云服务的整体架构。

规范的本地采购与发票开具。 硬件与设备第一次就针对中国主体正确采购、开票并入账，欧洲财务团队无需摸索一套陌生流程，上海员工也无需自己先行垫付费用。

将合规义务作为服务的一部分来处理，而不是一个附带项目。 随着系统与数据流的变化，持续review并维护等保定级与个保义务，而不是仅在一次法律项目中处理一遍，然后随着业务增长而悄悄过时。

在同一套安排下管理上海与北京这两间办事处，而不是两套各自临时拼凑的方案，也是在两地统一管理身份认证、安全策略与报告体系更为一致的方式——这正是覆盖两座城市、纳入同一份SLA的管理型IT云服务，往往能够取代原本各自为政的两套本地临时方案的地方。

一位向总部汇报的本地雇员 vs 一家临时应急的本地维修商 vs 一家以"文档化中国例外清单"交付全球标准的管理型IT合作伙伴（Brocent模式）

• 一位向总部汇报的本地雇员 ——确实在现场安排了一个真实的人，对语言与在场性有实实在在的帮助，但单一雇员就是单点故障：休假、生病或离职都没有覆盖，没有正式的升级路径，也很少同时具备网络工程、终端管理、安全与合规的全部技能广度。它还往往演变成一个总部所知有限的、非正式的第二IT部门。
• 一家临时应急的本地维修商 ——处理偶发的物理问题很好用——打印机、布线、办公室搬迁——但结构上是被动响应型：没有7×24小时覆盖，不对终端机群或安全态势负责，不具备合规能力，也无人对上海与北京办事处是否真正达到公司其他地方同等的标准负责。
• 一家以"文档化中国例外清单"交付全球标准的管理型IT合作伙伴（Brocent模式） ——凡是不需要改变的，原样保留总部设计的样子；对少数确实需要、且经过刻意选择的不同之处，逐一妥善处理：在中国工作时间运转的双语服务台、覆盖两座城市的现场响应、针对真实网络路径调优的终端分发、本地采购与开票，以及持续管理的等保／个保义务。取舍在于，纸面上它比一位本地雇员的成本更高——而诚实的答案是，一位本地雇员从一开始就没有真正覆盖过同等的范围。

常见问题

"中国IT支持"实际上包含哪些全球服务台无法提供的内容？

它包含的，是一个不分语言、不分时区的全球服务台在结构上就无法独自提供的东西：一个能在中国工作时间、用中文运转的服务台，而不只是按欧洲时钟运转的英语服务台；真正能够触达上海与北京两地的本地驻场响应，而不是把中国当成一个据点来对待；已经从这两间具体办事处实测过、而不是想当然地假设与其他地方一致的网络与终端表现；带有正确发票开具的本地硬件采购；以及一份纯欧洲安全政策所无法履行的等保／个保合规义务。它不会取代全球标准——它填补的是这套标准无法原封不动照搬过去的那几处具体缺口。

我们需要先有一个中国主体，才能在本地采购IT支持吗？

在大多数情况下，是的——一个已注册的本地主体，通常是让本地硬件采购（通过发票系统正确开票）以及大多数在本地签约的IT服务变得顺畅可行的前提，也正是等保与个保义务实际所依附的那个主体。已经在中国有员工、却尚未正式设立本地主体的公司，应当把这一点列为最先需要与法律和财务顾问一起厘清的问题，因为它决定了哪些东西可以在本地采购与签约，哪些在过渡期内必须走母公司这条路径。

我们应该如何测试全球协同办公工具在每间办事处的实际表现是否足够好？

针对上海与北京员工日常真正依赖的具体应用——视频会议、文件同步、身份认证与VPN路径，以及对其工作至关重要的任何SaaS平台——从这两间办事处、在人们实际使用的时段进行测试，持续观察若干天，而不是只做一次性检查。将结果与同样应用在欧洲或美国办事处的表现相比较，并把任何有实际意义的差距，当作一项设计输入来处理，而不是一件需要忍受的一次性不便。避免在未针对具体办事处实测之前，就假设某项服务受到还是没受到影响——跨境网络表现会随时间、随路由而变化，这正是为什么在这件事上，实测胜过假设。

等保与个保的责任在我们自己，还是在服务商？

法律责任在于运营上海与北京办事处的中国主体，实际上也就是公司自身，而不是任何外包服务商——一家管理型IT合作伙伴无法代替你承担这份法律责任。一家有能力的合作伙伴能做的，是让你处于可辩护地位所需的运营工作：系统定级、与等保要求对齐的持续安全管控，以及支持个保合规的数据处理实践，作为服务的持续一环来交付，而不是一次性项目。最终的责任归属，以及定级与备案的签字确认，仍然应当由你自己的法律顾问参与把关。

一家服务商能否用一份SLA同时覆盖上海与北京？

可以，对这个规模的公司而言，这通常是更为一致的选项，因为两间办事处共享身份认证、安全策略、终端标准与报告体系，而单一服务商能够避免管理两家互不沟通的本地供应商所带来的协调成本。这份SLA仍然应当、也理应体现出：上海与北京是两个各自独立的现场地点，各有自己的响应承诺，而不是假装"中国"是地图上的一个点。

如果我们之后再开设第三座中国城市的办事处，会有什么变化？

比大多数公司预期的要少——前提是前两间办事处已经按有文档记录的方式建立起来，而不是靠临时拼凑的应急办法。服务台、身份与安全基线、采购与开票流程，以及合规框架，在设计上大多是可以延展的，而不需要从零重建——第三座城市主要新增的，是另一个现场响应据点，以及（如果办事处规模足够大）它自己的本地网络实测，沿用已经在上海与北京验证过的"先测量、后设计"方法，而不是假设表现自然会一致。

让中国IT支持，真正匹配业务实际运转的方式

一间上海总部办公室与一间北京销售办公室，并不只是欧洲搭建的全球IT标准之下多出来的两个站点——它们运行在不同的语言里、不同的时钟上、跑在一条必须实测而非假设的网络链路上，并且处在一套无论总部政策怎么写、都实实在在压在本地主体身上的合规体制之下。这不意味着要推倒重来。它意味着一份简短、经过刻意选择并形成文档的清单，写明中国究竟需要在哪些地方有所不同，由一位真正对此负责的人所有，叠加在一套已经在其他地方做得足够好、并将继续保持这份水准的全球标准之上。

Brocent自2007年在北京成立以来，一直为在中国运营的外资科技与软件公司提供支持，也与数十家在亚洲唯一据点就是中国、正努力按一套从未真正为它们量身定制过的欧洲标准运转的公司，进行过完全一样的对话。如果这听起来正是贵公司今天所处的状况，欢迎联系我们，从贵公司上海与北京办事处的实际需求出发展开对话，而不是从一份模板开始。