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

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

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

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

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

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

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

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

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

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

單業務模式下的系統架構

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

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

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

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

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

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

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

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

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

交易中臺誕生的系統架構

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

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

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

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

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

供應鏈中臺初長成

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

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

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

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

標準的供應鏈中臺模式

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

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

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

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

系統架構變成了：

跨平臺的供應鏈中臺模式

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

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

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

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

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

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

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

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

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

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

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

題圖來自Unsplash，基於CC0協議