【供应链架构day7】美团供应链的架构之道：O2O关键战场在供给端

英国知名供应链专家Martin Christopher曾经说过一句非常深刻的话：“21世纪的竞争不是企业和企业之间的竞争，而是供应链和供应链之间的竞争。”

什么是供应链

在风云变幻、寡头纷争的O2O战场，美团屡出重拳并步步为营，战绩不俗。这一切离不开背后的神秘技术团队——供应链。

除了传统团购，美团在O2O的一些细分领域，比如酒店、旅游、外卖、早餐等等也逐步开花结果。这些新生的细分领域的项目标准化程度不一，如何支持这些细分领域的项目生产，如何让这个支持过程高效可靠，帮助美团把握住一个又一个的O2O风口，就成了美团供应链系统面临的挑战。

供应链系统的挑战

复杂数据细粒度结构化

在购买传统商品时，在淘宝、京东上，用户更关心的是产品规格、材质、物流方面的信息，比如一件红色T恤，用户会关心是纯棉的吗，是不是XL码，所在的省份支持哪些快递公司，快递费多少，而不太会关心商家所处的位置。而购买餐饮团购时，用户就非常关注这个商家的物理位置，需要具体到哪个城市哪个商圈哪个门店。即使同为团购单，餐饮和酒店又有很大不同。餐饮单需要关心几人餐，餐具是否免费，允不允许自带酒水，是川菜还是江浙菜系列等。酒店单需关注是大床房还是双人床房，是否免预约，工作日和周末是否价格不同等。

由此可以看出，在不同的细分领域，甚至同一领域下不同的品类，商品的标准化程度都有很大不同。以传统团购中餐饮品类下火锅子品类为例，一个细化的方案包括：方案信息（菜系、几人餐、套餐几选几、具体菜品等），购买须知（交易类型是美团券还是优惠码，项目有效期，美团券有效期等），还有商家自身文案描述等，大概涉及将近100个属性。那么问题就来了，为什么需要将粒度拆分得这么细呢/p>

背后有两个原因。

一，从大的方向上来讲，供应链连接了商家和用户，也就是需要同时对接到B端和C端。B端的利益相关人是地面销售人员，他们对供应链系统的需求是录入效率高。在不同细分领域以及不同品类之间有共同关注的属性，比如购买须知(也就是项目有效期这些概念)。我们从散落的属性中把这些可复用的属性抽出来，抽象为购买须知模块，帮助BD预填写很多默认值，可以有效提升BD的上单效率。同时对C端的消费者来讲，需要从很多维度进行搜索，方便的找到符合预期的商品，而搜索的前提就是内容的结构化。

二，美团C端的渠道也愈来愈多，各C端渠道对项目方案的属性维度要求不一且调整频繁。结构化是实现这些需求的必然路径。

售卖方式灵活多变

支持完品类繁多的餐饮单方案详情后，我们马上面临另外一个问题——复杂多变的售卖方式。酒店双人间，含早餐和不含早餐，双床还是大床房都对应不同价格。其实，线下的酒店售卖场景对应到线上，除了早餐和房型的差别，还面临节假日、不同时段等等规则，产生了多种多样组合售卖方式。并且每次交易后，商家都需要扣减指定一类房型的库存。此时又该如何应对呢。是否每多一个售卖方式，BD就要重复录一个方案必然会导致录单时长呈几何倍数增长。如果方案细节发生调整，关联的大量方案也需要同时修改，给BD带来的成本太高。这就对供应链系统提出了新的要求：只录一次，就能支持复杂多变的售卖方式。

品类和属性动态调整

团购做精做深的过程，反应在产品层面，就是品类的扩充和拆分。例如自助餐品类需要新增字段，表达是否含WiFi、是否含停车位。例如火锅品类拆分为成都火锅、重庆火锅。每次品类的扩充与拆分都意味着产品录入界面调整，后台存储改变。体现在开发上面，需要前后端同时支持，烦不胜烦。这对供应链又提出了新要求：品类和属性调整零开发量。

直面挑战

构建 O2O 生活服务模型

实现上面这些高大上的要求，美团供应链系统其实也不是一蹴而就的。从糙快猛的作坊式开发，到今天搞架构搞模式搞生态，供应链系统的进化是一部可歌可泣的血泪史。在经历品类猛调，渠道猛扩之后，技术一路小跑却依然跟不上产品的迭代速度。当时系统已经积攒了历久弥陈的代码和逻辑，在新需求面前难于招架、步履维艰。这时我们意识到出了问题。飞速行驶的火车就无法优雅地换轮子吗，业务多次迭代后系统就必然动态不得了案必然是否定的。供应链技术团队在痛定思痛之后选择了一条最难但也是彻底解决这个问题的道路：给O2O行业的各业务生态建模，抽象出产品中心。

我们以多售卖方式的酒店为例来看看产品中心的映射关系。对商家而言，能提供的服务单元包括大床房，酒水，早餐，WiFi。这些服务按照商家的销售意愿组装成销售单元进行售卖，如大床房+早餐、大床房+WIFI、大床房。对C端用户而言，感知到的就是销售单元，享受到的是销售单元内涵盖的服务单元。需要销售端感知的限制被抽象为销售规则，需要消费端感知的限制被抽象为消费规则，售卖方式被抽象为价格规则。这些规则可以被统称为SKU属性。销售单元适配上不同的SKU属性，就成为不同的C端产品。

事件驱动，过程解耦

自动化一切

908

还在继续

发展到后来，908已经不再是一个项目的名字，而是自动化一切的思路。到今天供应链系统也还在一点点雕琢，例如针对重复审单的情况引入工作流，针对品类动态扩展的情况引入属性中心。以属性中心为例，之前品类和属性调整往往意味着几天的重复开发和臃肿的代码，现在只需要业务人员在配置页面用几分钟的时间简单配置。

成就

动作快

降成本，提效率

总结

以产品和变更中心为Model沉淀，以动态表单和动态模板完成View自动拼接，以属性中心和工作流完成Control逻辑驱动，最终供应链系统以MVC定下高可用自动化的江山。

=>更多文章请参考：《中国互联 业务研发体系架构指南》

https://blog.csdn.net/Ture010Love/article/details/104381157