简介：这份资源是面向制造业信息化从业者、MES 项目需求人员与实施顾问的用户需求说明书，围绕制造执行系统的术语体系与业务模块展开，帮助读者理解 MES 与 ERP 的衔接逻辑及现场管控要点。文档系统梳理了 ERP、MES、BOM、PPR、PS、POM、MM 等基础术语，并延伸至工单管理、工艺路线、ESOP、FPY/FTY、SN 与 PN 追溯、OEE 设备效率计算，以及不良现象、不良原因、维修动作与责任归属等质量管理维度，同时覆盖工单发料清单、供应商、条码编码规则、原材料仓与线边仓等物料管理内容。资源包共 1 个 docx 文件，约 14.53MB，正文达 119 页，目录结构完整，便于按章节检索。目前已有 743 人学习下载，适合需要撰写需求文档、梳理业务流程或开展 MES 选型与实施的中高级读者参考。

1. 119 页 MES 用户需求说明书，到底在写什么

接手一个 MES 项目，最怕的不是代码写不出来，而是需求文档翻到第 30 页就发现前面埋的坑已经填不上了。制造执行系统（MES）的用户需求说明书动辄上百页，很多人拿到手第一反应是「这么厚，从哪看起」。我见过太多团队把这份文档当成验收清单，结果上线三个月后车间还在用 Excel 补录数据。这份 119 页的说明书，本质上不是功能列表，而是一份把车间物理世界翻译成软件逻辑的契约。它要解决的核心问题是：当 ERP 下达工单之后，从物料上线、工序流转、设备参数采集、质量判定到成品入库，这一整条链路里每一个动作由谁触发、数据存在哪、异常怎么处理。适合谁看？适合正在做 MES 选型的技术负责人、准备基于若依框架搭 MES 的后端开发、以及被甲方需求文档折磨过的实施顾问。如果你只关心「有没有报工功能」这种粒度，这份文档会让你在联调阶段付出代价。

2. 从 119 页里拆出可落地的功能域：先画数据流再谈模块

2.1 为什么不能按章节顺序读需求说明书

拿到一份 119 页的 MES 用户需求说明书，最常见的翻车方式是从第一页按顺序读到最后一页。文档的章节编排往往按部门职能划分——生产管理、质量管理、设备管理、物料管理，每个部门只关心自己那一块。但 MES 的落地逻辑是反过来的：数据流是横向贯穿的，工单从 ERP 同步过来，经过排产、派工、报工、质检、入库，每个环节都在修改同一张工单的状态。如果按章节顺序读，你会把工单状态机拆散在五个章节里，最后拼不起来。

我一般会先做一件事：把文档里所有出现「状态」「触发」「回写」「同步」的段落抽出来，画一张工单生命周期图。这张图不需要多漂亮，用纸笔就行，关键是标清楚每个状态变更的触发条件。比如「已派工」变成「生产中」是操作工点击开始按钮，还是设备首件信号自动触发？「生产中」变成「待检」是报工数量达到工单数量，还是操作工手动提交？这些细节在文档里可能分散在不同章节，但它们是联调时扯皮最多的地方。

提示：如果文档里对状态流转的描述有矛盾，以生产管理章节为准，质量章节的判定逻辑通常只做分支条件，不改变主状态机。

2.2 用若依框架搭 MES 时，需求文档里的哪些字段直接决定表结构

基于若依框架做 MES 是现在很常见的选型，若依自带用户、角色、菜单、部门、字典这些基础表，能省掉大量脚手架工作。但 MES 的核心表——工单表、工序表、报工记录表、质检记录表——必须自己设计。需求说明书里对字段的描述往往藏在功能描述的文字里，不会给你一张完整的 ER 图。

我通常按这个顺序从文档里抠字段：先找「工单」相关的所有描述，把工单号、产品编码、计划数量、已完工数量、工单状态、计划开始时间、计划结束时间、实际开始时间、实际结束时间、优先级这些字段列出来。然后找「工序」相关描述，确定工序是挂在工单下还是挂在产品工艺路线上。这一步很关键：如果工序挂在产品上，工单开工时需要根据产品编码复制一份工序快照；如果工序直接挂在工单上，排产逻辑会简单很多，但工艺变更时历史工单会受影响。

-- 工单主表：字段来源是需求文档中「生产工单管理」章节 CREATE TABLE mes_work_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '工单号，文档要求全局唯一', product_code VARCHAR(64) NOT NULL COMMENT '产品编码，关联物料主数据', plan_qty DECIMAL(12,3) NOT NULL COMMENT '计划数量，支持小数', done_qty DECIMAL(12,3) DEFAULT 0 COMMENT '已完工数量，报工累加', status TINYINT DEFAULT 0 COMMENT '0草稿 1已下达 2生产中 3待检 4完工 5关闭', plan_start DATETIME COMMENT '计划开始时间', plan_end DATETIME COMMENT '计划结束时间', actual_start DATETIME COMMENT '实际开始时间，首道工序报工时写入', actual_end DATETIME COMMENT '实际结束时间，末道工序报工且质检合格后写入', priority TINYINT DEFAULT 5 COMMENT '优先级，1最高9最低', create_by VARCHAR(64), create_time DATETIME, update_by VARCHAR(64), update_time DATETIME ) COMMENT 'MES工单主表';

上面这段建表语句里，status字段的枚举值直接对应需求文档里工单状态流转的描述。done_qty用DECIMAL而不是INT，是因为文档里如果出现「按重量报工」或「按米数报工」的场景，整数会丢精度。actual_start和actual_end不跟计划时间共用字段，是为了后面做计划达成率分析时不用再拆逻辑。

2.3 报工与质检的联动逻辑：文档里最容易漏掉的三个约束

需求说明书里报工和质检通常是两个章节，但实际业务里它们必须联动。我梳理文档时一定会确认三个约束：第一，报工数量是否允许超过工单剩余数量？有些车间允许超报，因为实际生产会有损耗补投；有些则严格禁止。第二，质检不合格时，报工记录是整批退回还是按不合格数量拆分？这决定了报工记录表要不要加「合格数量」「不合格数量」「让步接收数量」三个字段。第三，末道工序报工后，工单是自动完工还是等质检结论？如果质检周期长，工单会卡在「待检」状态，影响后续排产。

// 报工服务层伪代码：体现文档中「报工数量校验」和「质检触发」的约束 public void reportWork(Long orderId, BigDecimal qty, Long工序Id) { MesWorkOrder order = workOrderMapper.selectById(orderId); // 约束一：是否允许超报，从字典表读取配置 BigDecimal remain = order.getPlanQty().subtract(order.getDoneQty()); if (qty.compareTo(remain) > 0 && !config.allowOverReport()) { throw new ServiceException("报工数量超过工单剩余数量"); } // 写入报工记录，同时更新工单已完工数量 reportMapper.insert(buildReport(orderId, qty, 工序Id)); order.setDoneQty(order.getDoneQty().add(qty)); // 约束三：判断是否末道工序，决定是否触发质检 if (isLastProcess(order.getProductCode(), 工序Id)) { order.setStatus(OrderStatus.WAIT_QC); // 生成质检任务，质检结论回写工单状态 qcService.createTask(orderId); } workOrderMapper.updateById(order); }

这段代码里config.allowOverReport()对应需求文档里「报工管理」章节的配置项，isLastProcess需要根据工艺路线表判断。很多团队在开发阶段把这两个逻辑写死，上线后车间要求改规则，只能改代码重新发版。更好的做法是把「是否允许超报」「末道工序判定方式」做成字典或参数配置，在需求说明书评审阶段就提出来。

3. 把 119 页文档变成开发任务：拆解、排期与联调准备

3.1 按「数据流闭环」拆解任务，而不是按文档章节

119 页文档如果按章节拆任务，会拆出几十个功能点，排期表看起来很长，但联调时发现每个功能都差一点。我习惯按数据流闭环拆：第一个闭环是「工单下达 → 派工 → 首道工序报工」，这个闭环跑通，说明工单状态机、人员绑定、工序流转的基础逻辑没问题。第二个闭环是「报工 → 质检 → 不合格处理 → 返工报工」，这个闭环跑通，说明质量模块和报工模块的联动没问题。第三个闭环是「完工 → 入库 → 工单关闭」，这个闭环跑通，说明 MES 和 ERP 或 WMS 的接口没问题。

每个闭环拆成后端接口、前端页面、数据库变更三部分。后端接口按若依的规范写在 Controller 层，前端页面用若依的 Vue 模板改。数据库变更一定要用 Flyway 或 Liquibase 管理，不要手动改表，否则测试环境和生产环境不一致时排查成本极高。

3.2 需求文档里没写但必须确认的接口清单

MES 不可能孤立运行，它至少要和 ERP 同步工单和物料，和设备采集平台同步设备状态和工艺参数，和质量系统同步质检标准。需求说明书里通常只写「与 ERP 对接」，不会写接口字段和频率。我一般会在开发前拉着甲方确认这几件事：工单同步是 ERP 推给 MES 还是 MES 定时拉？同步频率是 5 分钟还是实时？物料主数据变更后 MES 是立即更新还是等下次工单同步？设备采集数据是走 MQTT 还是 HTTP 上报？这些问题的答案直接决定接口层的设计。

这张表里的频率是常见做法，具体以文档描述为准。如果文档里只写了「实时同步」，一定要追问是秒级还是分钟级，这决定了要不要上消息队列。

3.3 用若依代码生成器加速基础模块，但别生成核心业务表

若依的代码生成器能根据表结构生成增删改查页面和接口，对于「物料管理」「设备台账」「班组人员」这类基础数据模块，能省掉大量重复工作。但工单、报工、质检这三张核心表不建议用生成器直接生成，因为它们的业务逻辑不是标准 CRUD。工单状态流转需要自定义接口，报工需要事务控制和并发锁，质检需要和报工联动。我一般用生成器生成基础代码后，手动重写 Service 层，Controller 层保留若依的权限注解和日志注解。

# 若依代码生成器导入表后的典型目录结构 ruoyi-admin/src/main/java/com/ruoyi/web/controller/mes/ ├── MesWorkOrderController.java # 工单接口，需手动改状态流转方法 ├── MesReportController.java # 报工接口，需加事务和并发控制 └── MesQcController.java # 质检接口，需加与报工的联动逻辑

上面这个目录结构是若依单体版的标准结构，如果是微服务版，Controller 会放在各自的业务模块里。生成代码后第一件事是检查@PreAuthorize注解里的权限标识是否符合需求文档里的角色权限矩阵，若依默认生成的权限标识是mes:workOrder:list这种格式，需要和甲方确认角色划分。

4. 避坑：119 页需求说明书里最容易埋雷的五个地方

4.1 工单状态枚举值前后不一致

现象：文档第 12 页写工单状态有「已下达、生产中、已完工」，第 47 页写「已下达、生产中、待检、已完工、已关闭」，第 89 页的报表章节又出现「暂停」状态。开发按第 12 页写了枚举，联调时发现质检模块要改状态，报表模块要查状态，全部对不上。

原因：需求说明书通常由不同部门的人分章节编写，生产部门写生产章节，质量部门写质量章节，报表章节可能由 IT 部门补写，状态定义没有统一评审。

解决：在开发前拉一次状态机评审会，把所有章节里出现过的状态列出来，统一成一张状态流转图，确定每个状态的触发条件和可流转方向。这张图作为附件放进需求文档，后续开发以它为准。

4.2 报工数量精度和单位不明确

现象：文档写「报工数量」，但没写单位是「件」还是「千克」，也没写小数位数。开发用INT存数量，上线后车间报工 1.5 千克，系统存成 1，数据全错。

原因：需求文档编写者默认读者知道业务单位，但开发人员不一定了解车间实际计量方式。

解决：在需求评审时确认每个数量字段的单位和小数位数，建表时统一用DECIMAL(12,3)，前端输入框加单位提示。如果不同工序单位不同，在工序表里加单位字段。

4.3 质检不合格处理流程缺失

现象：文档写了「质检不合格」，但没写不合格之后怎么办。开发做了「不合格则工单关闭」，上线后车间要求返工，工单已经关了，只能新建工单，数据统计全乱。

原因：质量章节通常只写判定标准，不写处置流程，处置流程往往在车间管理制度里，没进需求文档。

解决：主动追问不合格品的处置方式——返工、返修、让步接收、报废，每种处置对应工单状态怎么变、报工记录怎么改。在报工记录表里加「处置方式」字段，工单状态机里加「返工中」状态。

4.4 设备采集数据频率和存储策略没写

现象：文档写「采集设备运行状态」，开发按每秒采集一次设计，上线后一天产生几千万条数据，数据库扛不住。

原因：设备管理章节通常由设备部门写，他们只关心「能采集到」，不关心存储成本。

解决：确认采集频率是秒级、分钟级还是变化时上报。如果是秒级，考虑用时序数据库或只存变化记录。在需求文档里补一条「设备状态数据保留周期」，通常 3 到 6 个月。

4.5 权限矩阵和若依角色模型对不上

现象：文档写「操作工只能报工，班组长可以派工和审核，车间主任可以查看所有报表」，但若依的角色模型是菜单权限加数据权限，操作工和班组长的数据权限范围需要额外配置。

原因：需求文档的权限描述是业务语言，若依的权限模型是技术语言，中间需要翻译。

解决：把文档里的角色和若依的角色做映射，明确每个角色能看到哪些菜单、能操作哪些按钮、能看哪些部门的数据。若依的数据权限用@DataScope注解实现，需要在角色管理里配置数据范围。

5. 从文档到上线：用验收场景反推需求覆盖度

5.1 用「一条工单的完整旅程」做验收测试

开发完成后，怎么验证 119 页文档里的需求都覆盖到了？我的做法是设计一条工单的完整旅程，从 ERP 同步工单开始，到工单关闭结束，中间经过派工、首件报工、过程报工、末件报工、质检、不合格返工、再次报工、完工入库。每个环节检查三件事：数据写入了正确的表、状态流转符合状态机、相关报表能查到数据。这条旅程跑通，说明核心需求覆盖了 80%。

-- 验收时用这条 SQL 检查工单全链路数据是否完整 SELECT wo.order_no, wo.status AS 工单状态, COUNT(r.id) AS 报工次数, SUM(r.qty) AS 累计报工数量, qc.result AS 质检结论, wo.actual_start, wo.actual_end FROM mes_work_order wo LEFT JOIN mes_report r ON r.order_id = wo.id LEFT JOIN mes_qc qc ON qc.order_id = wo.id WHERE wo.order_no = 'WO20250101001' GROUP BY wo.id;

这条 SQL 能快速看出工单有没有报工记录、报工数量对不对、质检结论有没有回写。如果actual_end为空但状态是「已完工」，说明状态流转和实际时间写入有 bug。

5.2 需求覆盖度自查表：119 页里哪些内容可以后置

不是所有需求都要在第一期上线。我一般把需求分成三类：核心闭环必须做，包括工单、报工、质检、基础数据；增强功能可以二期做，包括高级排产、设备联网采集、SPC 分析；报表和看板可以先用 SQL 出数，后续再做成页面。这样拆分后，第一期开发量能压缩 40% 左右，上线风险也小很多。

这张表里的页数占比是经验值，具体看文档结构。如果文档里报表章节超过 30 页，说明甲方对数据分析需求很强，一期至少要做一个基础看板，否则验收时不好交代。

5.3 我踩过的一个坑：别把需求文档当合同

最后说一个血泪经验。我曾经按需求文档严格开发，文档里写「报工时可以修改数量」，我就做了修改功能。上线后车间说修改数量会导致和 ERP 对不上，要求改成「报工后不能修改，只能冲销重报」。这个变更在文档里没写，但业务上合理。后来我养成了一个习惯：需求文档是起点不是终点，开发过程中每两周和车间确认一次实际操作流程，把变更记录在需求跟踪矩阵里。这样上线时不会因为「文档里没写」而被动。

希望帮到你。

本文还有配套的精品资源，点击获取