![](http://static.javashuo.com/static/loading.gif)
嚴選在發展過程當中,不斷面臨着商業環境的變化,如流量模式、競爭格局,也會遇到忽然的公共衛生事件-疫情。採購系統做爲嚴選供給端的核心繫統之一,作好頂層設計並持續進行系統演進,才能適應劇烈的業務變化,服務好最終用戶。本文從定義宏觀、設計藍圖、落地系統、持續演進四個點展開整個採購系統架構過程,但願跟你們一塊兒找找作業務系統架構設計的感受。前端
1. 前言web
嚴選在發展過程當中,不斷面臨着商業環境的變化,如流量模式、競爭格局,也會遇到忽然的公共衛生事件-疫情。採購系統做爲嚴選供給端的核心繫統之一,作好頂層設計並持續進行系統演進,才能適應劇烈的業務變化,服務好最終用戶。本文從定義宏觀、設計藍圖、落地系統、持續演進四個點展開整個採購系統架構過程,但願跟你們一塊兒找找作業務系統架構設計的感受。後端
2. 定義宏觀:捕捉底層「穩定邏輯「安全
從企業級的商業定位、到供給端的供應鏈業務特色、再到技術側的系統架構特徵,不斷聚焦,推演採購系統的底層架構關鍵點。微信
2.1 最大的變化和不變:商業定位,肯定架構底層邏輯架構
從變化來講,企業不可避免的要面臨商業環境的變化,以及自身發展的訴求。這時候企業商業定位面臨着調整,業務範圍可能擴張或者收縮,業務模式可能微調或者顛覆。這時候架構的重心發生極大變化,須要提早作出規劃和調整,否則系統和業務發展的間隙愈來愈大。app
業務特色框架 |
架構特色工具 |
|
平臺模式性能 (如:天貓) |
撮合大量商家和消費者,關注交易量,關注GMV。入駐品牌多,品類廣,更關注商品的交易屬性,基本不關注生產製造環節。 |
量每每起的很快,得確保系統設計是易於擴展的,不管是表的拆分,仍是機器擴容。營銷玩法每每多變,爲了快速的響應業務,須要靈活的前臺設計和較爲堅實的中後臺能力。 |
品牌模式 (如:嚴選) |
關注忠誠用戶,關注利潤率,以品爲核心,從設計製造環節抓起,到商品交付給用戶,乃至產生的售後環節都須要兼顧。但每每品類數量增加較慢,同時資產較重。 |
每每須要向多渠道鋪貨,因此業務前端要匹配各個平臺的玩法規則。而業務後端從商品企劃到設計、生產、製造、運輸、倉儲的鏈條極長,流程的聯動,數據的準確性保障都是須要仔細考慮的。並且爲了匹配業務前端,每每要作渠道庫存、渠道訂單這樣的抽象設計。 |
2.2 全鏈路拉起來看特色:深度協同&雙向驅動
供應鏈採購做爲整個嚴選電商業務的後端,有如下特色:
商業鏈條極長,商品選品,採購溯源,計劃下單,合同簽署,備料協同,生產製造,品質管控,物流運輸,倉儲管理,退供翻新,金融結算等環環相扣。
協同角色極多,從商品開發,採購,計劃,品控,關務,財務等密切合做。
層次錯綜複雜,從傳統的供應鏈三流:實物流、信息流、資金流,加上如今頻頻說起的商流,流和流之間縱橫交錯。
嚴選供應鏈業務和技術做爲互相咬合的齒輪,前期主要是業務驅動,大量場景須要實現線上化,完成初期的流程閉環和數據積累。發展到必定的階段,就會出現大量技術驅動的場景,逐漸展示出數智化的特徵,好比:服務供需平衡的銷量預測、智能補貨,服務庫存平衡的採購分倉、倉間調撥。總體供應鏈採購的發展呈現出技術和業務雙驅的特徵。因此架構設計的過程當中,要認清當前系統和業務的發展階段,平衡好當前訴求和將來發展,作好業務支撐的同時,積極挖掘數智化場景的機會點,爲變化留有餘地同時拒絕過渡設計。
2.3 找準系統演進關鍵特徵:以準確性、可用性爲基
理清業務的特色後,須要圈出採購系統關注的技術特徵,以及這些關鍵特徵的演進目標。這裏說下其中兩點:
可用性。做爲履約核心鏈路,多角色平常工做須要頻繁操做的在線系統,能全天候完整的爲用戶提供服務能力是基礎也是關鍵。
準確性。由於業務鏈路長(從計劃下單到採購請款結算中間要通過十多個關鍵流程),業務完結週期長(短的幾天,長的達一年以上)等,這些特徵對數據的準確形成很大挑戰。又因爲採購是關鍵的成本結算鏈路,因此對數據的準確性有很高的要求。
咱們須要進一步量化這些架構特徵,用以觀察和保證系統是向着目標方向去拉動的。好比:咱們關注服務可用性,可使用在線率、故障率這2個指標。指標構建和落地要結合公司大的技術環境,若是公司有SLA/SLO/SLI的相關服務質量平臺,能夠直接借力,把指標歸入本身的架構觀察大盤,而不是本身來重複構建。相似的也能夠借力自動化測試平臺,來構建一些性能、安全性的架構特徵的量化觀察指標。
3. 設計藍圖:肯定階段性目標架構
當咱們理清關鍵底層邏輯後,能夠開始肯定咱們的階段性目標架構藍圖。架構的視角不少,描述的方法也不少,好比經典的RUP 4+1視圖。這裏僅從限界上下圖、業務架構圖兩個視角展開。
3.1 限界上下圖:分治之基、扯皮之盾
分治,大系統小作。採購系統包含跨境採購、採購執行、退供/翻新等大量業務,同時要和大量的外部系統如商品中心、供應商、財務等打交道,在這種業務場景極多,和外部聯動極多的系統,只有清晰的界定好內外部邊界,才能將系統和人員職責拆分到位。系統的服務化粒度能夠直接映射參考內部子域的劃分。若是系統大小合適,系統負責人和系統之間一對一的配比是比較好的方式。
3.2 業務架構圖:業務場景和系統能力平滑匹配
畫業務架構圖要將業務和系統儘可能思考清楚,就圖自己要明確橫向和縱向要表達什麼。
橫向:表達業務流程
利益相關者:能夠經過用戶的利益關注點不一樣作用戶羣體的劃分,每每能夠經過角色來抽象劃分後的用戶。
橫向業務閉環:業務最終必定是服務於用戶的,全部利益相關者的關注點應該在每一個橫向層次上獲得承載和體現。
縱向:表達能力分層
縱向關注拆解,從「業務願景「不斷的拆解到一個個細小的‘業務能力’載體。
分層,對拆解過程進行抽象,概括,提煉出4層表達結構:場景層、產品功能層、系統能力層、業務模型層。
場景分析是個關鍵點。業務架構產出靠不靠譜,其中一個因素的是業務域下的做爲輸入的場景是否考慮清晰,是否覆蓋全面,也就是‘場景分析’這個動做有沒作到位。這層東西是基礎,至於分層業務架構產出,如L0,L1,L2層能夠在這個基礎上作抽象和結構化。
4. 落地系統:有層次,有節奏的構建系統
4.1 一樓,橫向擴張:以域爲核心,打造系統版圖
搭建業務和系統大的框架結構,作業務域級別的覆蓋和服務系統級別的落地。供應鏈採購做爲相對成熟的業務,能夠參考業界的業務側總體版圖對系統的形態作個預判。而後結合當前系統和業務現狀,規劃系統發展路徑。若是來的新需求不在當前子域內,能夠考慮將新的系統直接構建出來,承接這塊的業務需求,以知足將來發展。若是有板塊內的關鍵子域落到其餘的板塊裏,能夠經過邊界治理的方法,將業務和系統能力劃回來,同時不屬於採購系統的也堅定劃出,以保證規劃的總體性和系統內聚。
4.2 二樓,垂直深挖:精細化場景覆蓋
多角度驗證場景完整性,作場景級別的業務覆蓋和系統能力級別的補全。當業務域初步搭建成型後,在能支撐用戶完成基本的業務流程的基礎上,不斷挖掘用戶在成本控制、提效、體驗上的深度訴求,迭代細分場景豐滿系統能力。好比審批域,能夠提供專門服務於緊急場景的緊急審批能力,除了幾個關鍵節點的審批,其餘平常審批節點都繞過,極短期完成審批;也能夠根據用戶的便攜化審批的訴求,提供移動審批能力。
4.3 三樓,自動化&數智化
自動化&數智化是當前的終極階段,這塊須要長期的思考和探索。在精細化作了一段時間後,系統具有了必定的成熟度基礎,團隊也對業務有了比較深刻的理解,能夠挖掘自動化&數智化的機會點。好比探索個性化流程場景:爲不一樣的業務方個體搭建個性化採購流程。其中的關鍵思路是採購是個流程性很重的系統,而有些流程節點的設計實際上是在風險控制和效率之間博弈,好比某些審批節點。而每一個業務人員個體的靠譜程度是不一樣的,若是能爲某些靠譜的業務人員跳過某些主要基於風險控制考量的節點,那麼能夠極大提高流程效率。
5. 持續演進:動態平衡
目標架構只是某個時間對架構的理想狀態作出的判斷,當一些關鍵因素髮生變化時,目標架構須要及時調整,而變化是持續的,因此從某種程度上來講目標架構是連續變化的。當目標架構變化後,會開啓新一輪的定義、設計、落地過程,因此係統能力和需求的匹配一直處於一個動態平衡中。舉個今年(2020年)雙十一的例子說明市場環境變化致使業務變化,而業務變化後系統側須要作出調整。
市場變化:今年雙十一銷售高峯除了‘11.11’當天,還有‘11.1-11.3’,造成2個銷售的波峯,波峯之間有7天的緩衝。
業務變化:對採購側的業務方來講,這樣的市場變化,多了‘一次覆盤,一次補貨’。一次覆盤指的是‘11.1-11.3’大促作完後,能夠快速覆盤下當前採購量和目標之間的誤差,調整一些關鍵數據好比大促係數(大促期間對比平銷期採購量的倍數)。一次補貨指的是,覆盤後發現的一些採購量誤差、一些爆品的缺貨風險能夠抓緊再補貨一次。
系統變化:首先一波大促變兩波,對流量、系統容量須要從新評估和設計。其次能夠提供一些數據輔助決策工具幫助業務快速作‘11.1-11.3’覆盤,和‘11.11’採購量從新預測。最後提供緊急補貨工具,縮短採購履約時間,完成誤差採購量補貨。
6. 最後
供應鏈這樣的B端系統是有很深的門檻的,對架構師的業務深度、技術深度提出了雙向要求,埋頭作系統每每作很差系統。只有將業務敏感度和架構方法論結合,用發展動態的眼光去看,纔會發現真正的技術價值、業務價值的閃光。
做者簡介
無峯,網易資深服務端研發工程師,供應鏈側一線架構師,負責供應鏈採購的服務體系建設,聚焦於履約基礎流程搭建、履約效率、成本控制等方向的解決方案。
招聘信息
網易校招補錄持續進行中,點擊👇「閱讀原文」,查看相關信息。
本文由做者受權嚴選技術產品團隊發佈
本文分享自微信公衆號 - 嚴選技術產品團隊(YanxuanTechProd)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。