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

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

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

Z公司是一個電商平台，主營化妝品業務，從成立之初，總共經曆了四次大的供應鍊的業務模式升級，分别是：

階段一：商家發貨階段。平台搭建之初，為了省供應鍊成本，主要由商家承擔發貨。

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

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

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

Z公司的供應鍊發展階段

因為業務的叠代更新，系統架構也跟着做了相應的4次大的升級演變。下面我們分别對每個階段的業務及系統規劃來進行拆解，看看Z公司的系統是如何跟着業務一步一步演變到今天這個樣子的。

01 階段一：商家發貨階段

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

業務發展初期的業務流程和架構

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

02 階段二：自營發貨階段

随着業務的慢慢擴大，商家發貨就出現了弊端，經常出現假發貨、商品品質差等問題，比較損害用戶體驗，但因為平台的體量還不足夠大，無法像大公司一樣約束商家（否則人家不跟你玩了，你就斷貨了，兩敗俱傷），所以問題一直無法根治。

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

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

當前系統出庫流程為：當訂單産生以後，由交易系統根據商品的歸屬對訂單進行拆分，商家貨源的商品推送商家發貨，業務方登錄自營商家賬号，将訂單導出來，再導入ERP系統中完成發貨，最後将發貨的物流單号回填到商家後台通知用戶。

自營發貨階段的業務流程和架構

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

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

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

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

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

二、招聘一名專業的倉儲經理對倉庫流程和商品庫存做精細化管理；

三、産研部門快速開發一套倉儲系統來支持倉儲發貨業務，實現将庫存、訂單與銷售平台打通聯動。

由于業務量的增大，系統的複雜程度也随之提升，産研中心也跟着業務的調整步伐将原有的團隊進行了擴編，并抽出5名技術負責新倉儲、采購相關供應鍊系統的初期建設。

在新倉儲經理還沒有招聘到崗之前，為了趕項目工期，産品經理小W便與業務方一起基于現有的業務模式快速出具了一套簡易的倉儲入出庫流程：①在ERP系統中創建采購單以後，下發采購單到新倉儲WMS系統中；②商品到貨以後，在新WMS中收貨、加庫存，并同步庫存給銷售平台上架售賣；③用戶下單以後，訂單下發到WMS系統中揀貨打單，打包發貨。

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

倉儲精細化管理的業務流程和架構

新WMS系統上線以後，雖然有很多問題，但随着慢慢的優化改善，錯發貨漏發貨的現象明顯下降了，加上新倉儲經理的到崗，對倉庫進行了專業的規劃布局和現場管理，并提了很多系統方面的優化需求，倉儲作業效率提升了30%以上，每天發貨幾千單毫無壓力。

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

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

随着倉儲團隊的搭建和倉儲系統的上線，自營業務慢慢步入正軌，一年後已經頂起了公司GMV的半邊天，這個時期，商家業務和自營業務并駕齊驅，成為公司的兩大業務支柱，可喜可賀，但随之遇到了新的供應鍊問題：

一、一個倉庫已經無法滿足日益增長的業務量，需要提前規劃倉庫擴充；

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

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

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

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

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

一、将倉儲WMS系統基于訂單出庫的功能解耦，通過發貨單來承接訂單，不再強依賴訂單；

二、在交易訂單和倉儲系統之間搭建起履約系統和中央庫存系統，所有出庫訂單必須先經履約系統進行履約的審核、拆單、合包等處理後，以倉庫和商家為單位生成發貨單，将自營業務下發對應倉庫的WMS系統，商家訂單下發商家發貨系統，倉庫和商家發貨以後，再将物流單号回傳履約系統，履約系統統一返給上遊交易系統；

三、WMS以倉庫做數據權限升級，從單倉支持到多倉，每個倉庫管理自己的進銷存數據；

四、搭建物流管理系統，統一管理全國各個倉庫的發貨物流策略，并對物流環節全程跟蹤。

以上四招一出，一套健全的履約系統雛形就出來了，訂單從下單到用戶簽收過程中，也不再是一張訂單到底了，而是會經曆履約發貨單、倉儲發貨單和物流單等多個業務單據流轉，隻有這樣才能符合公司的規劃預期。小Q本以為這是本公司特有的系統特色，後來和業内朋友一溝通才知道這種架構也是業内通用的解決方案，原來通往正确的道路上大家都是殊途同歸，早知道就不用自己生憋這麼久了。

方案得到了CTO的肯定，立即投入資源立項開幹，研發過程中的心酸自不用說，但結果不負衆望，3個月以後，經過交易、履約和倉儲配送3個團隊的齊心協力，這樣的一套基于新架構的的履約系統問世了。

供應鍊履約階段業務流程和架構

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

新系統的上線，成功解決了供應鍊業務擴張的問題，但由于系統的複雜程度大幅提升，需求實現成本和人力成本也随之增加不少，經常做一個需求會涉及五六個團隊一起聯動，如何才能讓産研團隊更加高效敏捷，成了CTO眼中的難題。

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

05 最後的總結

故事講到這也該接近尾聲了，但Z公司的業務發展還在繼續，供應鍊的發展也還會有階段五、階段六、階段七……每個階段都會有業務的困難和新的系統解決方案，循環往複、生生不息，未來會走向何方，我們不得而知……

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

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

（2）現在都在大談特談的MVP和敏捷開發，但有些工作是不能省，也不能敏捷的，比如系統的基礎架構，如果架構不穩，就是房子的地基不牢，終有一天，我們會為今天的偷懶埋單，而為之付出數倍的成本。

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

（4）系統做到最後，一定是回歸業務本質，特别是B端系統和供應鍊尤其如此，因為業務才是需求源頭。真實需求是客觀存在的，不是産品經理造出來的，無論是産品經理、架構師還是程序員，要做的事情隻有一件：發現需求并解決問題。而先理業務，再聊系統規劃和實現，是事半功倍的不二法則，永不過時。

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

專欄作家

scm木筆，供應鍊産品筆記，人人都是産品經理專欄作家，産品一俗生，深耕于供應鍊領域。

本文原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部