系统重构中的新老切换是产品经理面临的重大挑战，尤其当涉及多系统交互和复杂业务逻辑时。本文以SRM系统为例，详细拆解分阶段迁移策略——从核心订单流程搭建到财务结算切换，揭秘如何在保障业务连续性的同时实现平滑过渡。更包含实战中血泪总结的通用原则，助你避开数据比对、多系统协同等深坑。

遇到系统重构，免不了要考虑新老系统的切换方案，遇到上下游系统数据交互多，加上业务复杂度高的，切换方案就得好好考虑。一些个人的思考想法，不一定对，有问题欢迎提出来欢迎交流。

▲SRM产品架构图

分步骤切换新老系统

以下为举例，各家做法可以不同，依据实际需要。（后面有图例说明）

阶段一

搭建的模块：

0-1SRM采购端：基础资料、供应商管理、价格管理、订单管理、权限

0-1SRM供应商端：权限、供应商资料、订单管理

目标：

1. 最核心流程0-1分步骤搭建、以及流程依赖的基础信息搭建；
2. 建单用的基础信息最好用新SRM的，若不能，则老系统提供；
3. 由老系统的采购需求生成新SRM的采购订单，订单执行还走老系统，做新老系统采购订单的关键信息比对。

说明：

1. 整个SRM里面最主要的流程是订单的执行，从采购需求-订单下达-订单交货-结算对账，采购需求若企业个性化需求较多较复杂的，可以放到后续，先接老系统的采购需求去新SRM生成采购订单；
2. 正向流程先搭建，后续再考虑补足逆向；
3. 根据流程的先后，像结算对账常在月底，需要前置采购订单流程跑通后才到财务这块，所以先在老系统处理，也就是说，有一段过渡期，需要新SRM生成的订单回传老系统，在老系统做结算对账。
4. 围绕生成订单相关的基础资料、供应商、价格，因新SRM后续如果用srm自己的这些数据，那么可以0-1可以简易搭建或者从老系统取（要跟开发沟通方案，如果老系统没法支持新系统来取数据的，可以从老系统同步一份）
5. 老系统的采购需求单->新SRM的采购订单，如果业务/系统比较复杂的，前期要比对新老系统的采购订单数据（关键信息是否生成错误），订单执行都在老系统，采购订单没问题后，后面再搭建交货执行。

阶段二

搭建的模块：

0-1SRM采购端：收货管理、收货串接wms和中央库存、寻源管理、合同管理、质量协同、生产协同、库存协同、采购工作台、采购需求

0-1SRM供应商端：首页门户、合同管理、寻源协同、收发货管理

需求迭代优化的此处不举例了，依据实际业务需要处理。

目标：

1. 搭建采购订单的收货入库，与wms串接，并且逐步替换老系统的订单创建->收货入库，这段流程
2. 采购需求管理搭建

说明：

1）采购订单生成（比对数据没问题后），搭建到订单的收货入库，跟wms、质检系统对接，生成对应收货单、质检结果。采购入库单，依据业务/系统复杂度，可能需要新老系统比对收货执行数据确保没问题，再逐步切换到新系统。比如过渡阶段业务未切到老系统存在wms对新老系统都有回传收货采购入库数据，经过数据比对没有问题后，最终切换到新业务的只能回传留一个系统。

2）切换：

①采购订单在新srm生成、老系统不直接生成这部分已切到系统的的采购订单，而是由采购订单回传给老系统在老系统生成采购订单（注意下老系统的生成采购订单的条件，可能要解开限制）

②收货执行结果在新srm生成，已切换到新系统的收货执行结果老系统自己不接wms，而是由新srm给到老系统去生成收货采购入库。

这里有wms执行结果回传的控制、以及采购入库加库存对接中央库存也要确定好切换方案。

阶段三

搭建的模块：

0-1SRM采购端：对账结算、统计报表0-1SRM供应商端：对账结算、统计报表

目标：

1. 对账结算和采购退货搭建
2. 统计报表搭建

说明：

1. 涉及财务钱相关的逐步切换，必要时先新老系统做数据比对后，再切换。
2. 统计报表影响不大，注意取值数据源，尽量从新srm取

图例

说明：

这样一步步处理，虽然比较谨慎，但比较复杂，特别是收货管理那段，要串联外部系统，再加上要按业务线/维度逐步切换就更麻烦，甚至可能要在生产环境搭一套测试数据，多系统要对应做改造隔离开测试数据和实际业务数据，就更复杂了。万一切换过程中有异常，还要考虑到应对措施甚至要业务走回老系统。未切到新系统时还要考虑单据单号的映射关系，新老系统数据流衔接上，以及避免重复加库存多收货或者多付款的事情发生，单据唯一不能乱。

所以，一般还是建议比如除了财务结算处理外，像采购需求、采购订单、收货执行，这些上下游单据有牵连并且协同外部多系统的，还是一起按某个业务维度切换到新系统，这样简单一些。

围绕订单相关的基础资料、供应商数据，逐步切换时，因为有一部分有使用到这些数据的模块还在老系统，所以可能要做回传或同步，尽量两边只留一个业务可增改删的操作入口（可以依字段 但增加操作难度，最好不要）。

实际推广时，可以跟业务商定按照一些业务维度来推广，供应商这边选几家配合小范围推广。

每家做法不一样，依据实际来。

切换新老系统的通用原则

每家情况不一样，但有一些共同的要点：

1. 没把握的，就先要比对数据，把整个流程拆解下来一步步处理 比如先建单，建单没问题再执行。
2. 尽量让开发参与进方案讨论（产品主导），从开发的角度可能会有一些不一样的做法，有些甚至要生产环境做测试数据、用新的服务器、老系统能否支撑的对接方式…系统上下游要改造。
3. 新建的系统，基础信息或者必要的信息尽量用自己系统的或者别的系统也行，尽量少去老系统接，因为最终是要拿掉老系统的，前期可以把老系统的基础资料拉过来一份。总之要知道，新系统迟早要代替老系统，尽量少做后续没啥用的一次性改造，而且对老系统尽量少改，老系统的逻辑你也不会很想都去扒出来的，找开发扒低代码的懂的懂。
4. 按流程先后、业务发散/收敛，核心与非核心，制定迁移计划，比如个性化的需求单、需求计划，可以放后面，比对对账是在流程靠后位置的，可以先不做，先做正向后接逆向。
5. 中间过渡，有些在新系统，有些在老系统，会有业务存在两边使用的过渡期，设计时尽量两边只留一边数据操作入口，并同步另一边系统
6. 接入业务时，可以按照某些类型的业务先推广 选量小一些的，没问题再逐步放开接入业务。