广州酒店价格联盟

干货 | 深度解析美团、滴滴两大玩家战略布局+美团O2O供应链架构设计

小肖说物流2020-09-15 14:45:18

3/12   你的时间有限,不要为别人而活。 — 谷正.



分享物流知识,传播物流资讯

感谢有你,常伴于此

2018.3.2 Hello everyone



近日,美团打车、滴滴外卖的相关报道,充斥着我们的朋友圈。各种分析性文章层出不穷,大多都未曾深究事情本质。


而今天分享这篇文章,将从独特的“解剖”视角来分析这两大玩家的战略布局,层层深入,带你剥离浅显的认知,对你十分有用。





如果你是原始人,没有自然科学知识,如何分类蝙蝠、猫头鹰、海豹和企鹅?




“会飞的”“会游泳的”各一类:




但在 19 世纪博物学家看来,你的视线只停于表象,没触及问题本质。


你剥离多少层表象,就能发现多大程度上的本质。


解剖蝙蝠、海豹,你会发现,它们的心脏都是两心房两心室,耳朵都有听小骨,都有乳腺、喝奶长大,都是哺乳动物。


解剖猫头鹰、企鹅,它们都有喙、爪、两足、羽毛,都是卵生,同属鸟类。


所以:



当然,这个答案可能也不对。在 21 世纪,有人认为它们属于同一序列。


“解剖”至原子层面,从 138 亿年前宇宙大爆炸诞生氢原子以来,小到原子、生物,大到星体、宇宙,均由氢原子“拼接”而成。


《连线》主编凯文·凯利的观点更激进,他将一切统称“进化体”,不仅蝙蝠、猫头鹰、海豹和企鹅,而且石头、蜜蜂、人类、机器、互联网甚至也是同类。因为进化是一个充满灰度的斜坡,一切都是“进化体”,都在自简单向复杂进化。



相信凯文·凯利,不像相信博物学家那么容易。毕竟是 20 多年前就预言加密货币的人,他提出的理论往往领先于社会共识。


但重要的是,在不断颠覆的分类方式中,你会发现,分类概念是人为设定的,它有多大可靠性,往往基于认知处在哪一层面。


令人诧异的跨界


美团外卖,滴滴打车。这是 2017 年前,甚至是现在多数人的认知。


即使早在 2014 年 Uber 已有外卖,你也难想象美团、滴滴会竞争,而且这一天来得这么快。毕竟:


  • 2016 年 11 月 Uber 退出中国市场后,滴滴独大,看不到被颠覆的可能;

  • 2017 年 4 月,美团点评整体盈亏平衡,外界认为它将探索盈利;

  • 更重要的是,外卖和打车在认知里不是一件事。



但是,跨界却正在进行。美团从去年开始进入打车市场:


  • 2017 年 2 月,上线南京打车业务(现占滴滴南京地区的6%);

  • 2017 年 12 月,成立出行事业部(与外卖的组织层级相同);

  • 近期,准备在七个城市试运营。


滴滴反击,2017 年底招募外卖骑手,并选南京为首站。



第一层解剖



将外卖、打车“解剖”到技术层面,你会发现,其实它们在解决同一类问题。


下图来自 Uber 的技术博客:



来源:eng.uber.com


改变对象与目标,外卖也可套用:




这实则是一个旅行推销员问题(TSP):


  • 给定一系列城市,以及每个城市间的距离;

  • 为一个旅行推销员做决策优化;

  • 求解他访问每座城市一次并回到起始城市的最短回路。


当然,在外卖、打车的实际场景中,决策优化问题比 TSP 复杂百倍。


以外卖为例:


  • 算法指派时,未来订单信息不确定。如,决策前,没有 TSP 的确定“城市”点,美团须用机器学习研究闲时运力调度;

  • 每笔订单有一定数量骑手备选,同时,骑手身上还有若干订单正在配送。实则是为动态的多个对象做决策;

  • 每笔订单有预计到达时间(ETA)、商户出餐速度等多条件约束,不能只考虑最短回路。ETA、预估出餐时间,同在机器学习的研究范围内;

  • 另外,还需考虑特殊情况,如,空闲时将订单派给不熟练的骑手锻炼,火锅订单只给特定骑手,订单改派等。


所以,在外卖里,简化的 TSP 会升级为带有若干复杂约束的 DVRP 问题(Dynamic Vehicle Routing Problem),如下图所示:



来源:tech.meituan.com


用数学方法优化决策问题,一般包括三要素:决策变量(做什么决策),约束条件(决策的限制因素),优化目标。


美团的外卖模型可简化为:



略加修改,你会发现,它也可用于打车平台:



所以,当阅读美团和 Uber 的技术博客时,你会发现他们在目标描述上的惊人相似:


  • 美团工程师追求“在配送体验(送餐更快、ETA 更准确)和配送成本(劳动力更少)之间取得最佳的平衡”;

  • 对 Uber 的算法设计者而言,“超高效的路线规划,和高度准确的 ETA,至关重要”。


事实上,不论外卖,还是打车,都需要调度算法支持。虽然两者有不同的外包团队和数据积累,但进入对方市场,实则是摊薄了技术研发费用。



为什么进入打车市场?



技术层面的相似性,还不足以回答这个问题。


王兴(美团 CEO)的理由是用户需求,用户去餐厅需要打车。因为王慧文(美团外卖负责人)给他的数据显示,2.5 亿日活跃用户中,30% 有出行需求。


这是一个好理由,但不代表能说服所有人。《财经》的宋玮反问他:“打车路上用户可能也需要看淘宝,你为什么不做淘宝呢?”


虽然淘宝与打车关联度不高,在某种程度上影响了这个问题的质量,但我理解她提问的本意。即:美团进入打车市场的战略意图是什么?以客户为中心只是美团的愿景,不能用它回答所有商业问题,否则大量用户用微信分享餐厅信息,怎么不做一个微信?



第二层解剖



要解决这个问题,须“解剖”到商业模式层面。


外卖平台符合诺贝尔经济学奖得主 Jean Tirole 对双边市场的描述:


1. 把交易双方或多方的参与者聚集到平台上。


2. 市场一边会吸引另一边用户,形成正向循环。如,补贴策略。


3. 几乎所有市场都是“two-sided”,有买卖两方。但只有那些用平台结构(而不仅是合理收费)影响交易量的,才是双边市场。


如,美团将外卖送达时间从 2015 年的 41 分钟缩短至现在的 28 分钟,提升用户端交易意愿。

如,美团提高了餐厅厨房的使用效率,提升餐厅端交易意愿。


4. 具有正外部性,用户越多,平台价值越大。




打车平台也是双边市场。滴滴的 On-Demand 服务降低了出租车的空载率,同时,也降低了乘客等车时间。




然而,带给美团竞争优势的双边市场,同时也是它频繁跨界作战的原因。从 Facebook 到微信,在技术驱动的行业里,我们习惯于看到“赢者通吃”。


双边市场显然不是。在美国,Uber 虽占据 3/4 的市场,有绝对优势,但竞争对手 Lyft 却能持续融资,用 1/4 的市场份额和它抗衡。在国内外卖市场,饿了么和美团则四六开。


这是因为,微信的优势在需求侧。你之所以用微信,是因为你所有朋友都用,而你加入后又增加朋友们的使用价值。如此循环,形成网络效应,再小的竞争优势也被迅速放大。


双边市场的优势则在供给侧。它具备规模效应,越多骑手、出租车,用户体验越好。但用户数量无法直接影响用户选择,你加入不是因为朋友都在,而是这个平台的服务好。


而且,规模达到一定程度后,继续增加,不仅没有提升用户体验,成本反而增加。正如 Lyft 的创始人所说,“规模效应到了一定点就没用了,一般这个点是从接单到抵达的 3 分钟时间限制”。


所以,护城河不够深的双边市场类公司极具危机感。王兴说:“美团这个公司永远离破产只有 6 个月时间。”


不过,他还说:“我不太担心现有的竞争对手。”


这不矛盾。因为颠覆者往往不是出自现有行业,就像沃尔玛的挑战者不是 Costco,而是在线卖书的亚马逊。


现在,美团手握高频的外卖,滴滴有高频的打车,量级相当。然并不能高枕无忧,两者的 App 重合度有 19.46%,这让美团有机会进入打车市场,同样,滴滴也有机会挑战美团外卖。



对美团而言,双边市场带来的危机更来自于新兴领域的高频交易。如果某天我们热爱某样服务,召唤它的频率比外卖还高。那么美团就将被迫面对高频打底频的降维打击。



所以,我们看到了一个四处出击的美团。


它找新业务的逻辑正是“交易频率”。《财经》披露:


美团内部,有一个类似雷达的扫描团队,每日监控中国商业社会发生的所有互联网交易项目,日过千单立马学习研究。这个机制让美团发现了外卖、发现了打车,也发现了民宿、新零售、充电宝等测试项目。



第三层解剖



如果将“解剖”推进至互联网层面呢?


理解互联网,先要理解它的基础 TCP/IP 协议。70 年代的科学家设计这套协议,就是为计算机间的交流提供通用“语言”,让世界各地的计算机链接在一起,实现“文本”传输。


互联网的核心实则是“文本”对话。比特(Bit)是这种“文本”的最小单位。


不论哪个行业,都将从原子转化为比特,但转化的先后次序与难易程度是不一样的。这一点清晰体现在过去 20 年的科技公司诞生史:


  • 谷歌、百度最先出现,因为搜索引擎本身就是一种“文本”处理方式;

  • 至于 Facebook、微信,它们提取了用户身上的最大公约数——社交,但将社交转化为社交网络,须有手机拍照的配合,否则想象一个没有头像的微信是件挺困难的事;

  • 之后是阿里巴巴、京东,它们将商品转化为在线展示,此时转化难度加大,体现在公司层面,就是业务更重,需要支付、物流的配合;

  • 到了美团、滴滴,它们在垂直行业推进比特转化,“大块”领域已被分割,剩下的市场像一座座孤岛,不论外卖还是打车,都须面对不同的市场挑战;



而且,在美团、滴滴这种模式里,为了发挥供应侧优势,不能做浅链接,对行业的转化程度要够深。

以餐饮为例,美团点评从提供餐厅信息,到团购交易,再到外卖配送,现在还给餐饮老板提供 ERP 系统,比特的转化程度逐步变深。


王兴将之称为“入地”:


大家吃到一盒饭,上游有无数事,从种地、采摘、捕捞,到运输、仓储、零售。互联网率先改变了外卖订餐,接着上游的各个环节也一定会被改造。我相信凡是还没被互联网改变的行业,都将被改变,只是先后顺序不一样。越靠近消费者,越敏感,越先被改变。下半场的机会是入地,不光做 to C,还要到各个行业里,改造其整个链条。


P.S. 为简洁阅读,删减了口语词


除了入地,2017 年美团和滴滴还互相进入了对方市场。



上图这种模式的横向拓展边界在哪?


8 年前,你在京东上只能买到 3C 产品。2010 年,京东突然杀进图书市场,和当时的图书电商 No.1 当当网开战。这同样是一件无法理解的事,以短攻长,又坚决不求盈利。8 年后的今天,你已经知道,进入图书市场只是开始,京东的目标是综合电商。


现在,美团、滴滴展开竞争。但这显然也只是开始。


王兴之所以说“上天”,美团之所以研究人工智能、大数据、云计算,都是因为它的 On-Demand 服务不仅要在外卖里以亿计算,而且还准备进入其他市场,如打车。


它的目标是“综合生活服务商”?曾投资京东的徐新(今日资本创始人)如今也重仓了美团。她说:“高频的、刚需的,只要跟交易有关美团都应该做。”美团用商业里的一个环节作为核心,从商业讲是交易,从客户角度讲是服务。


最后,也许它们会变成这样,转化一切的比特机器:



在这个维度上,我们已经能理解,为什么王兴思考美团的使命”eat  better,live  better”这句话,会想了整整一年。




本文大概

3758

读完共需

15

分钟



美团供应链模型图



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

一是将拟定的方案细化,让消费者能看到详尽的图文描述,价格,购买限制等等。二是审核这个方案,确保它在法律上有效,在财务上可靠。

完成这个生产过程后,用户就可以到美团的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定下高可用自动化的江山。

                                


来源:架构之家,格竹集

来源:小肖说物流整理,媒体转载请注明来源

免责提示:仅供分享不做任何商业用途,版权归原作者所有。部分文章因转载众多,无法确认原作者的,仅标明转载来源。如有问题,请后台微信:留言会立即删除,并表示歉意,谢谢!



说物流

小|肖

一个物流人的笔记本
基于情怀的一些感悟
聚合物流行业新知识

微信号:小肖说物流

长按上方二维码

“识别图中二维码”即可关注

Copyright © 广州酒店价格联盟@2017