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

电商、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里数据错了又没查出来，后果不小。

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