美團 O2O 供應鏈系統架構設計解析

英國知名供應鏈專家Martin Christopher曾經說過一句很是深入的話：「21世紀的競爭不是企業和企業之間的競爭，而是供應鏈和供應鏈之間的競爭。」

什麼是供應鏈？

在風雲變幻、寡頭紛爭的O2O戰場，美團屢出重拳並步步爲營，戰績不俗。這一切離不開背後的神祕技術團隊——供應鏈。

供應鏈，簡稱 SCP（Supply Chain Process）。美團藉助平臺的優點與商家展開合做，將約定的合做方案落實到紙質契約。彼時用戶還不能直接看到或購買這些契約上的合做方案，須要一個電子化的生產過程。這個過程完成兩件重要的事情，一是將擬定的方案細化，讓消費者能看到詳盡的圖文描述，價格，購買限制等等。二是審覈這個方案，確保它在法律上有效，在財務上可靠。完成這個生產過程後，用戶就能夠到美團的C端，例如手機APP或美團主站上看這個方案併發起購買，產生一筆交易。到具體的門店進行消費時，就能獲得方案中商家許諾的服務。這一系列的過程：合做，交易，消費都是牢牢圍繞一個概念發生的，那就是項目。這個項目的生產過程，就是美團供應鏈。

這個生產過程由哪些角色參與了哪些事，生產出來的項目又是什麼呢？以傳統團購爲例，一個經典的上單過程由美團在城市端的BD（業務拓展人員）發起。BD和商家達成合做意向後簽署一紙合同，再到美團的業務門戶錄入此次合做和詳細方案，而後提交總部審覈。審覈人員根據審覈手冊作出判斷，若是本次合做和方案可靠合法就將其審覈經過。審覈經過的方案再通過CMS（內容管理系統）完成標題圖文的包裝和各個C端渠道的適配，一單項目就生產完成了。能夠看到，這個過程涉及多個業務環節和人員角色，若是能提升其中一些環節效率或減小人員投入，將成爲公司的核心競爭力。

除了傳統團購，美團在O2O的一些細分領域，好比酒店、旅遊、外賣、早餐等等也逐步開花結果。這些新生的細分領域的項目標準化程度不一，如何支持這些細分領域的項目生產，如何讓這個支持過程高效可靠，幫助美團把握住一個又一個的O2O風口，就成了美團供應鏈系統面臨的挑戰。

供應鏈系統的挑戰複雜數據細粒度結構化

在購買傳統商品時，在淘寶、京東上，用戶更關心的是產品規格、材質、物流方面的信息，好比一件紅色T恤，用戶會關心是純棉的嗎，是否是XL碼，所在的省份支持哪些快遞公司，快遞費多少，而不太會關心商家所處的位置。而購買餐飲團購時，用戶就很是關注這個商家的物理位置，須要具體到哪一個城市哪一個商圈哪一個門店。即便同爲團購單，餐飲和酒店又有很大不一樣。餐飲單須要關心幾人餐，餐具是否免費，允不容許自帶酒水，是川菜仍是江浙菜系列等。酒店單需關注是大牀房仍是雙人牀房，是否免預定，工做日和週末是否價格不一樣等。

由此能夠看出，在不一樣的細分領域，甚至同一領域下不一樣的品類，商品的標準化程度都有很大不一樣。以傳統團購中餐飲品類下火鍋子品類爲例，一個細化的方案包括：方案信息（菜系、幾人餐、套餐幾選幾、具體菜品等），購買須知（交易類型是美團券仍是優惠碼，項目有效期，美團券有效期等），還有商家自身文案描述等，大概涉及將近100個屬性。那麼問題就來了，爲何須要將粒度拆分得這麼細呢？

背後有兩個緣由。

一，從大的方向上來說，供應鏈鏈接了商家和用戶，也就是須要同時對接到B端和C端。B端的利益相關人是地面銷售人員，他們對供應鏈系統的需求是錄入效率高。在不一樣細分領域以及不一樣品類之間有共同關注的屬性，好比購買須知(也就是項目有效期這些概念)。咱們從散落的屬性中把這些可複用的屬性抽出來，抽象爲購買須知模塊，幫助BD預填寫不少默認值，能夠有效提高BD的上單效率。同時對C端的消費者來說，須要從不少維度進行搜索，方便的找到符合預期的商品，而搜索的前提就是內容的結構化。

二，美團C端的渠道也越來越多，各C端渠道對項目方案的屬性維度要求不一且調整頻繁。結構化是實現這些需求的必然路徑。

售賣方式靈活多變

支持完品類繁多的餐飲單方案詳情後，咱們立刻面臨另一個問題——複雜多變的售賣方式。酒店雙人間，含早餐和不含早餐，雙牀仍是大牀房都對應不一樣價格。其實，線下的酒店售賣場景對應到線上，除了早餐和房型的差異，還面臨節假日、不一樣時段等等規則，產生了多種多樣組合售賣方式。而且每次交易後，商家都須要扣減指定一類房型的庫存。此時又該如何應對呢。是否每多一個售賣方式，BD就要重複錄一個方案？這必然會致使錄單時長呈幾何倍數增加。若是方案細節發生調整，關聯的大量方案也須要同時修改，給BD帶來的成本過高。這就對供應鏈系統提出了新的要求：只錄一次，就能支持複雜多變的售賣方式。

品類和屬性動態調整

團購作精作深的過程，反應在產品層面，就是品類的擴充和拆分。例如自助餐品類須要新增字段，表達是否含WiFi、是否含停車位。例如火鍋品類拆分爲成都火鍋、重慶火鍋。每次品類的擴充與拆分都意味着產品錄入界面調整，後臺存儲改變。體如今開發上面，須要先後端同時支持，煩不勝煩。這對供應鏈又提出了新要求：品類和屬性調整零開發量。

審覈流程可配置

不一樣的業務渠道對上單審覈的卡控要求不一。以今年的新業務形態買單爲例，從產品運營層面就已經決定毛利、敏感詞等方面的可靠性，只須要總部的編審人員審覈方案數據一致性。而團購渠道歷史悠久，方案覆蓋的場景複雜多變，須要城市端作出初審，再交由總部的中臺人員代運營。但這些審覈過程又不是靜態不變的，一旦線下上單場景發生調整，線上的審覈也須要當即跟進調整。這對供應鏈系統提出的要求就是：審覈過程可配置。

直面挑戰構建 O2O 生活服務模型

實現上面這些高大上的要求，美團供應鏈系統其實也不是一蹴而就的。從糙快猛的做坊式開發，到今天搞架構搞模式搞生態，供應鏈系統的進化是一部可歌可泣的血淚史。在經歷品類猛調，渠道猛擴以後，技術一路小跑卻依然跟不上產品的迭代速度。當時系統已經積攢了歷久彌陳的代碼和邏輯，在新需求面前難於招架、寸步難行。這時咱們意識到出了問題。飛速行駛的火車就沒法優雅地換輪子嗎，業務屢次迭代後系統就必然動態不得了？答案必然是否認的。供應鏈技術團隊在痛定思痛以後選擇了一條最難但也是完全解決這個問題的道路：給O2O行業的各業務生態建模，抽象出產品中心。

咱們以多售賣方式的酒店爲例來看看產品中心的映射關係。對商家而言，能提供的服務單元包括大牀房，酒水，早餐，WiFi。這些服務按照商家的銷售意願組裝成銷售單元進行售賣，如大牀房+早餐、大牀房+WIFI、大牀房。對C端用戶而言，感知到的就是銷售單元，享受到的是銷售單元內涵蓋的服務單元。須要銷售端感知的限制被抽象爲銷售規則，須要消費端感知的限制被抽象爲消費規則，售賣方式被抽象爲價格規則。這些規則能夠被統稱爲SKU屬性。銷售單元適配上不一樣的SKU屬性，就成爲不一樣的C端產品。

事件驅動，過程解耦

針對審覈過程動態可配置的目標，咱們引入了工做流。爲不一樣的業務渠道設計不一樣的審覈流程：有哪些審覈節點，每一個審覈節點由哪些人員角色操做，每一個審覈節點在經過或駁回後的流向，均可以動態配置，分分鐘搞定。業務系統再也不關心工做臺的概念，供應鏈系統的信息流和事件流推進徹底交由了工做流系統。不只於此，原先累積在供應鏈系統之上，針對上單時長、等待時長等數據分析的工做用到的過程數據，都從業務系統解耦出來，由工做流的流程數據提供原生支持。從過程數據記錄，挖掘分析等需求解放出來，供應鏈系統就更能騰出精力來專一於提高自身核心競爭力——更強更快。

自動化一切

908

在上單量飆升時，壓縮供應鏈的上單成本能爲公司帶來直接收益。壓縮成本就意味着在保證上單質量的同時儘量縮短上單時長、下降人工參與度。咱們將供應鏈生產過程化整爲零，切分爲多段，每一段採用定製的自動化策略，精細運營。在審覈環節引入免審，在撰寫環節引入免寫，目標爲「單均成本下降90%，效率提高8倍」，所以公司內部將這個項目稱之爲908。

還在繼續

發展到後來，908已經再也不是一個項目的名字，而是自動化一切的思路。到今天供應鏈系統也還在一點點雕琢，例如針對重複審單的狀況引入工做流，針對品類動態擴展的狀況引入屬性中心。以屬性中心爲例，以前品類和屬性調整每每意味着幾天的重複開發和臃腫的代碼，如今只須要業務人員在配置頁面用幾分鐘的時間簡單配置。

成就動做快

以優惠買單爲例，完整的供應鏈流程支持的開發成本是5人日，包括：完整的商家入駐，個性化的契約協議、方案錄入、結構存儲和審覈流程，並對接多個C端渠道。而在以前，這個數字是30人日。

降成本，提效率

實現免審免寫後，體現出兩個數字的變化。一是編審部門解散，這個部門原來有近百人負責上單過程的審覈和撰寫；二是上單量增加1000%的背景下，上單成本下降了90%以上。

總結

從技術角度回顧供應鏈的上單過程。BD在前臺發起一塊兒上單請求，後臺根據BD要錄單的業務渠道、品類等，經過DF（Dynamic Form）渲染出錄入頁面。請求到達後端後，先通過AC（Attribute Center）層自動完成針對不一樣DF的合法性檢查，再轉化爲後臺產品中心要求的數據格式。錄完的方案數據沉澱到產品中心，並經過Gravity調度具體方案的審覈任務。發生修改後，修改過程沉澱到變動中心，變動自己的審覈也交由Gravity調度。產品中心收到Gravity的審覈經過消息通知後，就安排CMS使用不一樣的動態模板完成拼裝，進而輸出到不一樣的C端。

以產品和變動中心爲Model沉澱，以動態表單和動態模板完成View自動拼接，以屬性中心和工做流完成Control邏輯驅動，最終供應鏈系統以MVC定下高可用自動化的江山。