从0到1搭建OMS订单管理系统

    OMS(订单管理系统)是电商供应链最重要的环节之一,整个业务链条大致为:买家从电商平台下单--OMS(订单)--WMS(仓储)--TMS(运配)--买家,OMS主要起到承上启下的作用,上接电商平台,对其进行订单的管理(还有一些内部订单的管理,后面说),下接仓储,安排订单的出入库,最终将商品送到买家手中。对了,还有一些资金流需要与ERP交互,这是企业内部的需求。

           有人可能会问,我大电商平台有对应的后台,为什么要用OMS?以下为个人观点:1、电商平台的后台主要是对订单销量、退货退款单量进行统计、管理商品的上下架、店铺的装饰、平台的活动等,可以说是支撑平台运营的基本功能;而OMS更多的是为企业提供更多具体的,包括企业内部的订单管理及个性化的服务,如:采购订单、调拨订单、黄牛订单的管理等等;2、一般来说,买家在电商平台下的订单并不是直接就下发给仓库发货的,而是需要进行订单的管控,可以看下京东或当当下单流程,都有一步是审核,OMS可以做这方面;3、如果某个店铺有多个仓库,但是商家应该安排哪个仓库发货呢?比如我有北京和上海两个仓库,如果买家的收货地址是北京,那发货的仓库就需要是北京仓,这个就需要在OMS中进行发货优先级的配置了……其实还有很多其他的原因,总的来说只要平台的开放API支持,OMS基本可以替代电商后台。

           OMS的用户角色包括:客服、售后专员、发票专员、仓库管理员、商品专员、结算专员、物流专员等等,主要看此OMS实现了哪些功能,因为它本身可以做很多的拓展。

           介绍下此次OMS的背景,目的是做一个2B的平台,包含了从供应商--服务商--零售商--门店--消费者的交易关系,可以说是B2B2B2B2C,我有点晕……这里的重点是零售商,他们是我们此次设计主要要进行销售和管理的对象,也就是零售商怎么通过OMS要货,给自己的实体门店,门店再进行销售。

           从0到1一定要做好优先级排序,然后要看时间,没时间做的,砍砍砍!本次做的OMS资源极少,从接需求到上线,只有1个月时间(5月,而且包含两个假期……),而要做的内容包括用户注册登录、权限管理等各种基础架构的搭建,还有多层级的交易关系设计,以及考虑到未来与WMS对接的设计,工作量可想而知,所以第一版时把所有需要对接的功能全部改成了导入的方式,比如创建商品、订单发货、订单签收等。

           接下来各个击破:用户注册登录、权限管理、审批流、订单与单据(重中之重)、库存管理、售后管理、发票管理

           1、用户注册登录

           其实这个大家并不陌生,这个是创建用户信息的过程,正常2C的注册流程直接通过电话或邮箱注册即可完成,但是2B涉及到审核资质的问题,所以在注册时需要相关负责人进行审核,审核通过后此账号才能登录。

           这里当时就遇到一个问题,是注册申请后就创建用户信息,但是此时用户信息无效(即不可登录系统),还是审核通过后才创建用户信息,且用户信息有效?

           本来我想的是第一种,但是当初在需求评审时并没有说清楚,而且我自己当时也没细想,开发大牛在做开发设计时直接按后者设计的,直到后来具体开发时有些地方跟我当初的设计有冲突才发现问题,因为时间紧,也就直接改的我的设计方案。

           直到现在我仍觉得第一种方式更好些,但是第二种方式也并非不妥。

           2、权限管理

           这个绝对是搭建任何后台产品都需要的最重点功能,没有之一!

           以前我只知道用户--角色--权限关系,后来才知道有个名词叫:RBAC模型。因为后台产品的角色特别多,比如我上面收到的客服、仓库管理员之类的,每种角色的人看到的功能是不一样的。所以要把每个功能(页面、按钮)挂到对应的角色身上,再把角色分配给用户。比如我有一个账户是zhenghuig,我是一个客服,那么就给我分配“客服”这个角色,我就只能看到需要我操作的功能了。

           刚才说的是功能角色,还有一个是数据角色。比如此OMS中有供应商、服务商、零售商、门店,4个主体,这些主体有层级关系,看到的数据范围不一样,比如零售商可以看零售商自己和门店的数据,但是门店不能看零售商的数据。数据角色就是在角色身上挂上不同地域或者主体的数据权限,你是我的下级,我能看你的,但你不能看我的。

           功能角色权限是必需的,而数据角色权限是非必需的。我当时就陷入了深深的纠结当中。如果不用数据角色,那么在给用户授权时,分配完功能角色后,就需要选择可以查看的数据范围;如果用数据角色,在给用户分配完功能角色后,再给用户分配数据角色就行了。

           用数据角色坏处是,每次在创建用户前,都要事先定义好数据角色,不然就没办法给他分配相应的权限,所以前期就需要定义好数据角色,或者每次在创建不同角色的新用户后都要再创建数据角色,过程类似于:创建用户--创建数据角色--授权--分配功能角色--分配数据角色。而不用数据角色的过程类似于:创建用户--授权--分配功能角色--选择数据范围。

           很明显后面这个过程更简洁,但是如果用户量大了,那就每次创建一个用户都需要重复勾选数据范围,即使角色相同。而且要修改某一类角色人的数据范围时,需要修改每个相关账号的数据范围,而有了数据角色这个过程就变得很简单了。所以设不设计数据角色需要权衡。

           3、审批流

           审批流程主要是针对需要审批的工作单(各类申请单),最简单的审批流程只需一个人或者一个角色审批,状态分为:待审批、审批通过、审批不通过。如果一个工作单需要多个不同角色审批,简单的做法就是“写死”,比如门店的要货申请,需要零售商、服务商、供应商,3个主体对应的角色审批,那么“写死”的做法就是这个流程固定,走到哪个审批步骤以后都是这个审批步骤,不可修改审批流程的先后步骤和审批角色,要改就要改程序。而如果要灵活的话,就需要整个审批流可配置,这是一个比较麻烦的过程,要设计灵活。

           这个OMS第一版并没有做复杂的审批流,之前在做其他的项目时倒是设计过,可以定义某个流程需要几步审批,每步审批人的角色,这样就相对灵活而且开发不太复杂。也有做成图形的,一个流程图加各种控件,通过拖拽完全自定义流程,太麻烦。

           4、订单与单据

           订单主要包括:对消费者的销售订单、企业内部或公司间的采购订单、从一个仓库或库存地到另一个地方的调拨订单、退换货订单;

           单据说的是物流单,为了处理库存而存在,有商品和数量,但没有金额。单据主要就分为两类:出库单、入库单,这两类可以和不同的订单进行组合。

           为什么OMS要设计物流单?因为要对接WMS(仓储管理系统)。OMS里的每种订单都要设计对应的下发WMS的单据,比如:我在电商平台下了一个订单,这个销售订单就要进入OMS,审核通过后把发货信息下发给WMS,这时就要在此销售订单的基础上系统自动创建一个销售出库单,把这个单据信息给到WMS,WMS根据收到的出库单信息安排发货,发货完成后会操作此出库单,把信息给回到OMS,通知OMS发货成功,这时OMS就要扣减对应的库存。

           既然是这样,为什么不直接把销售订单下发给WMS,而要设计订单--单据的两层结构?这种情况确实好像不需要做两层,但是有些时候需要一个订单对应两个单据,比如调拨订单(1个调拨出库单和1个调拨入库单)、换货订单(1个换货入库单和1个换货出库单),如果这时还是用一个订单,这个订单的单据类型就会一会儿入库,一会儿出库,逻辑上不清晰,对历史查库存变动记录也会有影响。

           这么多单据每一个都单独查会比较麻烦,所以一般会统一设计一个凭证表,用来记录所有出入库各个类型单据的商品数量变动。

           5、库存管理

           库存一般分为采购在途库存、实物库存、销售在途库存(在途就是在路上,是虚拟库存)。库存跟上面的单据息息相关,也就是库存的增减都是以单据过账(WMS通知OMS出入库完成)为依据。

           1)采购的过程中(OMS给WMS下发采购入库单),库存为采购在途,当库房收货后,WMS通知OMS采购入库完成,OMS中将减少采购在途库存并增加对应的实物库存(相当于库存的转移)。

           2)销售订单下发后(OMS给WMS下发销售出库单),WMS安排发货,发货完成WMS通知OMS销售出库完成,OMS中将减少实物库存并增加销售在途库存。

           3)当买家签收订单后,TMS会将物流信息回传给OMS,OMS扣减销售在途库存。

           这就是整个正向流程,商品所有权变动引起的库存变动情况。

           逆向的比较复杂,涉及签收前退货和签收后退货两种,暂略过……

           6、售后管理

           售后主要涉及到3部分:退货、退款、换货。当当都支持换货了,天猫到现在还不支持换货,不知道怎么搞的。最简单的换货方式是同品换货,而异品换货一般都涉及内部审批流,还是挺麻烦的。

           既然天猫不支持换货,那么OMS还是支持吧,当然这也要看重要和紧急度,此次OMS第一版并没有做售后管理部分。

           做退货时,退货订单要注意设计参考订单,也就是能找到原销售单的订单行,因为这涉及到后续退款、开红票的金额等。

           7、发票管理

           发票一般会分为2C、2B两种,就是给消费者开的发票和企业间采购开的发票(一般称为进项发票或销项发票,这两个词是相对的,我的销项是你的进项,你的进项是我的销项)。而每种发票又都会涉及退货时开冲红发票。

           2C发票一般是随货物一同寄出,当然也有电子发票,这就需要OMS和WMS之间进行协调,定义好发票的类型,才知道给消费者时开何种发票(一般分为纸质普通发票、电子普通发票、纸质专用发票、电子专用发票)。

           消费者退货后,服务商一般按一定周期汇总退货数据给到供应商,由供应商开冲红发票,反冲之前的进项发票。

           还有很多其他的模块,比如商品管理、上下架管理、对账管理、黄牛单管理。。。

           这次能顺利开展工作,真的很靠有技术大牛带,很多我只是提个想法,他就知道怎么做了,很省心。但是问题也出来了,就是在跟踪项目进度过程中,开发团队有些排斥,我又不好说,没办法我只能安排了每日站会,虽然跟大牛的关系很好,但是我想他也不会鸟我的站会,但我还是要做给其他人看。很多东西我还没玩转,在具体表结构设计上的一些对应关系还需要继续学习。

           写在最后,2B产品在设计过程中更注重每个功能模块之间的衔接,也就是信息流如何形成闭环,在考虑某个模块的改动时,要多考虑是否对其他功能模块或者系统造成影响。大家都说2B产品重逻辑轻体验,其实并不是不想重体验,只是除了体验还有更重要的事要做。不管是什么产品,重要的都是解决用户需求,体验不过是锦上添花,而产品本身的特性才是雪中送炭!