合理的系統架構從來不是設計而來的，而是演變而來的，做系統規劃需要我們靜下心來一點一點地修改完善。本文基於真實案例，分享了一個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 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。
