英國知名供應鏈專家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定下高可用自動化的江山。
