講一個關於供應鏈中台的故事

中台是這兩年火起來的一個概念，市面上有關中台的文章很多，但關於供應鏈中台的文章卻少之又少，並不是供應鏈不適合做中台，相反，供應鏈系統是天然具備中台屬性的。

筆者想借助一個故事，聊一聊我眼中的供應鏈中台。故事是杜撰的，但思想是真實的，希望和大家一起交流成長。

説起中台，從去年的風光無限，到今年的跌下神壇，再到現在的迴歸理性，正好驗證了物理學中的簡諧運動理論；當經歷了千人追捧和萬人踐踏以後，如果還能屹然於世，必有其價值所在，也終將會迴歸其價值的本質，達到均值迴歸（所謂均值迴歸，指的是無論是低於或高於真實價值的狀態，都有向真實價值迴歸的趨勢，其迴歸趨勢的強度就類似於彈簧，偏離中心越遠，強度就越大）。

本篇文章中，講一個關於供應鏈中台的誕生的故事，聊一聊筆者眼中的供應鏈中台。

在電商新零售的整個業務和系統架構中，供應鏈無疑是處於後端的一個極其重要且複雜的體系，特別是多平台多業務都需要共用供應鏈能力的時候，它幾乎無處不在卻又深不可測，商品、訂單、庫存、倉儲、物流這些環節環環相扣，一不留神就會出現一些隱藏在冰山之下的疑難雜症，解決起來費時費力，直接影響用户履約。

於是如何能讓這個龐然大物以小清新的姿態呈現給前端各業務，讓不同的業務都能夠共用，且能迅速的接入進來，便是供應鏈中台的職責了；就像一個工廠一樣，我們需要將我們複雜的底層能力進行加工、封裝，輸出為業務需要的能力，這個過程便是供應鏈中台化。

供應鏈中台並不是憑空出現的，而是隨着業務的發展慢慢形成的，是一個慢慢演進水到渠成的過程，強扭未必瓜甜，中台的建設也是一個持續完善的過程，沒有終點。

言歸正傳，開始講故事了，我們一起來看看Z公司的供應鏈中台的演化之路（故事為筆者根據日常工作杜撰而來，不具備嚴謹性，若有不合理的地方，各位看官一笑而過即可~）。

Z公司創業之初，主打3C數碼垂直品類自營業務，為了快速支持業務發展，整個公司就3套系統：業務前端APP，運營後台（負責所有電商前後台的業務）和一套簡單的倉儲系統（負責商品收發存退），系統架構如下：

單業務模式下的系統架構

由於業務簡單，運營系統和倉儲系統都是貼合業務自行訂製的，所以調整起來非常方便；但隨着業務的逐漸壯大，平台上用户越來越多，單純的3C品類已經無法滿足某些用户的訴求了；於是公司開始擴品類，讓用户在平台上有更多的選擇，同時提升平台的銷量。

為了快速試錯，各新品類的業務之間除了共用前端APP入口和用户，後台業務完全自由發展，怎麼快怎麼實現，於是照搬3C業務，每條業務很快都有了自己的運營後台，自己的倉儲系統。

不久以後，系統架構成了這樣：

各業務各自為陣的系統架構

新業務拓展很成功，訂單量快速的增長了起來。但與此同時，公司也出現了一系列的供應鏈問題：

• 每個業務新起以後，都需要自己從前端到供應鏈末端搭建整套系統，資源嚴重浪費；
• 每個業務都是自己兼職做供應鏈，各自為政，自己制定作業標準，服務水平參差不齊，極度影響用户體驗；
• 各個業務之間沒有打通，無法資源共享形成規模效應，供應鏈成本居高不下；

意識到這樣發展下去以後，平台口碑會越來越差，成本也居高不下，於是高層決策：

• 成立交易中台團隊，主要負責各業務線交易、支付、商品條線的整合與收攏，各業務後台只負責業務端的邏輯。一些交易無法承接的供應鏈業務，仍然採用從倉儲系統獲取的機制不變。
• 後端單獨成立供應鏈部門，招聘專業的倉儲團隊，將供應鏈業務（採購、倉儲、配送等）做整合，同時研發了一套標準的倉儲管理系統，新開的倉庫全都用這套標準系統。

於是，新的系統架構變成了這樣：

交易中台誕生的系統架構

這樣的架構似乎解決了業務問題，因為他們終於可以擺脱複雜的後端邏輯，集中火力攻打業務了。

但隨之而來的問題是，供應鏈側跟着業務的節奏變化太快，也越來越複雜，每次業務的調整如新開倉庫、增加拆單合單邏輯等，交易中台都需要跟着調整；只要一次沒有通知到位，必然出現商品、庫存、訂單下發等一系列問題，任何一次庫房的倉儲系統出現調整，都需要交易跟着變動，真是苦不堪言。

這樣發展下去當然不行呀，從架構合理性上來説，交易中台應該更聚焦交易業務，供應鏈業務應該在供應鏈團隊內部形成閉環，不應該讓交易過多幹預倉儲的邏輯。

於是，各位產品和技術大拿根據業務現狀，對後端系統邊界做了劃分，系統架構再一次梳理後進行調整，便出現了訂單履約中心、中央庫存和倉儲交互中心3個系統：由訂單履約中心和中央庫存與交易進行標準接口的交互（訂單負責履約調度，中央庫存負責所有倉儲系統的庫存調度）；由倉儲交互中心與各個倉儲系統進行對接，以此保證信息上下傳的標準化；交易無法承接的業務（比如庫存、退貨），也支持業務直接與履約中心和中央庫存交互。

這樣供應鏈中台的雛形就出來了，所有供應鏈引起的差異和調整都能在供應鏈系統內部完成，對交易和業務無感知，同時供應鏈體系可以同時承接多個上游業務了：

供應鏈中台初長成

這樣的系統架構更加合理了，然而天下太平的盛況並沒有持續太久，業務嚐到中台帶來的甜頭以後，又對供應鏈提出了更高的要求：“你們整個後端的邏輯都太複雜了，我們接入時還要了解你們每一個系統的邏輯，好費勁哦，能不能更簡單點，不要讓我們對接這麼多系統？”

你們是為公司創造收益的，是我們的衣食父母，所以服務好你們，解決你們的痛點就是我們中台的職責所在。

於是，為了給業務更簡單的接入體驗，供應鏈的各位產研達人們再次踏上了架構優化的征程，這回算是真正的供應鏈中台了，我們把供應鏈各系統的功能拆散，再按照業務訴求組裝成標準化中台服務，以便讓業務更便捷的接入；例如訂單取消服務，在供應鏈內部需要訂單履約中心、中央庫存、倉儲系統等多個系統聯動；現在只需要中台提供一個接口給業務系統調用就能立馬告知取消成功或失敗的結果，難度係數降低100%。

升級完的系統架構變成了這樣：

標準的供應鏈中台模式

現在所有的業務都已經接入了供應鏈中台了，這回應該可以舒坦一陣子了吧！正當供應鏈產研的同學們沉浸在勝利的喜悦中的時候，又接到一個新的項目：公司要在其它平台上開店了，商品、訂單、庫存需要打通，期望一個月上線……

好吧，這是一個合理的需求，似乎無法反駁，剛好我們的供應鏈中台經過一番沉澱以後，似乎只需要增加一個“平台”的屬性，就能夠跨過自營業務，服務於其它平台了；對於後端供應鏈來説，自營和三方的平台無非只是兩個不同的接入方而已（當然自營是親爹，我們會有更多的VIP權限開放啦）。

於是供應鏈中台很快就完成了調整，成功的將三方平台的業務接入進來了。由於每個銷售平台的基礎數據、訂單樣式、庫存形態不盡相同，總不能讓好不容易穩定的供應鏈中台再為每個平台適配一回吧？

為解決這個問題，又引進了一個平台交互中心繫統，主要與外部平台對接，將每個平台的差異性放在這一個系統中進行標準化處理以後，再與供應鏈中台進行對接，這樣中台內部就不用受到平台業務差異的影響了；反向與各平台交互的時候，也是同樣在這一層進行反向輸出。

系統架構變成了：

跨平台的供應鏈中台模式

故事講到這裏似乎圓滿結束了，然而業務的發展並不像電視劇一樣會有劇終；如同我們設計所有的B端系統一樣，始於業務發展，也終將止於業務發展，供應鏈中台不斷的沉澱，帶來的是系統架構的日益複雜和人員組織的增加，比創業之初臃腫多了，對於已經有接入先例的業務，我們當然能夠快速應對，體現中台的威力，但這一天出了意外……

原因是業務方帶來了一個新的業務模式，目前供應鏈所有的底層能力都無法支持，一旦調整起來，工程量巨大，還會影響其它已穩定的業務。

各方評估以後的最終結論是：為快速試錯，業務側產研決定自行搭建一套運營和供應鏈體系。一切又回到瞭如同企業剛發展之初那樣……

這是一個週而復始的故事，Z公司在不斷髮展的過程中誕生了供應鏈中台，並將供應鏈能力逐漸沉澱，為更多的業務賦能，但由於新模式的接入和系統架構的日漸複雜，供應鏈中台最終又成為了業務發展的瓶頸。

中台是把雙刃劍，使用得當了會產生極大的價值，但若使用不當反而會連累業務，因為它並不萬能。

在筆者看來，中台更多的是一種思想，其本質是複用和共享，指導我們將複雜的場景抽象化，將通用的功能複用。

從表現上看，它可以是一個系統，也可以是一羣跨系統的合集，還可以是某個系統中的一個小模塊，甚至可以連繫統都不是，只是一種業務形態均可；只要能夠快速的應對不同的業務場景，我們都可以稱之為中颱化。

最後，總結一下哪些企業適合搭建供應鏈中台：

• 多平台、多業務形態，業務共性大的企業；
• 多倉配形態，需要標準化輸出的企業；
• 模式清晰、業務相對穩定的企業；
• 大老闆支持的企業（不是開玩笑，這點最重要，中台建設往往涉及到多部門協作，沒有大老闆支持，是很難的）。

作者：木筆，產品一俗生，深耕於供應鏈領域，微信公眾號：供應鏈產品筆記

本文由 @木筆 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議