四种语言、一张工单、五份记录

重点： 一家日本制造企业的新加坡区域办公室，要支撑另外四个东盟国家的团队。工单用英语、日语、泰语和印尼语提交，而报给东京总部的月报必须是日语。这个办公室一直靠善意，以及一位如今已成为单点故障的双语行政同事撑着。解法不是再招几个多语人才，而是：一套记录、一个系统、一种被明确定义的记录语言。

制造出这个问题的结构：把新加坡当作东盟区域办公室

相当多日本总部的制造企业，是通过新加坡区域办公室来运作东南亚业务的。理由都说得通，而且多半是商业上的：区域财务职能设在这里，资金与法人架构在这里最清晰，区域销售负责人可以驻在这里，而外派的日籍管理者在这里不必面对本区域其他外派地的语言与子女就学摩擦。区域办公室协调着马来西亚、泰国、越南、印尼、往往还有菲律宾的工厂、销售团队和经销商。

从 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 支持页面上，而一个划定范围的数字需要先聊清楚你们实际的国别分布。