五供应商变一张账单：香港IT整合案例

简而言之： 一家香港专业服务机构在核对IT预算时，翻出了五张互不相干的供应商账单——杀毒软件、云备份、工单系统、远程访问工具，以及真正的IT支持合同——彼此毫无关联，其中两笔账单还在为根本没人用的授权继续付费。把这些工具整合到同一个互联平台上，重点从来不是账单变小，而是一堆彼此孤立的工具在结构上根本看不到的问题。

香港的专业服务机构为什么会用上五家IT供应商？

没有哪家机构是故意把IT堆叠成五家供应商的。它是一个决定接一个决定慢慢积累出来的，每一个决定单独看都合情合理。

一家五十到一百人规模的律师行、会计师行或咨询公司，很少配有能做五年架构规划的IT部门。它们通常是靠一位办公室经理或运营主管，遇到什么问题就解决什么问题。杀毒软件到期了，就有人去买杀毒软件。新闻里看到勒索软件的报道，于是订阅了一份云备份服务。原来靠一个大家都半理不理的共享邮箱记录IT请求，后来换成了某位合伙人侄子推荐的工单工具。公司改成混合办公后需要远程支持，于是有人开了一个屏幕共享工具的账号。而在这一切当中，某个时间点又单独请了一家真正的IT支持商来维持系统正常运转，账单和以上这些完全分开算。

每一笔采购单独看都说得通。没有人坐下来专门决定，公司要靠五家互不相通的公司来运行五套系统。它是这样自然积累出来的——就像一间办公室慢慢堆满了家具，这里添一把椅子，那里加一个文件柜，直到有一天什么都不成套，也没人记得那把好椅子是谁买的。

这在香港专业服务行业里是一个特别常见的模式，因为这类机构采购IT的方式，和采购其他非核心业务的东西一样：被动应对，谁有空谁去处理，那周谁接电话就找谁。这样经营律师行也许是理性的。但这样管理IT，并不理性。

具体场景：五张账单，没有一个统一的真相来源

下面是一个复合场景，取材自我们在同类规模、同类型机构中反复看到的模式——不是某个具名客户。

一家七十人规模的香港律师行，运营事务由两位合伙人分担，因为没有专门的运营岗位。每个季度，他们都要坐下来核对一次技术预算。这一次，核对出来的是五笔独立支出。杀毒软件通过一家分销商每年续订一次。云备份每月通过第二家供应商按存储量计费，续订日期是什么时候同意的，谁也说不清。用于记录IT请求的工单工具，每月向第三家公司支付一笔小额SaaS费用，但用得并不统一——有些员工干脆直接发邮件提需求。让IT支持商在出问题时能远程连接机器的远程访问工具，是从第四家供应商那里按坐席单独授权的。而真正解决问题的人——负责修东西的IT支持合同——是第五笔支出，按小时或按月费结算。

五张账单。五个客服电话。五个登录后台，彼此之间没有任何数据互通。当办公室经理想回答一个简单的问题——"我们的电脑上到底装了什么？有没有哪些授权是白花钱的？"——却发现根本没有一个地方能查到答案。她得分别登录四个不同的供应商后台，再手工对照一份从两次人事变动之前就没更新过的表格。

这五个工具单独看，没有一个选得差。杀毒软件是知名产品。备份供应商口碑扎实。问题从来不在于任何一个单点工具的质量，而在于公司买下的是一整套点状解决方案，各自把自己那一件事做得很好，却谁都不知道对方的存在。

五个互不相通的工具，对这种规模的机构究竟意味着什么代价

这种模式的代价，不会在哪一天突然爆发出来。它体现为摩擦、浪费和盲区——这类东西，往往要等到出事那一刻，人们才会注意到。

没有人掌握全貌。 问办公室经理、问合伙人、问IT支持商"我们现在完整的IT环境是什么样子"，每个人都只能从自己那一个角落回答。支持商知道自己关闭了哪些工单。备份供应商知道自己在备份什么，但不知道这是否和实际部署的情况一致。没有人有完整地图，因为压根就没有哪套系统是为承载这张地图而设计的。

出问题时，第一步是打电话找人，而不是排查修复。 一旦出事——某台笔记本被入侵了，备份悄悄停止运行了，某位离职员工的权限没被收回——第一步从来不是诊断，而是先搞清楚这是五家供应商中哪一家的问题，然后打电话过去，再等对方确认这确实是他们的问题、不是别人的。一起同时波及终端和备份系统的安全事件，意味着要分别给两家从未打过交道、也没有任何共享记录的公司分别打电话。

授权浪费藏在明面上，却没人发现。 这是最不易察觉、但从金额上讲往往最大的一项代价。为几个月前就已离职的员工购买的软件授权，还在继续付费。为一个早已结项的项目预留的坐席，还挂在账上。备份档位是按公司过去某个数据量设定的，业务扩大或收缩之后从没人重新调整过。五家供应商没有一个有动力提醒你这件事——每家的后台只显示自己那一款产品，一个没人用的授权，在系统里照样显示为"生效中"，照样每月扣费。要发现这种浪费，需要有人手工核对五套互不相通的系统——实际情况是，从来没有人真的去做过。

覆盖缺口只有在暴露它的那次事故里才会显形。 一台设备被更换了，旧的远程访问代理却从没被卸载——它仍然运行在一台放在储藏室里的机器上，仍然是一个有效的入口，而没有哪套库存系统能够捕捉到这一点，因为没有一套系统会去追踪"什么设备上到底装了什么"。一位新员工入职第一天就有备份覆盖，因为有人记得手动配置好；另一位新员工却没有，因为没人记得。这些并不是某一家供应商工作没做好，而是没有任何东西把各个环节连起来的必然结果。

续约条款和定价各自漂移。 五份合同各自有五个不同的续约周期，是由当年碰巧在处理这家供应商事务的人分别在五个不同时间点谈下来的，这意味着没有人对公司在IT上实际的总支出有一个统一的视角，更谈不上把它们打包起来去谈判的筹码。

我们的看法：整合到一个平台的理由，不是账单变小

当客户带着这个问题来找我们时，他们本能地期待听到的说法是"整合起来能省钱"。这其实并不是最有力的论点，我们也不会以此作为切入点，因为它并不总是成立——单一供应商打包的价格，未必比原来那几个点状方案加起来便宜多少，而客户对纯粹靠"省钱"来推销整合的说法保持怀疑，是有道理的。

真正的论点是结构性的：互联的工具能够看到孤立工具在设计上根本看不到的东西——这跟任何一个单点工具本身做得好不好没有关系。

一款杀毒软件，无论多好，也只知道终端上的威胁。一款备份产品，只知道备份任务本身。二者都无法告诉你，某台报出安全警报的笔记本，正是上周备份悄悄失败的那一台——因为它们从一开始就不是为了互相比对而设计的，是来自不同公司、没有共享数据模型的不同产品。这不是靠各买一个更好版本的工具就能解决的问题。这是运行互不相通系统的结构性局限，无论单个供应商的产品做得多出色，这个局限都不会消失。

这也正是博迅对自家托管IT平台所持的看法：它不是在导入时临时拼凑起来的若干第三方产品，而是运行在博迅自主构建、端到端运营的同一套引擎之上，各模块之间的数据是互通的，因为它们从一开始就是这样设计的。有两个具体的例子能说明这带来了什么：我们安全审计模块里的许可证治理功能，能够标记出一个已经采购付费、却没有在任何设备上实际使用的软件坐席——因为追踪已安装软件的同一个平台，也在追踪授权配额，两者可以互相比对。资产生命周期追踪则意味着，硬件和软件的更新决策是根据设备实际的使用年限和状态做出的，而不是靠某个人当年设的一个日历提醒——这既能防止把状态还好的设备提前更换，同样也常常能避免误续费本该退役的东西。

这两件事，放在任何一个单独的点状方案内部都做不到，无论它本身做得多好。它们需要两个不同的功能能够同时看到同一份数据。这才是"一个平台"的真正论点：不是它在纸面上更便宜，而是它能在结构上做到一堆各自单独采购的工具做不到的事——因为它从一开始就是为此而生的。

一次整合审计实际上会发现什么

为了让这个论点更具体，而不只是停留在抽象层面，下面是这类审计在把这种规模的机构从分散工具迁移到统一平台时，通常会发现的东西——同样是一个复合案例，不是某个具体客户的真实数字。

通过许可证治理发现的闲置软件坐席。 回到前面那家七十人规模的机构：核对已配置授权与设备实际使用情况后，会发现一批坐席——数量往往超出公司的预期——仍在为几个月前就已离职的员工继续付费，或者对应着一个早已悄悄结束的试点项目。没人取消它们，是因为取消一个授权首先需要有人注意到它没被使用，而注意到这件事，需要交叉核对两套从来没被设计成可以交叉核对的系统。在一个互联的平台上，同样这套在新客户导入阶段用来标记这些问题的许可证治理检查，会持续运行下去，所以这些浪费不会在六个月后悄悄卷土重来。

已停用设备上仍装着的旧版远程访问工具。 这既是一个安全问题，也是一个成本问题。设备在日常业务中会被更换——一台笔记本坏了，有人升级了设备，一台机器被挪作他用——而在这个过程中，原本让供应商远程连接进行支持的旧版远程访问软件并不总是被卸载，因为卸载它从来不是任何人明确的职责。一台放在储藏柜里、还装着有效凭证和活跃远程访问代理的设备，依然是一条可以进入的通道。一套能把每台设备和每个已安装工具对照起来看的资产管理视图，能够捕捉到这类缺口，因为它就是为此而设计的；而五个各自只看到自己那一小块的独立后台，在结构上根本做不到这一点。

只有当一切都汇总到同一个地方时才会显形的备份覆盖缺口。 在工具分散的版本里，备份覆盖情况完全取决于当初配置每台机器的人做了什么设置，逐台机器各不相同。一旦终端库存和备份状态汇报到同一个平台，那些原本看不见的缺口——一台压根没配置备份任务的笔记本，一个悄悄失败了好几周却没人注意到的备份任务，因为没人盯着那家供应商独立的告警后台——就会变成一份清单，而不是等到某次恢复失败时才被意外发现。

这些发现都不需要什么高深的工具。它们只需要同一个平台同时掌握每一组对比中的两端——已安装软件与授权配额、设备与备份任务、终端与远程访问授权——而这恰恰是一堆各自单独采购的点状方案在结构上做不到的事情。

临时拼凑 vs 打包分销商 vs 一套互联引擎

考虑整合的机构常常以为选择只有两种："维持现状"或者"买一个打包方案"。其实存在有意义的第三种选择，而第二种和第三种的区别，只有在越过账单本身去看时才会显现出来。

三种模式的对比

点状方案堆叠（"每一项都用最好的工具，各自单独管理"） —— 每个单独的工具本身可能确实是一款优秀产品。但没有任何东西把它们连起来：许可证数据在一个后台，设备清单在另一个后台，备份状态在第三个后台，没有人拥有一个横跨所有系统的统一视角。浪费和缺口一直隐形，直到某次事故或审计逼着有人手工核对五套系统。
打包分销商（一张账单，后端依然互不相通） —— 有些供应商乐意把你的账单合并成一张月结单，同时继续转售那些原本各自独立的底层产品，每一个依然运行在自己的后端上，用着自己的数据模型。这只解决了"五个客服电话"这一个问题，别的什么都没解决。许可证治理检查依然看不到备份系统，因为在这一张合并账单的背后，工具之间彼此对话的方式其实什么都没变——也就是说，它们依然互不相通。
一套互联引擎（我们打造自家托管IT平台时的目标） —— 一个单一平台，资产清单、许可证配额、备份状态、工单系统和远程访问授权，是同一套系统里的各个模块，而不是来自不同公司的各自产品。一条审计记录，取代五条。一项真正能看到"已安装"与"已授权"是否一致的许可证治理检查，因为这两份事实存放在同一个地方。一次事件响应只需一通电话，而不是打一圈电话找人，因为接电话的工程师手上已经掌握完整信息，而不需要先向另外四家供应商分别打听。

坦白说明一点：从五家供应商切换到一个平台，是一个真实的项目，不是拨一下开关那么简单。现有合同需要跑完剩余期限或正式过渡，员工需要适应新的支持渠道，如果一家机构和现有点状方案供应商确实关系不错，也有理由把这一点放在天平上，和上面这些结构性论点一起权衡。当一家机构已经能指出上述问题里至少一项——一个没人说得清用途的授权、一次要打三通电话才能诊断清楚的事故、一次靠吃亏才发现的备份缺口——整合的理由就最站得住脚。

这在托管IT关系中处于什么位置

这不是一款可以单独购买的产品，而是整个IT关系运作方式的形态。它作为底层平台内嵌在托管IT支持之中，而不是挂在另一套体系之外的附加模块。其中终端那一半——为许可证治理和资产追踪功能提供设备级数据的远程支持与安全审计代理——是BCS Beam，被包含在博迅的托管IT方案中，而非单独出售，因为一个只能看到公司部分设备的平台，无法对其中任何一台设备给出完整的图景。

对于在"完全外包"和"自建IT团队"这两端之间的机构，同样的互联平台逻辑也可以通过一种托管服务安排来获得，与现有的内部团队协作，而非取而代之。无论采用哪种方式，这种结构性优势——一套能够比对授权配额与实际使用情况、设备与备份覆盖情况、终端与远程访问授权的系统——来自于平台本身，而不是叠加在其上的支持模式。

博迅自2007年起在亚洲运营，2021年起总部设在新加坡，2016年起在香港设有办公室。五十到一百人规模的律师行、会计师行、咨询公司这类专业服务机构，正是我们经常合作的一类客户，这也是为什么"工具一件一件买、直到没人能看清全貌"这个特定模式，我们能一眼认出来，而不是每接到一个新客户就要重新摸索一遍的原因。我们各市场的方案及各档位包含的内容，都列在定价页面上。

常见问题

把所有东西都放到一个供应商身上，风险不是更集中吗？

这是一个合理的本能反应，但它把两件不同的事混在了一起：供应商集中和系统集中。整合到一个互联平台，确实会把支持关系集中到一家公司身上。但这并不意味着技术上的单点故障风险会比原来五家供应商更高——某种程度上反而更低，因为一个互联平台可以在设计上就考虑冗余，并作为一个整体系统被统一监控，而五套各自独立的点状方案，每一套都各自承担着独立的故障风险，却没有人盯着它们之间的缝隙。面对提出整合方案的供应商，值得问的问题不是"如果你们出问题了怎么办"，而是"你们的冗余设计是什么样的，如果合作不顺利我的退出路径是什么"——不管你现在用几家供应商，这都是一个合理的问题。

过渡期间，现有的工具合同怎么处理？

这取决于每份合同当前所处的阶段。大多数整合项目是分阶段进行的：新工具先与旧工具并行上线，数据和配置逐步迁移，等确认新平台运行正常后，旧合同再让其自然到期或正式终止，而不是一个周末就全部切换过去。一个负责任的托管IT合作伙伴会提前把你现有合同的到期日和整个过渡计划对照起来，这样你就不会不小心为六个月的重复覆盖多付一份钱，也不会在合同还没到期时就被要求直接放弃，却没有任何应对计划。

这样的整合，实际上要花多长时间？

这取决于机构规模，以及现有工具堆叠得有多复杂，但对于一家五十到一百人规模的机构而言，核心过渡阶段——终端代理部署完成、备份迁移完成、工单和远程访问切换过来——通常是以周为单位完成的，而不是以月为单位，前提是先经过一个摸底和梳理的阶段。发现闲置授权和覆盖缺口的审计（也就是上文描述的那类发现）通常发生得很早，往往就在导入的最初几周内，因为将来长期运行这个平台的同一套工具，正是执行那次首轮审计的工具。

这会不会比现在付给五家供应商加起来的钱还多？

有时会，有时不会——这真的取决于具体要替换的是哪些工具，以及这家机构目前在多少没人用的授权上花了冤枉钱，而这一点审计本身通常就能揭示出来。我们不会把"账单上的数字会变小"当作说服你这样做的理由，因为这个承诺并不总是成立，机构对以此为卖点的供应商保持怀疑，是有道理的。更有力的论点在于，这个互联平台能看到、能做到的事情，是五个各自独立的工具在结构上做不到的——授权浪费、覆盖缺口、一通电话就能响应的事件处理——不管总额和你以前付的钱相比是多是少。

我们能不能保留一个自己确实喜欢用的工具？

有时候可以，但这会削弱整合的核心论点——价值来自工具之间数据互通，而不仅仅是来自向更少的公司采购。一个被单独保留在互联平台之外的工具，会为它自己那一块重新引入整合原本就是要解决的那个盲区——它不会出现在和其他一切一样的许可证治理检查或资产清单视图里。如果一家机构确实有充分理由保留某个工具，这是一个合理的取舍，前提是大家都清楚，这一部分会留在统一图景之外。

"一条审计记录"在实际操作中到底意味着什么？

它意味着有一份单一记录，涵盖了原本会分散在几套互不引用的独立供应商日志里的信息。具体来说：有一个地方能显示有哪些设备、每台上装了什么、备份是否是最新的、谁拥有远程访问权限以及何时使用过，还有哪些授权已配置、哪些实际处于活跃状态——而不是来自五个独立后台的五个各自的答案，需要机构自己在每次审计或事故要求全貌时手工去核对拼凑。

如果贵机构目前账面上能数出两三家以上的IT供应商，又说不准正在付费的授权是不是真的都在用，这通常就是值得采取行动的信号。联系我们，我们可以一起梳理一下，对贵机构目前的工具堆栈做一次审计，大概率会发现什么——无论最终是否与我们合作整合。