本文定位：匿名客户案例。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
客户是一家区域食品加工企业，过去也有进销存，但批次追溯主要靠纸质记录。一旦客户投诉某批产品，质检、仓库和生产要翻好几本台账才能定位原料和出货去向。
二、关键症状：真正卡住业务的地方
我们第一阶段只做追溯闭环：原料入库生成批次，生产投料关联原料批次，成品入库生成生产批次，出库记录客户和渠道，质检报告挂到对应批次。
三、落地/救火路径：先收口，再扩展
系统上线前，团队最担心一线员工不会用。我们把扫码和下拉选择做到最少，关键岗位只处理自己那一步。质检上传报告、仓库扫码出入库、生产确认投料，其他字段由系统带出。
四、结果：能被管理动作验证的变化
上线后客户做了一次模拟召回，从成品批次反查原料批次、质检记录和出货客户，原来要半天，现在 15 分钟内能拿到清单。
五、给同行的建议：别先追求大而全
食品企业数字化不要只谈 ERP 功能，批次追溯是安全底线。先把这条线跑通，再扩展采购、库存、成本核算，组织更容易接受。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、这个案例里最关键的取舍
这家企业一开始也想“一次性上完整 ERP”，把采购、库存、生产、质检、销售、成本核算全部做完。但我们评估后建议先收窄到批次追溯，因为监管、客户投诉和召回演练是最硬的业务底线。只要这条链路没跑通，再漂亮的库存报表和成本报表都不可靠。
第一阶段我们没有追求字段大而全，而是只保留追溯必须字段：原料批次、供应商、入库日期、质检结果、生产批次、投料关系、成品批次、出库客户和出库日期。对一线员工来说，每一步只多做一个扫码或选择动作，系统自动带出上下游信息。这样上线阻力比完整 ERP 小很多。
项目验收也不是看“功能有没有开发完”，而是看能不能完成两次演练：从成品批次往前追原料和质检，从原料批次往后追受影响成品和客户。两次演练都能在规定时间内出清单，才说明追溯闭环真的成立。
八、追溯系统要先从批次规则开始
食品加工企业做追溯，很多人第一反应是上扫码设备和标签打印，但真正难的是批次规则。原料批次、生产批次、半成品批次、成品批次、出货批次之间如果没有稳定关系，扫码再多也只能记录动作，不能完成召回。
这个项目第一阶段先定义批次编码和流转规则：原料入库必须记录供应商、到货日期、检验状态和批次；生产投料必须关联工单和原料批次；成品入库必须关联生产批次；出货必须关联客户和成品批次。这样当某个原料批次出现问题时，系统能反查影响了哪些成品、发给了哪些客户。
为了降低一线负担，我们没有一开始要求所有节点都扫码，而是先在关键节点扫码：原料入库、投料、成品入库、出货。其他环节保留人工确认，等流程稳定后再逐步增加设备和标签。
九、合规系统验收要看召回演练
食品追溯系统不能只看页面是否能录入，而要做召回演练。随机选一个原料批次，要求在规定时间内查出供应商、检验记录、使用工单、成品批次、库存剩余、已发客户和责任人。如果查不出来，说明系统只是记录了数据，还没有形成追溯链。
企业也要定期复盘批次数据质量：有没有漏扫、有没有手工补录、有没有批次混用、有没有异常没有审批。追溯的价值不在平时多一张报表，而在出问题时能快速、准确、可审计地缩小影响范围。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
