美團(tuán) O2O 供應(yīng)鏈系統(tǒng)架構(gòu)設(shè)計(jì)解析

英國知名供應(yīng)鏈專家Martin Christopher曾經(jīng)說過一句非常深刻的話：“21世紀(jì)的競(jìng)爭(zhēng)不是企業(yè)和企業(yè)之間的競(jìng)爭(zhēng)，而是供應(yīng)鏈和供應(yīng)鏈之間的競(jìng)爭(zhēng)?！?/p>

什么是供應(yīng)鏈？

在風(fēng)云變幻、寡頭紛爭(zhēng)的O2O戰(zhàn)場(chǎng)，美團(tuán)屢出重拳并步步為營，戰(zhàn)績不俗。這一切離不開背后的神秘技術(shù)團(tuán)隊(duì)——供應(yīng)鏈。

供應(yīng)鏈，簡稱 SCP（Supply Chain Process）。美團(tuán)借助平臺(tái)的優(yōu)勢(shì)與商家展開合作，將約定的合作方案落實(shí)到紙質(zhì)契約。彼時(shí)用戶還不能直接看到或購買這些契約上的合作方案，需要一個(gè)電子化的生產(chǎn)過程。這個(gè)過程完成兩件重要的事情，一是將擬定的方案細(xì)化，讓消費(fèi)者能看到詳盡的圖文描述，價(jià)格，購買限制等等。二是審核這個(gè)方案，確保它在法律上有效，在財(cái)務(wù)上可靠。完成這個(gè)生產(chǎn)過程后，用戶就可以到美團(tuán)的C端，例如手機(jī)APP或美團(tuán)主站上看這個(gè)方案并發(fā)起購買，產(chǎn)生一筆交易。到具體的門店進(jìn)行消費(fèi)時(shí)，就能得到方案中商家許諾的服務(wù)。這一系列的過程：合作，交易，消費(fèi)都是緊緊圍繞一個(gè)概念發(fā)生的，那就是項(xiàng)目。這個(gè)項(xiàng)目的生產(chǎn)過程，就是美團(tuán)供應(yīng)鏈。

這個(gè)生產(chǎn)過程由哪些角色參與了哪些事，生產(chǎn)出來的項(xiàng)目又是什么呢？以傳統(tǒng)團(tuán)購為例，一個(gè)經(jīng)典的上單過程由美團(tuán)在城市端的BD（業(yè)務(wù)拓展人員）發(fā)起。BD和商家達(dá)成合作意向后簽署一紙合同，再到美團(tuán)的業(yè)務(wù)門戶錄入這次合作和詳細(xì)方案，然后提交總部審核。審核人員根據(jù)審核手冊(cè)做出判斷，如果本次合作和方案可靠合法就將其審核通過。審核通過的方案再經(jīng)過CMS（內(nèi)容管理系統(tǒng)）完成標(biāo)題圖文的包裝和各個(gè)C端渠道的適配，一單項(xiàng)目就生產(chǎn)完成了?？梢钥吹剑@個(gè)過程涉及多個(gè)業(yè)務(wù)環(huán)節(jié)和人員角色，如果能提高其中一些環(huán)節(jié)效率或減少人員投入，將成為公司的核心競(jìng)爭(zhēng)力。

除了傳統(tǒng)團(tuán)購，美團(tuán)在O2O的一些細(xì)分領(lǐng)域，比如酒店、旅游、外賣、早餐等等也逐步開花結(jié)果。這些新生的細(xì)分領(lǐng)域的項(xiàng)目標(biāo)準(zhǔn)化程度不一，如何支持這些細(xì)分領(lǐng)域的項(xiàng)目生產(chǎn)，如何讓這個(gè)支持過程高效可靠，幫助美團(tuán)把握住一個(gè)又一個(gè)的O2O風(fēng)口，就成了美團(tuán)供應(yīng)鏈系統(tǒng)面臨的挑戰(zhàn)。

供應(yīng)鏈系統(tǒng)的挑戰(zhàn)復(fù)雜數(shù)據(jù)細(xì)粒度結(jié)構(gòu)化

在購買傳統(tǒng)商品時(shí)，在淘寶、京東上，用戶更關(guān)心的是產(chǎn)品規(guī)格、材質(zhì)、物流方面的信息，比如一件紅色T恤，用戶會(huì)關(guān)心是純棉的嗎，是不是XL碼，所在的省份支持哪些快遞公司，快遞費(fèi)多少，而不太會(huì)關(guān)心商家所處的位置。而購買餐飲團(tuán)購時(shí)，用戶就非常關(guān)注這個(gè)商家的物理位置，需要具體到哪個(gè)城市哪個(gè)商圈哪個(gè)門店。即使同為團(tuán)購單，餐飲和酒店又有很大不同。餐飲單需要關(guān)心幾人餐，餐具是否免費(fèi)，允不允許自帶酒水，是川菜還是江浙菜系列等。酒店單需關(guān)注是大床房還是雙人床房，是否免預(yù)約，工作日和周末是否價(jià)格不同等。

由此可以看出，在不同的細(xì)分領(lǐng)域，甚至同一領(lǐng)域下不同的品類，商品的標(biāo)準(zhǔn)化程度都有很大不同。以傳統(tǒng)團(tuán)購中餐飲品類下火鍋?zhàn)悠奉悶槔?，一個(gè)細(xì)化的方案包括：方案信息（菜系、幾人餐、套餐幾選幾、具體菜品等），購買須知（交易類型是美團(tuán)券還是優(yōu)惠碼，項(xiàng)目有效期，美團(tuán)券有效期等），還有商家自身文案描述等，大概涉及將近100個(gè)屬性。那么問題就來了，為什么需要將粒度拆分得這么細(xì)呢？

背后有兩個(gè)原因。

一，從大的方向上來講，供應(yīng)鏈連接了商家和用戶，也就是需要同時(shí)對(duì)接到B端和C端。B端的利益相關(guān)人是地面銷售人員，他們對(duì)供應(yīng)鏈系統(tǒng)的需求是錄入效率高。在不同細(xì)分領(lǐng)域以及不同品類之間有共同關(guān)注的屬性，比如購買須知(也就是項(xiàng)目有效期這些概念)。我們從散落的屬性中把這些可復(fù)用的屬性抽出來，抽象為購買須知模塊，幫助BD預(yù)填寫很多默認(rèn)值，可以有效提升BD的上單效率。同時(shí)對(duì)C端的消費(fèi)者來講，需要從很多維度進(jìn)行搜索，方便的找到符合預(yù)期的商品，而搜索的前提就是內(nèi)容的結(jié)構(gòu)化。

二，美團(tuán)C端的渠道也愈來愈多，各C端渠道對(duì)項(xiàng)目方案的屬性維度要求不一且調(diào)整頻繁。結(jié)構(gòu)化是實(shí)現(xiàn)這些需求的必然路徑。

售賣方式靈活多變

支持完品類繁多的餐飲單方案詳情后，我們馬上面臨另外一個(gè)問題——復(fù)雜多變的售賣方式。酒店雙人間，含早餐和不含早餐，雙床還是大床房都對(duì)應(yīng)不同價(jià)格。其實(shí)，線下的酒店售賣場(chǎng)景對(duì)應(yīng)到線上，除了早餐和房型的差別，還面臨節(jié)假日、不同時(shí)段等等規(guī)則，產(chǎn)生了多種多樣組合售賣方式。并且每次交易后，商家都需要扣減指定一類房型的庫存。此時(shí)又該如何應(yīng)對(duì)呢。是否每多一個(gè)售賣方式，BD就要重復(fù)錄一個(gè)方案？這必然會(huì)導(dǎo)致錄單時(shí)長呈幾何倍數(shù)增長。如果方案細(xì)節(jié)發(fā)生調(diào)整，關(guān)聯(lián)的大量方案也需要同時(shí)修改，給BD帶來的成本太高。這就對(duì)供應(yīng)鏈系統(tǒng)提出了新的要求：只錄一次，就能支持復(fù)雜多變的售賣方式。

品類和屬性動(dòng)態(tài)調(diào)整

團(tuán)購做精做深的過程，反應(yīng)在產(chǎn)品層面，就是品類的擴(kuò)充和拆分。例如自助餐品類需要新增字段，表達(dá)是否含WiFi、是否含停車位。例如火鍋品類拆分為成都火鍋、重慶火鍋。每次品類的擴(kuò)充與拆分都意味著產(chǎn)品錄入界面調(diào)整，后臺(tái)存儲(chǔ)改變。體現(xiàn)在開發(fā)上面，需要前后端同時(shí)支持，煩不勝煩。這對(duì)供應(yīng)鏈又提出了新要求：品類和屬性調(diào)整零開發(fā)量。

審核流程可配置

不同的業(yè)務(wù)渠道對(duì)上單審核的卡控要求不一。以今年的新業(yè)務(wù)形態(tài)買單為例，從產(chǎn)品運(yùn)營層面就已經(jīng)決定毛利、敏感詞等方面的可靠性，只需要總部的編審人員審核方案數(shù)據(jù)一致性。而團(tuán)購渠道歷史悠久，方案覆蓋的場(chǎng)景復(fù)雜多變，需要城市端做出初審，再交由總部的中臺(tái)人員代運(yùn)營。但這些審核過程又不是靜態(tài)不變的，一旦線下上單場(chǎng)景發(fā)生調(diào)整，線上的審核也需要立即跟進(jìn)調(diào)整。這對(duì)供應(yīng)鏈系統(tǒng)提出的要求就是：審核過程可配置。

直面挑戰(zhàn)構(gòu)建 O2O 生活服務(wù)模型

實(shí)現(xiàn)上面這些高大上的要求，美團(tuán)供應(yīng)鏈系統(tǒng)其實(shí)也不是一蹴而就的。從糙快猛的作坊式開發(fā)，到今天搞架構(gòu)搞模式搞生態(tài)，供應(yīng)鏈系統(tǒng)的進(jìn)化是一部可歌可泣的血淚史。在經(jīng)歷品類猛調(diào)，渠道猛擴(kuò)之后，技術(shù)一路小跑卻依然跟不上產(chǎn)品的迭代速度。當(dāng)時(shí)系統(tǒng)已經(jīng)積攢了歷久彌陳的代碼和邏輯，在新需求面前難于招架、步履維艱。這時(shí)我們意識(shí)到出了問題。飛速行駛的火車就無法優(yōu)雅地?fù)Q輪子嗎，業(yè)務(wù)多次迭代后系統(tǒng)就必然動(dòng)態(tài)不得了？答案必然是否定的。供應(yīng)鏈技術(shù)團(tuán)隊(duì)在痛定思痛之后選擇了一條最難但也是徹底解決這個(gè)問題的道路：給O2O行業(yè)的各業(yè)務(wù)生態(tài)建模，抽象出產(chǎn)品中心。

我們以多售賣方式的酒店為例來看看產(chǎn)品中心的映射關(guān)系。對(duì)商家而言，能提供的服務(wù)單元包括大床房，酒水，早餐，WiFi。這些服務(wù)按照商家的銷售意愿組裝成銷售單元進(jìn)行售賣，如大床房+早餐、大床房+WIFI、大床房。對(duì)C端用戶而言，感知到的就是銷售單元，享受到的是銷售單元內(nèi)涵蓋的服務(wù)單元。需要銷售端感知的限制被抽象為銷售規(guī)則，需要消費(fèi)端感知的限制被抽象為消費(fèi)規(guī)則，售賣方式被抽象為價(jià)格規(guī)則。這些規(guī)則可以被統(tǒng)稱為SKU屬性。銷售單元適配上不同的SKU屬性，就成為不同的C端產(chǎn)品。

事件驅(qū)動(dòng)，過程解耦

針對(duì)審核過程動(dòng)態(tài)可配置的目標(biāo)，我們引入了工作流。為不同的業(yè)務(wù)渠道設(shè)計(jì)不同的審核流程：有哪些審核節(jié)點(diǎn)，每個(gè)審核節(jié)點(diǎn)由哪些人員角色操作，每個(gè)審核節(jié)點(diǎn)在通過或駁回后的流向，都可以動(dòng)態(tài)配置，分分鐘搞定。業(yè)務(wù)系統(tǒng)不再關(guān)心工作臺(tái)的概念，供應(yīng)鏈系統(tǒng)的信息流和事件流推動(dòng)完全交由了工作流系統(tǒng)。不僅于此，原先累積在供應(yīng)鏈系統(tǒng)之上，針對(duì)上單時(shí)長、等待時(shí)長等數(shù)據(jù)分析的工作用到的過程數(shù)據(jù)，都從業(yè)務(wù)系統(tǒng)解耦出來，由工作流的流程數(shù)據(jù)提供原生支持。從過程數(shù)據(jù)記錄，挖掘分析等需求解放出來，供應(yīng)鏈系統(tǒng)就更能騰出精力來專注于提升自身核心競(jìng)爭(zhēng)力——更強(qiáng)更快。

自動(dòng)化一切

908

在上單量飆升時(shí)，壓縮供應(yīng)鏈的上單成本能為公司帶來直接收益。壓縮成本就意味著在保證上單質(zhì)量的同時(shí)盡可能縮短上單時(shí)長、降低人工參與度。我們將供應(yīng)鏈生產(chǎn)過程化整為零，切分為多段，每一段采用定制的自動(dòng)化策略，精細(xì)運(yùn)營。在審核環(huán)節(jié)引入免審，在撰寫環(huán)節(jié)引入免寫，目標(biāo)為“單均成本降低90%，效率提升8倍”，因此公司內(nèi)部將這個(gè)項(xiàng)目稱之為908。

還在繼續(xù)

發(fā)展到后來，908已經(jīng)不再是一個(gè)項(xiàng)目的名字，而是自動(dòng)化一切的思路。到今天供應(yīng)鏈系統(tǒng)也還在一點(diǎn)點(diǎn)雕琢，例如針對(duì)重復(fù)審單的情況引入工作流，針對(duì)品類動(dòng)態(tài)擴(kuò)展的情況引入屬性中心。以屬性中心為例，之前品類和屬性調(diào)整往往意味著幾天的重復(fù)開發(fā)和臃腫的代碼，現(xiàn)在只需要業(yè)務(wù)人員在配置頁面用幾分鐘的時(shí)間簡單配置。

成就動(dòng)作快

以優(yōu)惠買單為例，完整的供應(yīng)鏈流程支持的開發(fā)成本是5人日，包括：完整的商家入駐，個(gè)性化的契約協(xié)議、方案錄入、結(jié)構(gòu)存儲(chǔ)和審核流程，并對(duì)接多個(gè)C端渠道。而在之前，這個(gè)數(shù)字是30人日。

降成本，提效率

實(shí)現(xiàn)免審免寫后，體現(xiàn)出兩個(gè)數(shù)字的變化。一是編審部門解散，這個(gè)部門原來有近百人負(fù)責(zé)上單過程的審核和撰寫；二是上單量增長1000%的背景下，上單成本降低了90%以上。

總結(jié)

從技術(shù)角度回顧供應(yīng)鏈的上單過程。BD在前臺(tái)發(fā)起一起上單請(qǐng)求，后臺(tái)根據(jù)BD要錄單的業(yè)務(wù)渠道、品類等，通過DF（Dynamic Form）渲染出錄入頁面。請(qǐng)求到達(dá)后端后，先經(jīng)過AC（Attribute Center）層自動(dòng)完成針對(duì)不同DF的合法性檢查，再轉(zhuǎn)化為后臺(tái)產(chǎn)品中心要求的數(shù)據(jù)格式。錄完的方案數(shù)據(jù)沉淀到產(chǎn)品中心，并通過Gravity調(diào)度具體方案的審核任務(wù)。發(fā)生修改后，修改過程沉淀到變更中心，變更本身的審核也交由Gravity調(diào)度。產(chǎn)品中心收到Gravity的審核通過消息通知后，就安排CMS使用不同的動(dòng)態(tài)模板完成拼裝，進(jìn)而輸出到不同的C端。

以產(chǎn)品和變更中心為Model沉淀，以動(dòng)態(tài)表單和動(dòng)態(tài)模板完成View自動(dòng)拼接，以屬性中心和工作流完成Control邏輯驅(qū)動(dòng)，最終供應(yīng)鏈系統(tǒng)以MVC定下高可用自動(dòng)化的江山。