在风云变幻、寡头纷争的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定下高可用自动化的江山。

 

本文是美团技术沙龙第一期，上的分享内容。来自微信公众号：美团技术团队

原文地址：http://tech.meituan.com/o2o-architecture.html?utm_source=tuicool#rd