完善的供應鏈系統，是美團自創立至今持續茁壯成長的基礎所在。它經歷「千團大戰」和後來殘酷同業競爭的重重磨練。在不斷的自我優化與創新中，幫助美團奠定了團購行業的領先地位。而面對企業今後多元化業務的發展需要，這個系統又進行了架構的重塑。
在UPYUN主辦的「 UPYUN Open Talk 」第三期北京站上，美團技術專家、供應鏈平臺系統負責人陳義宏向與會的知名企業及創業團隊的開發者們做了深入淺出的精彩分享。
以下為分享摘錄：
美團是以團購起家並作為核心業務，之後增加了一些支付、商家管理，包括驗證、憑證方面還有其他的等業務。供應鏈系統主要負責商品的生產和商品的運營，其中的這個「商品」指的是我們本地的生活服務的各種套餐、代金券和其他的業務。
關注過團購領域的朋友們應該聽說過「千團大戰」，美團之所以能在這樣的挑戰中活下來，一個重要原因是我們的BD比較牛。這一塊的工作流程是：在BD與商家談妥之後，會給商家在美團建立一個帳號，籤訂合同，以便在之後把談妥的這些東西變成大家在手機APP或者是網站上出售的東西，比如團購券。從BD談妥單子，到消費者能從網頁上買到商品，這中間的過程都是供應鏈完成的工作。
它的定位，是給美團是正在茁壯成長的業務提供支持，因此它的建設是一步步循序漸進的。
美團的供應鏈系統的架構不是很複雜，它是隨著公司創立到在現在的各個發展階段而一步步建立起來的，架構有一個不斷演進的過程。
1.手工階段
系統初創是在2010年，當時我們是模仿美國的例子，一天一單，全靠手工。單子上傳上去，七天之後才可以在網站上看見。流程上有編審的程序，不但要審核，還要專人進行編輯。這種情況延續到2011年，高層進行了一個星期的考量之後，決定一天要上多單。
2. 從在線化到自動化
從這時起，我們要求每天上單量達到250，並相應安排了250個編輯。因此，公司開始建立一個合同和CMS，就是替換成編輯的手工工作。CMS是結構化，有三大塊，原來一個人的工作分成三個人來做。做完這個之後一個人可以上11單。
和滴答團、拉手、糯米競爭時，美團並不佔據很大優勢。公司針對性地調整了策略，大幅度增加每天上單的數量，計劃要一天上幾千單。就一個單子和商家談好之後，要儘快上線。
之後，公司基本上把整個關鍵系統重新寫了，把每一個看見的元素都屬性化。具體做法，就是在同一屬性的情況下做了一個模板的概念，模板可以根據不同的品類具有不同的屬性。
我們結合前端一起根據我們模板配置，根據配置自動輸出目錄界面的一套系統，就是動態表單。輸出基本上每一個屬性都有一個ID，有一個值。後來又節省了大量編輯或審核人員的工作，又裁掉了大部分的頁面美化工序，效率得到了大大提升，做了非常多的自動化的工作，上單時間減少到2天。
這樣，到2014年9月份，我們的上單量一天接近1.4萬單/日。編輯數量也從最初的240人縮減到10人，上單時間一般都是在一天之內。這之後，美團奠定了團購領頭羊的地位。
1. 平臺+差異化
在如今，整個行業都處於不斷的快速變化中。團購現在已經無法支撐一家比較大的公司了，我們很多的競爭對手都已經開始涉及新業務，比如點評投資餓了麼，主打外賣。美團也要做同樣的發展，所以就有了美團外賣和早餐的出現。此外還有一些新的品類垂直運營，像KTV、並作項目，現在有獨立團隊在運營；酒店和售票的領域也進行了拓展。現有業務都會在飛速發展中，包括一些新的形式，像到家服務，以及代替代金券的滿減。
以上這些的新業務，給供應鏈系統提出了挑戰——從單一的團購到解決多業務支撐，我們該怎麼做？首先應該對它進行重新的梳理。對比有些在供應鏈系統上投入幾十個人團隊的企業，我們現在人員要少得多，2013年只有兩個人，如今也只有11、12個人在做。因此現在需要改變之前這種粗獷的、不考慮系統內部設計的快速迭代發展方式。
因此，我們分析了美團內部的系統，比如我們的外賣、早餐、酒店，尋找它們上單的流程存在哪些共性和差異。差異基本上都體現在流程和展示方面，我們就對這些差異進行結構化的定義，對它們進行針對性的優化。
比如現在有閃電上單，BD上單，銷售人員和商家談妥了之後自行上單。另外我們還有商家自助上單。雖然它們的流程不一樣，但是他們的底層相同的。我要做的就是這種統一平臺+差異化流程的系統優化。
前面提到了動態表單，它其中的一個問題就是屬性綁定。而當我們上單渠道多的時候，同一個屬性在不同的上單渠道上顯示的值的數量可能不同。現在的方法，就是把這些值剝離開來，變成一個AC（屬性中心），和一個DF（動態表單）。我們會做各種上單錄入的模板，每個渠道都不一樣。而且會為每一個屬性在不同的渠道定義不同的顯示項，再根據顯示項來產生組成我的模板，再把模板輸出到具體的錄入的過程當中。
同時，系統的CMS也是根據屬性去生成頁面。我們會在保持我們產品中心非常平臺化的情況下，做一個差異化的適配。以做KTV的上單系統為例，因為商家可能比我們理解的更深入，因此就讓他們定包廂、時間和酒水，而適配我們來做。在價格、結算和庫存這塊都有以產品為中心，輸給我們的下遊。通過我們系統屏蔽了各種不同商家渠道和不同業務的差異，髒活累活我們來做，給所有下遊系統的工作提供了很大的便利。
2. 產品中心的結構
這個是我們的產品中心，這是它內部的結構，我們會做一些抽象，比如說消費單元，一個人最終能夠到商家那裡去消費的東西。比如理髮店，理髮就是一個消費單元，理髮的時候還給你掏一下耳朵，那也是一個小費單元。
至於銷售單元，這個和用戶最終享受到的服務有一定的關係，但定義的方向不同。從銷售的概念來說，比如你買一臺iPhone，銷售單元就是iPhone+耳機+貼膜之類，而這其中的消費單元就是單獨的手機/耳機/貼膜。銷售單元就是一個打包，是消費單元在網站上售賣的不可分開購買的一個抽象。所以我們有了銷售單元之後，我們的庫存是做在銷售單元之上。
團購是一個類型，套餐是另一個類型。KTV可能沒有物流信息，但是他有預定信息，因此，我們可以在產品層次上根據不同的業務線做抽象。而產品作為我們最終出售的東西，它有一套銷售規則：比如這個商品的開賣時間或者搶購時間；它的購買渠道，比如這個套餐只能在手機端購買在PC端不行；還有購買規則，比如一個手機號只能買一個，此外還有消費規則。這樣，通過整個這一套體系，基本上能夠在底層支撐我們現有旅遊、外賣、酒店、物流的多元化業務，團購自然不在話下。
這就是我們現在支撐多業務的平臺+差異化的基礎，在此基礎上是一些流程。每一個系統將來要接入一個新的業務的話，它只需要通過我們的AC+DF一個界面，經過我們的流程，再接入我們平臺化的東西，這個業務就會得到系統的支持。