编辑导语：无论是传统企业还是电商，供应链都是一个非常重要的环节，同时供应链也是一个极其复杂的系统，包含了从生产制造到流通过程中的所有环节。本文作者对广义的供应链进行了分析，一起来看一下吧。
无论是传统企业还是电商，供应链都是一个重要的环节，且无法绕过。甚至一个企业的成功与否，很大程度上取决于其供应链建设的完整性。但是供应链是一个极其复杂的系统，包含了从生产制造到流通过程中的上下游的所有环节。笔者在本文尝试去打造一个“乌托邦”式的供应链，浅浅的聊一下广义的供应链都包含哪些内容，希望对你有所启发。
注：本文所述的供应链，是围绕自产自营电商进行假设
本文不再从基础定义去推导什么是供应链，直接关注业务本质，来便于大家快速理解。
凡是需要进行货物或者服务的有偿传递的过程，都离不开人货场。
上述是基于业务场景进行的划分，传递到产品层面时，我更加倾向于用“四流合一”来抽象供应链，并拓展供应链形成一个广义的供应链。
传统四流主要强调的是企业与上游之间的沟通与往来，忽略了下游的衔接；为了提高整个项目的效率，实现降本增效是应该统筹看待上下游的四流合一。
综上我们通过了业务角度的形象化、产品角度的抽象化来分别解读了广义的供应链应该是什么模样的，那具体到产品方案上，应该怎么样做才能具体落地呢？下文会继续进行产品方案的分总模式拆解。
供应链的底层建设决定了其后期的可拓展性、灵活性。最常采用的是业务划分的模式进行建设例如订单履约中心、中央库存、仓储系统等，然后再进行抽象提供相关的中台服务。
好处是业务方对接中台很轻松，不用理会后台的复杂逻辑；坏处是，后台逻辑复杂，各个底层业务的耦合较深，越到后期越有牵一发动全身的趋势，真的是“有苦自己咽”。基于这些问题考虑，我更推荐的通过领域模型，进行DDD的实践落地（有兴趣的可以单独查询，在这里就不深入了）。
领域驱动设计是一门技术语言，对产品来说的好处就在于是以每个功能为切入点，不深度耦合，每次的迭代都遵循：
按照此思路，根据实际业务场景，可以大概划分为如下的领域：
说明：简单的领域模型，实际可能有差异
1）核心数据
商品中心实现对全公司货物的统一管理，负责基础商品数据维护；码中心实现一物一码、一物多码、管理盒提箱码的关系、满足营销策略；最后通过中央库存管理，实现对全公司所有货物的统一调度、分发，实时掌握库存情况，指导其他业务开展工作。
2）核心功能
货物需要流动，通过订单中心收集全公司的订单需求进行相关的订单策略配置，例如是否需要拆单、是否为预售、如何生成发货单等，是唯一的订单收口单位，与业务紧密关系的；发货中心承接单纯的供应链发货任务，没有业务规则的困扰，快速行使供应链发货的本质职能；退换货中心则主要承担售后功能，串连仓库、供应链、前段业务订单的退款；最后的物流中心，就是供应链的神经，传递着最上层的指令，并且实时监控每一宗货物的交付。
3）辅助功能
在全国自建多仓布局下，CDC-RDC-FDC之间的货物调拨分配显得尤为重要，为了更好的提供实时数据给中央库存做决策，调拨中心是必须搭建的，形成科学、实时的调拨策略，统筹全国调拨计划；调拨过程落地后我们称之为配送过程，不同于2C的配送有完整运营商承接，受制于全部不同地区的经济发展程度，调拨配送可能需要自建或者购买TMS模块来实现对调拨货物的实时掌握，以便于成本控制。
上述底层域划分清楚后，各自都能独立运作，并提供相应的横向支持，整个地基显得更加牢固，如下图所示：
底层域的交互在尽可能简单的场景下，对于上游业务来说也显得很复杂，理解成本是偏高的，此时就应该结合实际业务开展供应链中台建设，进行相应的任务编排。
从产品角度来理解，中台的任务编排其实就是内部任务编排与外部任务编排。
内部任务编排：对一些常用的任务进行规划编排，尽可能简单的让业务使用，例如库存查询服务，业务方可以输入A商品，系统根据权限配置返回中央库存、分仓库库存、可售数、可配数等，兼容多场景。
外部编排：提供多种服务给到业务方，其自行进行编排以达到某种目的，例如先利用商品查询服务获取到商品编码，再用商品编码进行商品库存查询。
按照这个思路，我们倾向于在中台提供商品应用服务、库存查询服务、订单API服务、物流查询服务、码应用服务、数仓服务，将供应链后台的复杂结构服务化，通过不断的服务补充来完成供应链中台建设
综上可以看出，供应链中台建设主要是围绕着“多快好省”的方式进行的，并不会暴露太多供应链底层逻辑，减少了沟通节点与成本。
供应链中台不仅会支持兄弟部门的业务，围绕供应链业务会拓展出很多产品应用，如下图所示：
广义的供应链前台涵盖了从招采到最后的数据驾驶舱的全部前台功能。
上述功能都是依托于供应链中台服务实现，并不直接干涉供应链后台底层业务流转，可以根据财务审计要求、供应链业务诉求随时灵活调整。
不同于供应链前台，业务前台其实与供应链是没有直接关系了，而是通过其自营业务、或者在第三方电商平台的业务进行数据收集后，通过供应链中台的相关服务与供应链发生交互，主要是通过“不可见”的接口进行的，这里就不详细表述了。
除了上述的前中后台，在供应链业务中还有一个很重要的方向就是外部对接，前中台业务绝大部分都局限于公司内部的数据交互与治理，但是远远满足不了供应链的交付需求，例如业务前端有一个货物需要指定某快递承接，此时就需要引入外部的例如快递承运商等第三方平台来协助共建供应链。
如上图所示，WMS是整个外部最核心的对接方，货物在仓库里面的所有验收上架、分拣运作均需要通过其完成，且软硬件结合明显，专业度极高，一般采用全套才买或者租赁仓库对接公司供应链系统的方式进行。
快递承运商一般是与WMS进行对接，由甲方（公司）下达派送命令到WMS再传递到对应的快递承运商执行的，但是涉及到大客户协议、快递费用对账、更高精度的拦截、改派、疫情防控等，还是需要甲方与快递承运商直连，实现精准的1V1。
OMS/ERP主要为可能会存在对接独立于本供应链之外的系统例如第三方电商等。
财务审计则是最后的数据标注输出，供应链的繁琐流程决定了其对账成本的巨大的，如何与公司的财务系统实现业财一体化，是一直探索的目标。
对于需要自行生产实物的公司，还需要能够具备与工厂流水线的机器对应的系统对接的能力，例如二维码的喷涂等。
根据上面的分模块介绍后，我们可以很清晰将各个模块拼接起来，形成如下图所示的广义供应链的完整架构
上述架构是我们“乌托邦”式的畅想，实际落地中，往往会有阻力或者难度，并不是说不让做而是根据公司的实际情况，可能放在其他模块更加合适。
类似与上述场景的问题还有很多，我们就不再展开了，那在面对如此多的问题困扰下，如何快速的建设一个能跑起来的供应链呢？我们需要的是一个可落地MVP路径，如下图所示：
在此MVP加持下，基本可以满足业务诉求，保证业务先行。但是作为一个产品经理的执念，大家不要忘记了心中的“乌托邦”！
本文由 @寒松 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。