本文是美團技術沙龍第一期，O2O技術架構與實踐上的分享內(nèi)容赌髓。請在微信搜索“美團技術團隊”關注我們的公眾賬號从藤，了解更多活動信息。

寫在前面

英國知名供應鏈專家Martin Christopher曾經(jīng)說過一句非常深刻的話：“21世紀的競爭不是企業(yè)和企業(yè)之間的競爭锁蠕，而是供應鏈和供應鏈之間的競爭夷野。”

1 什么是供應鏈

在風云變幻荣倾、寡頭紛爭的O2O戰(zhàn)場悯搔，美團屢出重拳并步步為營，戰(zhàn)績不俗舌仍。這一切離不開背后的神秘技術團隊——供應鏈妒貌。

供應鏈，簡稱 SCP（Supply Chain Process）铸豁。美團借助平臺的優(yōu)勢與商家展開合作灌曙，將約定的合作方案落實到紙質(zhì)契約。彼時用戶還不能直接看到或購買這些契約上的合作方案推姻，需要一個電子化的生產(chǎn)過程平匈。這個過程完成兩件重要的事情，一是將擬定的方案細化，讓消費者能看到詳盡的圖文描述增炭，價格忍燥，購買限制等等。二是審核這個方案隙姿，確保它在法律上有效梅垄，在財務上可靠。完成這個生產(chǎn)過程后输玷，用戶就可以到美團的C端队丝，例如手機APP或美團主站上看這個方案并發(fā)起購買，產(chǎn)生一筆交易欲鹏。到具體的門店進行消費時机久，就能得到方案中商家許諾的服務框杜。這一系列的過程：合作软吐，交易，消費都是緊緊圍繞一個概念發(fā)生的盘寡，那就是項目尤误。這個項目的生產(chǎn)過程侠畔，就是美團供應鏈。

這個生產(chǎn)過程由哪些角色參與了哪些事损晤，生產(chǎn)出來的項目又是什么呢软棺？以傳統(tǒng)團購為例，一個經(jīng)典的上單過程由美團在城市端的BD（業(yè)務拓展人員）發(fā)起尤勋。BD和商家達成合作意向后簽署一紙合同喘落，再到美團的業(yè)務門戶錄入這次合作和詳細方案，然后提交總部審核最冰。審核人員根據(jù)審核手冊做出判斷揖盘，如果本次合作和方案可靠合法就將其審核通過。審核通過的方案再經(jīng)過CMS（內(nèi)容管理系統(tǒng)）完成標題圖文的包裝和各個C端渠道的適配锌奴，一單項目就生產(chǎn)完成了『豆桑可以看到鹿蜀，這個過程涉及多個業(yè)務環(huán)節(jié)和人員角色，如果能提高其中一些環(huán)節(jié)效率或減少人員投入服球，將成為公司的核心競爭力茴恰。

除了傳統(tǒng)團購，美團在O2O的一些細分領域斩熊，比如酒店往枣、旅游、外賣、早餐等等也逐步開花結果分冈。這些新生的細分領域的項目標準化程度不一圾另，如何支持這些細分領域的項目生產(chǎn)，如何讓這個支持過程高效可靠雕沉，幫助美團把握住一個又一個的O2O風口集乔，就成了美團供應鏈系統(tǒng)面臨的挑戰(zhàn)。

2 供應鏈系統(tǒng)的挑戰(zhàn)

2.1 復雜數(shù)據(jù)細粒度結構化

在購買傳統(tǒng)商品時坡椒，在淘寶扰路、京東上，用戶更關心的是產(chǎn)品規(guī)格倔叼、材質(zhì)汗唱、物流方面的信息，比如一件紅色T恤丈攒，用戶會關心是純棉的嗎哩罪，是不是XL碼，所在的省份支持哪些快遞公司肥印，快遞費多少识椰，而不太會關心商家所處的位置。而購買餐飲團購時深碱，用戶就非常關注這個商家的物理位置腹鹉，需要具體到哪個城市哪個商圈哪個門店。即使同為團購單敷硅，餐飲和酒店又有很大不同功咒。餐飲單需要關心幾人餐，餐具是否免費绞蹦，允不允許自帶酒水力奋，是川菜還是江浙菜系列等。酒店單需關注是大床房還是雙人床房幽七，是否免預約景殷，工作日和周末是否價格不同等。

由此可以看出澡屡，在不同的細分領域猿挚，甚至同一領域下不同的品類，商品的標準化程度都有很大不同驶鹉。以傳統(tǒng)團購中餐飲品類下火鍋子品類為例绩蜻，一個細化的方案包括：方案信息（菜系、幾人餐室埋、套餐幾選幾办绝、具體菜品等）伊约，購買須知（交易類型是美團券還是優(yōu)惠碼，項目有效期孕蝉，美團券有效期等）屡律，還有商家自身文案描述等，大概涉及將近100個屬性昔驱。那么問題就來了疹尾，為什么需要將粒度拆分得這么細呢？

背后有兩個原因骤肛。一纳本，從大的方向上來講，供應鏈連接了商家和用戶腋颠，也就是需要同時對接到B端和C端繁成。B端的利益相關人是地面銷售人員，他們對供應鏈系統(tǒng)的需求是錄入效率高淑玫。在不同細分領域以及不同品類之間有共同關注的屬性巾腕，比如購買須知(也就是項目有效期這些概念)。我們從散落的屬性中把這些可復用的屬性抽出來絮蒿，抽象為購買須知模塊尊搬，幫助BD預填寫很多默認值，可以有效提升BD的上單效率土涝。同時對C端的消費者來講佛寿，需要從很多維度進行搜索，方便的找到符合預期的商品但壮，而搜索的前提就是內(nèi)容的結構化冀泻。二，美團C端的渠道也愈來愈多蜡饵，各C端渠道對項目方案的屬性維度要求不一且調(diào)整頻繁弹渔。結構化是實現(xiàn)這些需求的必然路徑。

2.2 售賣方式靈活多變

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

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

團購做精做深的過程卫袒，反應在產(chǎn)品層面，就是品類的擴充和拆分单匣。例如自助餐品類需要新增字段夕凝，表達是否含WiFi、是否含停車位户秤。例如火鍋品類拆分為成都火鍋码秉、重慶火鍋。每次品類的擴充與拆分都意味著產(chǎn)品錄入界面調(diào)整鸡号，后臺存儲改變转砖。體現(xiàn)在開發(fā)上面，需要前后端同時支持膜蠢，煩不勝煩堪藐。這對供應鏈又提出了新要求：品類和屬性調(diào)整零開發(fā)量。

2.4 審核流程可配置

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

3 直面挑戰(zhàn)

3.1 構建 O2O 生活服務模型

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

我們以多售賣方式的酒店為例來看看產(chǎn)品中心的映射關系。對商家而言品山，能提供的服務單元包括大床房胆建，酒水，早餐肘交，WiFi笆载。這些服務按照商家的銷售意愿組裝成銷售單元進行售賣，如大床房+早餐涯呻、大床房+WIFI凉驻、大床房。對C端用戶而言复罐，感知到的就是銷售單元涝登，享受到的是銷售單元內(nèi)涵蓋的服務單元。需要銷售端感知的限制被抽象為銷售規(guī)則效诅，需要消費端感知的限制被抽象為消費規(guī)則胀滚，售賣方式被抽象為價格規(guī)則。這些規(guī)則可以被統(tǒng)稱為SKU屬性乱投。銷售單元適配上不同的SKU屬性咽笼，就成為不同的C端產(chǎn)品。

3.2 事件驅動戚炫，過程解耦

針對審核過程動態(tài)可配置的目標剑刑，我們引入了工作流。為不同的業(yè)務渠道設計不同的審核流程：有哪些審核節(jié)點双肤，每個審核節(jié)點由哪些人員角色操作施掏，每個審核節(jié)點在通過或駁回后的流向层宫，都可以動態(tài)配置，分分鐘搞定其监。業(yè)務系統(tǒng)不再關心工作臺的概念，供應鏈系統(tǒng)的信息流和事件流推動完全交由了工作流系統(tǒng)限匣。不僅于此抖苦，原先累積在供應鏈系統(tǒng)之上，針對上單時長米死、等待時長等數(shù)據(jù)分析的工作用到的過程數(shù)據(jù)锌历，都從業(yè)務系統(tǒng)解耦出來，由工作流的流程數(shù)據(jù)提供原生支持峦筒。從過程數(shù)據(jù)記錄究西，挖掘分析等需求解放出來，供應鏈系統(tǒng)就更能騰出精力來專注于提升自身核心競爭力——更強更快物喷。

3.3 自動化一切

3.3.1 908

在上單量飆升時卤材，壓縮供應鏈的上單成本能為公司帶來直接收益。壓縮成本就意味著在保證上單質(zhì)量的同時盡可能縮短上單時長峦失、降低人工參與度扇丛。我們將供應鏈生產(chǎn)過程化整為零，切分為多段尉辑，每一段采用定制的自動化策略帆精，精細運營。在審核環(huán)節(jié)引入免審隧魄，在撰寫環(huán)節(jié)引入免寫卓练，目標為“單均成本降低90%，效率提升8倍”购啄，因此公司內(nèi)部將這個項目稱之為908襟企。

3.3.2 還在繼續(xù)

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

4 成就

4.1 動作快

以優(yōu)惠買單為例，完整的供應鏈流程支持的開發(fā)成本是5人日屿愚，包括：完整的商家入駐汇跨，個性化的契約協(xié)議务荆、方案錄入、結構存儲和審核流程穷遂，并對接多個C端渠道函匕。而在之前，這個數(shù)字是30人日蚪黑。

4.2 降成本盅惜，提效率

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

5 總結

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

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