电商ERP实战1:新老系统切换之数据迁移
原标题:电商ERP实战1:新老系统切换之数据迁移
导读:
据灯塔专业版实时数据截至月日时分影片周处除三害票房突破亿今天结合电商实战为大家分享我是如何做系统迁移的这个也是产品中后期做大型企业项目必会遇到的希望对看到文章的你有所帮助当时笔...
据灯塔专业版实时数据,截至3月17日12时19分,影片《周处除三害》票房突破5亿。...
今天结合电商ERP实战为大家分享,我是如何做系统迁移的,这个也是产品中后期,做大型企业项目必会遇到的,希望对看到文章的你有所帮助~
当时笔者公司ERP原本是外部公司研发的,由于业务发展无法继续支撑,这个也是很多大公司常见的操作了,业务体量发展到一定程度,一般都会把原有第三方解决方案,转换为自研系统进行业务支撑。
这个过程就涉及到新老系统切换了,原有系统的业务数据逻辑等,都需要迁移到新系统。
当时我主要是分为3大步进行的:迁移前置工作、正式数据迁移、收尾工作,接下来我们展开进行详细描述~
一、迁移前置工作
这部分工作一般会在系统正式迁移前,进行提前配置。包含迁移方案、迁移前置条件输出,需要按步骤、按顺序做好记录。
1. 迁移方案
系统切换和系统部署2大原则基本一致,蓝绿部署——一键全部切换新系统;金丝雀部署——少量用户先用新版本,逐步切换。对应到新老系统切换方案,就是一键全部切换新系统;或者并行分步切换,部分业务先切新系统,逐步将全部业务切换到新系统。
图中举例说明了2种方案,涉及隐私,部分数据做了隐藏~
每个方案需要结合业务逻辑,梳理写出具体细节步骤,优劣势,最后结合实际与CTO、研发经理进行综合方案评审。当时笔者所在供应链业务线还要配合电商业务,最终我们采用一键换新,一次性全部迁移的方案。当时切换业务逻辑:先条码、后订单、最后库存迁移。
结合实际业务逻辑,当年青涩的我总共输出了4版方案,这里思路基本就是:
一次性全部迁移:老系统发完全部货物,再进行全部条码、订单迁移。一次性全部迁移:先把所有条码进行迁移、全部订单进行迁移、最后仓库实际库存迁移。并行分布迁移:新订单新系统发货,老订单老系统发货,老订单全部发货完成后,进行条码、订单迁移,最后仓库实际库存迁移。并行分布迁移:先把已经出库的条码进行迁移,后期每天对新发货的条码进行迁移。
这块方案输出也是产品的基操了,带着解决方案找领导,而不是问题抛给领导。嗯,不然的话,这个产品离滚蛋不远啦,管理层只是来协调资源做决策的~ 像项目管理里边的CCB,CCB只是决策机构,不是作业机构哈~
2. 迁移前置工作
方案梳理完成后,就可以进行前置工作的具体输出了,最近看高项的书,发现正式场合都是需要一份报告+详细方案输出。
当时我负责业务线没有专职项目经理,所以这部分文档我都是实用为主,并没有报告、详细迁移方案区分,只输出了一份表格的详细迁移方案。
基本格式涵盖了:事项总括、具体事项、事项拆分、详细执行步骤、对应数据来源、具体执行人、负责人、执行时间、状态备注等,具体如下图:
至于那句老莫的方案,李翔方案什么的。年少勇啊,大家不要学习,表达过自己的想法就可以了,具体执行还是要以领导意志为准。所幸我很少遇到小心眼的领导,不然该被穿小鞋了哈哈哈~ 这块跟新系统实施上线要提前配置的工作差不多,软件配置、账号及权限维护、基础资料维护,商品维护等~
这块大家结合自己业务来就可以了,唯一想提醒的是:B端业务如果涉及到硬件设备,比如:PDA、工业一体机等,还需要记录具体台数,初始化配置步骤,在现场配置好每台设备。
一般涉及工作:软件安装、MAC地址、IP地址获取等,结合具体业务及功能来看。像我们开发了快捷键激光扫码功能,就需要PDA开发者项进行提前配置才可正常使用(具体因公司、业务线而议,有的公司这部分工作实施来做。不管哪个部门或角色做,这里都需要记录清楚,因为这是系统迁移不可绕开的工作),如果涉及打印机等的,基本也是类似,硬件最终上线都是需要有这些前置配置条件的~
每项业务执行时间、具体执行人都需要提前规划好,这里就可以充分牛马组内的开发了,让人人都有活干~
大家不要只会自己埋头干活,适当带动你组内开发参与到业务中去。
注意暂停业务的时间也需要在迁移计划中体现,不然这边系统迁移,那边业务人员哼哧哼哧给你造数据,这下好了系统迁移工作要无限期不能终止了~
其他提前维护的内容ERP的基操了,大家应该都懂。
二、正式数据迁移
具体业务数据的迁移,这部分都是需要结合实际业务系统逻辑顺序来做,一般顺序在输出方案时已经确认了。我们当时的方案,一次性全部迁移:先条码、后订单、最后库存迁移。
每项业务迁移都需要明确不同业务类型、状态数据如何迁移,并提前确定迁移方式。这里以条码业务来进行举例,思路都差不多。
迁移事项分类主要是:指导思想、前置条件、不同状态、不同业务类型、迁移需要留存字段等。
1. 迁移事项实例
① 指导思想用来让组内同事对此达成一致意见, 尽量避免大家理解不一致导致的问题。
② 当前业务的前置条件,条码迁移这里没有。以销售订单来举例,ERP商品需要先和电商平台商品进行关联,才可以进行订单数据迁移。这里和系统迁移前置工作不一样的点在于:此处是当前业务迁移前置动作,业务逻辑关联有前后顺序,并且只能在系统迁移过程中进行操作。ERP商品关联前,电商平台需要先进行迁移商品迁移并下推ERP,ERP才可以进行商品关联。而系统迁移前置工作,基本都可以在迁移前提前配置。
③ 当前业务贯穿业务类型较多、并且业务逻辑完全不一致的,需要写出每个业务类型的数据具体迁移方式。
④ 当前业务不同状态业务数据如何迁移,这里产品条码不同状态迁移方式、注意事项都不一样~ 订单的话,历史订单、在途订单等按照状态分别列出了,状态比较多的,需要按照平时订单状态机的输出依次列出
⑤ 迁移需要留存字段,一般会保留旧系统全部字段在数据库,前台展示可以考虑以新系统为准。
2. 迁移方式
迁移方式基本和数据新增的方式一样,一是直接接口、或数据库同步形式,这部分工作一般由开发同事直接进行;数据量较小的话,用表格导入的方式进行。至于手动新增,这部分就,除非10条以下数据,比如仓库、店铺配置哈哈哈~
三、收尾工作
正式数据迁移完成后,就是系统迁移的收尾工作啦。
收尾工作我按2部分进行的,一部分老系统接口等处理,还有财务数据处理。系统迁移完成后,老系统接口一定要关闭,不然数据混乱后期处理麻烦。笔者当时只是迁移了业务历史、在途和新数据,财务数据没有进行迁移,后期财务数据还需要再做一次迁移。
当然,这份迁移方案也不是一版定稿的,当时基本写了3、4版方案,再去跟技术主管、CTO反复讨论。除了详细迁移方案,还有日常软件上线的必不可少的操作手册、切换背景、后期业务规划等附件~
至于最终迁移效果还是不错的,很可惜没能亲身经历(当时笔者已经跳槽去新公司开展新业务了),不过留下的迁移方案还是非常详细的,基本涵盖迁移全部工作,文档在手,万事不怕~
本文由 @木子gee 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
- 版权所属:王牌阁
- 本文地址:http://how.uexe.cn/15340.html
- 版权声明:原创文章,转载时必须以链接形式注明原始出处及本声明。