一个供应链系统，是怎样从规划到演变的？

会员服务 ·

一个供应链系统，是怎样从规划到演变的？

2022 年 11 月 3 日 人人都是产品经理

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

合理的系统架构从来不是设计而来的，而是演变而来的，做系统规划需要我们静下心来一点一点地修改完善。本文基于真实案例，分享了一个Z公司的供应链体系发展演变的故事，希望能给初学者一些启发。

全文共 5011 字，阅读需要 10 分钟

——————/ BEGIN /—————

最合理的系统架构通常不是设计来的，而是演变来的，我们在做系统规划时，有的时候需要稍微慢一点，不能急功近利，因为业务和时间才是我们最好的架构师。

本篇文章，木笔想给大家分享一个Z公司的供应链体系发展演变的故事，基于一些真实案例汇总改编而来，希望给初做系统规划的朋友带来一些启发；故事背景和素材都是杜撰的，若有雷同，纯属巧合哈~

Z公司是一个电商平台，主营化妆品业务，从成立之初，总共经历了四次大的供应链的业务模式升级，分别是：

阶段一：商家发货阶段。平台搭建之初，为了省供应链成本，主要由商家承担发货。

阶段二：自营发货阶段。平台开始尝试自营商品采购和入仓，但作为一个特殊商家入驻平台，通过自己的仓储发货。

阶段三：仓储精细化阶段。随着商品品类和订单量的增大，需要精细化管理实物进销存，组建自己的仓储团队和库房。

阶段四：供应链履约阶段。开始重用户体验和供应链履约，有多仓分仓、合单、物流预约等履约诉求。

▲ Z公司的供应链发展阶段

因为业务的迭代更新，系统架构也跟着做了相应的4次大的升级演变。下面我们分别对每个阶段的业务及系统规划来进行拆解，看看Z公司的系统是如何跟着业务一步一步演变到今天这个样子的。

商家发货阶段

Z公司成立之初时，主打线上电商平台，通过MCN引流，商品货源全都来源于合作商家，由商家发货，平台抽佣，所以只建立了线上交易营销体系和商家系统，用户下单以后，就从交易系统将订单按照商家维度拆分后分发给对应的商家发货，交易系统和商家系统共用交易订单，商家操作商家系统做商品上架和订单发货，系统架构如下图所示：

▲ 业务发展初期的业务流程和架构

这样的架构很符合公司现状，简单灵活，产品经理小W和4名研发、1名测试妹子就能支撑起整个业务，因为模式简单，每次需求上线很快，问题也少，业务和产研彼此合作非常愉快，业务方常常在公共场合表达自己遇到了最专业的产品经理和技术团队，说的小W怪不好意思的。

自营发货阶段

随着业务的慢慢扩大，商家发货就出现了弊端，经常出现假发货、商品品质差等问题，比较损害用户体验，但因为平台的体量还不足够大，无法像大公司一样约束商家（否则人家不跟你玩了，你就断货了，两败俱伤），所以问题一直无法根治。

老板意识到公司想进一步做大，还是需要有稳定靠谱的货源，不能完全依赖商家，于是开始尝试自营业务，寻找自己的供应链渠道，这样货源和品质更加有保障，并且营收比收取平台佣金更高。

做自营必然就需要有自己的采购和仓储，于是从销售部门抽出两名同事来兼职负责采购和仓储管理。

当时在大家的眼里，自营和商家在业务处理上没有太大的区别，无非就是多了一个需要从自己的仓库里发货的特殊的商家，于是以最低成本启动了此项目，做法也简单：临时在办公室里摆了几排货架当做仓库，通过购买的一套XX ERP 系统管理商品的采购和进销存业务，线上则为自营业务开设了一个商家账号，也用商家系统承接订单进行发货。

当前系统出库流程为：当订单产生以后，由交易系统根据商品的归属对订单进行拆分，商家货源的商品推送商家发货，业务方登录自营商家账号，将订单导出来，再导入ERP系统中完成发货，最后将发货的物流单号回填到商家后台通知用户。

▲ 自营发货阶段的业务流程和架构

因为是自营业务运行的初期，商品品种和订单量都不大，线上订单承接和线下发货没有实现联动，业务方在自己的办公室里搭建的简易的仓库也能勉强满足发货需求。这个阶段系统层面没有大的调整，需求承接和处理仍然很快。

仓储精细化阶段

临时仓库的模式跑了三个月以后，自营的SKU 和订单量都开始上涨，符合预期。

老板决定加大对自营业务的投入：计划管理1000个以上SKU，库存量达到10万，很明显办公室里的小仓库已经无法满足库存管理现状。

与此同时，由于线上的商家发货和线下的ERP发货没有通过系统打通，销售的同事兼职发货也不专业，在过去的3个月里，也经常出现错发漏发的情况，很伤用户体验。

为了解决以上问题，COO做了三个决策：

找一个标准的仓库来管理商品进销存；
招聘一名专业的仓储经理对仓库流程和商品库存做精细化管理；
产研部门快速开发一套仓储系统来支持仓储发货业务，实现将库存、订单与销售平台打通联动。

由于业务量的增大，系统的复杂程度也随之提升，产研中心也跟着业务的调整步伐将原有的团队进行了扩编，并抽出5名技术负责新仓储、采购相关供应链系统的初期建设。

在新仓储经理还没有招聘到岗之前，为了赶项目工期，产品经理小W便与业务方一起基于现有的业务模式快速出具了一套简易的仓储入出库流程：

在ERP系统中创建采购单以后，下发采购单到新仓储WMS系统中；
商品到货以后，在新WMS中收货、加库存，并同步库存给销售平台上架售卖；
用户下单以后，订单下发到WMS系统中拣货打单，打包发货。

新WMS系统参考ERP的设计思路，没有波次、没有策略，只有基本的货位和库存管理、打单出库和订单取消流程，订单生成以后，直接基于交易订单进行打单、拣货和发货，项目组加班加点，终于赶在1个月内完成了系统的上线，实现了商品的精细化管理。

▲ 仓储精细化管理的业务流程和架构

新WMS系统上线以后，虽然有很多问题，但随着慢慢的优化改善，错发货漏发货的现象明显下降了，加上新仓储经理的到岗，对仓库进行了专业的规划布局和现场管理，并提了很多系统方面的优化需求，仓储作业效率提升了30%以上，每天发货几千单毫无压力。

在这个阶段里，系统复杂度和工作量相对之前提升了不少，产研团队也因此分成了好几个team各司其职，彼此之间经常会出现一些系统边界和沟通协作的问题，导致业务方提的需求再也无法像之前一样保质保量了，时不时还会出现线上bug，业务部门的老员工经常怀念之前人少、业务简单，能快速奔跑的日子，可惜如今业务模式今非昔比，再也回不去了。

供应链履约阶段

随着仓储团队的搭建和仓储系统的上线，自营业务慢慢步入正轨，一年后已经顶起了公司GMV的半边天，这个时期，商家业务和自营业务并驾齐驱，成为公司的两大业务支柱，可喜可贺。

但随之遇到了新的供应链问题：

一个仓库已经无法满足日益增长的业务量，需要提前规划仓库扩充；
很多新品类的供应商在外地，如果都从外地采购回总部，物流费太高，时效也长，遇到突发情况就会无法及时到货；
公司开始重视用户体验和履约，希望给用户提供更好的履约服务，比如提供承诺部分地区次日达、多单合包、无忧售后等。

以上问题的决策方案是在全国5地开仓，通过全国的仓储网络布局来为用户提供更优的履约服务，并解决单仓产能不足和外地采购的问题，一举多得。

但这对目前的系统架构挑战相当大。

由于多地建仓，就需要多个仓库都使用WMS系统，这还好说，把WMS做个升级，支持多个仓库身份就可以了，可是多地铺货，就意味着一个用户的订单可能会被拆分到多个仓库发货，履约过程中需要对订单进行拆单和合单，而目前的架构里，仓库发货是基于订单的，和订单强关联，这就比较麻烦了，总不能直接操作订单数据吧！

小W悔不当初，当初为了快速支持仓储业务，技术哥建议直接在订单表上进行开发仓储WMS，那样工作量可以减半，虽然知道一旦有多仓了一定会出现问题，但当时为了按时上线，小W也没再坚持，如今业务发展至此，当初的担心还是不幸发生了。

后悔也无济于事，解决问题才最重要，还好业务给了3个月的缓冲期，还有时间亡羊补牢。

经过认真思考，小W拿出了新的系统解决方案：

将仓储WMS系统基于订单出库的功能解耦，通过发货单来承接订单，不再强依赖订单；
在交易订单和仓储系统之间搭建起履约系统和中央库存系统，所有出库订单必须先经履约系统进行履约的审核、拆单、合包等处理后，以仓库和商家为单位生成发货单，将自营业务下发对应仓库的WMS系统，商家订单下发商家发货系统，仓库和商家发货以后，再将物流单号回传履约系统，履约系统统一返给上游交易系统；
WMS以仓库做数据权限升级，从单仓支持到多仓，每个仓库管理自己的进销存数据；
搭建物流管理系统，统一管理全国各个仓库的发货物流策略，并对物流环节全程跟踪。

以上四招一出，一套健全的履约系统雏形就出来了，订单从下单到用户签收过程中，也不再是一张订单到底了，而是会经历履约发货单、仓储发货单和物流单等多个业务单据流转，只有这样才能符合公司的规划预期。

小Q本以为这是本公司特有的系统特色，后来和业内朋友一沟通才知道这种架构也是业内通用的解决方案，原来通往正确的道路上大家都是殊途同归，早知道就不用自己生憋这么久了。

方案得到了CTO的肯定，立即投入资源立项开干，研发过程中的心酸自不用说，但结果不负众望，3个月以后，经过交易、履约和仓储配送3个团队的齐心协力，这样的一套基于新架构的的履约系统问世了。

▲ 供应链履约阶段业务流程和架构

系统上线以后，业务也按照节奏开始全国开仓布局，在磨合了2个月以后基本趋于稳定。

小W看着一个个包裹从不同的仓库发出，仿佛看到了一张张真实满意的笑脸，那是用户对履约服务的认可，如若如此，自己和项目组过去几个月的披星戴月和筚路蓝缕都值得了。

新系统的上线，成功解决了供应链业务扩张的问题，但由于系统的复杂程度大幅提升，需求实现成本和人力成本也随之增加不少，经常做一个需求会涉及五六个团队一起联动，如何才能让产研团队更加高效敏捷，成了CTO眼中的难题。

另外，由于系统变多，财务数据往往需要跨多个系统提取，但各系统统计维度各不相同，使得财务核算成本也大幅提升。

财务总监经常向CTO吐槽说，创业初期，每天的营收用计算器都能算出盈亏，现在信息化强多了，各种智能系统，却不能出个完整的财务报表了，到底是进步了还是退步了？

CTO也只能无奈陪笑，承诺会在下半年规划一套健全的业财一体化系统来解决财务问题……

最后的总结

故事讲到这也该接近尾声了，但Z公司的业务发展还在继续，供应链的发展也还会有阶段五、阶段六、阶段七……每个阶段都会有业务的困难和新的系统解决方案，循环往复、生生不息，未来会走向何方，我们不得而知……

Z公司的发展轨迹并不唯一，它是木笔笔下的一个故事，更是很多公司的缩影。

相信很多朋友都能从中看到自己曾经奋斗的影子，我们不去评论每个阶段的好与坏，因为存在即合理，相信每个阶段做的决策一定是当时最合理的，用后来人的视角去评判当初的好坏总是片面的。

但对过去做复盘，我们还是有一些经验值得借鉴的：

1）业务的发展往往不是线性的，可能在某一个时间点会有质的变化，比如外部环境的变化、订单量的指数级增长或断崖式下跌、业务模式的快速调整，这就要求系统规划时需要有一定的前瞻性，这个前瞻性的度需要合理把握，不宜太短见也不宜太长远，太短会阻碍业务的变化，太长会增加实现成本，力不从心，合理的方式是架构上做好长期兼容，但落地时先考虑短期实现。

2）现在都在大谈特谈的MVP和敏捷开发，但有些工作是不能省，也不能敏捷的，比如系统的基础架构，如果架构不稳，就是房子的地基不牢，终有一天，我们会为今天的偷懒埋单，而为之付出数倍的成本。

3）业务的复杂一定会带来系统的复杂吗？一定的，无论是横向的业务模式扩充，还是纵向的单量的增大，都需要从系统层面支持，有时是性能上的，有时是功能上的，有时是策略上的，但好的架构就是让系统尽量简单清晰，退而求其次，是将复杂藏在系统内部，把简单展示给业务，这是大道至简的精髓，说起来容易，实现起来却不容易。

4）系统做到最后，一定是回归业务本质，特别是B端系统和供应链尤其如此，因为业务才是需求源头。真实需求是客观存在的，不是产品经理造出来的，无论是产品经理、架构师还是程序员，要做的事情只有一件：发现需求并解决问题。而先理业务，再聊系统规划和实现，是事半功倍的不二法则，永不过时。

先总结以上4点吧，以后有机会咱们再细聊。

最后，用文章开头的结论作为本文的结束：最合理的系统架构通常不是设计来的，而是演变来的，业务和时间才是我们最好的架构师。