快好知 kuaihz

电商O2O后台供应链系统实操记录——采购模块

本文主要写作者在公司设计供应链系统的实操记录,根据所在公司的业务模式,介绍供应链系统整个设计过程的思路、方法和核心要点。

电商、O2O行业的产品线中,后端的业务支持系统占据了很大的比重,比如订单系统、供应链系统等。

不同于纯线上的产品,电商、O2O领域的产品基本都是后端大于前端,这些后端产品覆盖了公司的核心数据,作为公司业务运行的基础。而且因为每个公司的业务形式不同,通常需要有一套自己的或者定制化的系统作为公司独特的业务支持。

供应链系统是为公司提供商品进销存业务的管理系统。大部分以交易为核心业务的公司,都有自己商品进货发货的供应链业务,而各个不同的行业和领域又有自己独特的供应链业务形态。供应链系统通常包含采购、库存管理、出入库、物流等多个模块,是公司后台产品线重要的一环。

作为一个后端产品的产品经理,日常工作的核心在于深入地挖掘业务,梳理流程,产出模块化的系统设计方案,和C端产品有着不小的差别。

本文主要写我在公司设计供应链系统的实操记录,根据我所在公司的业务模式,介绍供应链系统整个设计过程的思路、方法和核心要点。

由于供应链具体的业务和流程每个公司不一样,这类后台产品并不像C端产品那样能直接用来参考,因此本文不是一篇介绍供应链系统应有的流程和功能的文章,核心在于思路和方法的分享,功能细节仅供参考。

一、业务背景和系统目标

首先介绍一下公司的基本业务。我们是一家做上门服务的O2O公司,不同于打车外卖等纯供需匹配的模式,我们的服务体系是自营的,而且由于自身业务的特殊性,有自己的一套类似于电商的供应链业务。

我们的具体业务,首先是由上门服务人员领取仓库的商品,用户下单后,上门到用户家里完成服务,根据订单消耗商品同时产生废品,完成服务。

商品来源于供应商的采购,废料通过采购的逆向流程退回供应商。整体来说,我们的供应链和通用的电商供应链体系比较类似,有采购、库存、出入库模块,只是没有物流发货的业务。

设计系统之前,第一步需要明确系统的目标。我们公司之前有一个1.0版本的供应链系统,但是旧版系统有很多业务流程的缺失,造成库存数量不一致,很多模块都是业务方在做手工帐,已不符合当下的业务发展。因此公司需要做一个2.0版本的新版系统来完整地支持业务。从产品角度来看,相当于从零到一的系统重构。

整个供应链业务的核心目标有三点,库存一致,资金一致,一物一码,分别是三个阶段。一物一码是未来的目标,资金一致需要和财务系统的体系打通,当前版本的目标即为从手工帐到系统库存一致。细分下来,需要将所有业务模块线上化,在每个业务模块中,涵盖所有环节的人和操作,即达到流程闭环。

二、什么是采购

采购,顾名思义,是从供应商手上批量采购商品到我们自己的仓库。采购是供应链业务的头部环节,作为公司库存的源头,又有着大量现金流,其重要性不言而喻。供应链系统的采购模块对业务的价值主要有三点:

1. 不同角色之间的业务流转和信息同步

采购会涉及到采购人员、供应商、仓库、质检这几个角色,一项采购业务需要在每个角色之间流转,各角色之间需要实时信息同步。这一点是基础。

2. 数据分析的辅助决策

采购各环节中的数据分析,比如供应商的良品率、发货时效,比如各个商品的采购满足率等,在有业务流程的基础上做数据分析。

3. 库存和资金的一致性

采购是公司库存和利润的源头,需要系统记录每一笔库存数量和财务的资金账目。

供应链系统的采购模块包括几个部分:采购的主流程,即采购申请、下采购单、采购入库这一系列流程;供应商管理,针对供应商信息、样品和财务的管控;采购逆向流程,即供应商退货。本文主要介绍采购采购的主流程。

三、采购主流程的业务对接

明确系统目标后,接下来就开始和业务方,即公司的供应链部门,进行业务的对接。

1、第一步,梳理流程,确定强流程节点,所有业务围绕着这几个节点进行

流程图如下:

2、第二步,需要确定每个流程节点中,参与业务的人员角色

我们公司的采购业务有以下这几个角色:

1)pmc,即物控计划员,职责是根据订单消耗情况,管控仓库商品数量的计划。在采购流程中,作为采购申请的发起者。

2)采购人员,根据采购申请,向和各家供应商下采购单。

3)供应商,外部角色,根据采购单发货,并定期和公司进行采购结算。

4)仓库,接受供应商发来的商品,并将良品入库,不良品退回。所有货物实体必须由仓库操作收发货。

5)质检,如果采购来的商品需要进行质量检验,需要质检参与进行检测。

6)财务,进行采购单的审核,定期和供应商结算。

3、第三步,确定各流程节点的具体操作,梳理完整的流程

1)采购申请。由pmc根据计划,或者其他仓库提交上来的申请来统一创建、管理采购申请。采购人员收到采购申请后,将采购的商品和数量分配给多个供应商,针对每个供应商分别创建采购单。

2)采购采购环节比较复杂,首先采购人员创建采购单后,需要与供应商核价,即确认报价。收到供应商的反馈后,采购人员再确定采购单并提交至财务部门进行审批,最后提交给供应商进行发货。由于早期没有给供应商的系统,需由采购将以上采购信息录入系统。

3)发货。发往每一个仓库的采购单,供应商每个批次发货时给出发货数量和物流信息,同样由采购人员进行录入。

4)收货。由仓库人员清点从供应商收到的商品及数量,通过收货操作录入系统。

5)质检。首先根据发货仓库是否有质检人员来配置是否需要质检的判断。需要质检的批次,通过质检操作填写质量检测的结果。

6)入库/退货。根据质检结果,仓库人员分别进行入库和退货操作。在入库环节发生库存数量的变化。

7)结算。根据供应商的账期,在一个固定的时间和供应商进行结算。因为这一步不是实时的环节,不算在主流程中。

根据角色和业务操作,我们可以将流程图细化,如下:

四、业务场景、数据和关系的梳理

完成业务流程的对接后,接下来需要对接数据、单据等业务的细节,根据这些确定系统各子模块的结构、关系等。

1、第一步,确定一个单子会包含哪些字段

首先是商品,即具体采购什么货品,数量多少,价格多少。

然后是供应商。每个采购单都会有个目标供应商。

第三个,仓库。一个采购单会发货至不同的仓库,因此仓库也是一个重要的字段。

2、第二步,确定各环节之间的的关联关系,一对一还是一对多,强关联还是弱关联

这一步是重点,直接决定了底层数据表之间的关系:

1)采购申请和采购之间:一对多关系,弱关联。采购人员会对一个采购申请拆分多个供应商,分别下采购单,因此两者之间是一对多关系。实际业务中,存在不通过采购申请,直接下采购单的情况,比如一些让供应商补发的采购,因此两者之间是弱关联;

2)采购单和采购收货之间:一对多关系,强关联。

采购单详情里有仓库这个字段,所以一个采购单本身对应的就是多个仓库的收货。从收货开始一直到最后,单据都是以仓库为单位,但采购单中,仓库字段被放在了在商品详情里。为了方便各仓库操作,在设计系统时,加入了采购子单的概念,即以供应商和仓库为单位,将一个采购单拆分为多个采购子单,发货环节依据采购子单进行发货。

存在供应商对同一个仓库的采购单进行多批次发货的情况,比如采购单的周期为一周三批,供应商会在每周固定时间分批次发货。因此采购子单和发货是一对多关系。

发货一定是根据采购单发的,因此强关联。

3)采购发货和采购收货:这两个操作使用的是同一项数据,收货完全按照发货进行。

4)采购收货和质检:同上,使用同一项数据,质检完全按照收货进行。

5)质检和入库/退货之间:各自一对一,强关联。收货并质检后,会根据质检结果,将采购收货的记录拆分为需要入库和退货的部分,一个批次的采购收货分别对应一个批次的采购入库和采购退货。

在这里有一个注意点:不能有多对多的关系,因为多对多关系会无法溯源。

举一个例子,在设计系统时碰到了这样一种情况:原本计划在采购申请环节中,以仓库为单位提交采购申请单,再交由采购

这样做的结果是,申请子单和采购单就是多对多关系了,申请子单是以仓库为单位,采购单以供应商为单位,那么采购单的下一步发货,每个供应商就只有发货总数量,获取不到分别给每个仓库发多少货了。除非把每一个供应商和每一个仓库全部拆开,那样一次采购得有上百个单子,根本不现实。

后来我们的做法是采购流程中不包含仓库为单位的采购申请,只提供汇总的申请功能。

3、第三步,确定各个环节的关系,确定有哪几个单据,以及每个单据的商品详情字段

整个流程中,一共包含这五种单据:采购申请单、采购单、收货单、入库单、退货单。

1)采购申请单:采购申请环节的单据,字段为仓库、商品、数量。

2)采购单:采购环节,根据采购申请单创建采购单。以供应商为单位,详情字段为仓库、商品、数量和价格。供应商本身不计入详情的字段中。

3)采购收货单:收货和质检环节,根据采购单创建采购收货单,以仓库为单位,字段为商品、收货数量、质检通过数量和质检不通过数量。

4)入库单:入库环节,同上。

5)退货单:退货环节,以仓库为单位,字段为商品和数量。

4、第四步,确定各单据之间,商品数量是否有关联关系

因为库存数量是整个供应链系统的核心,所以需要确定商品数量的变动过程:

1)采购申请量和采购量:在实际业务上,采购量不一定等于采购申请量。因为采购申请是计划入库的数量,但给供应商下采购单时,需要考虑到供应商少发、质检不通过需退货的情况,因此采购数量通常会大于申请数量。两者之间数量无关联。

2)采购量和采购收货量:下采购单后,供应商会有发货数量不足、路上丢失等情况,所以收货数量也不一定等于采购数量,无强关联,收货数量需要仓库清点后填写。

3)采购收货量和采购入库量/退货量:这里很明显,入库和退货是根据收货的数量来的,所以数量之间有强关联,入库+退货=收货

根据以上梳理得出的各环节关系结构图如下:

五、界面和操作

最后一步,终于到了设计界面和操作,产出原型的时候。这时需要将业务转化为界面显示和功能,还有以下几个事情要做:

1、界面

界面设置有两种做法,一种是将一个单据作为一个界面,通过权限将操作分开;另一种是将每个流程环节作为一个界面,我们采用了这种方案,保证每个界面有唯一的角色。

2、状态

状态的设置需要参考当前所处环节和数量变动情况这两个情况,给出用户需要了解的动态描述。采购的状态非常繁多,每一个独立的环节都需要有单独的状态,而且需要根据每个商品,将状态划分为部分和全部。具体页面的状态如下:

1)采购申请:待采购采购中、已完成;

采购申请是由pmc发起和跟进的,不关心具体的采购过程,只需要给出采购结果;

2)采购单:待采购,已发货,部分收货,全部收货,已质检,完结;

采购单是核心的环节,由采购人员对采购过程进行全程跟进,因此状态需要精确到每个节点,和单据中的每类商品。

3)采购发货/收货:待收货,待质检,已质检,完结;

收货单是从发货环节开始,由仓库负责收货以及后续的跟进;

4)质检:待质检、已质检;

5)入库:待入库、已入库;

6)退货:待退货、已退货;

这三个环节只涉及到一个操作,比较简单。

3、功能操作

功能操作是根据状态实时变动的。将前文梳理出来的操作,对应到每个页面的每个状态节点中即可。

功能操作设计的核心,在于能最大保证数据准确性的前提下,尽可能提升操作的效率和体验。首先,对于一个从0到1的系统来说,在系统上做类似于excel的数据操作一定是很难用的(尤其是没有前后端分离的系统)。然后,有些功能会存在数据准确性上的风险,比如导入和批量操作。

部分业务环节的数据量会非常庞大,比如采购单的创建,详情数据动辄上百条。

这时业务方会希望在ecxel中做这些操作然后导入系统,但是站在系统的角度,必须平衡数据风险和操作体验,因为导入后系统很难一条条去监控数据的正确性,一旦excel里数据错了又没查出来,后果不小。

因此我们只能有选择性地做导入功能,对于新增的数据支持导入,对于数据的修改则不支持导入。鉴于此,针对每个操作的设计都需要斟酌一番。

最后附上部分页面和操作的原型图。

1)采购申请页面

2)采购单页面

3)采购收货页面

4)采购商品详情

5)创建采购单(包含导入和导入校验操作)

6)批量发货操作

7)收货操作

8)质检操作

相关阅读

电商O2O后台供应链系统实操记录——订货/调拨模块

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:电商  电商词条  供应链  供应链词条  后台  后台词条  模块  模块词条  记录  记录词条