午夜免费电影-中文字幕丰满乱孑伦无码专区-久久久久久亚洲精品无码-国产精品天天狠天天看

1、什么是供應鏈

在風云變幻、寡頭紛爭的O2O戰場，美團屢出重拳并步步為營，戰績不俗。這一切離不開背后的神秘技術團隊——供應鏈。
供應鏈，簡稱 SCP（Supply Chain Process）。美團借助平臺的優勢與商家展開合作，將約定的合作方案落實到紙質契約。彼時用戶還不能直接看到或購買這些契約上的合作方案，需要一個電子化的生產過程。這個過程完成兩件重要的事情，一是將擬定的方案細化，讓消費者能看到詳盡的圖文描述，價格，購買限制等等。二是審核這個方案，確保它在法律上有效，在財務上可靠。完成這個生產過程后，用戶就可以到美團的C端，例如手機APP或美團主站上看這個方案并發起購買，產生一筆交易。到具體的門店進行消費時，就能得到方案中商家許諾的服務。這一系列的過程：合作，交易，消費都是緊緊圍繞一個概念發生的，那就是項目。這個項目的生產過程，就是美團供應鏈。

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

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

2、供應鏈系統的挑戰

2.1 復雜數據細粒度結構化

在購買傳統商品時，在淘寶、京東上，用戶更關心的是產品規格、材質、物流方面的信息，比如一件紅色T恤，用戶會關心是純棉的嗎，是不是XL碼，所在的省份支持哪些快遞公司，快遞費多少，而不太會關心商家所處的位置。而購買餐飲團購時，用戶就非常關注這個商家的物理位置，需要具體到哪個城市哪個商圈哪個門店。即使同為團購單，餐飲和酒店又有很大不同。餐飲單需要關心幾人餐，餐具是否免費，允不允許自帶酒水，是川菜還是江浙菜系列等。酒店單需關注是大床房還是雙人床房，是否免預約，工作日和周末是否價格不同等。
由此可以看出，在不同的細分領域，甚至同一領域下不同的品類，商品的標準化程度都有很大不同。以傳統團購中餐飲品類下火鍋子品類為例，一個細化的方案包括：方案信息（菜系、幾人餐、套餐幾選幾、具體菜品等），購買須知（交易類型是美團券還是優惠碼，項目有效期，美團券有效期等），還有商家自身文案描述等，大概涉及將近100個屬性。那么問題就來了，為什么需要將粒度拆分得這么細呢？
背后有兩個原因。一，從大的方向上來講，供應鏈連接了商家和用戶，也就是需要同時對接到B端和C端。B端的利益相關人是地面銷售人員，他們對供應鏈系統的需求是錄入效率高。在不同細分領域以及不同品類之間有共同關注的屬性，比如購買須知(也就是項目有效期這些概念)。我們從散落的屬性中把這些可復用的屬性抽出來，抽象為購買須知模塊，幫助BD預填寫很多默認值，可以有效提升BD的上單效率。同時對C端的消費者來講，需要從很多維度進行搜索，方便的找到符合預期的商品，而搜索的前提就是內容的結構化。二，美團C端的渠道也愈來愈多，各C端渠道對項目方案的屬性維度要求不一且調整頻繁。結構化是實現這些需求的必然路徑。

2.2 售賣方式靈活多變

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

2.3 品類和屬性動態調整

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

2.4 審核流程可配置

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

3、直面挑戰

3.1 構建 O2O 生活服務模型

實現上面這些高大上的要求，美團供應鏈系統其實也不是一蹴而就的。從糙快猛的作坊式開發，到今天搞架構搞模式搞生態，供應鏈系統的進化是一部可歌可泣的血淚史。在經歷品類猛調，渠道猛擴之后，技術一路小跑卻依然跟不上產品的迭代速度。當時系統已經積攢了歷久彌陳的代碼和邏輯，在新需求面前難于招架、步履維艱。這時我們意識到出了問題。飛速行駛的火車就無法優雅地換輪子嗎，業務多次迭代后系統就必然動態不得了？答案必然是否定的。供應鏈技術團隊在痛定思痛之后選擇了一條最難但也是徹底解決這個問題的道路：給O2O行業的各業務生態建模，抽象出產品中心。
我們以多售賣方式的酒店為例來看看產品中心的映射關系。對商家而言，能提供的服務單元包括大床房，酒水，早餐，WiFi。這些服務按照商家的銷售意愿組裝成銷售單元進行售賣，如大床房+早餐、大床房+WIFI、大床房。對C端用戶而言，感知到的就是銷售單元，享受到的是銷售單元內涵蓋的服務單元。需要銷售端感知的限制被抽象為銷售規則，需要消費端感知的限制被抽象為消費規則，售賣方式被抽象為價格規則。這些規則可以被統稱為SKU屬性。銷售單元適配上不同的SKU屬性，就成為不同的C端產品。

3.2 事件驅動，過程解耦

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

3.3 自動化一切

3.3.1 908

在上單量飆升時，壓縮供應鏈的上單成本能為公司帶來直接收益。壓縮成本就意味著在保證上單質量的同時盡可能縮短上單時長、降低人工參與度。我們將供應鏈生產過程化整為零，切分為多段，每一段采用定制的自動化策略，精細運營。在審核環節引入免審，在撰寫環節引入免寫，目標為“單均成本降低90%，效率提升8倍”，因此公司內部將這個項目稱之為908。

3.3.2 還在繼續

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

4、成就

4.1 動作快

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

4.2 降成本，提效率

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

5、總結

從技術角度回顧供應鏈的上單過程。BD在前臺發起一起上單請求，后臺根據BD要錄單的業務渠道、品類等，通過DF（Dynamic Form）渲染出錄入頁面。請求到達后端后，先經過AC（Attribute Center）層自動完成針對不同DF的合法性檢查，再轉化為后臺產品中心要求的數據格式。錄完的方案數據沉淀到產品中心，并通過Gravity調度具體方案的審核任務。發生修改后，修改過程沉淀到變更中心，變更本身的審核也交由Gravity調度。產品中心收到Gravity的審核通過消息通知后，就安排CMS使用不同的動態模板完成拼裝，進而輸出到不同的C端。
以產品和變更中心為Model沉淀，以動態表單和動態模板完成View自動拼接，以屬性中心和工作流完成Control邏輯驅動，最終供應鏈系統以MVC定下高可用自動化的江山。