凌晨 4 点，中央工厂的生产线已经开了两个小时，头一批吐司刚下烤箱，冷链车在门口排队。生产经理盯着排产表犯愁：今天 120 家门店的订货单加起来比上周同期多了 18%，但中央厨房的两条线满产也只能多做 12%，剩下的缺口要么挤掉门店端的可颂产能、要么让远郊那 20 家店缺货。门店端那边，店长还在用微信群报订货数，临期商品的报损单堆在抽屉里没录系统。这种场景，在 30 家店以上的烘焙连锁、茶饮品牌、快餐加盟体系里几乎每天都在上演——而每一处错配，都在吃利润。
烘焙和连锁餐饮的数字化，难点从来不是「装一套 ERP」，而是把中央工厂的生产节拍、冷链的温层与时效、门店的销售节奏、效期的不可逆性，捏到一套数据流里。这篇文章想帮你把这几件事拆清楚：中央工厂+门店到底卡在哪、市面上的标品方案各自能覆盖到哪一段、什么情况下必须走定制、AI 接进来又能解决什么——最后留一份选型决策表和踩坑清单，让你看完能直接拿去内部开会用。
一、中央工厂+门店模式的 5 个真痛点
走访过十几家连锁烘焙和茶饮品牌后，痛点其实高度一致，只是表现形式不同。把它们摊开：
| 痛点 | 表现 | 业务影响 |
|---|---|---|
| 订货预测不准 | 店长凭感觉报量，新品和促销日预测全靠拍脑袋 | 缺货损失销售机会，过量直接进报损 |
| 产能排产乱 | 中央工厂排产表 Excel 滚动维护，多线协同靠喊 | 加班费高、设备利用率低、临时插单挤掉计划单 |
| 冷链效期失控 | 出库批次没绑效期，门店收货也不验批次 | 临期商品没人盯，到期前 24 小时才发现 |
| 门店调拨低效 | A 店滞销 B 店缺货，调拨流程跨多个系统 | 同城调拨拖一两天，过了销售窗口 |
| 原材料追溯断 | 面粉、奶油、果酱的批次只在采购单里，进了配方就丢 | 出问题召回时只能整批下架，损失放大 |
这 5 个痛点的本质是同一件事：数据在不同环节用不同的颗粒度、不同的口径、不同的系统记录，每跨一道工序就丢一层信息。中央工厂用的是生产 BOM 视角，门店用的是 POS 销售视角，冷链用的是物流批次视角，到了财务又变成成本核算视角。一套真正打通的系统，要做的事就是让批次号、效期、温层、订单号在这四个视角之间不掉链。
二、中央工厂端：从订货预测到冷链出库
中央工厂这一侧，至少要管三件事：接订货单、排生产计划、按温层出库。
订货预测。门店报上来的订货量是预测的下限，不能直接当排产依据。成熟系统会用一套加权算法：门店历史日销+同期对比+天气+节假日+营销日历，给店长一个建议订货量，店长在这个基础上微调，总部再做产能侧的总量校验。如果总产能不够，系统按「直营优先、高毛利 SKU 优先、距离近的门店优先」做一轮平衡。这套逻辑落地的难度在配方和组件的层层展开——一款生日蛋糕可能由 12 个半成品组成，每个半成品又对应不同的产线和温层。
生产排产。烘焙的特殊性在于发酵、烘烤、冷却都有时间窗口，排产软件不能像离散制造那样按工时排队。常见做法是把生产线按温度区段切片，烤炉、醒发箱、冷却隧道作为受限资源，用启发式算法做日计划，留 15% 的弹性产能给临时插单。这块功能离 金属加工车间 MES 的有限产能排产 在思路上有共通之处，但烘焙的批次粒度更细。
冷链出库。出库环节决定了门店收到的是不是合格品。每个 SKU 绑温层属性（冷冻-18°C、冷藏 4°C、常温），出库时按车次拆单，配送路线规划要考虑温层兼容（冷冻和冷藏一般不混车）。每个外箱贴批次码+生产日期+保质期，门店收货扫一下就能写入门店库存表，效期信息自动跟着商品走。
三、门店端：智能订货、收货验签、效期管理、报损
门店端的系统设计哲学跟中央工厂完全不同——中央工厂追求精准，门店追求店员傻瓜化操作。一个新店员第二天就要上岗，系统不能让他记 50 个按钮在哪。
门店端日常动线：
开店 → 收货验签（扫码核对到货）→ 上架（自动写入门店库存）
→ 销售（POS 实时扣减）→ 临期预警（系统推送+POS 自动打标）
→ 报损/转促销 → 当日盘点 → 次日订货建议 → 店长确认提交
四个高频功能：
- 智能订货。系统根据近 4 周日销、近 7 天天气、本店缺断货历史、临期库存生成建议订货量，店长一键确认或调整。新品由总部强推，店长不能改。
- 收货验签。配送车到店，店员扫外箱码逐一核对，缺件、错件、批次问题当场拍照回传，纠纷处理走系统流程，避免事后扯皮。
- 效期管理。库存表里每个商品都带批次和效期，到达「临期阈值」（一般是剩余 1/3 保质期）时 POS 端推送提醒，自动加价格标签或进促销组合。
- 报损规则。临期未售出按预设规则报损，店长在 APP 上拍照+扫码确认，数据回流总部用于优化下一轮订货模型。
效期管理这件事，跟生鲜零售的逻辑一脉相承，可以横向参考 食品溯源系统的批次实践 里关于批次绑定的部分。
四、标品方案盘点：餐饮 SaaS+ERP+冷链的常见组合及断层
市面上能搜到的方案大概可以归成五类，每一类都有它能覆盖的那一段和盖不住的那一段：
| 方案类型 | 代表产品形态 | 能覆盖 | 断层在哪 |
|---|---|---|---|
| 餐饮 SaaS+收银 | 单店或小连锁场景的 POS+会员 | 门店收银、会员、外卖对接 | 没有中央工厂概念，配方和产能管不了 |
| 通用 ERP 加生产模块 | 偏制造业的 ERP 套生产 | 采购、生产、库存、财务 | 门店端弱，冷链温层和批次效期通常要二开 |
| 烘焙/连锁餐饮垂直 SaaS | 行业专用的中央厨房+门店一体化 | 中央工厂排产、配方、订货、报损 | 加盟体系的财务对账偏弱，跟自有冷链调度集成度低 |
| 自研拼凑 | 收银+进销存+Excel+企微群 | 单点功能可用、便宜 | 数据不通，到了 30 家店以上必崩 |
| 头部巨头方案 | 大型连锁集团选型 | 全链路、稳定、有方法论 | 价格起步 100 万+，小连锁套不上、续费曲线非线性 |
实践里最常见的「断层」有三个：①主数据不一致——POS、ERP、中央厨房三套商品档案，改一次价改三遍；②财务月结对不上——加盟门店的进货按批次价、销售按零售价，毛利核算口径不统一；③冷链车队跟订单系统两层皮——车到哪、温度多少、几点到店，系统里完全是黑盒。
如果你正在评估 SaaS 现成方案与定制开发的取舍，烘焙连锁这个场景的判断要比一般行业更难，因为门店端的标准化和中央工厂的非标性是同时存在的。
五、什么时候必须走定制？
不是所有连锁烘焙都需要定制。给一个简单的边界：
- 可以用标品的情况：直营为主、单一品类（纯烘焙或纯茶饮）、配送依赖第三方冷链、门店数在 50 家以内、SKU 不超过 100、配方相对稳定
- 必须考虑定制或深度二开的情况：
- 有自有冷链车队，需要把车辆、司机、温度监控、路线规划接进订单系统
- 多品类混合（烘焙+茶饮+轻食、或+中央厨房代工外销）
- 加盟+直营混合，且加盟体系有自己的财务、授信、保证金逻辑
- 跨区域多个中央工厂，需要按距离和产能动态分配订单
- 已经在用钉钉/企业微信做组织协同，需要把审批、考勤、报表全部嵌进去
定制不等于推翻重来。常见的路径是「标品 ERP 打底+门店端定制+冷链调度定制+总部数据中台」的组合拳。这种打法的工作量评估，可以参考 ERP 定制项目的成本拆解 和 自定义软件开发报价区间。
值得多说一句的是：过去三年 AI Coding 工具的普及，让定制开发的「人月单价」和「实施周期」都在下行通道。同样一套门店端 APP，两年前可能要 5 个研发干 4 个月，现在主力工程师配合 AI 辅助编码，能压到 3 个人干 2.5 个月。这意味着，过去因为预算原因只能咬牙用标品的中型连锁，现在可以重新算一笔账。
六、ERP+中央厨房+门店收银+冷链一体化架构
把上面这些拼起来，一套实际能落地的架构大致是这样的：
[主数据中心]
├─ 商品/配方/价格/温层/效期规则
└─ 组织/门店/加盟商/账套
│
├─[中央工厂 MES]──排产、领料、批次、出库
│
├─[ERP]──采购、库存、财务、成本核算
│
├─[冷链调度]──车队、温度、路线、签收
│
├─[门店端 APP/POS]──订货、收货、销售、报损、盘点
│
└─[BI+AI 中台]──销售分析、订货预测、效期预警、选址
四个集成边界要重点设计：
- 主数据 → 各业务系统：单向推送，禁止业务系统反写商品档案
- MES ↔ ERP：生产工单、领料单、入库单实时同步
- 冷链 ↔ ERP/门店端：出库单→运单→签收单形成闭环，批次和温度全程可查
- 门店端 → BI/AI 中台：销售明细 T+0 入仓，预测模型 T+1 更新
如果你的体系里已经在用钉钉，主数据中心和审批流可以直接长在钉钉上，参考 钉钉作为业务底座的数据同步架构 的做法，把组织、人员、流程的复用率拉满。
七、AI 接进来：四个能直接出业务结果的点
AI Agent 在烘焙连锁场景里不是噱头，几个落地点已经被反复验证：
| 场景 | AI 做什么 | 衡量指标 |
|---|---|---|
| 门店订货预测 | 用销售+天气+节假日+营销日历做 SKU-门店-日颗粒预测 | 缺断货率下降、报损率下降 |
| 效期临期预警 | 提前 24-72 小时预测哪些批次会临期，推促销组合 | 报损金额下降、临期转化率 |
| 滞销品分析 | 自动分群门店、识别长期低销 SKU，建议下架或调整配送 | SKU 数下降、平均周转加速 |
| 新店选址参考 | 用现有门店销售特征+人口/商圈/竞品数据做候选地评分 | 新店首年达店龄 1 年同店销售比 |
这几件事的共性是：数据闭环已经被门店端和 ERP 跑通，AI 只是在数据基础上加一层决策辅助。如果数据底座本身有问题（POS 数据脏、批次没绑死），AI 模型再强也救不了。所以做 AI 之前，先把 AI Agent 落地的前置条件 自检一遍。
另一个值得放进规划的是 AI 自动报表生成，可以把总部每天的「门店日报、SKU 销售榜、报损榜、加盟商对账单」全部从手工 Excel 解放出来，节省的不只是人力，更重要的是让数据被更频繁地看到。
八、选型决策表：四种典型情况的判断框架
| 你的情况 | 推荐方向 | 预算区间（年） | 实施周期 |
|---|---|---|---|
| 单店或 3 家以内 | 餐饮 SaaS+轻量进销存 | 1-3 万 | 1 个月 |
| 10-30 家直营、单品类 | 垂直 SaaS 中央厨房+门店端 | 8-20 万 | 2-3 个月 |
| 50 家以上、加盟+直营混合 | ERP+中央厨房+门店端组合，关键模块定制 | 50-150 万 | 6-12 个月 |
| 多品类、多中央工厂、有冷链车队 | 标品打底+定制深度二开+AI 中台 | 150 万+ | 12-24 个月 |
预算上下浮动的关键变量是 SKU 数、加盟门店占比、是否自有冷链、是否需要全国多仓。实施工作量一般占总预算 25%-40%，这部分别砍，砍了后面全是坑。
九、踩坑清单：少走 8 条弯路
按出现频率排序，给你 8 条最容易踩的坑：
- 主数据没有先行——先上 POS 再补 ERP，结果商品档案永远对不齐
- 配方没标准化就上系统——同一款产品三家中央工厂三个配方，BOM 没法落
- 门店端 UI 太复杂——按钮超过 15 个，店员永远只用 3 个，数据失真
- 批次和效期不强制——上线时为了快，把批次设成选填，半年后想加加不上
- 加盟商对账逻辑没想清楚——保证金、授信、账期、返利混着算，月底吵架
- 冷链温度只记录不报警——温度异常没人看，出问题召回都不知道哪车
- 报损单走纸质流程——店长收抽屉里月底才录入，数据回流总部已经过期
- AI 模型急于上线——历史数据只有 3 个月就训练预测模型，结果不如店长拍脑袋
这份清单本质上是在提醒一件事：连锁餐饮的数字化项目，70% 的失败原因不在系统本身，而在主数据治理和业务流程标准化没做扎实。这个规律在 连锁零售门店系统整合 里也反复出现，可以一并参考。
十、写在最后
烘焙和连锁餐饮的数字化不是一道选择题，而是一道排序题——先把哪一段打通、再补哪一段、什么时候叠 AI、什么时候考虑替换主系统，每一步都对应不同的预算和组织准备度。门店数到了 30 家以上，再用 Excel 和微信群撑下去的边际成本会指数级上升；门店数到 100 家以上，不做主数据治理和效期闭环，每年损失的利润够再开 10 家店。
判断自己处在什么阶段，最简单的办法是问三个问题：**报损率有没有超过 5%？店长每天花在订货和库存上的时间有没有超过 1 小时？总部要做一次跨门店分析需要协调几个系统？**这三个数字一摆出来，要不要动、动到什么程度，基本就清楚了。系统选型不是越贵越好、也不是越行业越好，关键是契合自己当下的规模和接下来 24 个月的扩张节奏——把这件事想透，剩下的就是执行问题。
