电商后台系统改造项目笔记(7)ERP系统对接

万万没想到,Oracle ERP系统这么难搞。

按照我最初的设想,相当于把ERP架空了,ERP变成了一个类似金蝶、用友这样的纯粹财务系统。新的电商后台系统负责所有业务层的处理,只把处理完成后涉及到对账的凭证给到ERP即可。

但是,在和财务部门领导和同事,以及ERP专家的N次来回沟通后,我明白了:完全在业务操作层上绕开ERP,是做不到的。有些是技术上的限制,如Oracle ERP的信息流数据链非常严密,不能随便切掉某个环节,用外部数据替换。而更多的,则是非技术性的因素导致的。

在项目早期调研阶段,我和财务沟通时,她们就多次表达了类似的观点:咱们公司花了这么大的代价,才上了一套Oracle ERP系统,经过很长时间的改造和磨合,才勉强用起来,虽然不完美,但是不至于出大乱子。潜台词就是,你们最好别动ERP系统,别想改动现有的流程和操作模式。

财务所理解的Oracle ERP,必须是电商业务的主承载系统,订单什么的都要在Oracle ERP里面处理。然而,你去考察下市面上的电商ERP就知道了,根本不是我司这么玩的。我们正在做的这个新系统,就相当于市面上的那些电商ERP系统,从采购到销售都能支撑。我们不得不问自己一个问题:我们这个新系统,意义何在?

说白了,这就是一个“沉没成本”的问题。隔壁部门某同事在了解到这个现状后,说了一句“及时止损”,然而,财务部门对公司有多重要大家是知道的,我们没办法架空已经在运行的ERP系统。

该对接的还是要对接,无非就是多一些开发工作量,架构复杂了一些,以后不太方便灵活扩展罢了。

(一)商品管理机制

领导坚持要以ERP为主,在ERP侧添加和管理商品,参考下图:

仓库同事反对这个方案,因为上面这个方案就意味着:每次新增商品,都要在两个系统分别执行一次,并在新系统中手动关联一次。操作上效率是比较低的。

你可能会感到奇怪:为啥需要在新系统侧手动新建SKU,而不是自动创建?这是因为两个系统的商品命名机制不太一样,无法直接从ERP同步到新系统并自动创建对应商品(反向同步倒是可以的)。有点抽象?看下面这个对比例子你就明白了:

我提议的方案如下:

如上图,只需要在新系统单方创建一次商品(SKU),接下来就让系统自动去完成同步和在ERP侧自动创建商品。

领导不同意我的方案,认为应该以ERP为主来管理商品。这事儿我说了不算,所以最后还是用领导的方案来执行,我只能表示无奈。

(二)采购订单与采购入库

有了最基础的商品数据后,我们接着处理采购的问题。

财务部门认为采购很重要,涉及到很复杂的会计科目计算,不能剥离到新系统去处理。沟通几次未果,只能按照他们的想法来设计处理流程。

如下图,采购下单和数量入库环节放在ERP,但是SN导入环节放在新系统(我们的主要产品是需要序列号管理的)。

此流程对仓库来说有点不顺手,因为需要在两个系统分开操作入库。实际上完全可以把ERP侧的“采购入库”环节放在新系统侧的,但是财务不同意。。。

(三)销售订单与销售出库(正向流程)

销售出库的流程比较简单,无非就是把订单本身和出库结果都告诉ERP那边就行了。

(四)销售退款(仅退款)

还没发货的情况下,销售订单可以执行仅退款的逆向流程,如下图(部分细节做了精简处理):

(五)销售退货退款

已经发货的情况下,销售订单可以执行退货+退款的逆向流程,如下图(部分细节做了精简处理):

以上这些流程的处理方案,并不算完美。在诸多现实因素的限制下,和ERP的对接做到这个地步,我也只能说,我们尽力了。。。

 

“电商后台系统改造项目笔记(7)ERP系统对接”的2个回复

  1. 把 ERP 架空,仅从从「电商 ERP」->「ERP」同步财务需求的记账单据。
    这个思路是对的,主要就是一些出入库单据。(结果单据,非过程单据)

    基础资料(如 SKU)以「ERP」为主系统建档,单向同步至「电商 ERP」也是没错的。品名问题看起来是可以解决的。

    「让业务操作人、仓库操作人在一套系统内完成作业」优先级应该更高,也避免错误。

    1. 理想与现实总是有差距,我主导的这个改造方案已经部分上线了,但商城隶属于另一个业务线,我也没办法深入插手了,况且我也已经离开这家公司了,后续就看接手的人如何处理啦。有点遗憾没能继续做下去,不过人生不就是这样么,各种不可预测的事情都会发生。

发表评论

电子邮件地址不会被公开。 必填项已用*标注