数据驱动在餐饮行业的探索与实践

餐饮行业过去几年的发展增速高于同期社会消费品零售总额增速,但行业存在门槛低、成本高、竞争激烈的问题。在这其中约600万商户正在使用“智能餐饮”ERP软件,占比不足10%。


640?wx_fmt=png


行业对于数据驱动赋能存在着巨大的需求,对于使用新技术来提高运营效率和用户体验进而最终提升营收有着迫切的愿望。我们希望线上积累起来的数据处理、运用能力能够在线下为这些一线的商户们带来实际的营收增长。随着菲住布渴酒店项目的进行,我们有了这一次深入行业的机会。


 一     背景


小厨是菲住布渴酒店早期在亲橙里开设的中端社会餐饮餐厅,担负着我们验证数字化运营技术方案的试验田角色。在小厨开业时,我们的数字化系统向其提供了包括点菜、下单、结账、后厨信息流转、对账等基础的运营功能,通过运营数据的入库存档初步解决了运营信息数字化及其流转的问题,打通了餐厅前后台及财务的数据交互,同时在运营过程中也收集了一定量的历史数据,为后续的技术升级与改造开辟道路。即,达到了目前市面上大多数餐饮门店使用的智能ERP的功能水平和技术水准。


典型的信息流转流程如下:

  1. 用户在页面点菜,菜品数据与其所属桌号流传到后厨,显示在各档口iPad终端上。

  2. 后厨分为热菜、冷菜、点心等多个档口,各档口配备iPad供厨师查询信息和操作菜品状态。

  3. 以热菜制作流程为例,菜品的原始食材在切配部切配,由切配师傅在iPad上改变对应菜品状态为“已切配”。

  4. 打荷师傅从切配台获得切配完成的食材,交由炉灶师傅加工,并在iPad上改变菜品状态为“已制作”。

  5. 上菜服务员从打荷台获取制作完成的菜品,并在iPad上改变菜品状态为“已上桌”。

  6.  菜品经由餐梯到达餐厅前台,由餐厅服务员端到对应的客人餐桌。

  7. 用餐完毕后,用户付款,订单完结、数据存档。


后厨iPad上的数据展示示意如图:

640?wx_fmt=png

 二     问题分析

在以这个模式运行一段时间后,逐渐暴露出一系列的问题,制约运营效率,损害用户体验。

  1. iPad对于特定菜品的操作需要明确所属桌号,繁琐的查找增加了厨师额外的操作负担。

  2. 为了标识菜品与其所属桌号,菜品准备时需用夹子在餐盘上夹上标识桌号的小纸片。

  3. 这不仅增加了操作维护成本,还间接影响食品卫生安全。菜品制作的先后顺序完全由各个档口的厨师决定。难以通盘考虑当前运营状态和运营目标。


造成的问题

  • 菜品流转速度慢,厨师因为进行系统所需的额外操作降低了有效操作时间。

  • 菜品上桌体验难以保证,菜品上桌时间不可控,等待时间长。

  • 菜品上桌顺序不可控,主食、荤菜、素菜的相对顺序不稳定。

  • 夹子与纸片引入的额外操作降低效率,同时影响食品卫生安全。


总结,数字化引入的额外操作限制了厨师的操作效率,同时对数字化信息的深度应用能够进一步保障用户体验。


以增加数据驱动的智能化决策和减少不必要的额外操作为核心,我们提出的解决方案如下:

  1. 去除夹子和纸片,直到服务员出菜时再根据当前餐厅状态决定菜品所属桌号,因为菜品与桌号的绑定关系一般不影响菜品制作。 

  2. 取消打荷操作菜品状态为“已制作”的流程,历史数据显示该部分数据采集不准确。 

  3. 对于切配等菜品流转起点的档口,由系统决定当前进入制作流程的菜品种类,对应iPad上仅展示该菜品而屏蔽其它菜品信息。 

  4. 在出菜口配置摄像头,通过捕捉菜品画面识别菜品种类与数量,由系统分配菜品所属桌号。 

  5. 使用NFC低功耗墨水屏显示菜名与桌号的对应,辅助餐厅服务员上菜。


对于解决方案的分析:

  1. 菜品在制作过程中绑定桌号是不必要的,改变其为仅在制作完成需要出菜时匹配桌号。从而,纸片与夹子就变的不必要,我们彻底去除与其相关的操作。

  2. 菜品制作顺序完全由系统根据当前餐厅状态决定,厨师不再参与决策。保证对于餐厅运营各因素的整体量化考虑以及方案的可迁移性。

  3. 切配等菜品流转起点iPad仅展示系统决策当前需要处理的菜品,这既提高了厨师的查阅效率也避免了厨师绕过系统私自决策的行为。

  4. 使用摄像头识别制作完成的菜品数量与种类,由系统自动分配其桌号,出菜服务员仅需点击确认,无需其它额外操作。操作便捷,响应迅速。

  5. 使用NFC低功耗墨水屏提示服务员菜品与桌号的绑定关系,消除因为纸片去除后对上菜过程造成的影响。墨水屏可多次重复擦除使用,安全环保。


整个过程既降低了运营系统对于制作过程的侵入程度,去除纸片与夹子对厨师造成的不利影响,同时也提高了厨师对于iPad设备的操作效率,最后充分使用系统处理数据的能力,核心过程均由系统参与决策,保证决策合理和保障用户体验。


 三     顺序调度

菜品顺序调度是该解决方案的第一个要点。在大量点单数据到达后厨时,需由调度系统决定哪一个菜品首先进入制作流程;在多个菜品制作完成需要上桌时,由系统决定菜品与桌号的匹配关系。前一种情况存在于以切配为例的菜品制作起始档口;后一种情况存在于出菜口摄像头拍摄并识别菜品的阶段。

调度过程需要考虑当前餐厅的整体运行状态,依据事先定义的运营目标,使当前“最需要”的菜品优先进入制作流程或选择当前“最合理”的餐桌匹配当前已完成的菜品。

为了完成这一目标,首先定义描绘餐厅整体不满意程度的量化餐厅状态Cost_R如下图:


640?wx_fmt=png

具体说明:

  1. 量化的状态Cost_R数值越小说明当前餐厅的运行状态越好。

  2. 单个餐桌的不满意程度Cost_t由两部分的乘积组成,第一部分是该桌尚未完成菜品的百分比,第二部分是由其等待时间决定的函数。

  3. 说明2中的函数在该桌未上菜时呈指数增长,用以监督第一个菜的上菜时间尽可能短。

  4. 上菜后,30min之内该函数呈线性增长,30min之后的部分呈指数增长,用以监督等待时间长的餐桌尽可能快的获得菜品。

  5. 同时考虑(求加权平均)所有餐桌不满意程度的最大值与平均值,保证整体状态的准确描述。

  6. 当餐厅有人排队时,完成上菜的餐桌数量参与总体不满意度的计算(图中的Cost_q部分,其中q为当前惨餐厅排队人数)。

  7. 函数中的常数系数是人为定义的经验值,可根据实际情况调整。

  8. 其他运营目标如上菜顺序,可简单归结到单个桌的等待时间参与量化评估。举例来说,若主食先于荤菜上桌,则该桌等待时间人为增加15min,以此对该异常顺序进行惩罚。

  9. 其它新增的、临时的调度方案可依据说明8中的方法对评估函数进行调整。


调度方法

枚举当前条件下所有可执行的操作决策(一种菜品进入制作的决策或一种菜品与桌号的匹配方案),模拟操作完成后的餐厅状态,利用以上量化方法评估餐厅状态,选取使餐厅状态最优的决策作为最终决策。


餐厅状态的模拟包含两部分:

  1. 对于操作涉及的菜品,更改其状态为已上桌。

  2. 时间上,考虑制作该菜品所需要的耗时,并将其增加在每一桌的等待时间上。


决策透出

在切配部等菜品制作流程的起点,仅展示当前决策需要制作的菜品,厨师根据提示准备菜品,并对其进行操作。


在出菜口展示系统分配后菜品与桌号的对应,由传菜服务员点击确认后写入系统,并显示在NFC低功耗墨水屏上。


传菜口的识别与分配结果如图:

640?wx_fmt=png

 四     菜品识别


基于计算机视觉的菜品自动识别是该解决方案的第二个要点。

为了加快出菜口菜品与桌号的匹配,利用摄像头检测菜品的种类与数量,并由系统分配其对应的桌号。


采集标注数据共8249幅图片,菜品57种。因为训练图片和测试图片是相同角度、光照、设备采集的图片,一定程度的过拟合在我们的应用中是可接受的。

检测网络选型主要考虑该图像检测任务是低频度的、大目标的、需要定位准确(用于目标跟踪辅助)的,实验对比选取Faster-rcnn with ROI Align Layer网络结构。该网络在我们的数据集上能够达到93%准确率与89%召回率,同时提供10fps(with Tesla P4)的工作速度。

网络结构示意图:

640?wx_fmt=png

为了支持多个菜品的同时交互,需对检测到的菜品进行跟踪,我们使用光流法对目标内的角点进行跟踪,从而追踪菜品,实现视场内菜品已上桌和未上桌状态的保留。

特殊地,我们把图像上角点光流变化过于杂乱(由标准差判断)的情况视为被服务员遮挡摄像头,此时在一定时间内保留菜品的位置信息,待其重新出现后进行基于bbox iou匹配,还原菜品原始信息。

识别及跟踪结果演示如下(框上的第一行数字表示菜品种类,第二行数字表示追踪ID):

640?wx_fmt=gif

640?wx_fmt=gif


上菜服务员、摄像头与系统整体交互过程示意图如下:

640?wx_fmt=gif

识别后的菜品,依据“顺序调度”小节介绍的方法,匹配对应桌号。

最终菜品与桌号的对应信息写入NFC低功耗墨水屏,辅助服务员上菜,墨水屏如下:


640?wx_fmt=png

 五     其它情况


因为线下场景存在大量非标的场景以及考虑到系统本身可能存在的错误,我们考虑了非标准和异常情况,对其中大部分场景设计兜底方案,如:

  1. 催菜过多的菜品无论是否被决策制作,均直接显示在iPad上并提示,供人工操作介入。

  2. 菜品识别结果可编辑,可由服务员操作修改识别结果和菜品对应桌号。

  3. 有特殊需求(如微辣)的菜品恢复夹子与纸条,并在iPad上着重展示。(日常运营中该部分菜品占比小于5%)

  4. 对于特殊的桌号(如vip包厢),可设置vip模式,优先进入调度。


 六     应用结果


系统的应用目标希望提高厨师操作效率、加速菜品流转,同时尽力保障以等待时间为指标的就餐用户体验。

在应用本方案后,后厨运转过程中可见的有利改变包括: 

  1. 一般情况无需使用与维护夹子与纸片。

  2.  iPad上的信息展示更高效与简洁。 

  3.  打荷厨师无需操作iPad。 

  4.  传菜服务员完成一批菜品上菜,iPad操作最少仅需一次点击。 

  5.  菜品上桌顺序由统一的系统逻辑决策。

应用后,数据统计层面: 1. 高峰期热菜制作时间缩短13.01%。 2. 单桌首个菜等待时间缩短5.0%。 3. 最后一个菜等待时间缩短13.2%。


 七     未来展望


菲住布渴酒店于去年双十二开业,小厨完成了自己的历史使命在春节前夕结束了运营。受限于运营时间以及小厨整体运营定位的限制,本文所述的方案仍有许多细节和问题还需要打磨和解决。同时,营收维度的数据也没有取得预计的结果。考虑到小厨自身的运营定位和价格水平,其还远没有达到需要依靠厨房效率来拉动营收的程度,这制约了该解决方案的一部分效果。


其它一些可进行探索和挖掘的细节与问题:

  1. 餐厅状态量化评估方案仍需长时间的验证与调整,部分参数目前设置依赖于经验值,其有效性仍有探讨的余地。

  2. 对于小厨不时会进行的菜品更迭,为了降低新菜品对于菜品识别技术的影响,可以采用样本扩充与度量学习技术降低对于新菜品数据量的需求(目前我们已有一些尝试并取得初步结果)。

  3. 受限于现有通信技术和硬件水平,NFC低功耗墨水屏写入速度较慢,在最繁忙的用餐高峰,效率不如原始的纸质打单机。

  4. 应对线下大量非标准情况对系统的完备性提出的挑战,比如催菜、整桌催菜、打包、备注、延迟上菜等等,目前主要采用的还是如上文所述系统与人工兜底相结合的方案。

我们在小厨运营的其它方面也做了一些尝试,比如逃单预警(解决逃单问题)、客流预测(降低原材料无谓损耗)等,限于篇幅本文就不再展开介绍了。


 八     总结

小厨的后厨赋能项目,是菲住布渴酒店项目技术组第一次关于线下行业赋能的尝试,心得总结如下:

  1. 当前阶段,全面的数字化不可避免需要人工参与,但其操作不应过多影响从业人员正常操作。

  2. 基于数字化的技术手段辅助运营,对于效率的提升和用户体验的保障是可行和有效的。

  3. 图像等非结构化数据的利用需要更多的对应领域算法的支持,同时还必须要考虑到冷启动和增量数据对于应用算法的影响。

  4.  线下场景复杂,兜底方案必须完善和周全,同时可以充分发挥从业人员的能动性,解决一些低频的复杂问题。

  5. 线下赋能的应尽力使场景数字化、数字化决策、决策触达、效果反馈形成数据闭环,依据效果反馈不断迭代更新各个部件,使数字化更准确、决策更合理、触达更有效。本方案中,通过工作人员人工点击的数字化方法使该闭环存在一定程度的断裂,制约了系统的整体发展。这也是我们下一步的发力方向。

推荐阅读:

揭秘淘宝用户增长全链路项目管理

精心筹备30个月,阿里首家未来酒店FlyZoo Hotel今日开业

天猫智慧门店探索:大数据驱动的品牌零售赋能

640?wx_fmt=jpeg

扫描二维码

关注淘宝技术


  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值