COLL-001: 需求上报与确认

优先级: 🔴 高 (18.0分) | 技术复用度: 80% | 实施周期: 2周

客户原话

"每周五要统计下周的需求,20个店长要在微信群里报数,有的报了有的忘了,我要一个个催,汇总完还要打电话确认,经常出错。有时候店长报100份,实际只卖了70份,浪费了30份;有时候报少了,不够卖,顾客投诉。"

—— 某连锁餐饮中央厨房计划员

业务场景描述

典型场景

场景1: 周度需求上报

• 每周五下午5点前,各卫星厨房要上报下周的需求
• 20个店长在微信群里报数,格式不统一,容易看错
• 计划员要一个个复制到Excel,汇总要1小时
• 有的店长忘记报,要打电话催,经常到晚上8点才收齐

场景2: 需求确认

• 汇总完需求后,要逐个打电话确认
• "你报的红烧肉是100份还是10份?"
• "你周三要50份,周四要80份,对吗?"
• 20个店长确认一遍,要1小时

场景3: 临时需求调整

• 周一早上,店长突然说"今天有团餐,要加50份"
• 打电话给计划员,计划员再打电话给生产部门
• 来回沟通,耽误时间,经常来不及生产

核心痛点

1. 上报混乱 - 微信群报数,格式不统一,容易遗漏
2. 汇总耗时 - 手工复制粘贴,汇总要1-2小时
3. 确认繁琐 - 逐个打电话确认,耗时长
4. 数据不准 - 店长凭感觉报数,经常报多或报少
5. 临时调整难 - 临时需求沟通成本高,响应慢

业务流程图

整体流程

graph TB
    A[需求上报周期开始] --> B[系统推送提醒]
    B --> C[卫星厨房店长]

    C --> D{上报方式}
    D -->|移动端| E[打开需求上报表单]
    D -->|PC端| F[登录系统填写]

    E --> G[填写需求数据]
    F --> G

    G --> H[系统智能提示]
    H --> I[参考历史数据]
    H --> J[参考天气预报]
    H --> K[参考节假日]

    I --> L[店长确认提交]
    J --> L
    K --> L

    L --> M[系统自动汇总]
    M --> N[异常检测]

    N --> O{是否异常}
    O -->|是| P[标记异常项]
    O -->|否| Q[正常数据]

    P --> R[推送给店长确认]
    R --> S{店长确认}
    S -->|修改| G
    S -->|确认无误| Q

    Q --> T[中央厨房计划员审核]
    T --> U{审核结果}
    U -->|通过| V[生成生产计划]
    U -->|驳回| W[推送给店长修改]
    W --> G

    V --> X[推送确认通知]
    X --> Y[店长查看确认结果]

需求上报流程

graph LR
    A[店长登录] --> B[选择上报周期]
    B --> C[系统展示菜品清单]

    C --> D[逐个填写需求量]
    D --> E{智能提示}

    E --> F[上周实际销量]
    E --> G[最近4周平均值]
    E --> H[同期历史数据]

    F --> I[店长参考填写]
    G --> I
    H --> I

    I --> J[系统计算总量]
    J --> K{异常检测}

    K -->|波动>30%| L[黄色预警提示]
    K -->|波动>50%| M[红色预警提示]
    K -->|正常| N[绿色正常]

    L --> O[店长确认或修改]
    M --> O
    N --> P[提交需求]
    O --> P

    P --> Q[系统记录提交时间]
    Q --> R[推送给计划员]

需求汇总与确认流程

graph TB
    A[所有店长提交完成] --> B[系统自动汇总]

    B --> C[按菜品汇总]
    B --> D[按日期汇总]
    B --> E[按厨房汇总]

    C --> F[生成汇总报表]
    D --> F
    E --> F

    F --> G[异常数据标记]
    G --> H{异常类型}

    H -->|未提交| I[催办提醒]
    H -->|数据异常| J[确认提醒]
    H -->|逾期提交| K[标记逾期]

    I --> L[推送给店长]
    J --> L
    K --> L

    L --> M[店长处理]
    M --> N[重新汇总]

    N --> O[计划员审核]
    O --> P{审核结果}

    P -->|通过| Q[生成生产计划]
    P -->|需调整| R[与店长沟通]

    R --> S[店长修改]
    S --> N

    Q --> T[推送确认通知]
    T --> U[店长查看]

临时需求调整流程

graph LR
    A[店长发起临时需求] --> B[填写调整信息]
    B --> C[调整原因]
    B --> D[调整数量]
    B --> E[需求时间]

    C --> F[提交申请]
    D --> F
    E --> F

    F --> G[推送给计划员]
    G --> H{计划员判断}

    H -->|可满足| I[调整生产计划]
    H -->|无法满足| J[协调其他厨房]
    H -->|拒绝| K[说明原因]

    I --> L[确认调整]
    J --> M{协调结果}
    M -->|成功| L
    M -->|失败| K

    L --> N[推送给店长]
    K --> N

    N --> O[店长查看结果]

业务规则详解

规则1: 需求上报周期

标准周期:

• 每周五下午5点前,上报下周(周一至周日)的需求
• 提前3天上报,给生产和采购留出时间

上报截止时间:

• 正常截止: 周五下午5点
• 延迟截止: 周五晚上8点(标记为逾期)
• 超过8点未提交,系统按历史数据自动生成

提醒机制:

• 周四下午3点: 第一次提醒
• 周五上午10点: 第二次提醒
• 周五下午4点: 最后提醒(未提交的店长)
• 周五下午5点: 催办提醒(未提交的店长)

规则2: 智能提示规则

历史数据参考:

建议需求量 = (上周实际销量 + 最近4周平均值) / 2

示例:
菜品: 红烧肉
上周实际销量: 100份
最近4周平均值: 120份
建议需求量 = (100 + 120) / 2 = 110份

节假日调整:

节假日系数:
- 春节/国庆: +30%
- 五一/端午/中秋: +20%
- 周末: +10%
- 工作日: 基准值

调整后需求量 = 建议需求量 × 节假日系数

天气影响:

天气系数:
- 雨天: 外卖+15%, 堂食-10%
- 高温(>35℃): 冷饮+25%, 热菜-15%
- 低温(<5℃): 热菜+20%, 冷饮-30%

调整后需求量 = 建议需求量 × 天气系数

规则3: 异常检测规则

波动检测:

波动率 = |本次需求 - 建议需求| / 建议需求 × 100%

判断:
- 波动率 < 30%: 绿色正常
- 30% ≤ 波动率 < 50%: 黄色预警,提示店长确认
- 波动率 ≥ 50%: 红色预警,必须填写原因

示例:

菜品: 红烧肉
建议需求: 110份
店长填写: 180份
波动率 = |180 - 110| / 110 × 100% = 63.6%

判断: 红色预警
提示: "需求量比建议值高63.6%,请确认是否正确,并说明原因"

异常类型:

1. 需求为0 - 该菜品本周不需要,需确认
2. 需求过高 - 波动率>50%,需说明原因
3. 需求过低 - 波动率<-50%,需说明原因
4. 连续多周为0 - 该菜品连续3周需求为0,建议下架

规则4: 临时需求调整规则

调整时机:

• 提前24小时: 可以调整,不影响生产
• 提前12小时: 可以调整,但需加急生产
• 提前6小时: 协调其他厨房调配
• 少于6小时: 一般无法满足

调整幅度:

• 增加<20%: 自动通过
• 增加20-50%: 计划员审批
• 增加>50%: 计划员+生产经理审批
• 减少任意幅度: 自动通过

调整原因:

• 团餐订单
• 活动促销
• 天气突变
• 其他(需说明)

规则5: 需求确认规则

自动确认:

• 绿色正常数据,自动确认
• 店长按时提交,数据无异常,自动确认

人工确认:

• 黄色预警数据,店长确认后通过
• 红色预警数据,店长说明原因后,计划员审核

确认反馈:

• 确认通过: 推送"需求已确认,将按此生产"
• 确认驳回: 推送"需求异常,请修改后重新提交"
• 部分确认: 推送"部分菜品需求已调整,请查看"

数据流转

输入数据

1. 历史销售数据 (来自卫星厨房)

   • 上周实际销量
   • 最近4周销量
   • 同期历史销量

2. 菜品数据 (来自 PLAN-002)

   • 菜品清单
   • 菜品分类
   • 菜品状态(在售/停售)

3. 节假日数据 (来自日历系统)

   • 节假日日期
   • 节假日类型
   • 节假日系数

4. 天气数据 (来自天气API)

   • 未来7天天气预报
   • 温度、降雨概率
   • 天气系数

输出数据

1. 需求汇总 (给 PLAN-001)

   • 按菜品汇总的需求量
   • 按日期汇总的需求量
   • 按厨房汇总的需求量

2. 生产计划 (给 PROD-001)

   • 生产菜品清单
   • 生产数量
   • 生产时间

3. 配送计划 (给 DIST-001)

   • 配送目的地
   • 配送菜品和数量
   • 配送时间

关键业务问题

问题1: 如何提高店长上报的准确性?

场景:

• 店长凭感觉报数,经常不准确

解决方案:

1. 智能提示: 提供历史数据参考,减少盲目估计
2. 异常预警: 波动过大时提醒,避免明显错误
3. 数据反馈: 每周反馈实际销量vs上报需求,让店长看到差距
4. 考核机制: 需求准确率纳入绩效考核

问题2: 如何处理店长不按时上报?

场景:

• 有的店长经常忘记上报,或者拖到最后一刻

解决方案:

1. 多次提醒: 提前2天、1天、当天多次提醒
2. 催办机制: 未提交的店长,单独推送催办
3. 自动生成: 超过截止时间,系统按历史数据自动生成
4. 考核机制: 按时提交率纳入绩效考核

问题3: 如何处理需求波动大的情况?

场景:

• 某些厨房的需求波动很大,难以预测

解决方案:

1. 分析原因: 是促销活动、团餐订单、还是其他原因
2. 提前沟通: 如果有大型活动,提前告知计划员
3. 弹性生产: 预留10-20%的弹性产能
4. 应急调配: 建立厨房间的调配机制

问题4: 如何处理临时需求?

场景:

• 店长临时要加单,但生产来不及

解决方案:

1. 提前量要求: 至少提前24小时申请
2. 加急通道: 紧急情况下,协调加急生产
3. 厨房调配: 从其他厨房调配库存
4. 拒绝机制: 实在无法满足,说明原因,拒绝申请

实施要点

第一步: 设计上报表单

表单字段:

1. 上报周期(周一至周日)
2. 菜品清单(从菜单库获取)
3. 每日需求量(可按天填写)
4. 备注说明

表单优化:

• 移动端适配,方便店长随时填写
• 支持批量复制(如周一到周五需求相同)
• 支持快速填写(一键填写建议值)

第二步: 配置智能提示

需要准备的数据:

1. 历史销售数据(至少4周)
2. 节假日日历
3. 天气API接口
4. 各菜品的基准需求量

第三步: 设置提醒和催办

提醒配置:

1. 提醒时间(周四、周五)
2. 提醒方式(钉钉/企微/短信)
3. 提醒对象(未提交的店长)

第四步: 培训店长

培训内容:

1. 如何登录系统
2. 如何填写需求
3. 如何查看智能提示
4. 如何处理异常预警
5. 如何申请临时调整

预期收益

量化指标

指标	当前	目标	提升
需求汇总时间	2小时	10分钟	缩短92%
需求准确率	70%	85%	提升15%
按时提交率	60%	95%	提升35%
确认沟通时间	1小时	10分钟	缩短83%
临时调整响应时间	2小时	30分钟	缩短75%

业务价值

1. 效率提升 - 计划员每周节省3小时,可以做更多分析工作
2. 准确性提升 - 智能提示帮助店长更准确地预测需求
3. 沟通成本降低 - 减少电话沟通,提高协同效率
4. 数据沉淀 - 积累需求数据,用于后续分析和优化

成功案例

案例: 某连锁餐饮中央厨房

背景:

• 20个卫星厨房,每周需求上报
• 微信群报数,汇总要2小时
• 需求准确率只有65%,经常浪费或缺货

实施效果:

• 需求汇总时间从2小时降至10分钟
• 需求准确率从65%提升至82%
• 按时提交率从60%提升至92%
• 计划员每周节省3小时,可以做更多数据分析

客户反馈:

"以前每周五都要催店长报数,催到晚上8点。现在系统自动提醒,店长在手机上就能填,10分钟就汇总完了。最重要的是,系统会提示历史数据,店长报得更准了。"

相关场景

• PLAN-001: 周度生产计划制定 - 需求数据的使用方
• PLAN-002: 菜单标准化管理 - 菜品清单来源
• DIST-001: 配送计划与路径优化 - 配送计划依据
• COLL-002: 库存同步与可视化 - 库存数据参考
• COLL-003: 应急调配与补货 - 临时需求处理

常见问题

Q1: 如果店长不会用系统怎么办?

A:

1. 提供详细的操作手册和视频教程
2. 安排专人培训,一对一指导
3. 设置客服热线,随时解答问题
4. 界面尽量简单,减少操作步骤

Q2: 如何处理新开的卫星厨房?

A:

• 新厨房没有历史数据,无法智能提示
• 可以参考同类型厨房的数据
• 或者让店长手工填写,运营1个月后再启用智能提示

Q3: 如何处理季节性菜品?

A:

• 季节性菜品(如火锅、冷饮)的需求波动大
• 建议在系统中标记为"季节性菜品"
• 使用同期历史数据,而不是最近4周数据

Q4: 如何与现有系统集成?

A:

• 如果有ERP或订单系统,优先从这些系统获取销售数据
• 需求数据可以推送回ERP,或者在本系统中管理
• 通过API接口实现数据同步