讲一个关于供应链中台的故事

中台是这两年火起来的一个概念，市面上有关中台的文章很多，但关于供应链中台的文章却少之又少，并不是供应链不适合做中台，相反，供应链系统是天然具备中台属性的。

笔者想借助一个故事，聊一聊我眼中的供应链中台。故事是杜撰的，但思想是真实的，希望和大家一起交流成长。

说起中台，从去年的风光无限，到今年的跌下神坛，再到现在的回归理性，正好验证了物理学中的简谐运动理论；当经历了千人追捧和万人践踏以后，如果还能屹然于世，必有其价值所在，也终将会回归其价值的本质，达到均值回归（所谓均值回归，指的是无论是低于或高于真实价值的状态，都有向真实价值回归的趋势，其回归趋势的强度就类似于弹簧，偏离中心越远，强度就越大）。

本篇文章中，讲一个关于供应链中台的诞生的故事，聊一聊笔者眼中的供应链中台。

在电商新零售的整个业务和系统架构中，供应链无疑是处于后端的一个极其重要且复杂的体系，特别是多平台多业务都需要共用供应链能力的时候，它几乎无处不在却又深不可测，商品、订单、库存、仓储、物流这些环节环环相扣，一不留神就会出现一些隐藏在冰山之下的疑难杂症，解决起来费时费力，直接影响用户履约。

于是如何能让这个庞然大物以小清新的姿态呈现给前端各业务，让不同的业务都能够共用，且能迅速的接入进来，便是供应链中台的职责了；就像一个工厂一样，我们需要将我们复杂的底层能力进行加工、封装，输出为业务需要的能力，这个过程便是供应链中台化。

供应链中台并不是凭空出现的，而是随着业务的发展慢慢形成的，是一个慢慢演进水到渠成的过程，强扭未必瓜甜，中台的建设也是一个持续完善的过程，没有终点。

言归正传，开始讲故事了，我们一起来看看Z公司的供应链中台的演化之路（故事为笔者根据日常工作杜撰而来，不具备严谨性，若有不合理的地方，各位看官一笑而过即可~）。

Z公司创业之初，主打3C数码垂直品类自营业务，为了快速支持业务发展，整个公司就3套系统：业务前端APP，运营后台（负责所有电商前后台的业务）和一套简单的仓储系统（负责商品收发存退），系统架构如下：

▲单业务模式下的系统架构

由于业务简单，运营系统和仓储系统都是贴合业务自行订制的，所以调整起来非常方便；但随着业务的逐渐壮大，平台上用户越来越多，单纯的3C品类已经无法满足某些用户的诉求了；于是公司开始扩品类，让用户在平台上有更多的选择，同时提升平台的销量。

为了快速试错，各新品类的业务之间除了共用前端APP入口和用户，后台业务完全自由发展，怎么快怎么实现，于是照搬3C业务，每条业务很快都有了自己的运营后台，自己的仓储系统。

不久以后，系统架构成了这样：

▲各业务各自为阵的系统架构

新业务拓展很成功，订单量快速的增长了起来。但与此同时，公司也出现了一系列的供应链问题：

• 每个业务新起以后，都需要自己从前端到供应链末端搭建整套系统，资源严重浪费；
• 每个业务都是自己兼职做供应链，各自为政，自己制定作业标准，服务水平参差不齐，极度影响用户体验；
• 各个业务之间没有打通，无法资源共享形成规模效应，供应链成本居高不下；

意识到这样发展下去以后，平台口碑会越来越差，成本也居高不下，于是高层决策：

• 成立交易中台团队，主要负责各业务线交易、支付、商品条线的整合与收拢，各业务后台只负责业务端的逻辑。一些交易无法承接的供应链业务，仍然采用从仓储系统获取的机制不变。
• 后端单独成立供应链部门，招聘专业的仓储团队，将供应链业务（采购、仓储、配送等）做整合，同时研发了一套标准的仓储管理系统，新开的仓库全都用这套标准系统。

于是，新的系统架构变成了这样：

▲交易中台诞生的系统架构

这样的架构似乎解决了业务问题，因为他们终于可以摆脱复杂的后端逻辑，集中火力攻打业务了。

但随之而来的问题是，供应链侧跟着业务的节奏变化太快，也越来越复杂，每次业务的调整如新开仓库、增加拆单合单逻辑等，交易中台都需要跟着调整；只要一次没有通知到位，必然出现商品、库存、订单下发等一系列问题，任何一次库房的仓储系统出现调整，都需要交易跟着变动，真是苦不堪言。

这样发展下去当然不行呀，从架构合理性上来说，交易中台应该更聚焦交易业务，供应链业务应该在供应链团队内部形成闭环，不应该让交易过多干预仓储的逻辑。

于是，各位产品和技术大拿根据业务现状，对后端系统边界做了划分，系统架构再一次梳理后进行调整，便出现了订单履约中心、中央库存和仓储交互中心3个系统：由订单履约中心和中央库存与交易进行标准接口的交互（订单负责履约调度，中央库存负责所有仓储系统的库存调度）；由仓储交互中心与各个仓储系统进行对接，以此保证信息上下传的标准化；交易无法承接的业务（比如库存、退货），也支持业务直接与履约中心和中央库存交互。

这样供应链中台的雏形就出来了，所有供应链引起的差异和调整都能在供应链系统内部完成，对交易和业务无感知，同时供应链体系可以同时承接多个上游业务了：

▲供应链中台初长成

这样的系统架构更加合理了，然而天下太平的盛况并没有持续太久，业务尝到中台带来的甜头以后，又对供应链提出了更高的要求：“你们整个后端的逻辑都太复杂了，我们接入时还要了解你们每一个系统的逻辑，好费劲哦，能不能更简单点，不要让我们对接这么多系统？”

你们是为公司创造收益的，是我们的衣食父母，所以服务好你们，解决你们的痛点就是我们中台的职责所在。

于是，为了给业务更简单的接入体验，供应链的各位产研达人们再次踏上了架构优化的征程，这回算是真正的供应链中台了，我们把供应链各系统的功能拆散，再按照业务诉求组装成标准化中台服务，以便让业务更便捷的接入；例如订单取消服务，在供应链内部需要订单履约中心、中央库存、仓储系统等多个系统联动；现在只需要中台提供一个接口给业务系统调用就能立马告知取消成功或失败的结果，难度系数降低100%。

升级完的系统架构变成了这样：

▲标准的供应链中台模式

现在所有的业务都已经接入了供应链中台了，这回应该可以舒坦一阵子了吧！正当供应链产研的同学们沉浸在胜利的喜悦中的时候，又接到一个新的项目：公司要在其它平台上开店了，商品、订单、库存需要打通，期望一个月上线……

好吧，这是一个合理的需求，似乎无法反驳，刚好我们的供应链中台经过一番沉淀以后，似乎只需要增加一个“平台”的属性，就能够跨过自营业务，服务于其它平台了；对于后端供应链来说，自营和三方的平台无非只是两个不同的接入方而已（当然自营是亲爹，我们会有更多的VIP权限开放啦）。

于是供应链中台很快就完成了调整，成功的将三方平台的业务接入进来了。由于每个销售平台的基础数据、订单样式、库存形态不尽相同，总不能让好不容易稳定的供应链中台再为每个平台适配一回吧？

为解决这个问题，又引进了一个平台交互中心系统，主要与外部平台对接，将每个平台的差异性放在这一个系统中进行标准化处理以后，再与供应链中台进行对接，这样中台内部就不用受到平台业务差异的影响了；反向与各平台交互的时候，也是同样在这一层进行反向输出。

系统架构变成了：

▲跨平台的供应链中台模式

故事讲到这里似乎圆满结束了，然而业务的发展并不像电视剧一样会有剧终；如同我们设计所有的B端系统一样，始于业务发展，也终将止于业务发展，供应链中台不断的沉淀，带来的是系统架构的日益复杂和人员组织的增加，比创业之初臃肿多了，对于已经有接入先例的业务，我们当然能够快速应对，体现中台的威力，但这一天出了意外……

原因是业务方带来了一个新的业务模式，目前供应链所有的底层能力都无法支持，一旦调整起来，工程量巨大，还会影响其它已稳定的业务。

各方评估以后的最终结论是：为快速试错，业务侧产研决定自行搭建一套运营和供应链体系。一切又回到了如同企业刚发展之初那样……

这是一个周而复始的故事，Z公司在不断发展的过程中诞生了供应链中台，并将供应链能力逐渐沉淀，为更多的业务赋能，但由于新模式的接入和系统架构的日渐复杂，供应链中台最终又成为了业务发展的瓶颈。

中台是把双刃剑，使用得当了会产生极大的价值，但若使用不当反而会连累业务，因为它并不万能。

在笔者看来，中台更多的是一种思想，其本质是复用和共享，指导我们将复杂的场景抽象化，将通用的功能复用。

从表现上看，它可以是一个系统，也可以是一群跨系统的合集，还可以是某个系统中的一个小模块，甚至可以连系统都不是，只是一种业务形态均可；只要能够快速的应对不同的业务场景，我们都可以称之为中台化。

最后，总结一下哪些企业适合搭建供应链中台：

• 多平台、多业务形态，业务共性大的企业；
• 多仓配形态，需要标准化输出的企业；
• 模式清晰、业务相对稳定的企业；
• 大老板支持的企业（不是开玩笑，这点最重要，中台建设往往涉及到多部门协作，没有大老板支持，是很难的）。

作者：木笔，产品一俗生，深耕于供应链领域，微信公众号：供应链产品笔记

本文作者 @木笔

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！