电商ERP实战1:新老系统切换之数据迁移

5 评论 1486 浏览 9 收藏 11 分钟

今天结合电商ERP实战为大家分享,我是如何做系统迁移的,这个也是产品中后期,做大型企业项目必会遇到的,希望对看到文章的你有所帮助~

当时笔者公司ERP原本是外部公司研发的,由于业务发展无法继续支撑,这个也是很多大公司常见的操作了,业务体量发展到一定程度,一般都会把原有第三方解决方案,转换为自研系统进行业务支撑。

这个过程就涉及到新老系统切换了,原有系统的业务数据逻辑等,都需要迁移到新系统。

当时我主要是分为3大步进行的:迁移前置工作、正式数据迁移、收尾工作,接下来我们展开进行详细描述~

一、迁移前置工作

这部分工作一般会在系统正式迁移前,进行提前配置。包含迁移方案、迁移前置条件输出,需要按步骤、按顺序做好记录。

1. 迁移方案

系统切换和系统部署2大原则基本一致,蓝绿部署——一键全部切换新系统;金丝雀部署——少量用户先用新版本,逐步切换。对应到新老系统切换方案,就是一键全部切换新系统;或者并行分步切换,部分业务先切新系统,逐步将全部业务切换到新系统。

图中举例说明了2种方案,涉及隐私,部分数据做了隐藏~

每个方案需要结合业务逻辑,梳理写出具体细节步骤,优劣势,最后结合实际与CTO、研发经理进行综合方案评审。当时笔者所在供应链业务线还要配合电商业务,最终我们采用一键换新,一次性全部迁移的方案。当时切换业务逻辑:先条码、后订单、最后库存迁移。

结合实际业务逻辑,当年青涩的我总共输出了4版方案,这里思路基本就是:

  1. 一次性全部迁移:老系统发完全部货物,再进行全部条码、订单迁移。
  2. 一次性全部迁移:先把所有条码进行迁移、全部订单进行迁移、最后仓库实际库存迁移。
  3. 并行分布迁移:新订单新系统发货,老订单老系统发货,老订单全部发货完成后,进行条码、订单迁移,最后仓库实际库存迁移。
  4. 并行分布迁移:先把已经出库的条码进行迁移,后期每天对新发货的条码进行迁移。

这块方案输出也是产品的基操了,带着解决方案找领导,而不是问题抛给领导。嗯,不然的话,这个产品离滚蛋不远啦,管理层只是来协调资源👈做决策的~ 像项目管理里边的CCB,CCB只是决策机构,不是作业机构哈~

2. 迁移前置工作

方案梳理完成后,就可以进行前置工作的具体输出了,最近看高项的书,发现正式场合都是需要一份报告+详细方案输出。

当时我负责业务线没有专职项目经理,所以这部分文档我都是实用为主,并没有报告、详细迁移方案区分,只输出了一份表格的详细迁移方案。

基本格式涵盖了:事项总括、具体事项、事项拆分、详细执行步骤、对应数据来源、具体执行人、负责人、执行时间、状态备注等,具体如下图:

至于那句老莫的方案,李翔方案什么的。年少勇啊,大家不要学习,表达过自己的想法就可以了,具体执行还是要以领导意志为准。所幸我很少遇到小心眼的领导,不然该被穿小鞋了哈哈哈~ 这块跟新系统实施上线要提前配置的工作差不多,软件配置、账号及权限维护、基础资料维护,商品维护等~

这块大家结合自己业务来就可以了,唯一想提醒的是:B端业务如果涉及到硬件设备,比如:PDA、工业一体机等,还需要记录具体台数,初始化配置步骤,在现场配置好每台设备。

一般涉及工作:软件安装、MAC地址、IP地址获取等,结合具体业务及功能来看。像我们开发了快捷键激光扫码功能,就需要PDA开发者项进行提前配置才可正常使用(具体因公司、业务线而议,有的公司这部分工作实施来做。不管哪个部门或角色做,这里都需要记录清楚,因为这是系统迁移不可绕开的工作),如果涉及打印机等的,基本也是类似,硬件最终上线都是需要有这些前置配置条件的~

每项业务执行时间、具体执行人都需要提前规划好,这里就可以充分牛马组内的开发了,让人人都有活干~

大家不要只会自己埋头干活,适当带动你组内开发参与到业务中去。

注意暂停业务的时间也需要在迁移计划中体现,不然这边系统迁移,那边业务人员哼哧哼哧给你造数据,这下好了系统迁移工作要无限期不能终止了~

其他提前维护的内容ERP的基操了,大家应该都懂。

二、正式数据迁移

具体业务数据的迁移,这部分都是需要结合实际业务系统逻辑顺序来做,一般顺序在输出方案时已经确认了。我们当时的方案,一次性全部迁移:先条码、后订单、最后库存迁移。

每项业务迁移都需要明确不同业务类型、状态数据如何迁移,并提前确定迁移方式。这里以条码业务来进行举例,思路都差不多。

迁移事项分类主要是:指导思想、前置条件、不同状态、不同业务类型、迁移需要留存字段等。

1. 迁移事项实例

① 指导思想用来让组内同事对此达成一致意见, 尽量避免大家理解不一致导致的问题。

② 当前业务的前置条件,条码迁移这里没有。以销售订单来举例,ERP商品需要先和电商平台商品进行关联,才可以进行订单数据迁移。这里和系统迁移前置工作不一样的点在于:此处是当前业务迁移前置动作,业务逻辑关联有前后顺序,并且只能在系统迁移过程中进行操作。ERP商品关联前,电商平台需要先进行迁移商品迁移并下推ERP,ERP才可以进行商品关联。而系统迁移前置工作,基本都可以在迁移前提前配置。

③ 当前业务贯穿业务类型较多、并且业务逻辑完全不一致的,需要写出每个业务类型的数据具体迁移方式。

④ 当前业务不同状态业务数据如何迁移,这里产品条码不同状态迁移方式、注意事项都不一样~ 订单的话,历史订单、在途订单等按照状态分别列出了,状态比较多的,需要按照平时订单状态机的输出依次列出

⑤ 迁移需要留存字段,一般会保留旧系统全部字段在数据库,前台展示可以考虑以新系统为准。

2. 迁移方式

迁移方式基本和数据新增的方式一样,一是直接接口、或数据库同步形式,这部分工作一般由开发同事直接进行;数据量较小的话,用表格导入的方式进行。至于手动新增,这部分就😀,除非10条以下数据,比如仓库、店铺配置哈哈哈~

三、收尾工作

正式数据迁移完成后,就是系统迁移的收尾工作啦。

收尾工作我按2部分进行的,一部分老系统接口等处理,还有财务数据处理。系统迁移完成后,老系统接口一定要关闭,不然数据混乱后期处理麻烦。笔者当时只是迁移了业务历史、在途和新数据,财务数据没有进行迁移,后期财务数据还需要再做一次迁移。

当然,这份迁移方案也不是一版定稿的,当时基本写了3、4版方案,再去跟技术主管、CTO反复讨论。除了详细迁移方案,还有日常软件上线的必不可少的操作手册、切换背景、后期业务规划等附件~

至于最终迁移效果还是不错的,很可惜没能亲身经历(当时笔者已经跳槽去新公司开展新业务了),不过留下的迁移方案还是非常详细的,基本涵盖迁移全部工作,文档在手,万事不怕~

本文更多的是从产品、业务角度进行的分享,技术角度考虑维度可能会不太一样。笔者也还在持续输出,成长~ 欢迎感兴趣、想要交流的评论区前排留言,一起进步成长~

本文由 @木子gee 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 之前还有一次WMS切换,涉及到应急预案的。这个后期大家感兴趣再进行分享

    来自浙江 回复
  2. 最近在参与SAP迁移的事情,一头雾水

    来自浙江 回复
    1. 希望文章能对你有点帮助

      来自浙江 回复
    2. 早遇到就好了,去年刚一头雾水的迁完

      来自浙江 回复
    3. 😂你们节奏好整齐,都是一头雾水

      来自浙江 回复