精简菜单先做依赖表：两道菜可能同名原料，却不共享同一套动作

菜单精简不是按销量从低到高删除菜品，也不是把使用“鸡肉”“番茄”的菜自动归为共享原料。每道菜都要连接到具体原料规格、预处理、炉位、人员、器具、洗消和服务时段，再看删除、合并或改排程能否真正减少依赖。低频菜如果使用全店已有原料与工具，可能几乎不增加复杂度；高频菜若需要专用腌料、专门容器和高峰唯一炉位，反而可能制造更多库存与任务冲突。

Alto-Shaam的原文把简化菜单、共用原料、库存控制与多功能设备作为降低厨房运营成本的一般建议。[1]这是厂商营销语境下的问题清单，不证明任何门店采用后一定节省成本，也不证明某款设备能替代现场验证。下文的依赖表和假设例由作者构造，用来判断下一步，而不是宣称已经取得经营效果。

销量表旁边必须有一张依赖表

先为每道候选菜建立节点：销售时段、原料SKU、包装与处理状态、配方版本、预处理、存放位置、加热任务、独占炉位、锅具、服务器具、清洗、消毒、干燥和存放。两道菜连接同一节点，才可能形成共享；只在节点名称上相似，却使用不同规格、不同任务或不同时间窗，不是共享。

下面是作者构造的两道菜示例，所有名称与时间都不代表真实门店。

依赖	菜A：香草鸡饭	菜B：辣味鸡卷	是否真正共享
鸡肉	原料SKU-J1，未腌制	原料SKU-J2，供应商预腌	否；名称相同但规格和成分不同
番茄	鲜番茄T1，切丁	同一T1，同一切丁规格	在批次与用量核对后可能共享
预处理	上午统一切配	到货后独立解包与分装	否
炉位	11:00—11:20占炉位1	11:10—11:30占炉位1	否；高峰重叠冲突
器具	通用浅盘与夹具	专用压卷板与带槽托盘	部分共享
收班	常规周转	专用器具另洗、另干、另存	否

这张表揭示两件事。第一，两个菜都写“鸡肉”并不能合并库存，因为一个是未腌制SKU-J1，一个是供应商预腌SKU-J2；配料、加工状态和适用提示可能不同。第二，鲜番茄T1看似可以共享，也要核对切型、配方用量、批次与食品处理条件，不能只把采购名称合并。

依赖表还要显式写出前后连接：原料指向预处理，预处理指向设备任务，设备任务指向成品与器具周转。若删除菜B只少买一个鸡肉SKU，却留下同一高峰的其他炉位任务，设备冲突不一定消失；若菜B的专用器具因此不再使用，收班动作可能减少。只有沿连接关系重算，才能知道复杂度实际移到哪里。

共享原料必须共享规格、状态和允许用途

判断原料共享时，不问“是不是同一种食材”，而问“是否是同一受控对象”。对供应商、产品码、包装、净含量、处理状态、配方成分、批次、存放、领用、切型与替代条件逐项核对。任何影响菜品声明、食品处理或操作的差异，都不能被“同名”覆盖。

例如菜A要求未腌制鸡肉按门店配方处理，菜B使用供应商预腌鸡肉。若把两者合成一个SKU，可能同时改变配方、前厅成分答复、人员动作和占用时间。即使感官上接近，也不是采购人员可单独批准的共享。真正可共享的节点应记录适用菜品、用量、峰值需求、失效条件和批准角色；原料版本变更时重新核对。

共享也不等于所有菜同时领取大包装。集中采购可能减少SKU，却增加开封后的分装、标签、库位与剩余管理。依赖表应同时显示采购包装与实际使用单位，查看是否为了少一个产品码而增加更多转换动作。没有现场数据时只把它列为待验证方案，不预写节省金额。

炉位按“完整占用”而不是加热分钟绘制

假设菜A在11:00进入炉位1，加热至11:15，移出与清场到11:20；菜B原计划11:10进入同一炉位，加热至11:25，清场到11:30。若表中只写有效加热十五分钟，两个任务看似都很短；放到共同时间轴后，菜B至少从11:10等待到11:20。这个等待是排程冲突，不证明必须删除菜B。

先测试不改变菜品的解决路径：调整批次大小或启动时点、把能提前完成的准备移出高峰、使用已经确认适用的另一炉位，或调整可兑现的服务时间。每条路径要保留原料、食品过程、人员与器具条件，不能为了图上不重叠而压缩未经验证的加热或清场。

排程表除了设备，还要显示同一位员工、同一锅具和同一通道。设备空闲但操作员正在处理另一批，任务仍不能开始；两个炉位都有空位但共用唯一锅具，也会排队。这样才能区分冲突来自菜品本身、批量设计还是排程，而不是把所有等待都归咎于“菜单太多”。

顾客替代要记录真实选择，不能用内部相似代替

厨房认为菜A和菜B都是鸡肉主食，顾客未必认为两者可替代。短期试验若暂停售卖菜B，只记录在菜B有效展示与销售时段内实际发生的请求：原菜成交、明确改选菜A、选择其他菜、取消、等待或无法确认。没有询问、没有订单或无法观察的顾客，不推断其偏好。

顾客离店或取消不能算替代成功；明确改选菜A也要检查菜A的等待、缺货和剩余是否改变。否则菜单精简只是把需求和废弃转移到另一道菜。价格、促销、展示位置、天气、团体订单和人员异常单列，短期相关性不写成长期偏好或因果。

测试前写停止条件。例如暂停售卖后取消、缺货或等待超过事先批准范围，或替代菜出现食品处理与成分信息缺口，就恢复原方案并保留发生记录。回退需包括菜单、后厨任务和前厅话术的同一版本，不只是重新把菜名放回页面。

洗、消、干燥、存放要分开算

复杂度常被从高峰生产转移到收班。器具周转至少拆成收集与预处理、清洗、消毒、干燥或冷却、检查、存放和再次取用。不同环节可能使用不同设施、人员与空间；机器程序结束也不等于器具已经干燥、检查并回到可用位置。

环节	记录起止	关键对象	不应使用的替代说法
清洗	入洗至污物去除步骤结束	器具、装载、程序、返工	“机器有容量”
消毒	按适用流程的消毒阶段	程序、条件、批次、异常	“洗过所以已消毒”
干燥/冷却	出机至达到后续处理条件	摆放、时间、空间、再污染控制	“程序结束即可叠放”
存放	检查完成至下次取用	位置、保护、数量、可达性	“柜里放得下”

若菜B使用专用压卷板，删除它可能减少一类器具；但要看该器具是否与其他菜共享，实际每峰值有多少件，是否造成额外装载、重洗、干燥占位和存放。厂家标称容量或烘干描述只能作为具体型号进一步核查的参数，不能覆盖完整周转，也不能证明总动作减少。没有正式说明书与现场试验时，使用通用设备类别比列一个无关型号更诚实。

返工尤其不能消失。器具因装载不当需要重洗，程序中断需要重新处理，或出机后仍有残留，这些都应保留起止和原因。若精简菜单后器具种类减少，但每次装载更拥挤、返工增加，复杂度未必下降。收班时间也要与清洁结果和次日可用状态一起看，不能只看员工打卡时点。

去留决定同时写减少项、增加项和未解决项

每个候选方案形成一行决策账。写清删除或合并的菜品版本，预计减少的原料SKU、库位、炉位冲突、专用器具和收班动作；同时写新增的集中分装、替代菜压力、标签、培训或排程动作；最后列未解决的顾客需求、食品信息、设备与洗消条件。

对菜B的假设例，可能得到的有限结论是：“停售菜B可减少SKU-J2和专用压卷板，并取消菜B原计11:10进入炉位时与菜A占用至11:20的冲突；但当前观察不足以证明顾客会稳定改选菜A，也没有证据证明菜A本身的等待减少；番茄T1峰值和菜A剩余仍需继续观察。”这比“删掉低频菜可以降本”更可复核，也允许结果反向支持保留菜B。

决策先限定到明确门店、时段和菜单版本，并设复审日期与回退条件。菜单、原料规格、设备、人员或服务渠道变化时，依赖表随版本更新，不把过期表当永久事实。最终判断不是哪道菜节点最多，而是哪个方案在保持必要食品与服务边界的同时，确实减少了总依赖和失败动作；没有证据时，结论就是继续验证，而不是用厂商宣传或设备名称填空。

参考资料

• Reduce Operating Costs in The Kitchen