本文主要写作者在公司设计供应链系统的实操记录，根据所在公司的业务模式，介绍供应链系统整个设计过程的思路、方法和核心要点。
电商、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）质检操作
#专栏作家#
潘帕斯雄鹰，人人都是产品经理专栏作家，进击、踩坑中的产品狗一枚，关注互联网，写过小说，看过哲学。简书：潘帕斯雄鹰。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Pexels ，基于 CC0 协议