简介这是一份车间制造执行系统MES的需求说明参考文档适合制造企业信息化负责人、MES产品经理、实施顾问在项目前期梳理业务边界也可作为编写技术协议或需求规格书的参考底稿。文档从软件总体设计出发明确基于Web的B/S架构与HTML5跨平台要求并提出数据库集群、负载均衡等部署建议。系统功能需求覆盖生产建模、生产排程与调度、物料配送管理、现场作业、质检、设备、看板、人员管理、数据采集和系统集成等模块其中生产建模细分为物料主数据、生产资源建模、工艺建模排程部分区分装配准时化排程与机加工序有限能力排程物料管理还涉及托盘配送与工位配料等细节能够帮助读者快速把握MES功能架构和需求要点。资源包共1个PDF文档大小约454KB为纯文本需求说明书便于在线预览和检索。目前已有334人浏览学习对正在做MES选型或需求调研的团队具有一定参考价值。1. MES 需求文档没你想的那么枯燥也没你用的那么透车间制造执行系统MES的需求说明文档听起来是那种「需要的时候翻两页不需要就永远躺在网盘里吃灰」的文件。但真正接过大大小小工厂项目的工程师都清楚只要你想把 MES 从 PPT 落地成车间里跑的界面、逻辑和报表最值钱的第一份输入恰恰就是这份需求说明。这篇笔记拆的就是这样一份参考文档——它以 PDF 形式给出了一套完整的 MES 需求说明框架覆盖生产工单管理、报工与完工、质量管理、返工返修、设备集成、追溯等核心域适合正在做 MES 选型、需求调研、方案设计或者被领导要求「先出个需求说明」的人。对新手来说它是入行最快的脚手架因为不用从零对着空白 Word 发呆对老手来说它的价值更像一张自查表——对照它检查自己漏了哪些业务边界和字段约束。这篇笔记会按「拆结构、讲用法、排坑、给技巧」的顺序展开全程只说实际怎么用。2. 先花 20 分钟理解需求文档的结构MES 从哪来到哪去2.1 MES 需求说明文档为什么值得逐节细看我见过不少同事拿到这份 PDF 后直接 CtrlF 搜关键词找到一段就复制一段完全不看先后的章节逻辑。这个做法在赶工期时能应付交差但到了评审会上业务方一句「你这个功能放在这个模块底下跟我们车间实际的流转顺序对不上」就能让整个方案被打回。所以拿到文档之后第一件事不是抄而是先把目录当成一张流程图来读需求说明文档的章节编排本质上就是在模拟「订单下来 → 排产 → 工单下发 → 车间执行 → 报工 → 质检 → 入库 → 追溯」这条完整的主干流程。参考文档通常会把章节分成项目背景与目标、业务现状描述、功能需求按模块拆分、非功能需求、接口需求、数据需求、实施范围与边界。这里最容易被忽略的是「业务现状描述」这节——很多人觉得这是给领导看的背景介绍跳过不读。实际上这一节里埋着最关键的选型理由为什么现有的 ERP 或手工 Excel 管不住车间MES 要解决什么具体痛点。读懂了这一节后面功能需求里的每一个字段、状态、按钮就都能跟业务动因挂上钩而不是孤立地看「这个按钮叫啥」。2.2 把这份 PDF 当模板用建立一个「需求条文」索引表读 PDF 和读 Word 的最大差别在于你不能直接在 PDF 上做细粒度批注翻阅也慢。我的习惯是拿到 PDF 后先用浏览器打印功能或 Adobe 的导出功能把内容转成 Word 或纯文本再做第一轮结构化。如果你不打算转换那就在 Excel 里手工建一个索引表每读一个章节就把「章节号、功能模块名、关键需求条文摘要、对应业务角色、涉及状态流转」记下来。这个过程看似笨但读完一遍之后你会发现自己对 MES 的理解比直接看结论清晰得多。建立索引表还有一个直接的好处写方案书或做差距分析时你可以快速定位「某条需求出自文档哪个章节」而不用每次重新翻 PDF。对于这份参考文档里常见的内容——比如生产工单管理的状态流转创建 → 下达 → 开工 → 完工在索引表里记下「状态字段在 4.1 节流转规则在 4.1.3 节」评审会上别人提出疑问时你翻页的速度就是你的专业度。3. MES 核心模块需求拆解从车间流程推导出功能清单3.1 工单管理与计划排产从 ERP 到车间执行的边缘地带MES 最核心的价值之一是接住 ERP 生产订单和车间执行之间的信息断层。参考文档里工单管理这块通常不只是一个「工单列表增删改查」而是包含工单接收自动或手动、工单拆分与合并按设备负荷、按批次、工单下发到产线或到工序、工单状态实时回写。你在读需求文档时要重点看这套状态机的定义——这是后续开发 MES 时最容易滋生混乱的地方。实际写需求说明时我一般会要求文档给出每个节点的业务规则工单创建 - 来源ERP生产订单自动生成 / 手工创建 / 计划排产结果导入 - 必填字段工单号、产品编码、数量、计划开始/结束时间、优先级 - 可选字段批次号、客户订单号、工艺路线版本、备注 工单下达 - 前置条件物料齐套检查通过可选、工艺路线已维护、BOM版本已锁定 - 状态流转创建 → 已下达 → 已开工 → 已完工 → 已关闭 - 异常分支挂起、取消、返工触发返工工单如果是纯手工作坊式的 MES 项目常见于从零搭建的私有化系统文档里还需要把「计划排产」的颗粒度说清楚是排到「产线日计划」还是「工序甘特图」。参考文档如果只是写到「支持排产」这种一句话级别的需求要立刻补充「按日排产、按周排产、自动排产还是手动拖拽调整」这类落地产能问题。因为从实际经验看MES 排产模块 80% 的返工都来自「需求文档只写了要排产没写排产的约束条件」。3.2 工序报工与完工汇报粒度决定系统价值工序报工是车间日常使用频率最高的功能也是需求文档里最需要抠细节的地方。每道工序的报工方式、报工数据项、异常处理这几项如果不逐字写清开发做出来后车间会用得非常痛苦。参考文档里常见的报工需求条文落到实施时可以拆成这样的功能描述报工方式支持 1. 扫码报工员工扫工序流转卡上的二维码自动带出工单/工序/设备 2. 触摸屏报工产线工位终端上选择工单 → 输入数量 → 提交 3. PC 端批量报工班组长代报适用于集中作业场景 报工数据项 - 合格数量必填 - 不合格数量必填 - 报废数量必填触发报废审批流程 - 作业人员默认取当前登录用户可改 - 设备编号多设备场景必填单设备/场地场景可空 - 工时自动计时模式/手动填写模式二选一配置报工的粒度直接决定 MES 的追溯和绩效考核准确度。按「工序报工」和按「工单报工」两者差异极大按工单报只能知道这批货做完了不知道卡在哪个环节按工序报才能做在制品WIP管理和瓶颈分析。需求文档如果在这块含糊后面做生产大屏时会发现数据完全没法看。3.3 质量管理与检验流程把质量标准嵌进步骤而不是独立一张表质量管理是 MES 需求里被「橡皮擦」概率最高的模块很多参考文档写质量就是「支持来料检验、过程检验、完工检验」但没有把检验标准和 MES 操作步骤绑定。合格的 MES 质量需求要明确检验任务是怎么触发的——是按工单触发、按批次触发还是按抽检比例自动生成实操里我建议需求文档里写清楚三个内容检验方案检验项、标准值、上下限、抽样数量、检验结果录入手工录入 / 仪器自动采集、不合格品处置让步接收、退货、返工、报废。作为模板来用可以把这段需求写成结构化文字检验项数据模型 - 检验项编码关联同一种物料的多个检验项 - 检验项名称 - 数据类型数值型/文本型/布尔型 - 标准值 / 上限 / 下限 - 缺陷等级致命/严重/轻微 - 取样方式首件/巡检/完工抽检 不合格品处置流程 触发条件 → 录入不合格数量与缺陷代码 → 系统生成质量异常单 → 质量工程师判定 → 处置结论返工/让步接收/报废/退货→ 返工触发返工工单让步接收触发审批流报废触发库存扣减3.4 返工返修模块最容易在设计阶段被忽略的「第二主流程」很多需求文档把返工当成质量管理里的一个小分支一两句话带过这是 MES 项目里我最常踩到的坑。返工返修不是一个「再报一次工」那么简单返工工单要不要关联原工单返工后的数量如何回写原工单返工的检验标准是否加严返工成本怎么归集——这些至少在需求文档里要有明确撰写。如果参考文档的返工内容较薄实施时我一般会补出这样的返工处理逻辑原工单数量不动在系统里生成一张关联返工工单并注明「来源工单号」返工工单走独立的工艺路线可能是去掉某几道工序也可能是加严检验返工完成后合格品回补原工单的在库数量但原工单的合格率统计中单独显示返工批次。这样追溯时可以通过「来源工单号」把返工链路从头串到尾而不是在 Excel 里靠人肉关联。4. 从「参考文档」到「自己项目的需求规格说明书」实操方法4.1 第一步做现状调研与差异化分析而不是直接套模板参考文档的核心价值是「参考」不是「复制」。很多团队直接拿同行业文档改个企业名就提交评审这是最危险的。原因是每个车间的物料流转习惯、班组组织方式、设备自动化水平都不一样一套需求照搬过来轻则培训成本高重则根本跑不动。我一般会用对比矩阵做差异化分析左侧列参考文档的章节条款右侧列本厂现状。对比项包括生产订单来源是 ERP 还是手工计划车间有没有电子看板或工位终端物料标识是纸质流转卡还是二维码/RFID质检数据是纸质记录还是仪器直传设备是手动输入数据还是通过 OPC-UA / Modbus 采集。逐项对照后凡是「参考文档写得很高级、本厂根本不具备条件」的条目要么砍掉要么补前置条件。4.2 第二步用文档反推「用例」再让业务方确认需求说明文档毕竟是「陈述句」而车间真正跑的是一个个「动作」。所以我在用完这份参考文档后会把一些核心需求转换成用例描述跟车间主任、班组长、质检员过一遍。比如把「支持工序报工」这句话转成三个用例小张在产线终端扫码报工、班组长在 PC 端代报工时、质检员发现不合格批次后冻结在制品。转完用例后请业务方在用例上签字确认这一步能规避掉四分之三的后期扯皮。因为业务方在「验收功能」的时候心里想的从来不是「文档里写了什么」而是「我那天跟你演示的操作会不会跟你想的不一样」。用例就是那个「操作场景的凭证」。4.3 第三步把非功能需求当一等公民对待MES 是车间级的实时系统对非功能需求的重视程度不应低于功能需求。参考文档里如果能读到响应时间、可用性、并发用户数、数据保留策略这几项那这份文档的含金量就不低如果只是功能列表就需要自己补充。非功能需求默认基线小型工厂私有化 MES - 页面响应时间普通查询 ≤ 3 秒报工提交 ≤ 2 秒 - 并发用户车间终端 50 并发报工类事务 10 并发 - 可用性系统运行时间 ≥ 99%按年度计算计划停机除外 - 数据保留生产记录工单/报工/检验至少保留 3 年不在线、可归档 - 接口响应与 ERP 交互的接口调用超时设置 10 秒异步处理优先这些基线会直接影响技术选型例如报工提交 2 秒的响应要求基本就排除了「每次报工直接调用 ERP 写接口同步等待」的方案转而采用 MES 本地写库 消息队列异步推送的方式。4.4 第四步需求文档评审要「抓业务方在场而不是 IT 在场」评审会如果只叫了 IT 和软件公司的人来一定会变成「这个字段长度是多少」的技术争吵。正确的评审组合是生产经理懂主流程、车间班组长懂操作细节、质量经理懂标准和追溯、设备主管懂数据采集边界。参考文档的每一节需求让相应角色现场确认。确认的标准是「这条需求对应的操作场景在你的车间真实存在的概率有多大」。如果他们都拍胸脯说会用到那文档的可执行性就过关了。5. MES 需求文档的避坑清单5 条血泪经验5.1 需求状态字段没定清楚开发时推倒重来现象开发完成后发现工单「完工」后还能被报工或者「已下达」的工单被质量冻结后直接跳到「完成」状态机逻辑乱成一锅粥。原因需求文档里只写了「有状态字段」没有写状态流转的触发条件和互斥规则。解决在需求文档中提供完整的工单状态流转图至少用文字描述每个状态的前置状态、跳转条件和禁止跳转状态变更操作统一收口到一个服务方法不能散落在各个页面的代码逻辑里。5.2 物料编码规则不一致MES 和 ERP 对不上账现象MES 中的物料编码用了「内部简化码」ERP 用的是「带版本号的物料号」两个系统间数据同步时频繁报错。原因需求文档的「数据需求」部分没有定义主数据规范没有明确哪个系统是主数据源。解决趁需求阶段就把主数据归属定死——物料主数据以 ERP 为准MES 接收后建立映射表如果工厂没有 ERP则 MES 作为主数据维护端编码规则写入《编码规范》附件与需求文档一同评审。5.3 报工数量输入后允许修改导致绩效数据失真现象员工报工后发现输错直接改数量月底绩效统计时数据被质疑。原因需求文档没定义「报工数据是否可改」和「修改是否需要审批」。解决需求阶段就明确——报工提交后允许班长在当日 24 点前修正但系统在修正记录表记录「原值/新值/修改人/修改时间」超过时限需走车间主管审批。把这条做成需求条目而不是开发时才讨论的问题。5.4 需求文档把所有功能都写成「必须」范围一路膨胀现象评审时业务方对每一页需求都说「要要要」项目预算和周期不断后移。原因参考文档是「全功能蓝图」不是「本厂实施范围」。解决把需求分成 P0第一期必须有、P1第二期可以有、P2远期考虑三个优先级。评审时要求业务方给每条功能标优先级逼他们在「做不完」和「先做什么」之间做选择。这条做不好上线时间永远只是个传说。5.5 设备数据采集在需求文档里写「支持」实施时发现协议根本不通现象文档里写「支持与 PLC 通讯获取产量数据」实施时发现车间里有 5 种不同年代的设备有的走 OPC-UA有的只开放 Modbus RTU有的根本没有联网端口。原因设备集成需求调研不足只写了结果效果而非约束条件。解决需求文档的接口需求章节改为「设备接口清单表」每个设备单独一行列明型号、通讯协议、数据点表是否开放、采集频率由设备主管签字确认。协议不清楚的设备宁可写「具备手动录入条件」也不要写「支持自动采集」。6. 让这份参考文档持续增值维护你自己的需求基线6.1 建一个「需求追溯矩阵」把每条需求钉死到验收测试需求说明文档的价值不在写完那一刻而在它能不能引导后续设计、开发、测试、验收的全过程。最实用的工具就是需求追溯矩阵每一行是一条需求条目列包含需求来源参考文档章节号、需求描述、优先级、设计模块对应代码工程里的模块名、测试用例编号、验收状态。需求追溯矩阵示例节选 | 需求编号 | 需求描述 | 优先级 | 设计模块 | 测试用例 | 验收状态 | |---------|---------|--------|----------|----------|----------| | MES-WO-001 | 工单支持从 ERP 自动拉取 | P0 | 工单管理 | TC-WO-001 | 已通过 | | MES-WO-002 | 工单支持手工创建 | P0 | 工单管理 | TC-WO-002 | 已通过 | | MES-QC-003 | 不合格品自动生成异常单 | P0 | 质量管理 | TC-QC-003 | 未执行 | | MES-RE-001 | 返工工单关联原工单号 | P1 | 返工返修 | TC-RE-001 | 未执行 |把这个矩阵放在需求文档的同级目录每次需求变更或测试完成后更新一行项目结束后它就是整个 MES 工程最完整的地图。没有这个矩阵做索引需求文档和开发代码就会变成两套各说各话的东西。6.2 版本管理PDF 参考文档不是「只读圣旨」而是「活的基线」需求文档进入实施阶段后一定会被改关键是让每次修改可追溯。建议从拿到这份 PDF 参考文档的第一天起就按「基线版本号 修改记录表」的方式管理。每次评审通过的版本打一个基线号V1.0、V1.1、V2.0修改记录表里写清变更人、日期、变更章节、变更原因、影响范围。我吃过一次亏项目中期有个人直接在共享盘上改了一版需求文档没有同步给开发团队成员各干各的等到联调时发现界面和逻辑对不上被迫加班返工。从那以后我每次收到这类需求文档不管格式是 PDF 还是 Word第一步永远是归档原版并建版本库之后任何改动必须走变更评审流程。这套做法坚持了几年踩坑概率大幅下降。希望这篇拆解能帮你在下一次 MES 需求分析时少走弯路把这份参考文档从「看过」变成「用过」。本文还有配套的精品资源点击获取