我前面写过三篇：为甚么要把数据从 POS 解耦、轻 POS 终端该留甚么、餐饮集团甚么时候需要数据中台。那三篇都在讲「系统应该怎样设计」。
这一篇讲的是另一件事：当你真的决定把旧系统换掉，门店里到底会发生甚么。
很多餐饮集团在签约新系统之前，最担心的是资料。供应商也很会安抚：「别担心，我们可以安排汇出，CSV、API 都给你。」听起来，换系统最难的部分是资料搬运，搬完就天下太平。
我见过太多次，这句话让人低估了真正的工作量。
资料汇出有机会在一个周末完成，但资料清理、核对与业务接续，通常不会同时结束。门店的动作记忆，也不会在同一个周末重置。
新系统上线第一天，收银员找不到退单按钮，店长不知道折扣权限在哪里。星期五晚市尖峰来了，旧系统的肌肉记忆还在，新系统的操作仍未熟悉。这才是换系统真正的成本。
而且最麻烦的是：项目计划通常写得很漂亮——整理商品、汇入会员、接好支付、培训店员、选一天切换。但晚市最忙的时候，顾客要求换一道菜，原单已付款、后厨已开始做，店员要找谁批准？厨房怎样收到改动？差额怎样处理？交班时，下一位同事从哪里知道这张单发生过甚么？
这些，项目计划往往没有写清楚。
旧系统里，有些流程从来没写进系统
一间店用同一套系统几年，员工会慢慢摸出自己的做法。
某些退款要找店长；某类套餐不能直接改，要先取消再重开；外卖平台的订单出了问题，要去另一台平板处理；交班有差额，先在纸上记下来，收店再对。
其中有些是合理的营运安排，有些只是为了绕过旧系统的限制。麻烦在于，两者往往混在一起。
如果只照着旧画面逐项搬，新系统很容易把旧问题重新做一次。但如果一句「新系统不是这样操作」就全部推翻，原本靠店长和熟手维持的工作，也可能突然没人接。
所以换系统前，除了问「有甚么功能」，还要问一句：这件事平时怎样完成？出了例外，又由谁收尾？
不是所有资料，都要用同一种方式搬
不是所有资料都需要在新系统第一天以同一种方式「活着」。开始之前，至少要分清三类。
第一类，是上线必需的资料与配置。 菜单、价格、门店、员工权限、支付及后厨分单设定，需要在切换前对齐。但汇入成功，不代表实际操作一定正确；套餐选项、分时价格和门店差异，仍要逐项验证。
第二类，是历史查询资料。 过往订单、发票和报表要保留多久、放在哪里，应按营运、财务及合规要求决定。门店需要的是在有需要时查得到，不一定是把全部历史交易变成新系统里仍可修改的订单。
第三类，是仍在延续的业务与权益。 未完成订单、待处理退款、会员点数、余额及优惠权益，不能只核对汇入笔数。除了完整核对总额和记录，还要抽样验证顾客能否按原有规则正常使用。
配方和库存亦要先问清楚由哪个系统负责。配方是品牌的重要资料，但不一定要绑在每一台交易终端；库存则要知道切换时点、更新来源，以及未完成的入货和扣减怎样接续。
这里有个前提：如果你当初没有做数据解耦，今天连「干净地搬」都会更困难。资料和逻辑绑死在旧系统里，汇出来的可能只是一批仍要重新理解和整理的栏位。
搬得完整，不是把所有资料都塞进新系统，而是每一类资料都有去处，每一件未完成的事都有人接。
不要只搬商品和会员，要把一张单走完
回到那张已付款、已送厨房，又需要换菜的订单。
新系统可能每项功能都有，连起来却仍然不顺。前台改好了，厨房没有收到；退款完成了，订单状态却没更新；记录存在后台，当班的人没有权限查看。
我会要求团队沿着一个班次走，把下面几个接点逐项确认——这比只看功能清单有用：
| 环节 | 资料搬到了，仍要确认甚么？ |
|---|---|
| 售罄／沽清 | 门店设定后，各渠道是否同步成功？失败由谁跟进？ |
| 点餐规格 | 加料、套餐选项与备注，后厨能否正确理解？ |
| 后厨分单 | 是否按门店实际出品分工配置，而非只套总部预设？ |
| 退款与改单 | 当班是否有人具备适当权限，操作能否留下记录？ |
| 交班对账 | 营业日、交易日与平台结算日的差异，是否有人解释和核对？ |
举个我常提醒的坑：平台还未结算的款项，不应只因为未到帐就被当成收款差额。要先知道比较的是哪一段时间、哪一种金额，再追查真正的异常。
功能齐全，和一件工作能完整收尾，是两种验收。
系统切换周：门店不能停接单
系统切换（cutover）不是按一个开关。门店不能因为换系统，就把所有营运停下来。
实际安排可以是逐店切换，也可以在风险可控的情况下一次切换。重点不是哪种方法看起来更干脆，而是有没有选择具代表性的门店和时段，先验证真实流程。
过渡期间，有些集团会让新系统负责新交易，旧系统只保留历史查询。但有一条界线必须画清楚：同一项业务事实，当下由哪个系统负责。
新订单在哪里建立？切换前订单的退款在哪里处理？会员余额何时转换？两边数字不一致时，由谁核对？如果没有这些安排，最后不是系统在并行，而是员工重复输入和人工对数。
历史查询和营运回退也要分开。旧系统即使仍可查阅，也不代表能安全接回营业。切换后产生的新订单、付款和会员变动怎样保留、怎样核对，都要在回退方案里写清楚并事先演练。
回退需要在多长时间内完成、旧系统保留多久，应按门店规模、交易复杂度和中断风险决定，不应只用一个固定期限套用所有项目。
开店前的最后一轮检查亦不能省：价格载好了吗？菜单同步了吗？支付终端测过了吗？离线模式验过了吗？轻 POS 的价值在这时才真正出现——终端该留的责任留住了，切换风险才压得下来。
上线后：门店在哪里卡住
上线日不是终点。很多问题要等到支援人员离场、不同班次开始独立操作，才会出现。
培训的对象通常是店长和管理组。但真正在收银台前面对顾客的，可能是晚市的兼职同事或刚入职的员工。他们需要的不只是一次培训，而是清楚的正常流程、例外处理方法，以及在现场找得到的支援渠道。
报表对不上，是另一个隐形问题。新系统对折扣、退款、税项和营业日的定义，可能和旧系统不同。这不一定是程式错误，但如果差异没有人解释，财务和门店很快便会失去信任。
这段时间，店长往往在当翻译：把旧流程里真正必要的部分，翻译成新系统的操作；同时指出哪些旧做法只是补洞，不应原样保留。
所以，上线支援不应只在切换当天出现。应该维持到门店能独立完成关键流程，而不是到某个预设日期便撤走。
试点门店也别只挑人手最齐、店长最熟悉系统的一间。堂食为主的店跑通了，不代表外卖繁忙的店也能照搬；店长全程在场跑通了，也不代表普通班次可以独立完成。
试点的价值，是找出不能直接复制的地方，不是证明项目已经成功。
上线之后，看门店有没有另外补一套
总部看到订单进来、报表出到，可能就认为换系统完成了。
门店却可能另外维持一张表，记退款、补偿和交班事项；店长继续在群组里批准操作；新系统只负责把最后结果补录进去。
这些额外做法，不一定全部有问题。有些是短期过渡，有些则是在提醒：正式流程仍然接不住工作。
不要急着要求员工把额外表格删掉。先看里面记了甚么，往往比再开一次培训更容易找到缺口。
验收时，除了看系统是否正常，我会看四件事：
- 一张有例外的订单，能否从发现问题一直处理到收尾，而不用反复人工转述？
- 当班员工能否在权限内处理，或清楚找到有权负责的人？
- 交班与对账的差异，是否有记录、可解释、有人跟进？
- 支援人员不在现场时，门店能否靠既定流程与支援渠道完成一个普通班次？
如果仍然需要项目组天天代做，就不能把这部分工作当成已交付。
换系统前，先过这份清单
如果现在就要动手，我会先确认六件事：
- 资料有没有分类？ 哪些第一天必须使用、哪些保留查询、哪些未完成业务需要接续？
- 流程有没有真正走过？ 是否用一个真实班次，从开店、尖峰到交班完整演练？
- 回退有没有演练？ 出现重大问题时，谁决定、怎样切换、新产生的交易怎样保留？
- 数字差异能否解释？ 新旧系统的折扣、退款、税项和营业日口径是否已对齐？
- 试点是否具有代表性？ 是否涵盖不同渠道、菜单复杂度和人员配置？
- 门店能否独立运作？ 支援撤走后，普通班次能否完成交易、例外处理与交班？
如果集团已经走到需要数据中台的规模，换系统更不能只看成 IT 项目。中台是底座，门店是现场；底层能力改了，现场的每一项工作仍要重新验证。
写在最后
换系统，表面上是搬资料，实际上是搬一个仍在运作的营运现场。
资料搬运或许只需要一个周末，真正花时间的，是让不同门店、不同班次和不同角色，重新建立一套能运作、能交班、也能处理例外的流程。
所以下一次有人说「资料可携很简单，我们帮你汇出」，你可以回他：资料我信你，但把门店流程接上这件事，我们要一起排进计划里。
把换系统当成现场营运工程，而不是一次技术搬运，集团才会预留对的人、时间与预算。
