通过商品流转了解系统模块组成

11 评论 7910 浏览 70 收藏 25 分钟

接二连三地写了十几篇关于电商财务的内容,都是些粗浅的介绍与总结,这部分只是财务系统的一部分,相对于电子商务公司的系统和业务来说更是很小的一部分。

罗马帝国不是一天建成的,正是因为有了这些微小系统的组成才形成了一个庞大的系统架构。这里想根据商品的生命周期来介绍一下我所了解的电商公司的系统模块组成。

每个公司所处的阶段不同,所以它的系统也是不断演化升级的,我个人的理解系统的技术一直在不断的推陈出新,系统是一直在合并与分拆过程中优化、重构、迭代。但无论如何演变,无论商业模式如何改变,始终围绕着供应链来进行。

商品流程介绍

物流、信息流、现金流是流通行业中的三个部分,个人简单把物流理解为关于商品(实物商品、虚拟商品)的流转,信息流是针对于我们的信息化系统的,现金流则是针对于货款的跟踪与管理的。

信息流和现金流都是以商品流为载体进行的,也是为了商品流更好的流转而服务的。无论你是开淘宝店卖服装还是在商场里开了个实体店,或者开发了一款APP或小程序创业,首先我们都需要选择商品,这里商品不仅指实物,也包括提供的服务等虚拟商品。

供应商管理

首先,我们要选择合适供货商或批发商,这时涉及的第一个系统模块就产生了即“供应商管理”。
供应商管理主要做什么?

它是供应链管理的基础模块,主要是包括供应商基础信息的管理、供应商资质的审核以及供应商考核等。

对于像我们以售卖商品为主的电商行业,主要有两种供货商即:直接供货给我们,由我们负责销售商品,一般叫自营供应商;还有一种是我们提供服务平台由供应商进行自行管理销售和发货,也叫商家,这种供应商在服务平台中一般都以店铺的形式存在。对于供应商的考核,要注重优质供应商的培养,撇弃劣质供应商。

合同管理

有了供应商,下一步就是签订合同,合同是供货商与我们的法律依据,商品的采购进货、退货、售卖与最终的财务结算都要以合同条款为基础进行。

合同可以按商品的采购与销售分为采购合同、销售合同,又可以按照与供应商或商家的合作模式分为自营合同、商家合同等。

具体的可以看一下《电商系统之合同管理》。对于合同管理我认为最重要的是相关条款的确定以及合同的变更(业务变化太快)。对于初创公司可以搭建简单的合同信息管理,对于规模大的公司对于合同管理要求就比较高,需要跟踪合同的执行过程中的各个环节。

商品管理

有了供应商和合同,这时我们才能采购或审核商品。针对于自营的商品我们需要录入商品信息、制作商品图片、生成商品详情页等基础性工作,对商家商品则更多的是商品的信息审核,确保商品信息的准确性。

商品管理系统是电商系统中核心系统。商品管理又可以分为商品品类管理模块、SPU与SKU管理、商品资质管理、商品属性管理、商品品牌管理、商品库存的管理等等。每一个模块扩展开又可以分为多个小模块。

商品价税管理可以从商品管理中独立出来,这里涉及商品的基准价、商品进价、商品退货价、商品市场价、商品售价等管理。

同时商品的定价策略是什么?

这里可能又需要比价系统,根据各友商的价格与自己的成本由系统进行价格的制定;对于税率有进项税和销项税两种。随着增值税改革,目前税率也会不定期的调整,每次的调整都会涉及商品采购与财务结算、账务报表等,所以在设计系统时需要考虑扩展性。

采购管理

有了商品,没有库存依然无法销售,对于自营商品需要先采购商品,对于商家商品则需要商家去维护商品库存。

如何采购即根据什么采购?

供应链中涉及到采购计划,初期在没有数据积累时,一般是根据销售部或运营部的预测进行商品采购。采购单是以供应商合同为基础进行的。采购管理是供应商关联的,所以这部分又涉及供应商管理平台,用于与供应商进行数据交互与审核及对账。

对于采购单数据的产生可以通过销售计划和采购计划单生成,也可以通过补货建议单生成,补货计划是供应链管理中的一个重要组成部分,它是根据需求计划、销售预测、到货周期等根据预测模型进行计算的。

在刘宝红的采购与计划管理中,针对预测有三个原则:

  1. 有预测比没有预测好;
  2. 预测是各部门协同完成的,不是供应链部门的功能;
  3. 预测数据的准确性是需要不断的循环修复与调整的。

有采就有退,商品能不能退货、退货数量是多少是由仓储部与采购部共同完成的,同时是要根据合同条款进行的。

到货预约管理

采购单创建并经过供应商的审核后,由供应商进行发货,对于发货也有两种(1)由供应商负责发货运输(2)公司自取,但是都面临一个共同的问题,发的货物何时到仓库,仓库应安排多少人去收货呢?

这就需要在供应商管理平台与仓库系统间构建到货预约系统模块,此部分需要根据仓库的存储空间及作业能力来进行预约模型的搭建。当供应商预约完成后,结合运输的在途时间便可以安排商品发货了。

入库管理

供应商发货后,经过干线运输最后就会送到仓库由我司负责入库、上架等操作,进行商品的保管。

入库有哪些操作,首先在仓库有专门的收货台,用于接收商品货物,由仓储的收货组负责。入库前需要进行商品的质检操作,这就涉及质检管理系统,质检有抽检和全检,有的按包装箱进行称重检查来判断商品是否少货或缺货。

在入库前不还涉及到装卸、标签打印等工作,这时就会产生装卸费、标签打印费等财务费用。

当这一些都完成后,收货组开始进行商品的入库操作,入库又分为整箱收货、散件收货等。而收货的商品是存放在整库,还是存放在零库,具体又涉及到仓库的库区、库位的管理,这些都是根据商品的相关属性来设置好的。

像生鲜类的商品又要根据商品温控属性确定是常温的、冷藏的、冷冻的,不同温控的商品要存放在对应的库区以便更好的保存,减少损耗。

对于比较大型的仓库,一般分为整库与零库,整库一般是整箱整箱的保存,商品的入库都是先入到整库,待销售时会从整库调拨到零库,进行商品的库内上架销售。仓库的管理涉及的知识特别多,我个人一直都对这部分非常感兴趣,只是没有太多的机会参与大型电商公司的库内管理与实践。

商品入库后,系统中就有可售库存了,前端售卖系统如APP、小程序、网站、合作渠道。

商品上架销售前工作

自营商品采购入库后,已经产生库存了;对于商家发货的商品,通过我们的服务平台可以进行库存设置。

商品可以售卖了吗?

这里回到商品管理部分,需要确认商品的图片是否已经上传完整,图片等都需要保存在CDN,这样才能保证前端的浏览和加载速度。

商品图片的管理是商品管理的重要组成部分。

商品的详情页是否生成、商品的价格是否设置好了吗?这部分需要结合网站或APP的CMS管理来进行配置。

商品是否有相关活动,这就涉及促销活动管理模块。对于我们熟悉的促销活动有商品秒杀(秒杀系统需要单独部署,每次的秒杀瞬间的流量都可能冲垮我们的APP或主站)、单品直降、满减、满赠等等。

如果公司提前发送了优惠券,这里又涉及到优惠券的发放、生效、使用等管理。

优惠券又分为满减券、现金券、品类券等等各种形式,光促销的玩法,就会把产品、研发稿的焦头烂额。

尤其当我们遇上比较糊涂的运营人员,活动设置的乱七八遭,出问题就找技术,从来不进行个人工作的检查,遇到这样的人员要极力克制,克制,再克制

在促销活动管理系统中,对于各活动间的互斥规则需要明确,不要你以为也不要我以为,最好在系统配置活动过程中加上必要的引导说明工作,以减少后期产品技术同事的擦屁股工作。

以上设置好了,商品可以销售了吗?

我们还缺少了一个环节,商品销售模板也叫配送模板的设置,即商品能送达的城市地区设置。所有的商品都需要设置包括自营与商家商品,所以关于区域编码需要采用与当前各大电商网站相同的编码,方便后续与第三方商家系统的对接。

运费模板也是上架销售前的重要部分,一般的商品都是按重量来确定收费规则,每个商品都需要进行运费模板的配置。

其它的准备工作还包括商品是否有会员价、是否支持货到付款(一般在商家上进行设置)、支付方式等。
至此,商品上架销售前的准备工作基本完成了。

分销渠道平台

在商品销售时,一般都有很多的销售渠道,线上有APP,小程序,第三方合作平台,线下有门店,大客户批发等,此外还可能有内部购销平台等。

商品如何确定在哪个平台销售,销售的价格是多少?

这就需要我们搭建一个分销渠道平台。它要能够分发商品,确定商品价格,同时最重要的是渠道库存是共享的还是独立的。

对于财务结算也要考虑到渠道的佣金计算逻辑等。此部分内容也应属于销售前的准备工作,在微信公众号上发布时没有独立出来,同事建议此部分应该做成一个类似于中台的系统来作来运营的操作。后续具体模块系统介绍时再做详细说明。

销售订单产生

商品销售的渠道有很多种,如APP上售卖、小程序上、网站售卖、第三方合作渠道、线下门店售卖。

从2011年开始的O2O到新零售的线上线下融合,从网上商城到移动APP再到这两年的社区团购小程序等,电商零售的发展是非常之快的(还有无人货架、无人超市等),销售方式也是非常之多。

如果有线下门店,则商品需要从自营仓或供应商供货到门店,产生门店库存,经过门店销售POS进行售卖。这从供应链的角度属于仓到店到户或供货商直送到店到户。这里涉及的系统有,门店销售系统、门店空间管理、门店进销存管理等几部分。

对于门店销售POS的理解等同于APP或小程序等线上销售,这里涉及的商品促销活动设置可以通过促销系统区分门店促销和线上促销两种方式。

商品的购物车管理、购物流程、支付流程等服务基本相同,但门店由于是可见即所得,所以商品浏览等可以不需要,超市的POS以及现在各超市推出的自助结账,基本上就是扫码、商品购物清单确认、支付、打印小票等几部分。

在网上商城的销售,需要网上运营部同事与产品、体验官来共同协作设计,一个简洁、清晰的商城+简洁的购物流程可以带来更多的浏览和转化率。

说到如何计算转化率,这又涉及相关的埋点进行数据的收集利用weblog来对用户的行为来进行分析。

在销售过程中有两个服务是比较重要的,即商品服务与库存服务;对于库存服务是非常关键的,商品是否超卖都与库存服务有着重要的关系,同时这部分也直接影响着下单流程的响应速度,关键的服务需要进行性能压力测试的。
商品销售的流程大家都熟悉,浏览、选定商品、加入购物车、支付、等待收货。

订单流转到后端

这里就会产生销售订单和支付流水,在电商系统组成中,前端下单系统与后端订单的业务处理是分开的,这里涉及很多的服务和任务。首先前端的数据库与后端的数据库就是隔离的,前端数据库可以扩展,后端的数据库是要进行分库分表的(每日订单量达到十万或百万级)。

1. 拉单服务:前端下完订单后,需要经过拉单服务将订单取到后端生产库,这个过程一般不做过多的逻辑处理。

2. 拆单服务:在后端库,订单是需要进行拆单的,拆单规则根据业务规则进行设置,商家商品要根据发货商家进行拆分、自发货商品要根据商品仓库、温控属性、活动类型(预售商品)等进行拆单。在拆单过程中要进行商品相关金额的分摊。

对于现在智能仓储系统的建设,对于前面介绍的拆单,一方面依赖于上游系统的商品属性,另一方面依赖于仓储系统的拆单逻辑。

3. 订单下发服务:订单经过拆单后,需要与仓储系统WMS进行对接,由仓库安排发货。

一般的WMS系统都采用第三方的,相对比较成熟稳定,没有必要自己搭建了。这里就涉及上位与下位系统的数据传递。

订单的下发与回传仅是数据交互平台的一般分,还有如商品数据、供应商数据、采购单据等传输。因为电商网站的订单量是非常大的,所以此服务要独立出来。

订单下发时要考虑哪些订单需要下发,哪些订单需要定时下发,哪些订单需要经过合单后再下发,规则还是蛮多的。不同的组合对于后续订单的作业与售后都可能不一样。

订单发货

发货是意味着我们的流程已经走过了一半,订单发货了一般情况下用户就不能再取消了。

仓储发货前需要进行订单波次生成、拣货、打包、发货等流程,由于有了第三方成熟的WMS系统,我们不需要了解太多的细节,只需要将系统间的对接接口参数、报文处理好就可以了。但是只要涉及两个系统的对接,如果双方规则定义模糊,那边后续问题就会相对较多。

商品运输:

对于订单发货,可能涉及多个包裹单,每个包裹单又对应不同的物流单号,此部分是与TMS系统对接的。不同的物流公司对于包裹单的处理跟踪也会有所不同。

用户在商城中看到的是订单(主要看拆单后的子订单),每个子订单由于商品属性不同,选择的物流产品也不同,比如普通商品与冷冻商品的运输方式肯定不同,那么就会对应不同的物流产品。

目前对于多数的电商公司都不会自建物流了,成本太高了,对于冷链物流一直是近年来不断优化,争议也是比较多的,没有实力根本无法满足商品、用户、商家的需求。

对于上面提到的包裹单一般是一个或多个包裹单对应一个子订单,在子订单的签收和取消时不仅要考虑到父订单,同时也要考虑到包裹单。

  • 考虑父订单是因为在用户下单时,用户可能享受了促销活动(如满减、赠品),当子订单发生取消和退货时要考虑到优惠的重摊重算(非常复杂);
  • 考虑包裹单时,防止一个包裹到了进行签收(另一个包括还没有到),给用户造成误解。
    订单运输的物流信息,需要与第三方物流或与像快递100等这样的服务平台进行对接,及时准确的获取运单信息。

快递将商品运送到用户手里前,还涉及到一个最后一公里的问题,即从配送站到用户的配送;这也是各大快递公司证明自己服务优劣的关键部分。

商品收货

收货又分为两部分即签收与拒收。

签收就是用户确认商品没有问题,签收确认(现在淘宝订单有的是先签收,如果有问题与快递员确定后再联系商家进行售后;贵重商品需要当面验收)。

拒收就是家里无人或商品质量或包装问题,用户不收货;拒收后商品会退还给供应商或仓库。这里又涉及到有实物拒收入库与无实物拒收入库(如保质期很短的鲜奶、鸡蛋、水果等用户拒收后如果再返还到仓库已经过期或腐烂,这时就不退仓了,降低物流成本)。

如果用户签收后,用户享用了此商品,那么此商品流程就完成了。

商品补发与换货

当商品在运输过程中损坏等原因没有满足用户需求,用户会通过售后系统进行申请商品补发或换货。

  • 商品补发就是一个新的商品重新生成补发订单、订单下发、发货、运输最终到用户手中。这里仍然走一遍订单流程。
  • 换货:如果是有实物的换货则原商品需要寄回到仓库或供应商,然后再生成一张换货订单,重新走一遍订单流程。

注意,这两种都不涉及用户的退款和收款(一般认为是等价相同商品),如果不同的商品,可以走退货流程,然后再重新代客下单。

商品退货

一直以来,商品的正向流程是比较简单的(相对于逆向流程)。但退货等售后工作必不可少,客服的售后系统是每个电商系统中非常重要的组成部分。

它包括工单的处理流程、理赔流程;工单和理赔都是围绕着商品的订单展开进行的,主要考虑以下几个方面即:

  1. 商品是否可退、退货或理赔的原因,责任方是谁
  2. 商品发生退货后是否涉及优惠,是否需要重新计算优惠,涉及的优惠券、红包等是否失效。
  3. 涉及的支付方式(如积分、礼品卡)是否要重新分摊与返还。
  4. 涉及的商品发票是否已开,是否需要红字发票。

如果退货商品需要退回仓库,需要创建退回入库单,快递方式如何,运费承担方等内容。

这里只是把主要的,想到的内容罗列一下而已,如果涉及到线下门店与供货商或仓储的内部商品管理,流程将会更加复杂。前面也提到了商品仓到家、仓到店到家、供应商到店到家、供应商到家等模式不同,售后的流程也会有所区别,这需要产品和业务以及研发人共同商讨解决方案。

总结:商品的整个流转流程简单说完了,每个流程中都涉及到不同的系统模块,每个系统模块数据有些都是要流转到财务进销存和数据分析系统中的。这里只是大框框的介绍,每个子系统的设计需要进行需求重新收集与了解,然后进行详细流程的设计才可以,后续计划逐步总结下各个系统模块和功能,希望对你我都有帮助,感谢大家阅读!

 

作者:倔强的大萝卜;公众号:倔强的大萝卜

本文由 @倔强的大萝卜 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 总结的很全面,一看就是经验丰富,一直想跟待的小朋友根据商品串下整个供应链知识,这个可以用了

    来自北京 回复
  2. 优惠券金额不能返还吧,只能重新补一张,不然财务对账时会混乱

    来自重庆 回复
    1. 对于优惠券金额的返还要考虑如果订单未发货前的取消等情况,可以直接返还,但券一般都是有使用时间和活动限制的;重新补一张也是一种方式。
      优惠券一般都是整张使用,发生商品退换货时,此部分金额是根据商品扣除的,需要计算实际退款金额,在财务对账上只要记录清晰一般还可以,不会混乱。

      来自北京 回复
  3. 腻害,学习了。
    感觉笔者对整个业务流转都很熟悉,说起来就很自如。

    来自浙江 回复
    1. 这些都是主流程,每一块都需要细化,互相学习交流,有兴趣可以关注我的公众号:)

      来自北京 回复
    2. 嗯嗯 关注了。哈哈哈哈,现在正在拜读每一篇文章。
      对我这种小白,看了很受益,平时很抽象的模块,就鲜活具象了起来。
      大赞~~

      来自浙江 回复
    3. 😀

      来自北京 回复
  4. 学习 了

    来自浙江 回复
    1. 共同学习分享:)

      来自北京 回复
  5. 写的很好

    来自广东 回复
    1. 谢谢😜

      回复