简介MES制造执行系统用户需求说明书共计119页以docx文档形式呈现面向制造企业信息化人员、MES实施顾问及生产管理人员。文档系统梳理了制造执行系统核心术语涵盖ERP企业资源计划、BOM物料清单、PLM产品生命周期管理等并对工单管理、工艺路线、ESOP电子标准作业程序等关键业务概念进行详细解读。生产流程管理部分聚焦FPY/FTY直通率、PDA数据采集、序列号与物料编码规则、OEE综合设备效率计算等核心指标质量管理模块针对不良现象、不良原因、维修动作及责任归属给出清晰定义。物料管理部分涉及工单发料清单、供应商管理、条码编码规则并区分原材料仓与线边仓两类仓储场景。资源共1个docx文件压缩包大小14.53MB已有742人学习下载适合需要系统理解MES业务逻辑与需求设计要点的读者参考。1. 一份 119 页的用户需求说明书才是 MES 项目的真正起点做 MES 制造执行系统的人迟早会碰到一份上百页的《用户需求说明书》。很多团队把它当成“甲方交差用的文档”签约后往柜子一放直接进需求调研。我这些年看过不少 MES 项目翻车原因恰恰出在这需求说明书没写透后续开发、验收、扯皮全都跟着遭殃。这一份 119 页的 docx本质上就是 MES 项目的“宪法”——它把车间里每一道工序、每一笔报工、每一次返工和每一张追溯链都提前钉死。能不能照着复现、能不能落地全看这份文档的颗粒度够不够细。这份说明书能解决什么问题它解决的是“业务方和开发方对同一个词的理解不一致”这件最要命的事。比如“完工”在计划员眼里是“整批下线”在质检员眼里是“合格入库”在开发眼里可能是“最后一道工序报工完成”。不写清楚上线后必然吵架。适合谁读适合准备启动 MES 选型或实施的生产经理、IT 负责人、甲方项目经理以及刚转岗做 MES 的产品经理和开发。这篇文章我就按这份 119 页说明书常见的内容框架拆成“业务蓝图怎么定、文档怎么拆、每章怎么写、坑在哪、怎么验收”五个部分每一段都是可以直接抄进自己方案里的思路。2. 先把业务蓝图定下来119 页文档前面的 20 页在写什么一份合格的 MES 用户需求说明书一定不是从“登录界面长什么样”开始的。它前面 20 页左右要先把工厂的家底盘清楚。这部分是整份文档的地基地基歪了后面 90 页写得再细也是空中楼阁。2.1 现状调研与术语统一这是文档的第一章也是吵架的源头这一章要回答三个问题现在怎么干的、痛点是什么、将来怎么干。很多团队以为“现状调研”就是画一张流程图其实真正的难点在术语统一。我见过最典型的例子同一个工厂里有人叫“工单”有人叫“制造订单”还有人叫“派工单”系统里到底用哪个词需求说明书必须在第一章就明确术语表并且和业务方逐条确认。术语表至少要覆盖这些维度单据类生产订单、工单、派工单、返工单、状态类已下达、已派工、生产中、已完工、已结案、数量类计划数量、合格数量、报废数量、待返工数量、时间类计划开工、实际开工、计划完工、实际完工。这张表不写清楚后面所有章节的“状态流转”和“数量逻辑”都会产生歧义。另一个容易忽略的是数据来源——比如“订单号”到底以 ERP 传过来为准还是允许车间手工建单这决定了 MES 和 ERP 的集成方式是单向同步还是双向交互。我一般建议在这一章里画一张“现状流程图 未来流程图”的对比把改善点逐条列出来作为后面需求合理性的依据。2.2 明确 MES 的边界哪些做、哪些不做、哪些将来做MES 不是万能的资源有限优先级必须排。需求说明书里要有一张功能边界表通常分三类本期范围、下期规划、明确不做。比如“设备数据采集机联网”如果只有老旧设备、没有传感器就别放进本期范围否则项目会死在接口上“高级排产APS”如果订单波动大、规则复杂通常也是二期再上。明确“不做”尤其重要它能挡住业务方随时冒出来的“顺手加个功能”的请求。边界表的形式往往是模块名称、需求描述、优先级P0/P1/P2、是否本期、依赖条件。这一页的价值不亚于后面任何一页因为需求说明书一旦被签字确认“不做清单”就是项目经理挡住需求蔓延的尚方宝剑。我见过太多项目死在“这个功能很简单顺便做一下”这句话上。在这部分还要写清楚 MES 与周边系统的接口边界比如 ERP 管计划与成本、WMS 管物料库存、QMS 管检验标准、SCADA 管设备实时数据MES 只做车间执行层的调度、报工、质量、追溯和绩效分析不要越界去接管仓库账或财务账。3. 文档正中间那 70 页把生产执行的主流程一页页写透这 70 页是需求说明书的躯干。每一页对应一个业务场景颗粒度要到“字段级”和“按钮级”。新手最容易犯的错是只写业务描述不写字段规则导致开发没法实现、测试没法写用例。从这章开始我按“从订单到完工”的顺序把每类功能文档里必须写透的内容拆给你看。3.1 工单管理从 ERP 接收到车间派工关键在状态流转工单管理是 MES 的第一站。需求说明书里要写清工单的来源是 ERP 自动下推还是 MES 手工创建还是两者都支持每张工单携带哪些字段产品编码、版本号、计划数量、计划开工/完工时间、优先级、工艺路线编号、物料清单版本。这些字段直接决定后续排产和报工的数据基础。状态流转图是这里的必备项标准状态机至少要这样定义。状态含义触发动作可执行操作已下达工单创建或从 ERP 接收系统自动/手工修改、取消、派工已派工已分配到产线或工作中心派工操作开工、改派生产中已开始第一道工序报工开工操作报工、暂停、质检已完工所有工序完成末道工序完工报工入库、关闭已结案数量核对、成本结算完成结案操作只读这条状态机必须写到“什么角色在什么条件下能做什么操作”。比如“取消”操作要限制在已下达状态、且由计划员执行“暂停”必须填原因代码已完工的工单不允许直接反冲数量要走返工单或红冲流程。字段规则也要写透计划数量大于 0、合格数加报废数加返工数不能超过投料数、完工数量不能大于计划数量加允许超量百分比。这些规则不写开发就会按自己的理解做测试也没依据。派工这块要写清三种模式手工派工调度员逐单指定产线、自动派工按规则引擎分配、混合模式自动推荐人工确认。派工后工单才能开工开工时系统要校验收料是否完成、前置工序是否完工、检验是否放行。这些校验逻辑是需求说明书里最容易遗漏、又是上线后最容易出问题的点。3.2 工序执行与报工这里多写一百字上线后少吵一百次架报工是 MES 里使用频率最高、纠纷也最多的功能。需求说明书里要写清报工的粒度和方式。粒度有三种选择不同车间选型完全不同按整批报工适合大批量、工序简单按工单报工适合流程型生产按序列号/单个工件报工适合离散型、有追溯要求的场景。汽车零部件、电子组装的追溯要求高基本都会选序列号级。报工方式也要写明车间终端固定工位机、移动 PAD、扫码枪、设备自动回传。每一种方式对应的交互和校验都不一样。报工的核心字段至少包含工序号、操作工、设备、报工数量、合格数量、报废数量、开始时间、结束时间、工时。别小看这个“工时”它直接喂给后续的绩效和成本模块。更关键的是不良处理逻辑报工时报废数和不合格数填了之后下一步是走返工、降级还是废品处理需求说明书必须给分支流程不能只写“记录不良”否则工单永远结不了案。我见过某个项目报工页面上有个“不良数量”字段业务方说“先记着后面处理”结果一个月后不良品堆了一堆工单全部卡在完工节点。后来开发加了一个“不良处置单”情况才好起来。工时数据准确与否还直接影响 OEE设备综合效率和人员效率的计算口径。需求说明书写“报工界面录入工时”开发就只做一个输入框如果写清“工时自动取开工到完工的时间差、允许人工修正且修正必须填原因”开发才会把计时逻辑和审计日志做进去。这就是文档颗粒度的差异。我开始做 MES 时也不理解为什么老工程师要求把每个字段的“必填/只读/可编辑/编辑条件”都写出来直到开发拿一句“操作工可以改数量吗”把我问住。3.3 物料与防错叫料、齐套、扫码防错每一环都要可执行车间的物料管理在需求说明书里通常占 10 页左右但它决定了生产能不能顺起来。物料管理至少覆盖四级需求投料从仓库领料到工序、在制品流转工序间转移、叫料线边缺料时触发拉动、齐套检查工单开工前物料是否齐全。投料的关键规则是“先入先出”如果物料有批次管理要求就必须按批次投料、按批次报工、按批次追溯。这部分很容易被业务方说成“物料管理是 WMS 的事”但 MES 里的物料更多是“生产消耗”视角和库存账不是一个维度。防错是 MES 里最有价值也最难做对的功能。常见防错有三类工单防错扫错工单不让开工、物料防错扫错物料编码报警或拦截、工序防错上一道没完工下一道不让扫。这些需求必须在文档里写“扫描结果和后台校验成功/失败分别出现什么反馈”比如指示灯、报警音、界面弹窗三选一。还有一个高频坑是反向追溯客户投诉某个产品不良需要反查用了哪一批来料。需求说明书里要写清追溯的链路产品序列号反查生产工单、工序报工记录、设备、操作工、物料批次、检验报告。这条链路不写透开发做出来的“追溯查询”多半只是个花架子查不出完整的“人机料法环”。3.4 返工返修与异常处理汽车水冷板这类场景必须单独成章返工返修是 MES 里最考验文档功力的模块尤其是汽车水冷板这类产品结构复杂、工序多、单片价值高返工路径多变。返工返修不能简单挂在原工单上因为原工单已经报工完成数量、工时、成本都结过了。常见做法是生成返工单来源关联原工单、原产品序列号、原不良代码返工路径可以重新指定工艺路线可能只有部分工序返工过程中发生的物料、工时、检验全部记在返工单上最后还要走返工后检验。需求说明书里这一章要写清几个决策分支返工后合格回原批次、降级转其他批次、报废处置。这些状态必须用“不良处置代码”驱动比如“开裂-可焊补”、“尺寸超差-可再加工”、“电性能不合格-报废”。代码表在文档里要给出样例并约定由质量部维护。返工单和原工单的关系要写明是否影响原工单的完工状态返工后的产品序列号是否沿用返工工时是否计入原工单成本这四个问题不回答清楚上线后成本账和追溯链一定对不上。实际上返工返修模块最容易出问题的地方是“返工路径校验”——系统允许自定义返工路线就必须限制不能跳过关键质量控制点比如焊接工序返工后必须重回气密检测这条规则必须在需求文档里而不是让操作工自己决定下一步干什么。4. 把 119 页拆成能落地的需求条目从文档到开发的桥前面讲了内容这一章讲方法和工具。很多需求说明书写了厚厚一本开发却不知道怎么开工。原因很简单文档是“按业务流程组织”的开发要的是“按功能模块组织”的需求。中间必须有个转化的桥否则 119 页形同虚设。这章我讲三个关键动作拆字段、拆接口、拆验收标准每一步都给可抄的表格和模板。4.1 用“需求条目化”的方法拆文档一个功能一张卡片需求条目化就是把文档每一章拆成“编号、模块、需求描述、业务规则、验收标准、优先级、依赖关系”的结构化条目。一个典型条目长这样条目项内容示例需求编号MES-PROD-022所属模块工序报工需求描述操作工在工序终端扫描工单条码后系统自动带出当前工序信息操作工录入完工数量并提交业务规则完工数量不能大于计划数量 5%合格数 报废数 ≤ 投入数首道工序开工前必须完成投料确认触发条件工单状态为“已派工”且当前操作用户有该产线报工权限验收标准扫描工单后界面响应 1 秒提交后工单在制品数量和工序进度实时刷新报工记录可在追溯查询中被检索优先级P0开发拿到这张卡片就可以排计划测试可以照着写用例业务方复核也直观。这个动作本质上是把“业务语言”翻译成“系统语言”翻译得越彻底后续返工越少。推荐用 Excel 或在线表格管理条目每一条有独立编号变更时走修订记录。需求条目化的另一个隐含作用是做“需求追溯矩阵”也就是每一条需求都能追溯到业务章节每一条功能点都能对应到需求编号。项目验收或审计的时候这个矩阵就是证据。4.2 接口需求怎么写不只写“传什么”还要写“出错怎么办”MES 是典型的重集成系统常见的接口有 ERP主数据、工单、库存、PLMBOM、工艺路线、QMS检验计划、不良代码、SCADA设备数据采集。接口需求说明书写得差是集成阶段进度延误的第一大原因。接口描述至少要有六项内容。一个是接口名称和方向是 MES 主动调用还是被动接收。一个是数据项清单字段名、类型、长度、是否必填。一个是触发时机是实时还是定时批量比如每 5 分钟同步一次还是每天凌晨批量。一个是失败处理ERP 没响应是重试几次还是进重试队列是否需要人工介入。一个是幂等性同一份数据重复推送会不会产生重复数据。还有一个是安全认证接口鉴权方式要保持一致。失败处理尤其重要。ERP 工单下发时偶尔会出现数据不完整比如工艺路线缺失MES 应该拒收还是先接收补全两种策略都有代价拒收会导致后续单也卡住因为同批下发的可能都缺接收再补会产生数据质量隐患。我见过的稳妥做法是MES 接收时做必填校验不符合规则的进“异常队列”由 MES 管理员处理后重试。这块在文档里要写清楚否则开发自己定策略业务方上线后才发现和预期不一致。接口字段映射表也容易踩坑同一个“物料编码”ERP 里是 18 位带前缀MES 里是 14 位纯数字映射规则不写明引进来的 BOM 会全部对不上。4.3 从文档到数据库表字段级需求的收官一步写需求的最终目的是让开发建表。数据库设计通常由开发负责但字段的“业务含义”必须是需求说明书定义清楚的。我在需求评审会上总会盯一张字段清单表它包含字段名称、业务含义、数据类型、长度、取值范围、是否必填、默认值、来源、是否可修改、是否纳入追溯。举个例子——“报废数量”这个字段业务含义是“本工序报工中判定为废品的数量”数据类型是数值型长度 10整数是否必填视检验规则而定来源是报工界面录入可修改条件是“未提交前可改、提交后需走反审核流程”是否纳入追溯为“是”。这十个属性写全了开发和测试就有明确依据业务方也不会因为粒度不同扯皮。字段清单表我建议按模块维护每个模块一张 Sheet编号统一关联需求条目。有些 MES 供应商有自己成熟的数据字典直接拿来套用也可以但还是要和业务方逐项确认“取值范围”和“默认值”尤其是车间里已经存在长期习惯的叫法。比如报工界面里显示“完成数量”还是“报工数量”很多操作工只认一种叫法。这个细节在培训阶段会放大成阻力。需求说明书能写清“界面显示文案”当然更好但至少要保证字段业务含义没有歧义。数字化转型卡壳往往不是卡在技术而是卡在操作工不肯用、不想用所以文档里把界面和常用叫法写清楚等于提前消掉一部分推广阻力。5. 避坑指南MES 需求说明书的 5 个高频翻车点我参与过 MES 项目的方案评审也看过别人家 119 页文档里的隐形坑。这章把最常见的五个问题按“现象→原因→解决”列出来每一条都是花钱买来的教训。5.1 业务方说“先按现状来”文档写完了才发现现状是手工 Excel现象需求说明书大张旗鼓写了两个月开发进场一看车间里根本没有可落地的数据基础连物料编码都还没统一。原因做需求访谈时业务人员习惯“照现状描述”但现状本身就是混乱的手工模式——Excel 管到一半、纸质流转单到处飞、编码靠人脑记忆。系统把这种现状固化下来上线后不但没有提效反而比手工更慢。解决写需求说明书之前先花两周做“数据治理”盘点。物料编码规则BOM 准确率工艺路线是否覆盖所有产品设备台账是否完整这四个如果不过关先别急着写系统需求先立规矩。文档里这些“前提条件”应该单独成章并让业务方签字确认这样后面数据出问题责任边界才清楚。5.2 状态机和字段规则不闭环开发只能靠猜现象界面原型都画好了开发问“报废数量提交后能不能改”业务方答“能改但要走审批。”再问“审批流是什么谁发起谁审批”就开始支支吾吾。结果开发按最简单的规则做提交后不可改只能做红冲。上线后业务方不认返工返修。原因需求访谈停留在“功能层面”没有深入到“逻辑层面”。解决每个核心功能写“业务规则清单”至少覆盖创建条件、修改条件、删除条件、超量/超标拦截规则、审批触发条件、操作失败后的提示文案这里写清楚可以省测试时间。还有一个偏门但实用的做法把所有“数量字段”统一过一遍定一个全局原则——数量类字段一旦产生效验和影响追溯就只允许新增冲销记录不允许原地修改。不要为极少数的“特殊情况”单独开口子否则数据迟早被改乱。5.3 验收标准写成“系统要支持”而不是“可测量的行为”现象需求说明书里写“系统要支持扫码报工”开发做完了业务方说不好用因为扫描枪扫一下要在界面跳转两次才完成报工操作工嫌麻烦。这不算功能缺失但验收永远扯皮。原因需求描述只有功能名缺验收标准。解决每一条需求条目必须有可测量的验收标准比如“支持扫码报工”改成“操作工扫描工单条码后系统在 2 秒内显示待报工工序扫码录入物料批次后如果批次错误系统在 1 秒内红色报警并禁止提交”。业务方再凭“我觉得好用”来挑刺在文档面前就没有力度了。5.4 只写正常流程不写异常流程上线后处处报错现象功能看着全都有一到车间实际跑就卡住——来料批次扫不出来怎么办工单工序漏了一道怎么办设备刚好停机、报工时间怎么算每件事都要找 IT。原因文档只写了“晴天路线”没写“雨天路线”。解决每个主流程配一张异常处理表列常见的十种异常场景然后写清发生后系统行为自动拦截、放行提醒、转人工处理角色处理时限是否需要记录审计日志。异常处理表不需要把所有的 corner case 覆盖完但覆盖八成常见情况项目风险就能降一半。5.5 权限设计只到角色没到数据范围现象需求说明书里画了一张角色权限矩阵生产主管能看所有工单操作工只看自己产线。开发照做三个月后出了问题操作工在查询页面输入工单号能查到其他产线工单——因为权限控制了菜单没控制数据行。原因权限设计少了一个维度“数据范围”。解决权限模型至少写清三层功能权限菜单和按钮、数据权限查到哪些工单本产线还是全厂、字段权限看到哪些列单价、成本是否可见。做 119 页需求说明书时权限往往是最后才补的章节这其实是埋雷。我一般建议把权限章节含角色矩阵、数据权限、审批流权限写到第 10 页左右的篇幅它能挡住上线后大半的权限扯皮。6. 最后一招把需求说明书变成可执行的验收清单需求说明书不只是用来给开发看的它完全可以变成项目验收和培训的底稿。这一章讲三个具体的技巧转成 UAT用户验收测试用例、转成培训手册、以及上线后需求变更的管理机制。先说转 UAT 用例。最省力的做法是每一个需求条目直接加一列“测试步骤”由测试人员基于验收标准编写。比如“MES-PROD-022 工序报工”对应用例准备一张已派工的工单用测试账号登录车间终端扫描工单条码录入完工数量提交。预期结果工单状态变为“生产中”界面显示“报工成功”追溯查询能查到这条记录。这样一套操作下来需求和用例一一对应覆盖率可度量验收时不会漏功能。其次是转培训手册。需求说明书里每个模块的“术语表”可以直接变成培训课件的第一章每个典型流程可以变成操作手册的操作步骤。我见过不少项目上线失败不是系统不好而是操作工不愿意用根本原因是没有把需求说明书里的业务逻辑简化成“傻瓜式”的操作指引。把这个动作提前到需求收尾阶段比上线前临时补做培训要省力得多。最后是需求变更管理机制。119 页的文档签完字不代表结束MES 项目从开发到上线中间一定会冒出新的需求或规则调整。常见的做法是需求说明书里预留一个“变更记录”章节约定什么级别的变更走什么流程——比如“字段显示名称修改”走快速通道由产品经理确认即可“增加一个新状态节点”走变更委员会评审评估影响工期和成本。变更一旦确认需求条目编号要保留原编号加“-R1/R2”后缀避免追溯断链。入口被堵住文档才能一直保持“可执行”的状态。关于这份 119 页 MES 用户需求说明书我的核心建议就一句话不要拿它当合同附件而是拿它当产品。文档的每一页都应该回答一个“开发会问、业务会问、验收会问”的具体问题而不是泛泛描述业务流程。我过去最倚仗的一个做法是把文档从 docx 转成一个需求条目表挂在需求管理工具里每天看“未澄清条目数”。这个数字降到零的时候项目才真正具备开工条件。这套方法经历过 2000 多页的整车厂需求文档也经历过 30 页的机加工小项目核心原理都一样——先定义清楚再动手实现。希望帮到你。本文还有配套的精品资源点击获取