新加坡 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 部署——正是同一套运营肌肉用在同一行业的门店端。