合理的系統(tǒng)架構(gòu)從來不是設計而來的，而是演變而來的，做系統(tǒng)規(guī)劃需要我們靜下心來一點一點地修改完善。本文基于真實案例，分享了一個Z公司的供應鏈體系發(fā)展演變的故事，希望能給初學者一些啟發(fā)。

最合理的系統(tǒng)架構(gòu)通常不是設計來的，而是演變來的，我們在做系統(tǒng)規(guī)劃時，有的時候需要稍微慢一點，不能急功近利，因為業(yè)務和時間才是我們最好的架構(gòu)師。

本篇文章，木筆想給大家分享一個Z公司的供應鏈體系發(fā)展演變的故事，基于一些真實案例匯總改編而來，希望給初做系統(tǒng)規(guī)劃的朋友帶來一些啟發(fā)，故事背景和素材都是杜撰的，若有雷同，純屬巧合哈~

Z公司是一個電商平臺，主營化妝品業(yè)務，從成立之初，總共經(jīng)歷了四次大的供應鏈的業(yè)務模式升級，分別是：

階段一：商家發(fā)貨階段。平臺搭建之初，為了省供應鏈成本，主要由商家承擔發(fā)貨。

階段二：自營發(fā)貨階段。平臺開始嘗試自營商品采購和入倉，但作為一個特殊商家入駐平臺，通過自己的倉儲發(fā)貨。

階段三：倉儲精細化階段。隨著商品品類和訂單量的增大，需要精細化管理實物進銷存，組建自己的倉儲團隊和庫房。

階段四：供應鏈履約階段。開始重用戶體驗和供應鏈履約，有多倉分倉、合單、物流預約等履約訴求。

Z公司的供應鏈發(fā)展階段

因為業(yè)務的迭代更新，系統(tǒng)架構(gòu)也跟著做了相應的4次大的升級演變。下面我們分別對每個階段的業(yè)務及系統(tǒng)規(guī)劃來進行拆解，看看Z公司的系統(tǒng)是如何跟著業(yè)務一步一步演變到今天這個樣子的。

01 階段一：商家發(fā)貨階段

Z公司成立之初時，主打線上電商平臺，通過MCN引流，商品貨源全都來源于合作商家，由商家發(fā)貨，平臺抽傭，所以只建立了線上交易營銷體系和商家系統(tǒng)，用戶下單以后，就從交易系統(tǒng)將訂單按照商家維度拆分后分發(fā)給對應的商家發(fā)貨，交易系統(tǒng)和商家系統(tǒng)共用交易訂單，商家操作商家系統(tǒng)做商品上架和訂單發(fā)貨，系統(tǒng)架構(gòu)如下圖所示：

業(yè)務發(fā)展初期的業(yè)務流程和架構(gòu)

這樣的架構(gòu)很符合公司現(xiàn)狀，簡單靈活，產(chǎn)品經(jīng)理小W和4名研發(fā)、1名測試妹子就能支撐起整個業(yè)務，因為模式簡單，每次需求上線很快，問題也少，業(yè)務和產(chǎn)研彼此合作非常愉快，業(yè)務方常常在公共場合表達自己遇到了最專業(yè)的產(chǎn)品經(jīng)理和技術(shù)團隊，說的小W怪不好意思的。

02 階段二：自營發(fā)貨階段

隨著業(yè)務的慢慢擴大，商家發(fā)貨就出現(xiàn)了弊端，經(jīng)常出現(xiàn)假發(fā)貨、商品品質(zhì)差等問題，比較損害用戶體驗，但因為平臺的體量還不足夠大，無法像大公司一樣約束商家（否則人家不跟你玩了，你就斷貨了，兩敗俱傷），所以問題一直無法根治。

老板意識到公司想進一步做大，還是需要有穩(wěn)定靠譜的貨源，不能完全依賴商家，于是開始嘗試自營業(yè)務，尋找自己的供應鏈渠道，這樣貨源和品質(zhì)更加有保障，并且營收比收取平臺傭金更高。

做自營必然就需要有自己的采購和倉儲，于是從銷售部門抽出兩名同事來兼職負責采購和倉儲管理。當時在大家的眼里，自營和商家在業(yè)務處理上沒有太大的區(qū)別，無非就是多了一個需要從自己的倉庫里發(fā)貨的特殊的商家，于是以最低成本啟動了此項目，做法也簡單：臨時在辦公室里擺了幾排貨架當做倉庫，通過購買的一套XX ERP 系統(tǒng)管理商品的采購和進銷存業(yè)務，線上則為自營業(yè)務開設了一個商家賬號，也用商家系統(tǒng)承接訂單進行發(fā)貨。

當前系統(tǒng)出庫流程為：當訂單產(chǎn)生以后，由交易系統(tǒng)根據(jù)商品的歸屬對訂單進行拆分，商家貨源的商品推送商家發(fā)貨，業(yè)務方登錄自營商家賬號，將訂單導出來，再導入ERP系統(tǒng)中完成發(fā)貨，最后將發(fā)貨的物流單號回填到商家后臺通知用戶。

自營發(fā)貨階段的業(yè)務流程和架構(gòu)

因為是自營業(yè)務運行的初期，商品品種和訂單量都不大，線上訂單承接和線下發(fā)貨沒有實現(xiàn)聯(lián)動，業(yè)務方在自己的辦公室里搭建的簡易的倉庫也能勉強滿足發(fā)貨需求。這個階段系統(tǒng)層面沒有大的調(diào)整，需求承接和處理仍然很快。

03 階段三：倉儲精細化階段

臨時倉庫的模式跑了三個月以后，自營的SKU 和訂單量都開始上漲，符合預期，老板決定加大對自營業(yè)務的投入，計劃管理1000個以上SKU，庫存量達到10萬，很明顯辦公室里的小倉庫已經(jīng)無法滿足庫存管理現(xiàn)狀，與此同時，由于線上的商家發(fā)貨和線下的ERP發(fā)貨沒有通過系統(tǒng)打通，銷售的同事兼職發(fā)貨也不專業(yè)，在過去的3個月里，也經(jīng)常出現(xiàn)錯發(fā)漏發(fā)的情況，很傷用戶體驗。

為了解決以上問題，COO做了三個決策：

一、找一個標準的倉庫來管理商品進銷存；

二、招聘一名專業(yè)的倉儲經(jīng)理對倉庫流程和商品庫存做精細化管理；

三、產(chǎn)研部門快速開發(fā)一套倉儲系統(tǒng)來支持倉儲發(fā)貨業(yè)務，實現(xiàn)將庫存、訂單與銷售平臺打通聯(lián)動。

由于業(yè)務量的增大，系統(tǒng)的復雜程度也隨之提升，產(chǎn)研中心也跟著業(yè)務的調(diào)整步伐將原有的團隊進行了擴編，并抽出5名技術(shù)負責新倉儲、采購相關(guān)供應鏈系統(tǒng)的初期建設。

在新倉儲經(jīng)理還沒有招聘到崗之前，為了趕項目工期，產(chǎn)品經(jīng)理小W便與業(yè)務方一起基于現(xiàn)有的業(yè)務模式快速出具了一套簡易的倉儲入出庫流程：①在ERP系統(tǒng)中創(chuàng)建采購單以后，下發(fā)采購單到新倉儲WMS系統(tǒng)中；②商品到貨以后，在新WMS中收貨、加庫存，并同步庫存給銷售平臺上架售賣；③用戶下單以后，訂單下發(fā)到WMS系統(tǒng)中揀貨打單，打包發(fā)貨。

新WMS系統(tǒng)參考ERP的設計思路，沒有波次、沒有策略，只有基本的貨位和庫存管理、打單出庫和訂單取消流程，訂單生成以后，直接基于交易訂單進行打單、揀貨和發(fā)貨，項目組加班加點，終于趕在1個月內(nèi)完成了系統(tǒng)的上線，實現(xiàn)了商品的精細化管理。

倉儲精細化管理的業(yè)務流程和架構(gòu)

新WMS系統(tǒng)上線以后，雖然有很多問題，但隨著慢慢的優(yōu)化改善，錯發(fā)貨漏發(fā)貨的現(xiàn)象明顯下降了，加上新倉儲經(jīng)理的到崗，對倉庫進行了專業(yè)的規(guī)劃布局和現(xiàn)場管理，并提了很多系統(tǒng)方面的優(yōu)化需求，倉儲作業(yè)效率提升了30%以上，每天發(fā)貨幾千單毫無壓力。

在這個階段里，系統(tǒng)復雜度和工作量相對之前提升了不少，產(chǎn)研團隊也因此分成了好幾個team各司其職，彼此之間經(jīng)常會出現(xiàn)一些系統(tǒng)邊界和溝通協(xié)作的問題，導致業(yè)務方提的需求再也無法像之前一樣保質(zhì)保量了，時不時還會出現(xiàn)線上bug，業(yè)務部門的老員工經(jīng)常懷念之前人少、業(yè)務簡單，能快速奔跑的日子，可惜如今業(yè)務模式今非昔比，再也回不去了。

04 階段四：供應鏈履約階段

隨著倉儲團隊的搭建和倉儲系統(tǒng)的上線，自營業(yè)務慢慢步入正軌，一年后已經(jīng)頂起了公司GMV的半邊天，這個時期，商家業(yè)務和自營業(yè)務并駕齊驅(qū)，成為公司的兩大業(yè)務支柱，可喜可賀，但隨之遇到了新的供應鏈問題：

一、一個倉庫已經(jīng)無法滿足日益增長的業(yè)務量，需要提前規(guī)劃倉庫擴充；

二、很多新品類的供應商在外地，如果都從外地采購回總部，物流費太高，時效也長，遇到突發(fā)情況就會無法及時到貨；

三、公司開始重視用戶體驗和履約，希望給用戶提供更好的履約服務，比如提供承諾部分地區(qū)次日達、多單合包、無憂售后等。

以上問題的決策方案是在全國5地開倉，通過全國的倉儲網(wǎng)絡布局來為用戶提供更優(yōu)的履約服務，并解決單倉產(chǎn)能不足和外地采購的問題，一舉多得。但這對目前的系統(tǒng)架構(gòu)挑戰(zhàn)相當大，由于多地建倉，就需要多個倉庫都使用WMS系統(tǒng)，這還好說，把WMS做個升級，支持多個倉庫身份就可以了，可是多地鋪貨，就意味著一個用戶的訂單可能會被拆分到多個倉庫發(fā)貨，履約過程中需要對訂單進行拆單和合單，而目前的架構(gòu)里，倉庫發(fā)貨是基于訂單的，和訂單強關(guān)聯(lián)，這就比較麻煩了，總不能直接操作訂單數(shù)據(jù)吧！

小W悔不當初，當初為了快速支持倉儲業(yè)務，技術(shù)哥建議直接在訂單表上進行開發(fā)倉儲WMS，那樣工作量可以減半，雖然知道一旦有多倉了一定會出現(xiàn)問題，但當時為了按時上線，小W也沒再堅持，如今業(yè)務發(fā)展至此，當初的擔心還是不幸發(fā)生了。

后悔也無濟于事，解決問題才最重要，還好業(yè)務給了3個月的緩沖期，還有時間亡羊補牢。經(jīng)過認真思考，小W拿出了新的系統(tǒng)解決方案：

一、將倉儲WMS系統(tǒng)基于訂單出庫的功能解耦，通過發(fā)貨單來承接訂單，不再強依賴訂單；

二、在交易訂單和倉儲系統(tǒng)之間搭建起履約系統(tǒng)和中央庫存系統(tǒng)，所有出庫訂單必須先經(jīng)履約系統(tǒng)進行履約的審核、拆單、合包等處理后，以倉庫和商家為單位生成發(fā)貨單，將自營業(yè)務下發(fā)對應倉庫的WMS系統(tǒng)，商家訂單下發(fā)商家發(fā)貨系統(tǒng)，倉庫和商家發(fā)貨以后，再將物流單號回傳履約系統(tǒng)，履約系統(tǒng)統(tǒng)一返給上游交易系統(tǒng)；

三、WMS以倉庫做數(shù)據(jù)權(quán)限升級，從單倉支持到多倉，每個倉庫管理自己的進銷存數(shù)據(jù)；

四、搭建物流管理系統(tǒng)，統(tǒng)一管理全國各個倉庫的發(fā)貨物流策略，并對物流環(huán)節(jié)全程跟蹤。

以上四招一出，一套健全的履約系統(tǒng)雛形就出來了，訂單從下單到用戶簽收過程中，也不再是一張訂單到底了，而是會經(jīng)歷履約發(fā)貨單、倉儲發(fā)貨單和物流單等多個業(yè)務單據(jù)流轉(zhuǎn)，只有這樣才能符合公司的規(guī)劃預期。小Q本以為這是本公司特有的系統(tǒng)特色，后來和業(yè)內(nèi)朋友一溝通才知道這種架構(gòu)也是業(yè)內(nèi)通用的解決方案，原來通往正確的道路上大家都是殊途同歸，早知道就不用自己生憋這么久了。

方案得到了CTO的肯定，立即投入資源立項開干，研發(fā)過程中的心酸自不用說，但結(jié)果不負眾望，3個月以后，經(jīng)過交易、履約和倉儲配送3個團隊的齊心協(xié)力，這樣的一套基于新架構(gòu)的的履約系統(tǒng)問世了。

供應鏈履約階段業(yè)務流程和架構(gòu)

系統(tǒng)上線以后，業(yè)務也按照節(jié)奏開始全國開倉布局，在磨合了2個月以后基本趨于穩(wěn)定。小W看著一個個包裹從不同的倉庫發(fā)出，仿佛看到了一張張真實滿意的笑臉，那是用戶對履約服務的認可，如若如此，自己和項目組過去幾個月的披星戴月和篳路藍縷都值得了。

新系統(tǒng)的上線，成功解決了供應鏈業(yè)務擴張的問題，但由于系統(tǒng)的復雜程度大幅提升，需求實現(xiàn)成本和人力成本也隨之增加不少，經(jīng)常做一個需求會涉及五六個團隊一起聯(lián)動，如何才能讓產(chǎn)研團隊更加高效敏捷，成了CTO眼中的難題。

另外，由于系統(tǒng)變多，財務數(shù)據(jù)往往需要跨多個系統(tǒng)提取，但各系統(tǒng)統(tǒng)計維度各不相同，使得財務核算成本也大幅提升，財務總監(jiān)經(jīng)常向CTO吐槽說，創(chuàng)業(yè)初期，每天的營收用計算器都能算出盈虧，現(xiàn)在信息化強多了，各種智能系統(tǒng)，卻不能出個完整的財務報表了，到底是進步了還是退步了？CTO也只能無奈陪笑，承諾會在下半年規(guī)劃一套健全的業(yè)財一體化系統(tǒng)來解決財務問題……

05 最后的總結(jié)

故事講到這也該接近尾聲了，但Z公司的業(yè)務發(fā)展還在繼續(xù)，供應鏈的發(fā)展也還會有階段五、階段六、階段七……每個階段都會有業(yè)務的困難和新的系統(tǒng)解決方案，循環(huán)往復、生生不息，未來會走向何方，我們不得而知……

Z公司的發(fā)展軌跡并不唯一，它是木筆筆下的一個故事，更是很多公司的縮影，相信很多朋友都能從中看到自己曾經(jīng)奮斗的影子，我們不去評論每個階段的好與壞，因為存在即合理，相信每個階段做的決策一定是當時最合理的，用后來人的視角去評判當初的好壞總是片面的。但對過去做復盤，我們還是有一些經(jīng)驗值得借鑒的：

（1）業(yè)務的發(fā)展往往不是線性的，可能在某一個時間點會有質(zhì)的變化，比如外部環(huán)境的變化、訂單量的指數(shù)級增長或斷崖式下跌、業(yè)務模式的快速調(diào)整，這就要求系統(tǒng)規(guī)劃時需要有一定的前瞻性，這個前瞻性的度需要合理把握，不宜太短見也不宜太長遠，太短會阻礙業(yè)務的變化，太長會增加實現(xiàn)成本，力不從心，合理的方式是架構(gòu)上做好長期兼容，但落地時先考慮短期實現(xiàn)。

（2）現(xiàn)在都在大談特談的MVP和敏捷開發(fā)，但有些工作是不能省，也不能敏捷的，比如系統(tǒng)的基礎(chǔ)架構(gòu)，如果架構(gòu)不穩(wěn)，就是房子的地基不牢，終有一天，我們會為今天的偷懶埋單，而為之付出數(shù)倍的成本。

（3）業(yè)務的復雜一定會帶來系統(tǒng)的復雜嗎？一定的，無論是橫向的業(yè)務模式擴充，還是縱向的單量的增大，都需要從系統(tǒng)層面支持，有時是性能上的，有時是功能上的，有時是策略上的，但好的架構(gòu)就是讓系統(tǒng)盡量簡單清晰，退而求其次，是將復雜藏在系統(tǒng)內(nèi)部，把簡單展示給業(yè)務，這是大道至簡的精髓，說起來容易，實現(xiàn)起來卻不容易。

（4）系統(tǒng)做到最后，一定是回歸業(yè)務本質(zhì)，特別是B端系統(tǒng)和供應鏈尤其如此，因為業(yè)務才是需求源頭。真實需求是客觀存在的，不是產(chǎn)品經(jīng)理造出來的，無論是產(chǎn)品經(jīng)理、架構(gòu)師還是程序員，要做的事情只有一件：發(fā)現(xiàn)需求并解決問題。而先理業(yè)務，再聊系統(tǒng)規(guī)劃和實現(xiàn)，是事半功倍的不二法則，永不過時。

先總結(jié)以上4點吧，以后有機會咱們再細聊，最后，用文章開頭的結(jié)論作為本文的結(jié)束：最合理的系統(tǒng)架構(gòu)通常不是設計來的，而是演變來的，業(yè)務和時間才是我們最好的架構(gòu)師。

專欄作家

scm木筆，微信公眾號：供應鏈產(chǎn)品筆記，人人都是產(chǎn)品經(jīng)理專欄作家，產(chǎn)品一俗生，深耕于供應鏈領(lǐng)域。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。