分阶段上线还是一次性切换？如何选择团队改用新业务系统的方式

大多数老板会花几个月决定新业务系统要做什么，却只花十来分钟决定团队该如何真正改用它。这十分钟的决定，也就是切换策略，决定了上线那天是平顺的星期一，还是一周的混乱、重复录入和丢单。切换策略宜在开发之前就定下来，而不是拖到开发的最后一周，因为这个选择会改变开发方要准备的东西：数据、账号、测试计划，以及哪些旧环节必须继续保留。

本指南写给已经或即将委托开发定制业务系统的中小企业老板和管理者。它比较四种切换方式，说明如何在其中做选择，并涵盖人们最常跳过的两件事：书面的回退方案和上线决策清单。这是一般性指导，不描述任何供应商如何推进上线，也不对上线日期或上线后的协助作任何承诺。这些内容应以您的书面报价为准。

它与您可能已经读过的几篇指南相衔接。开发要花多久，见定制业务系统需要多长时间。旧记录如何搬过去，见把您的数据迁入新系统。上线后几周如何让大家用起来，见如何让团队真正使用新业务系统。本文讲的是两者之间的决定：用什么方式、在什么条件下切换。

先问一个问题：糟糕的一天会造成多大损失？

每种切换方式，都是对同一个问题的不同回答：如果新系统在第一个真正的工作日出了问题，我们能承受多大的损失？靠 WhatsApp 接单的花店，损失一个下午还能恢复；靠发票决定下个月现金流的批发商就不行。在比较方式之前，先用大白话写下答案：

• 最先出问题的是什么？漏接订单、发票没发出、库存算错、工资延迟。写下最让您头疼的那一个。
• 我们能靠手工撑多久？一天、一周，还是完全撑不住。这决定了您必须多快能够退回去。
• 谁会受影响？只有员工，还是连客户和供应商也受影响。外部人员会让糟糕一天的代价急剧上升。
• 旧办法能继续运行吗？如果旧的电子表格或旧工具可以继续使用，您的选择会比旧办法将被关闭或本来就不可靠时多得多。

您的答案会把您推向谨慎，或者推向速度。下面的四种方式，就是这条线上的不同位置。

四种切换方式并排比较

不同的书和供应商叫法不同，这里用大白话说明。实际中它们常常组合使用，下表是一张地图，而不是四选一的菜单。

有两点常被忽略。第一，试点针对的是人和地点（一个分店）或一项任务（一个工作流程），而按模块分阶段针对的是软件的各个部分。第二，这些方式都不能代替测试。上线方式决定风险如何分摊，却不能消除本该由测试发现的风险，那是用户验收测试的任务。

并行运行：新旧并排

并行运行是在固定期间内，把同样的工作同时记录在旧系统和新系统中，再比对结果。它是最谨慎的方式，因为旧办法仍在，可以随时退回；它也最累人，因为总有人把工作做了两遍。

• 范围要窄。只对出错会真金白银受损的记录并行，如发票、已收款项或月底合计。要求每位员工把所有东西录入两遍，是并行运行演变成抗议的原因。
• 设定结束日期。把日期写进计划。没有终点的并行运行会变成永久的重复录入，而这正是新系统本来要消除的问题。
• 指定比对人。由一个人负责比对，并有一份简短清单：哪些合计必须一致，不一致时怎么办。
• 先说好以谁为准。新旧不一致时，调查期间以哪一边为准？没有规则，每个差异都会变成争吵。
• 覆盖完整周期。如果关键数字是月底结账，并行期就必须经历一次月底。两周平静的日子，并不能说明月底会怎样。

短期、有针对性的并行运行常与其他方式搭配，例如试点中只把试点分店的现金合计与旧表格核对。

试点：先从一个分店或一个工作流程开始

试点是把一小块选定的范围先切换到新系统，其他人照旧。切法有两种。

• 一个分店或团队。该分店的所有工作都转过去。这能在一个地方用真实工作测试整个系统，适合有多家门店或多个部门的企业。
• 一个工作流程。所有人只在新系统里做一项任务，例如接工单，其他任务仍用旧办法。这适合只有一个据点、风险集中在某一个流程上的情况。

试点范围的选择比人们想象的更重要。好的试点组要足够典型，能让您学到东西，又要足够宽容，能熬过粗糙的开头。避开最容易的分店，它会掩盖问题；也避开最忙的，它抽不出精力。选一位希望它成功、并愿意如实汇报问题的经理。

试点开始前，用书面写下“好到可以继续”意味着什么。例如：员工不用旧表格就完成了日常任务，每天的合计对得上，发现的问题清单中没有尚未解决的“必须修复”项。没有约定好的退出标准，试点就会漂移。时长应至少覆盖一个完整的工作周期，所以每月才做一次的任务就需要一个月。要预期试点会发现问题，这正是它的目的。只保留一份问题清单，分为“下一组之前必须修复”“可以等”和“新想法”。

代价是时间和别扭。用新系统的分店和用旧系统的分店，在最后一组切换之前无法共享对业务的统一视图，所以老板要看的报表在这期间可能得靠手工拼接。要在开始之前就为此做好安排，而不是到第二周才发现。

按模块分阶段：一次上线系统的一部分

按模块分阶段适合由可独立运作的部分组成的较大系统，例如先是客户记录，然后订单，然后库存，然后开票。各部分依次上线，团队一次学一个领域，开发方也一次修一个领域。

风险在衔接处。订单已在新系统、开票还在旧系统时，必须有人把信息搬过去，而这个交接环节正是错误滋生的地方。同意分阶段计划之前，先问三个问题：

• 每个模块真的能独立运作吗？如果订单离开库存水平就无法使用，阶段的先后就由依赖关系决定，而不是由偏好决定。
• 新旧并存期间，靠什么传递信息？临时导出、手工重新录入，或简单的对接。每一种都有时间和准确度的代价，请要求写明。
• 每个阶段本身能带来什么？一个阶段应让业务变得更好，而不只是离承诺更近一步。如果第一阶段只让员工多打字，就会招人嫌。

分阶段也是由小而精的第一版逐步长大的方式。如果您把第一版的范围控制得很紧，如如何确定应用第一版的范围所述，后来的模块就会作为后续阶段到来，每一个都用同样的方法做出自己的上线决定。

一次性全面切换：所有人，同一天

一次性全面切换，是在一个固定日期让所有人同时切换，并停用旧办法。它名声不好，其实并不公平：对于工作简单的小团队，这往往是正确答案，因为路径最短，而且没有人活在两个系统里。

以下情况大多成立时，这样做是合理的：

• 团队小到可以一起培训，并在一个地方提供支持。
• 工作简单，对每个人都一样，没有很长的依赖链。
• 测试用了真实数据和真实任务，而且将来要用系统的人参与了。
• 退回旧办法几天会不方便，但可以承受。
• 日期平静，而且回退方案已写好并演练过。

如果企业有多个据点，出错会波及客户或现金，或者数据杂乱又未经测试，这就是糟糕的选择。一次性切换不必等于“没有安全网”。最稳妥的一次性切换，会让旧系统在一段约定的时间内保持可查看，有时还可编辑，详见数据指南中关于只读安全网的部分。

切换当天，要写明员工向谁求助、由谁拍板。如果供应商在头几天会提供协助，请要求书面写明；本指南无法告诉您任何供应商提供什么。

如何选择：决策表

逐行对照，回答自己企业的情况，看看哪一栏总是胜出。如果答案不一致，通常合理的结果是组合方式，例如先试点，再让其余分店一次性切换，并对每天的合计做短期并行核对。

一个虚构的例子：三家门店的面包店

这个例子是为了说明思路而虚构的。它不是真实的客户或真实的项目。设想一家有三家门店和一个中央厨房的面包店。订单和每日销售记录在共用的电子表格和纸上，一个用于订单、生产清单和每日结算销售的新系统即将交付。

• 糟糕一天的代价：漏掉早上的生产清单会浪费原料，也让老顾客失望；销售合计出错会搞乱老板的现金核对。
• 旧办法还在吗？在：电子表格和纸张可以再保留一段时间。
• 决定：先在最安静但具代表性的门店试点整整一个月，然后另外两家门店一起切换，仅对每日结算销售合计做短期并行运行。

这家面包店不需要很长的并行运行或按模块分阶段的计划；它需要一个小小的试验场、清晰的退出标准和从容的第二步。只有一家店、两名员工的企业，理所当然可以选择一次性切换。关键在于让方式与风险相匹配，而不是选最复杂的那一个。

选择日期

无论哪种方式，日期都是一个决定，而不是必须死守的期限。几条经验法则：

• 避开最忙的时期。如开斋节、农历新年和屠妖节等节庆季，年底促销、开学，或您自己举办的任何活动。在订单高峰中上线，会拿走您需要的缓冲。
• 避开会计周期的两端。每月的头尾几天、发薪日和年终结账，都是学习新工具的坏日子。
• 在一周初、一天初开始。星期一早上开始，整个工作周都能用来发现和修复问题；星期五下午开始，周末就没人盯着。
• 前后都留出余地。前几天冻结变更，之后留几天平静期，让决策人和一位推动者随时在场。
• 日期晚定，消息早发。只通过上线决策来调整日期，并提早告诉员工，免得有人措手不及。

回退方案：先想好怎么退回，再往前走

回退方案回答的是：如果出了问题，我们如何回到旧的工作方式，由谁决定？在对上线兴奋不已的时候写这个很不舒服，这恰恰是必须提早写的原因。在危机中临时想出来的方案，只是猜测。

可用的方案简短而具体：

• 触发条件，事先定好。例如：订单无法录入的时间超过约定时长，合计与旧记录相差超过约定金额，或出现没有变通办法的必须修复问题。现在就约定阈值，而不是在压力下才定。
• 一位决策人。有名有姓，并有一位备份，可以说“退回去”。委员会无法快速回退。
• 旧办法需要什么。旧系统或旧表格必须仍然完整可用。在切换日做一份备份，并在不可回头点之前保持可编辑。
• 新系统里已做的工作怎么办。上线后录入的内容要重新录入、导出，或有意放弃。事先决定是哪一种，由谁来做。
• 不可回头点。过了某个时刻，例如旧数据已归档，或客户已收到新系统出具的文件，退回去的代价就会变高。写明那个时刻，并要求越过之前重新做一次上线决策。
• 一次演练。在测试副本上练习退回一次。没人试过的回退方案只是一种希望，不是计划。相关的演练，即恢复测试，在定制业务系统的安全基础中有说明。

也要写下万一退回，您会怎么告诉员工和客户。从容、有意地退回，是计划的成功，而不是项目的失败。

上线决策清单

上线决策会议是上线前几天与有权说“不”的人一起开的简短、有安排的决策会。下面每一项都应有明确的是或否、一位负责人和证据，而不是凭感觉。任何一项“否”只要可能导致糟糕的一天，就意味着暂缓上线。

暂缓上线是一个决定，而不是丢脸的事。记录缺什么、由谁在何时前补上，以及新的日期。把上线推迟一周代价很小；带着已知的缺口上线代价很大。如果供应商抗拒一个您能说得出理由的暂缓决定，这就是上线后合作会怎样的有用信息。

向开发方提出的问题

• 您建议我们采用哪种上线方式，为什么？好的回答会提到您的据点、数据和风险，而不是习惯做法。
• 旧办法能继续运行吗？能多久？问清必须保留什么，以及有没有什么需要关闭。
• 这个系统的回退是什么样子？要求给出步骤、所需时间和执行人。
• 模块或分店可以分别开通吗？如果可以，问清这是否会改变报价或时间线。
• 上线前后谁会在场，书面承诺了什么？答案应写进协议，而不是停留在口头。
• 如果系统包含手机应用，测试版本如何送到试点组的手机上，有问题的版本又如何撤回？在确定试点日期之前先问清楚。
• 上线之前需要我们做什么？数据核对、测试用户、各项决定：要一份清单和日期。

把同样的问题交给每家供应商，答案才能比较。如何比较两份定制软件报价介绍了如何把它们逐项对照。

常见错误

• 到最后一周才决定方式。到那时，数据、账号和测试都是按错误的计划准备的。
• 并行运行没有结束日期。它会变成永久的重复录入，以及对新系统悄悄的不信任。
• 试点没有退出标准。没有书面的成功定义，没人知道何时该继续。
• 选了最容易或最忙的试点组。前者掩盖问题；后者没有精力去发现问题。
• 把上线决策当成走过场。如果答案永远是“上线”，这个会议就是演戏。要让真正的“不”成为可能。
• 没有回退方案，或回退方案从没试过。第一次尝试就发生在危机之中。
• 为了兑现承诺在高峰期上线。为促销活动而不是为准备就绪选的日期，是在赌博。
• 太早停用旧办法。在您有意越过不可回头点之前，让旧办法保持完整可查。
• 忘了上线后的一周。上线只是开始；请按如何让团队真正使用新业务系统来安排第一个月。

Gotka Technologies 的定位

Gotka 的应用与系统开发服务开发手机应用、网页应用和业务系统，参考起价在您的需求确定范围后以书面报价为准。本指南是一般性建议，不描述 Gotka 如何上线、分阶段或支持任何项目，也不承诺任何上线方式或时间线。无论选择哪家供应商，签约之前都请要求以书面写明上线方式、回退方案和上线后的协助。如果您想聊聊自己的情况，欢迎联系我们。

上线前的相关阅读：与软件开发人员第一次沟通前要准备什么。

本指南中的关键术语

• 切换：从旧的工作方式转到新系统。
• 一次性全面切换：所有人在一个固定日期同时切换，旧办法停用。
• 分阶段上线：切换分几个阶段进行，按地点、团队或模块划分。
• 试点：先由一个小组（一个分店、团队或工作流程）使用新系统，其他人等待。
• 并行运行：新旧系统在固定期间内同时使用，并比对结果。
• 回退：新系统上线后出问题时，退回旧的工作方式。
• 上线决策：依据清单，对是否上线或推迟所作的有安排的决定。
• 不可回头点：过了这个时刻，退回去代价高昂或不可行。
• 退出标准：进入下一阶段之前必须满足的书面条件。