香港Hypercare IT支持：ERP上线计划

周一早上的上线问题，大多数不是ERP缺陷。它们是标签打印机、扫描枪驱动、权限设置，以及找不到新界面的员工。香港Hypercare IT支持（上线强化支持）让工程师在固定时间窗内驻场、收紧监控、开通直达的升级通道，并以书面交接转入日常支持。

公司，以及一切改变的那个周末

设想一家香港的贸易与分销公司，约九十名员工。公司从中国内地和东南亚的供应商进口消费品和轻工产品，卖给零售商、承包商和网店卖家。员工分在三个地方：销售和财务办公室占据商业大厦的一层，仓库在九龙东或葵涌的一幢工业大厦里，还有几位采购经常过关到供应商的工厂，靠笔记本电脑和手机办公。

过去十一年，公司一直跑在一套老旧的会计软件、一份悄悄变成“正式记录”的库存表格，以及散落在共享邮箱里的订单表单上。财务团队每个月结账要花将近一周，因为每个数字都得手工核对。财务总监终于批准了新的ERP，一个把订单、库存、采购和总账放在一起的集成平台。实施伙伴已经签约，切换定在一个周末：周五晚上冻结，通宵迁移数据，周日验证，周一早上所有人登录新系统。

本文写给发起这个项目的人，通常是财务总监，有时是营运总监。先说明一点：这是一个说明性的综合场景，并非某个具体客户。它取材于香港贸易分销公司里常见的一种处境，关于这家公司的所有数字都是为了便于计算而设定的假设。

公司只有一位内部IT，我们叫他IT主任。他能干，熟悉每一台电脑和每一个密码，平常一周已经忙到饱和。项目计划里，没有人写下周一谁来帮他。

这个遗漏就是本文的主题。ERP大体上会正常运转。问题是，九十个人同一时刻学习新的工作方式时，围绕ERP的一切由谁来照看。

ERP上线时，谁来修什么？

先看一个简单的事实：上线不是一件事，而是同一个几天内发生的一长串小事，它们分属不同的负责人。

ERP实施方负责什么

实施伙伴负责ERP本身，包括配置、数据迁移、会计科目的准确性、流程、报表、关键用户培训，以及应用程序的缺陷。采购订单税额算错、库存移动没有过账，这是实施方的问题，好的伙伴会安排人手应对。

合同通常就是按这个范围写的，这也有道理。实施方不可能对公司的笔记本电脑、仓库Wi-Fi或五年前买的标签打印机负责。这些东西不是他们选的，他们看不到，上线期间他们的人也往往不在香港。

现场没有人负责的事

再看一个真实的周一早上，仓库和办公室里会冒出什么。大致是这些：

仓库的标签打印机打出旧格式，因为驱动程序没有为新标签模板更新。
手持扫描枪连上了Wi-Fi，却到不了新系统，因为某条防火墙规则或证书不在项目清单上。
财务有六个人能打开新系统，却看不到总账界面，因为角色权限是按一份过期的表格映射的。
销售团队的笔记本习惯性打开旧的共享盘，文件继续存错地方。
一位用户的单点登录提示不断循环，是浏览器设置的问题，她连登录页都进不去。
银行接口或快递对接原本悄悄运行，现在需要新的凭证，而持有人正在休假。
有人点了旧的快捷方式，什么也没找到，就告诉行政主管“系统挂了”。

这些没有一个是ERP缺陷。但对于站在卡住的界面前的那个人来说，几乎每一个都像ERP缺陷，所以它们汇成一股不加区分的投诉。财务总监看到的是“ERP挂了”，于是打电话给实施方，实施方得花时间证明不是它的问题。

造成损害的那道缝

这就是实施方范围与现场其他一切之间的缝。这不是谁的错，而是项目的组织方式（围绕一个系统）与上线的体验方式（围绕一个想把活干完的人）之间的错位。

内部IT是唯一跨越两边的团队，也是余力最少的团队。IT主任同时是项目的技术联络人、用户卡住时第一个被找的人、必须保证其余业务照常运转的人，以及要向董事会解释哪里出了问题的人。我们这家公司的IT主任已经两个月夜里在写切换清单。到周一上午十点，他已经被打断了四十次。

如果这听起来像你的项目，有用的问法不是“我们需不需要更多IT”，而是“在一个明确的时间窗内，谁实际站在现场、有权限动手解决，以及IT主任需要第二双手时该找谁”。

什么是Hypercare IT支持？

Hypercare是围绕ERP上线、重大技术部署、新办公室开业这类高风险事件的短期高强度支持服务。博迅在Hypercare IT支持服务页面上把它描述为：在关键窗口期内，由经验丰富的工程师实际驻场。下面用平实的话说明服务页面所述的内容。

工程师在用户身边驻场

上线窗口期里，工程师与员工并肩工作，在现场实时解决问题，防止它们升级成拖慢上线的事故。在我们的场景里，就是标签打印机和扫描枪的问题。有人就站在出问题的人旁边，几分钟内解决，而不是等工单在队列里走一圈。

窗口期内收紧监控

Hypercare期间，监控阈值会收紧。服务页面说明，具体是更快的轮询间隔、更低的CPU和内存基线，以及对任何异常（而不只是严重异常）立即告警。道理很简单：平时负载高了十分钟才告警是合理的；上线期间，十分钟的卡顿就是全部的故事，因为所有人都在同时试用新系统。

直达的升级通道

一条专属的电话和聊天通道，把你的运营团队直接接到博迅的高级工程师和管理层，不排队，也没有语音菜单。服务页面称其在Hypercare窗口期内全天候可用。这很重要，因为棘手的问题往往出现在一天的边缘：周日晚上验证的时候，或者周一早上七点办公室还没坐满的时候。

作战室

博迅在上线期间设立虚拟或现场的作战室，让相关工程师和你的干系人在同一个沟通频道里，协调和决策都在一处完成。对一家有海外实施伙伴、财务总监、仓库经理和IT主任的公司，一个统一的频道比听起来更有价值。它避免同一个故障被用三种说法报给三个不同的人。

每日简报和有结构的收尾

每日Hypercare简报涵盖已提出、已解决和处理中的事故，项目发起人不用开口问，就能看到上线的健康状况。Hypercare以正式交接结束：完整的事故日志、经验总结文档、已知问题登记表，并确认日常监控和升级通道已上线并经过测试。收尾部分最常被跳过，我们下面再回来谈。

服务页面没有写的内容

页面没有给出日费率、套餐价格或标准时长。它描述的是四个步骤：范围界定与情况说明、工程师部署、Hypercare执行期、转入日常运维，并说明窗口期、系统范围、用户数量和风险领域在第一步确定。本文沿用这个思路。下面给出的人数或时长，都是这家说明性公司的假设，不是博迅公布的数字。

需要几位工程师、多少天、哪些班次？

规模估算是Hypercare决策最容易做错的地方：不是出于恐惧买多了，就是为了压缩预算买少了。更好的办法是从需求的形状出发。

从人和地点出发

需求不是平均分布的。它集中在两处：人们第一次使用新系统的地方，以及硬件接触新系统的地方。对我们的公司来说，就是仓库现场（扫描枪、标签打印机、共用终端，用户不习惯坐办公桌），以及财务办公室（权限和总账，用户非常习惯坐办公桌，任何错误都逃不过他们的眼睛）。

公司约九十人，假设其中六十人每天使用系统，三十人偶尔使用。这些是我们在示例里沿用的假设。

一个明确标注为假设的计算示例

下面的人手安排是这家说明性公司的，不是博迅的规则。它展示了一个双地点、九十人的公司，计划可能是什么样子。

仓库：前三个工作日派一名工程师，因为这里设备最多、对停摆最不能容忍。之后每天短时间上门。
办公室：前三个工作日派一名工程师，覆盖财务、销售和共用设备。之后工程师在办公室和仓库之间分配时间。
升级通道与监控：整个窗口期都启用，让现场工程师遇到异常情况可以随时拉高级工程师支援。
IT主任：受到保护。他依然是公司系统的负责人，不用去管现场的杂事。工程师接手队列，他来做决定。

也就是前三个工作日两名工程师，之后一名，全程有高级工程师远程支持。这是一个讨论的起点，不是建议。你自己的数字取决于有几个地点、第一天有多少用户的工作方式变了、有多少实体设备依赖新系统，以及你已有多少远程能力。

窗口期应该多长？

有两件事决定长度。第一是适应曲线：支持需求在第一天最高，随着大家熟悉界面而下降。第二是第一次月结，这是ERP真正受到检验的时刻。窗口期如果在第一次月结之前结束，财务团队就会在最需要帮助的时候无人支援。

在这个场景里，合理的计划是：前三个工作日重点驻场，头两周其余时间轻度驻场，监控和升级通道一直开到第一次月结完成。这是对这家虚构公司的判断。对你的公司，范围界定这一步的意义就是用证据而不是猜测来做这个决定。

哪些班次？

班次要匹配人们实际工作的时间。早上七点开始装货的仓库，需要工程师在那之前到场，而不是九点。月结当晚要加班的财务团队，晚上需要一位联系得上的工程师。工程师不在现场的时段，由升级通道兜底。

香港还多一个考虑：双语覆盖。仓库主管更习惯用粤语，实施方的顾问用英语工作，内地供应商联系人用普通话。能在这些语言之间顺畅切换的工程师，节省的时间很难量化，却很容易感受到。

最初72小时是什么样子？

下面是我们场景的逐时计划。细节属于这家说明性公司，但工作的先后顺序对周末切换来说很典型。

周五晚上到周六：还没人登录之前

工程师在冻结前到场，如果这个阶段是远程工作，则接入作战室频道。他们听取切换计划和在范围内的系统清单的说明。监控阈值收紧。升级通道通过一次测试电话确认，作战室频道建立，实施方、财务总监、仓库经理和IT主任都在里面。

第一项有用的工作，是把所有接触新系统的东西做一次实物盘点：每把扫描枪、每台标签打印机、每个共用终端、每台分配给关键用户的笔记本。这项工作枯燥，却恰恰是项目计划以为有人做过的那一项。

周六：迁移之夜与第一轮测试

实施方迁移数据的时候，现场工程师对着测试环境逐台设备检查：每把扫描枪能否连上系统，每台打印机能否打出新标签，每位关键用户能否登录。任何失败都记下、修复、复测。周六连不上的扫描枪只是不方便；同一把扫描枪周一早上七点在码头失败，旁边还有一辆货车在等，就是一起事故。

周日：有安全网的验证

关键用户验证自己的界面，权限问题就是在这时暴露出来的：财务团队看不到总账界面，仓库主管无法审批库存调拨。每一项都登记在作战室里，分配给对的负责人（角色映射归实施方，设备和访问归工程师），在当天结束前关闭。

周日晚上，工程师和项目发起人开一次简短的就绪评审，列出哪些已就绪、哪些已知未解决、每个未解决项的临时办法。原则是：不要有意外。

周一早上七点到十点：高峰

计划经受检验的时刻到了。工程师在第一班之前已经在现场。仓库的工程师站在收货码头旁，办公室的工程师在财务区，两人都在作战室频道里。

这个时段最常见的求助，就是前面列的那些：找不到界面、设备掉线、权限不对。它们当场解决。真正属于ERP缺陷的，会连同已收集好的证据转给实施方，让实施方把时间花在缺陷上，而不是花在证明这不是网络故障上。

周一中午到周二：长尾

第一个早上的高峰过去，出现了另一种模式：凭直觉熬过早上的人，现在碰到第二层问题。导不出来的报表；扫描件挂在错误的记录上；快递对接需要新凭证。当天结束时的每日简报列出已提出、已解决和仍未解决的事项。财务总监读到的是未解决问题的数量在下降，而不是从焦虑的同事那里听来的。

到周二晚上，轮廓通常已经清楚。如果计划对了，需求已经在下降，工程师救火少了、教学多了，未解决的项目是一份简短而且清楚的清单。

实施方支持、内部IT单打独斗，还是Hypercare？

覆盖一次上线，现实中有三种方式。下面用发起人最关心的几个问题来比较：谁修什么、持续多久、结束时还剩下什么。

ERP实施方的上线后支持

谁修什么：ERP应用程序，包括配置、数据缺陷、流程和报表。设备、网络、打印机，以及应用之外的用户访问，通常不在合同范围内。
持续多久：合同怎么写就多久，往往是上线后的一段约定时间，而且通常是远程交付，现场时间有限。
结束时剩下什么：一个稳定的应用，以及一份未结缺陷清单。实施方的记录只覆盖ERP，别的什么都没有。
最适合：应用问题。它是这类问题的正确负责人，无论如何都应该让它保持在沟通链里。

只靠内部IT

谁修什么：理论上是一切。实际上是IT主任先够得着的东西，按嗓门最大的人的顺序。
持续多久：要多久就多久，也就是IT主任的夜晚和周末。
结束时剩下什么：一位非常疲惫的IT主任，没有独立的事件记录，而且如果他辞职，知识会跟着他走。
最适合：用户只有寥寥几人的小型切换，IT主任确实有余力，而且上线不涉及太多实体设备。

Hypercare服务

谁修什么：现场，也就是设备、打印机、扫描枪、访问、连接、用户指引和监控，对应用缺陷则有直通实施方的清晰渠道。
持续多久：一个明确的窗口期，在范围界定时约定，有明确的终点。
结束时剩下什么：正式的交接包，包括事故日志、已知问题登记表和经验总结文档，并确认日常监控和升级通道运作正常。
最适合：同时涉及很多用户和很多设备的上线，而内部IT已经满负荷。

这三者与其说是互相替代，不如说是三个层次。实施方管应用，内部IT管公司的系统，Hypercare是临时增加的人手，让两边在负荷最高的那几周都能把本职做好。

Hypercare什么时候结束？

没有终点的支持窗口不是Hypercare，而是一份没计划好的外包安排，通常比有计划的更贵。在上线之前就约定好退出标准，才能让这次合作保持简短而诚实。

值得写下来的退出标准

标准因公司而异，但一份好的清单大致如下：

没有超过约定严重级别的未结事故，也没有阻止业务流程运转的未解决问题。
每日事故量已连续多个工作日低于约定水平。
第一次月结，或同等意义上的第一个完整业务周期，已经完成，没有现场级的阻碍。
日常监控已上线，告警阈值回到标准值，并且一次测试告警已送达正确的人。
日常运维的升级通道已经端到端测试过，而不是只写在文档里。
发起人读过最终简报，并认可剩余事项可以接受。

这份清单应当书面约定，这样决定收尾就成了对照标准的检查，而不是一场谈判。

交接包

服务页面列出了转入日常运维时包含的内容，值得当作检查清单来用。

事故日志：每一个提出的问题、如何解决、花了多长时间。一年后，它会解释为什么某个设置是现在这个样子。
已知问题登记表：仍未解决的事项，谁负责，临时办法是什么。
经验总结文档：上线暴露了环境、培训和流程的哪些问题，趁记忆新鲜时写下来。
日常运维支持的确认：监控和升级通道已上线并经过测试，这样工程师离开的第二天，有人知道该打给谁。

交接包的意义在于，知识属于公司。如果IT主任半年后辞职，上线期间发生了什么，并不只存在于他的脑子里。

Hypercare的费用，与延误一次月结相比如何？

我们不报价，因为博迅的Hypercare页面没有公布价格，而价格取决于范围。你可以通过范围界定的沟通获得报价；博迅的价格页面也展示了它在公布价格的服务上是怎样列出费率的。这里更有用的，是如何权衡这笔费用。

用你自己的数字，和糟糕的第一个月的代价比一比。问五个问题：

如果仓库半天发不了货，滑期的订单价值是多少？
如果第一次月结要花两周而不是一周，财务时间的成本是多少，又有哪些决策在等这些数字？
如果财务总监头一周变成项目的投诉热线，而不是在管财务，有什么事没人做？
如果IT主任在上线后过劳或离职，替换他并找回他所掌握的知识要多少成本？
如果客户在第一周收到迟到或错误的货，对客户关系的代价是什么？

你不会有精确的答案，也不需要。只要其中任何一项的代价，看起来比一次短期、明确范围的合作更大，决定就已经清楚了。如果一项也没有，你大概不需要Hypercare，更轻的安排可能就够了。

第二种可能性值得认真对待。一个只有十五位用户、没有实体设备、内部IT人手充足的上线，也许不需要驻场工程师。Hypercare适用于负荷高、容错空间小的情形。

Hypercare是一次冲刺，之后现场靠什么运转？

交接里最重要的一句话，不是关于工程师离开，而是关于他们离开后的第二天有什么在位。

Hypercare有意设计成临时的，它在几周内抬高了支持水平。之后，现场需要一个稳定的模式，和公司实际使用的IT量相匹配，而这次上线会为你提供有力的证据：事故日志显示哪些问题反复出现、哪个地点来电最多、需求落在哪些时段。

常见的去向有三种：

定期加按需的模式。对IT需求不大的公司，定期上门加远程协助也许就够了。另一篇文章香港驻场IT支持的几种模式比较了驻场、定期和派单这几种做法。
一位专属工程师。如果事故日志显示，仓库加办公室的工作量足以让一个人忙起来，博迅的全职驻场IT支持提供一位指名的工程师，休假时有替补，并有博迅整个团队做后盾。
IT主任身后的服务台。如果压力出现在正常时间之外，24×7服务台以普通话、粤语和英语应答；博迅公布的数字是每年处理约15,000起事件，90%的来电在40秒内接通。

它们并不互斥，而是可以合并成管理型IT外包服务下的一个安排，而大多数走过一次Hypercare窗口的公司最终都会走到这里，因为他们刚刚发现，自家那位唯一的IT做了多少看不见的工作。博迅创立于2007年，总部位于新加坡，自2016年起在香港观塘设有常驻工程办公室。

常见问题

Hypercare应该持续多久？

没有公布的标准，博迅的服务页面也没有给出，因为窗口期是在范围界定时根据你的上线计划确定的。通常有两件事决定长度：头几天之后需求下降得多快，以及第一个完整业务周期（例如第一次月结）何时完成。在我们的说明性公司里，这意味着前三个工作日重点驻场，两周内其余时间轻度驻场，监控和升级通道一直开到第一次月结完成。请在上线前就以书面约定退出标准。

Hypercare只适用于ERP项目吗？

不是。博迅把Hypercare描述为适合ERP上线、重大技术部署、新办公室开业和高风险业务事件，服务页面列出的场景包括ERP、Microsoft 365、办公室开业和云迁移。共同点是：短时间内很多人和系统同时变化，而且失败的代价很高。

ERP供应商或实施方会提供这个吗？

现场层面通常不会。实施方负责应用：配置、数据、流程和缺陷。设备、打印机、扫描枪、网络和应用之外的访问，一般不在这个范围内，你可以在自己的合同里核实。有些实施方可以推荐或协调一家伙伴来做这件事。实际的做法是，书面询问实施方，他们的上线后支持具体包括什么、不包括什么。

100位用户需要几位工程师？

这更多取决于地点和设备，而不是人数。一百人在同一个坐办公桌的办公室，与一百人分布在办公室和一个满是扫描枪和打印机的仓库，是两种不同的问题。在我们说明性的九十人公司里，计划是前三个工作日两名工程师，之后一名，全程有高级工程师远程支持。这是示例的假设，不是规则。人数应当在范围界定这一步，依据你的用户数、地点和风险领域来定。