编辑导语：无论是传统企业还是电商，供应链都是一个非常重要的环节，同时供应链也是一个极其复杂的系统，包含了从生产制造到流通过程中的所有环节。本文作者对广义的供应链进行了分析，一起来看一下吧。

无论是传统企业还是电商，供应链都是一个重要的环节，且无法绕过。甚至一个企业的成功与否，很大程度上取决于其供应链建设的完整性。但是供应链是一个极其复杂的系统，包含了从生产制造到流通过程中的上下游的所有环节。笔者在本文尝试去打造一个“乌托邦”式的供应链，浅浅的聊一下广义的供应链都包含哪些内容，希望对你有所启发。

注：本文所述的供应链，是围绕自产自营电商进行假设

一、供应链

本文不再从基础定义去推导什么是供应链，直接关注业务本质，来便于大家快速理解。

1. 人货场

凡是需要进行货物或者服务的有偿传递的过程，都离不开人货场。

• 人：上游包含了原材料提供商、生产制作商等；下游包含了经销商、店员、仓储专管员、快递小哥、消费者等；公司内部包含了采购计划组、调拨组、订单组、物流组、财务BP、前端业务方，甚至供应链产品经理。
• 货：可能是一个实物，可能是一种服务，在“人”的不断交付过程中完成功能的升级，例如从农民手里的甘蔗，通过生产制造变成了精美的白糖，再通过物流运输，分发到网店或实体店，再被购买后由快递小哥送到消费者手里。
• 场：“人”与“货”的串联是需要物理空间来承载的，“场”就是这个物理空间，工厂、仓库、快递中转中心、运输工具等共同组成了供应链的“场”，并在这些环节中将“人”与“货”的串联形象化，可视化。

上述是基于业务场景进行的划分，传递到产品层面时，我更加倾向于用“四流合一”来抽象供应链，并拓展供应链形成一个广义的供应链。

2. 四流合一

传统四流主要强调的是企业与上游之间的沟通与往来，忽略了下游的衔接；为了提高整个项目的效率，实现降本增效是应该统筹看待上下游的四流合一。

• 信息流：传统场景是买卖双方的信息交换与沟通，现在更多的是要求各个系统之间的打通，信息传递高效率，例如生产管理系统-ERP-OMS-WMS-TMS之间的信息自动化传递，从而提高作业效率。
• 商流：信息传递是多样性的，如何保证规范，那就要依靠商流中的合同约束、合同结算、合同付款来一步步的有效管理，甚至到下游的商品销售、发票获取等。
• 资金流：在合同完成结算后就需要涉及到实际的资金拨付，在实际场景下交付方式可以基于合同具体节点、压款等各种形式，就会导致合同结算进度与实际资金拨付差异，能反映出整体预算与决算的差异，保障各个阶段的供应链计划顺利运行。
• 货物流：回归到供应链的本质，也是供应链的核心，在完成上述三流后，就需要通过完整的供应链来监控整个货物的运转，并在完成对客户的交付后内部完成“对账”，形成四流合一的闭环。

综上我们通过了业务角度的形象化、产品角度的抽象化来分别解读了广义的供应链应该是什么模样的，那具体到产品方案上，应该怎么样做才能具体落地呢？下文会继续进行产品方案的分总模式拆解。

二、供应链后台

供应链的底层建设决定了其后期的可拓展性、灵活性。最常采用的是业务划分的模式进行建设例如订单履约中心、中央库存、仓储系统等，然后再进行抽象提供相关的中台服务。

好处是业务方对接中台很轻松，不用理会后台的复杂逻辑；坏处是，后台逻辑复杂，各个底层业务的耦合较深，越到后期越有牵一发动全身的趋势，真的是“有苦自己咽”。基于这些问题考虑，我更推荐的通过领域模型，进行DDD的实践落地（有兴趣的可以单独查询，在这里就不深入了）。

领域驱动设计是一门技术语言，对产品来说的好处就在于是以每个功能为切入点，不深度耦合，每次的迭代都遵循：

按照此思路，根据实际业务场景，可以大概划分为如下的领域：

说明：简单的领域模型，实际可能有差异

1）核心数据

商品中心实现对全公司货物的统一管理，负责基础商品数据维护；码中心实现一物一码、一物多码、管理盒提箱码的关系、满足营销策略；最后通过中央库存管理，实现对全公司所有货物的统一调度、分发，实时掌握库存情况，指导其他业务开展工作。

2）核心功能

货物需要流动，通过订单中心收集全公司的订单需求进行相关的订单策略配置，例如是否需要拆单、是否为预售、如何生成发货单等，是唯一的订单收口单位，与业务紧密关系的；发货中心承接单纯的供应链发货任务，没有业务规则的困扰，快速行使供应链发货的本质职能；退换货中心则主要承担售后功能，串连仓库、供应链、前段业务订单的退款；最后的物流中心，就是供应链的神经，传递着最上层的指令，并且实时监控每一宗货物的交付。

3）辅助功能

在全国自建多仓布局下，CDC-RDC-FDC之间的货物调拨分配显得尤为重要，为了更好的提供实时数据给中央库存做决策，调拨中心是必须搭建的，形成科学、实时的调拨策略，统筹全国调拨计划；调拨过程落地后我们称之为配送过程，不同于2C的配送有完整运营商承接，受制于全部不同地区的经济发展程度，调拨配送可能需要自建或者购买TMS模块来实现对调拨货物的实时掌握，以便于成本控制。

上述底层域划分清楚后，各自都能独立运作，并提供相应的横向支持，整个地基显得更加牢固，如下图所示：

三、供应链中台

底层域的交互在尽可能简单的场景下，对于上游业务来说也显得很复杂，理解成本是偏高的，此时就应该结合实际业务开展供应链中台建设，进行相应的任务编排。

从产品角度来理解，中台的任务编排其实就是内部任务编排与外部任务编排。

内部任务编排：对一些常用的任务进行规划编排，尽可能简单的让业务使用，例如库存查询服务，业务方可以输入A商品，系统根据权限配置返回中央库存、分仓库库存、可售数、可配数等，兼容多场景。

外部编排：提供多种服务给到业务方，其自行进行编排以达到某种目的，例如先利用商品查询服务获取到商品编码，再用商品编码进行商品库存查询。

按照这个思路，我们倾向于在中台提供商品应用服务、库存查询服务、订单API服务、物流查询服务、码应用服务、数仓服务，将供应链后台的复杂结构服务化，通过不断的服务补充来完成供应链中台建设

• 商品应用服务：提供商品增删改查服务，维护商品全局统一性
• 库存查询服务：提供中央库存、分仓库存、可售数、可配数等物料数据的单个或批量实时查询，支持前端实时售卖
• 订单API服务：中台最核心的功能，接收全公司所有订单的标准化输入，保证后续供应链流程正常流转
• 码应用服务：通过自身编码规则生产符合我司实际业务的编码并输出到生产系统中对商品进行赋码，并提供基于商品与码的关联查询服务
• 数仓服务：供应链唯一的大数据出口，能够进行简单的数据加工，给大数据部门提供可靠稳定的数据接口服务，实现供应链数据可视化
• 物流查询服务：围绕着赋能前端2C业务开展的，可以结构化多承运商的路由结构，输出符合我司的标准快递路由，减少阅读与统计成本

综上可以看出，供应链中台建设主要是围绕着“多快好省”的方式进行的，并不会暴露太多供应链底层逻辑，减少了沟通节点与成本。

四、供应链前台

供应链中台不仅会支持兄弟部门的业务，围绕供应链业务会拓展出很多产品应用，如下图所示：

广义的供应链前台涵盖了从招采到最后的数据驾驶舱的全部前台功能。

• 招采中心、生产/采购计划管理：主要聚焦的是招投标、工厂生产、成品采购等，与商品基础数据紧密相关，其中还会涉及到样品打样、供应商评分、开标等，一旦中标则进行合同管理模块
• 合同管理：合同的价值、数量，交付节点与数量，直接关系着调拨计划、入库上架时间、前端售卖节点等；而交付完成，根据产品质量则涉及到合同结算，以及合同款项的拨付，特别是采购种类繁多、SKU量级大的场景下，一个完整的供应链合同台账管理是必须的
• 收付款管理、对账管理、资金计划管理：是供应链预决算的体现，通过对采购相关合同付款、物流费用付款、仓储费用付款；以及销售资金的收款；自动匹配年度资金计划，进行全局的收支呈现
• 发票管理：主要在分为采购合同的进项发票管理，与售出货物的开票（销项发票）管理
• 数据驾驶舱：针对仓库库存实时分布、订单数据统计、物料运输数据统计的大屏展示，便于直观的了解供应链的整体运转情况
• 供应链工作台：供应链管理人员日程处理相关实物的工作台，例如工单咨询与处理、异常订单或异常物流的监控与处理、个人效率统计等

上述功能都是依托于供应链中台服务实现，并不直接干涉供应链后台底层业务流转，可以根据财务审计要求、供应链业务诉求随时灵活调整。

五、业务前台

不同于供应链前台，业务前台其实与供应链是没有直接关系了，而是通过其自营业务、或者在第三方电商平台的业务进行数据收集后，通过供应链中台的相关服务与供应链发生交互，主要是通过“不可见”的接口进行的，这里就不详细表述了。

六、外部对接

除了上述的前中后台，在供应链业务中还有一个很重要的方向就是外部对接，前中台业务绝大部分都局限于公司内部的数据交互与治理，但是远远满足不了供应链的交付需求，例如业务前端有一个货物需要指定某快递承接，此时就需要引入外部的例如快递承运商等第三方平台来协助共建供应链。

如上图所示，WMS是整个外部最核心的对接方，货物在仓库里面的所有验收上架、分拣运作均需要通过其完成，且软硬件结合明显，专业度极高，一般采用全套才买或者租赁仓库对接公司供应链系统的方式进行。

快递承运商一般是与WMS进行对接，由甲方（公司）下达派送命令到WMS再传递到对应的快递承运商执行的，但是涉及到大客户协议、快递费用对账、更高精度的拦截、改派、疫情防控等，还是需要甲方与快递承运商直连，实现精准的1V1。

OMS/ERP主要为可能会存在对接独立于本供应链之外的系统例如第三方电商等。

财务审计则是最后的数据标注输出，供应链的繁琐流程决定了其对账成本的巨大的，如何与公司的财务系统实现业财一体化，是一直探索的目标。

对于需要自行生产实物的公司，还需要能够具备与工厂流水线的机器对应的系统对接的能力，例如二维码的喷涂等。

七、完整架构与MVP

根据上面的分模块介绍后，我们可以很清晰将各个模块拼接起来，形成如下图所示的广义供应链的完整架构

上述架构是我们“乌托邦”式的畅想，实际落地中，往往会有阻力或者难度，并不是说不让做而是根据公司的实际情况，可能放在其他模块更加合适。

• Case1：收付款管理中针对销售收入一般放在交易模块，并不会由供应链来承接
• Case2：发票管理也只有在财务侧使用的情况下才会收集到跟采购合同相关的发票，销售侧发票不会同步到供应链环节
• Case3：第三方电商的订单明文数据，现在受制于相关法律要求，基本无法采集
• Case4：TMS的建设涉及到实体货车的购买与维护，成本巨大，一般企业难以负担，更多的是脱离监控的调拨或指定有第三方运输公司外包

类似与上述场景的问题还有很多，我们就不再展开了，那在面对如此多的问题困扰下，如何快速的建设一个能跑起来的供应链呢？我们需要的是一个可落地MVP路径，如下图所示：

在此MVP加持下，基本可以满足业务诉求，保证业务先行。但是作为一个产品经理的执念，大家不要忘记了心中的“乌托邦”！

本文由 @寒松 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议