指标字典
每个指标注明业务问题、分子与分母、统计周期、排除项、更新时间和责任人。例如实际供餐份数、下单份数与支付笔数分别统计；退款、取消和测试记录要有一致处理规则。
CAPABILITIES
餐饮大数据
以真实记录、统一口径和责任闭环，支持餐饮经营判断。具体数据范围、系统接入与分析能力须按项目确认。
数据底座
餐饮数据的价值在于解释现场并支持行动。先围绕菜单、订餐、采购、库存、生产、供餐、结算和反馈确定数据来源，明确每项记录由谁产生、何时发生、如何核对，再选择适合的采集和展示方式。共享的是口径与协作规则，不要求不同系统默认共用数据库。
项目方案还应明确菜单营养与过敏原信息、预约取餐、餐补权益以及验收、温控、消毒、留样和配送记录如何关联。数据清单应列明来源系统或表单、业务负责人、更新频率、必填字段、使用目的与保存要求。导入、接口或手工记录均要检查缺失、重复和延迟。信息不完整时保留“未采集”或“待核实”状态，不能填零或补造记录，以免误导经营判断。
统一口径
将组织、场地、餐厅、档口、餐次、菜品、原料与供应商分别建立稳定编码和名称对照。记录规格、单位换算、有效期及修改责任人，使同名异物、同物异名和历史版本能够被区分。主数据变更应先评估报表与结算影响，再确定生效日期，不能用直接覆盖抹掉历史口径。
可比分析
跨项目比较时同时列出营业天数、服务餐次、人员范围与外部变化。剩餐应区分未售出、加工损耗和餐后剩余；成本比较先统一含税范围、计量单位和分摊方法。
身份权限
先区分就餐资格、业务操作权限和管理查看范围。员工、学生、访客等身份只提供完成服务所必需的信息；现场人员、项目管理者与财务人员按职责访问不同范围。账号开通、岗位变动、临时授权与离场停用需要明确发起人、批准人和生效时间。
个人信息使用应说明目的并具备相应处理依据。对健康、生物识别及未成年人等敏感信息另行评估必要性和保护条件；能够用汇总数据回答的问题，不必展示个人明细。接口授权、操作日志、导出控制和保存期限需在项目方案中确定，本页不代表统一身份认证或人脸识别系统已经接入。
账实核对
采购订单、到货验收、库存收发、领用生产与费用结算需要建立对应关系。核对先检查品名、规格、单位、数量、单价和时间，再解释差额来自短收、退货、替换、报损或跨期入账。餐饮订单、支付、退款和餐补分别核对，避免把支付成功直接等同于已经供餐。
对账以原始记录和批准凭据为依据。重复导入应识别同一业务单据；更正保留原值、原因、操作者和批准记录。无法解释的差异进入待处理清单，由采购、现场或财务责任人核查后再确认，不用自动平账掩盖问题。
业务关系
从经营问题出发理解数据
菜品销量、库存成本与时段运营提供不同角度的信息。分析需要先统一口径，再支持经营调整，并以复盘检视调整后的变化。
运营决策
现场需要的是能够回答问题的视图：高峰集中在哪个时段，哪些菜品容易缺货，剩余与生产计划有什么关系，配送延迟影响了哪些餐次。以餐厅、餐次、菜品和时间为维度组织信息，再由负责人结合班次、天气、活动和临时安排判断调整方式。
预测功能若进入项目，应先说明输入数据、适用条件和人工修正机制，并与明确基准比较。历史不足、节假日或菜单变化时降低对结果的依赖。图表用于辅助判断，采购、菜单和人员调整仍需业务确认；没有实际验证的算法能力和改善比例不写成既有成果。
交付与维护
数据方案可按范围交付来源清单、主数据字典、指标说明、核对规则、角色权限表、异常处理流程和报表样例。验收关注记录能否追到来源、相同输入是否得到同口径结果、越权访问是否被阻止、差异是否有人跟进。上线后约定字段与接口变更流程，明确停机时的手工记录和补录方式。食品安全记录异常应及时交由相应责任人处理，不能等待经营报表周期结束。
行业参考
个人信息保护边界参考官方法律原文。本文的数据组织和核对流程为可按项目设计的方法，不证明任何具体系统、模型、接口或客户数据已经接入。