本文定位：匿名客户案例。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
客户是一家 120 人左右的零部件加工厂，原来用 Excel 管库存，采购靠微信群确认，车间领料靠纸单。问题不是没人努力，而是每个环节都有自己的账，月底盘点时永远对不上。
二、关键症状：真正卡住业务的地方
我们给出的第一版方案没有覆盖完整 MRP，也没有做复杂排产，而是先把物料档案、采购入库、生产领料、库存调整、盘点差异五个动作标准化。系统入口放在钉钉，仓库和采购用手机就能处理日常单据。
三、落地/救火路径：先收口，再扩展
项目最难的不是开发，而是统一物料编码。历史表里同一个轴承有 6 种写法，供应商名也经常混用。前两周我们和客户一起清洗高频 800 个物料，低频物料先保留旧编码，避免为了完美主数据拖垮上线。
四、结果：能被管理动作验证的变化
上线 6 周后，客户先拿到了三个结果：采购能看到可用库存，车间领料能追到工单，老板能看到库存金额和呆滞物料。后续再接生产进度、委外和质量检验，阻力小很多。
五、给同行的建议：别先追求大而全
这个案例说明，中小制造 ERP 的起点不一定是完整套件。先让物料流动可追踪，再谈成本核算和排产，成功率会高得多。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、为什么不先做完整排产
很多制造企业一谈 ERP 就想直接上排产、成本、委外、质检和条码追溯，但如果物料、库存和领料还没有统一，排产结果通常不可信。这个项目先做库存和物料流，是因为它们是后续所有模块的底座。没有准确库存，采购计划会错；没有工单领料，成本核算会错；没有物料编码，BOM 和报表都会错。
第一阶段验收标准也很朴素：采购能不能看到可用库存，仓库能不能追到出入库来源，车间能不能按工单领料，老板能不能看到呆滞和库存金额。只有这些基础动作稳定后，再做生产进度、委外和质检，团队才不会被复杂功能压垮。
八、第一阶段只做“三张表”的原因
这个项目最值得复用的地方，是一开始就把范围压到库存、采购、生产领料三张核心表。客户原本也想一次性做 BOM、排产、质检、委外、成本核算和条码，但我们和老板把问题拆开后发现，所有后续能力都卡在同一个底座：物料编码不统一、库存账不可信、领料没有工单来源。
如果这三个问题不解决，排产会根据错误库存做计划，成本核算会把材料消耗算错，质检和委外也无法追到批次。所以第一阶段的验收没有追求“功能很多”，而是追求四个问题有答案：这个物料当前可用库存是多少、这次采购为什么下单、这次领料对应哪个工单、盘点差异由谁确认。
落地时我们把高频物料先清出来，给每个物料确定名称、规格、单位、默认供应商和安全库存。低频物料暂时不强行清洗，避免主数据工作拖慢上线。这样做看起来不完美，但能让仓库和采购先在真实业务里跑起来，再根据使用情况逐步补齐。
九、制造企业上 ERP 的验收口径
中小制造企业第一阶段不要用“系统模块是否齐全”验收，而要看业务动作有没有闭环。采购员下单前能不能看到库存和在途；仓库入库时能不能关联采购单；车间领料时能不能关联工单；月底盘点差异能不能追到调整原因；老板看库存金额时能不能区分正常库存、呆滞库存和待检库存。
这些口径跑顺以后，再接生产进度、委外加工、质量检验和成本核算，系统才有可信数据。否则功能越多，错误传播越快。这个案例的核心不是“少做”，而是先把最小闭环做对。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
