简介面向制造企业信息化人员、MES实施顾问与系统设计开发者的制造执行系统MES用户需求说明书完整版共计119页。文档以厦门建霖MES项目为背景系统梳理了从项目范围、术语定义到工厂布局、产品描述、产线工作站及工艺路径注塑、抛光的完整业务框架并分章阐述了生产计划、生产管理、批次管理、载具管理、质量管理、物料管理、设备与模具管理及系统集成等核心模块的用户需求正文还包含版本历史、术语对照表和详细目录各模块按“现状—目标—流程—功能需求”的脉络展开便于直接裁剪复用。资源包内为1个docx文档整体约15.49MB可离线查阅或导入协作平台使用。目前已有944人学习下载适合正在编写需求规格说明书、推进MES选型或开展需求调研的读者参考尤其适合作为MES项目需求调研、蓝图设计、招投标附件编制及后续系统设计输入的底稿。1. 一份119页的制造执行系统MES用户需求说明书值不值得逐字读很多制造业团队第一次认真接触MES是从桌面那份119页的《制造执行系统MES系统用户需求说明书》开始的。它看起来像一份“甲方交差文件”但真正推动过MES选型和上线的人会知道这份文档里藏着整个项目成败的关键业务边界、追溯粒度、接口责任、验收标准。它解决的问题不是“要不要上MES”而是“MES到底做什么、做到什么程度、谁来验收”。适合工厂信息化负责人、MES实施顾问和软件项目经理在启动前逐章研读——读懂了它你才知道自己买的是一个车间看板还是一条完整的数字化产线。2. 制造执行系统的业务域地图先分清“要什么”再写“做什么”需求说明书最怕开头就堆“软件功能列表”。我拿到一份MES需求时第一件事是看目录有没有覆盖完整的业务域。制造执行系统MES不是单点工具它夹在ERP和底层自动化设备之间ERP告诉你本周要做什么MES告诉你产线此刻做到哪了、做得怎么样。缺了任何一个核心域项目上线后都会出现“信息断头路”。2.1 MES六大核心域从工单到追溯缺一个都是隐患最常见、也最稳妥的MES需求说明至少要覆盖六个业务域。先看一张典型的功能域对照表判断一份119页文档的信息是否完整。业务域业务输入核心动作输出/对接对象工单与排产ERP工单、销售预测拆解工单、排产、下达产线作业计划作业执行与报工派工单、工艺路线工序流转、完工上报产量与工时数据质量检验与追溯检验规范、批次信息来料检、巡检、终检质量记录、追溯链设备状态与OEE设备台账、停机事件状态采集、停机登记设备综合效率物料与WIP领料单、条码批次流转、在制品跟踪库存与物料位置人员与绩效班组排班、技能矩阵任务指派、工时归集计件工资、技能档案这六个域不是并列的“功能菜单”它们有先后依赖。工单和排产是龙头作业执行是主干质量、设备、物料是附着在工序上的数据采集点绩效是事后的统计输出。我评审需求说明书时会让车间主任、工艺、设备、质量和IT五个人各认领一个域逐条划钩缺一个域就直接列为重大缺陷。以工单域为例合格的需求必须写清楚工单从ERP下发到MES是自动还是手工、拆批规则是什么、插单怎么处理、工单关闭的前置条件是什么。这些不写清楚开发到一半就会陷入“你为什么不按我们车间习惯做”的争论。2.2 字段粒度的取舍追溯需求写不写得清差距全在这里业务域决定“有哪些功能”字段粒度决定“这些功能做到多细”。这是需求说明书最见功力的位置也是决定开发工作量的分水岭。拿质量追溯来说我见过最快的翻车方式是需求里只写一句“实现产品全流程质量追溯”。这句话没有任何开发价值。追溯到底到批次还是到序列号SN范围是原材料批次、生产过站记录、工艺参数还是检验数据回溯时间是查单件还是查整批不同答案对应的数据模型、扫码设备和存储成本差出好几倍。一份能落地的需求说明书应该给出明确的追溯链字段清单比如产品SN → 生产工单号 → 工序过站记录工序名、设备号、操作工、时间物料批次 → 供应商批次 → 来料检验单号 → IQC检验结果工艺参数 → 炉温上限/下限、实际炉温曲线文件号返工记录 → 返工原因、返工工序、返工后检验结果“要支持追溯”是概念上面这张表才是需求。我在写字段粒度需求时会直接明确能写到字段的就不要写到功能能写到字段必填与否的就不要留到开发阶段让程序员猜。还有一类细节特别容易被漏——数据采集方式。同样的“报工数量是10”人工键盘录入、扫码枪扫描、PLC自动上传是三种完全不同的实现路径涉及的信息化投入和现场操作习惯也截然不同需求说明书里要写明每个核心数据项的采集手段和采集时机。3. 119页文档的内容骨架站在评审者角度编排章节需求说明书写得厚不难难的是让评审会上每个人都找得到自己关心的部分。我习惯先给文档搭一个能“按角色翻查”的骨架而不是按软件菜单平铺。119页听上去多分到十个章节后每章不过十几页讨论起来非常高效。3.1 从现状流程写到验收标准一份可评审的目录结构下面是一份我在MES需求评审中常用的章节结构页数分布按照119页的篇幅规划各企业可以根据实际情况调整比例。章节内容重点参考页数1 项目背景与目标为什么上MES、解决什么痛点52 现状调研与痛点清单当前车间怎么管、数据断在哪103 MES范围与总体架构覆盖哪些车间、与ERP/设备集成边界84 业务流程详述从工单到入库的完整流程图205 功能需求按六个业务域逐条描述功能406 集成需求与ERP/PLC/WMS/安灯系统的接口定义107 数据与追溯需求追溯链、报表口径、字段粒度108 非功能需求性能、并发、安全、可用性89 验收标准与交付物每项需求的验收办法510 附录术语表、原始单据样张、角色权限清单3这个结构的关键顺序是“先业务后系统”。第4章业务流程是第5章功能需求的前提——功能是流程上长出来的不是从软件界面上倒推的。很多项目写反了一上来就是菜单树、按钮布局结果业务人员看不懂评审会往往演变成功能演示会。第3章的边界也值得单独拿出来确认。上MES常见的问题是跟ERP“抢地盘”生产计划排程到底在ERP做还是在MES做物料批次主数据在哪边建立这些边界问题如果不在一份119页的说明书里用集成章节专门约定实施阶段就会变成两个乙方扯皮现场。3.2 用例与验收标准怎么写才不算“假需求”功能需求章节最容易写成“系统应支持××”的流水账。比如“系统应支持工单下达”这就是一条假需求——它没有操作角色、没有前置条件、没有数据规则、没有失败处理。我在这一章坚持使用用例体UC格式每条需求都要能回答四个问题谁触发、前提是什么、操作路径是什么、结果怎么验证。写工单下达这一条需求时它的用例描述大致长这样用例编号UC-MES-001 用例名称ERP工单下达至MES 角色计划员 前置条件ERP工单状态为“已审核”MES接收接口正常 主流程 1. 计划员在MES工单管理界面点击“同步ERP工单” 2. 系统按既定规则校验工单物料编码、数量、交期字段 3. 校验通过后工单写入MES并生成车间任务号 4. MES回传“已接收”状态给ERP 备选流 2a. 校验失败工单进入异常队列系统提示具体原因 验收标准 1. 工单同步至MES时间不超过5秒 2. 异常工单在异常队列中可见且可导出这种写法每一条都对应开发任务和测试用例。需求说明书里用例写得多细后续开发阶段的理解成本就降多少。哪怕只是“工单同步”这一个动作字段映射、错误重试、日志记录都要在附录中列出否则到了上线前的接口联调阶段光对齐字段就能耗掉两周。4. 把业务需求翻译成系统边界功能清单、优先级与集成接口业务域和用例定下来之后得有一章负责“翻译”——把业务语言翻成可开发、可排期的功能列表和接口清单。我一般会把它做成两个独立小节一个是功能清单与优先级另一个是接口和数据字段清单。前者解决“我们做哪些”后者解决“每个功能到底怎么实现”。4.1 功能清单的编号与优先级先保住Must Have功能章节里写的几十条用例到落地阶段必须排优先级。我常用四象限法给功能需求分级避免在次要功能上消耗过多开发工时。优先级定义举例Must Have不做则系统无法上线报工、工单接收、产品SN绑定Should Have影响核心效率可短期绕行自动排产、OEE统计、看板Could Have有更好无则优化体验报表自定义、Excel导出美化Wont Have本期明确不做供应商远程协同、高级APS每一条功能需求都要带一个编号比如FR-MES-001对应所属业务域和用例编号。编号体系是评审时追踪的依据一份119页的需求说明书如果页码修改后没有对应的功能编号评审会上就会陷入“你说的是第几章哪一段”的混乱。功能清单表格至少包含功能编号、功能名称、所属域、优先级、对应用例编号、接口依赖这张表可以直接变成项目排期的基线。我建议在实施阶段将50%以上的工作量压给Must Have功能然后再谈看板和大屏。很多MES项目翻车不是因为功能做少了而是因为把大量工时花在“车间数据大屏炫不炫”上反而没时间打磨报工和追溯。先保住骨架功能是写在优先级表格里最重要的实施策略。4.2 接口和数据字段清单开发前必须锁死的细节MES项目里有句话最难的部分不是MES本身而是MES和周边系统的接口。接口章节在需求说明书里往往纸张不多却是实施过程中扯皮最多的地方。要在一份MES用户需求说明书里把集成需求写到位至少要给出接口清单表和数据字段表。接口编号接口名称来源系统目标系统数据内容频率/触发方式IF-001工单下发ERPMES工单号、物料编码、数量、交期每分钟轮询/接口触发IF-002报工回传MESERP完工数量、工时、报工时间每笔报工实时触发IF-003物料批次信息WMSMES批次号、库位、批次属性扫码实时查询IF-004设备实时状态PLCMES运行/停机/报警当前产量采集节点每3秒上报接口清单只解决“有没有接口”字段表才解决“接口能不能通”。我做过一个经典案例ERP工单下发MES两边开发前居然都不清楚“计划数量”字段一个用INT一个用DECIMAL联调时发现数量对不上排查两天才定位到类型转换问题。所以需求说明书里每一个接口都至少附一张字段映射表——字段名称、业务含义、数据类型、长度、精度、样例值、是否必填、来源单据。这个习惯能省掉联调阶段至少一半的沟通成本。另外数据字段这个环节常被低估的是主数据统一。物料编码、客户编码、供应商编码在ERP、WMS、MES里必须是一套编码。说明书里要专门写一节“主数据一致性原则”并规定以哪个系统的编码为准。至于技术落地我见过很多项目用若依这类前后端分离脚手架做管理端原型先把字段和流程固化到界面里再拿原型跟车间确认比纯文字需求直观得多——但原型只是辅助最终锁死字段的还是需求说明书里的表格。5. MES需求说明书避坑指南五个让项目翻车的典型问题119页的文档写出来不代表需求就被理解了。我在不同工厂见过大量的MES踩坑案例出问题的模式高度重复。把最常见的五类问题列出来每一条都是“现象→原因→解决”的完整链路值得在编写阶段就对照排查。5.1 需求层次混淆说“透明化”不说“看板”现象需求说明书里写着“实现车间透明化”“做到生产全过程可视”“支撑精益管理”评审时所有人都点头但开发拿到手不知道要建几张表。原因是把战略层目标当成了执行层需求中间缺少分解。解决方法是逐层拆解到可落地的对象车间透明化落到作业进度实时看板、工序在制品数量统计、异常事件实时报警三件具体的事可视化管理落到看板刷新频率、显示维度、统计口径。需求说明书里凡是出现“化”“级”“平台”这类词都要求补一句“具体表现为××功能”。5.2 追溯粒度不写死批次级和SN级成本差好几倍现象只写“支持产品追溯”开发按批次做了上线后质量部说要查单件或者反过来按SN做了发现产线根本没有逐件打码条件扫码效率跟不上。原因是追溯需求没有在说明书里定义追溯单元。解决方法是明确写出追溯粒度原材料批次到成品批次还是单品SN级并且写明追溯链上每个环节的字段来源。如果文档里出现了“追溯”二字必须同时出现“按××查询××”这是我在评审时的高频提问点。5.3 接口边界与责任划分不清ERP和MES扯皮现象ERP工单已经下发MES这边始终收不到两边都说是对方的接口问题排查了一周才发现接口规范里没有定义异常重试机制。原因是需求说明书里的集成章节只写了接口名称没写异常流程和数据责任。解决方法是把IF-001这种接口清单扩展到两层正常数据流和异常处理流。异常处理流要写明——接口失败后是自动重试还是进人工队列、重复工单怎么识别、脏数据由哪个系统的管理员负责清洗。边界清晰了扯皮才有依据。5.4 验收标准不可度量成了甲乙双方的拉锯战现象系统上线后甲方说“报表打开太慢”乙方说“能用就行”因为没有事先定义“慢”的标准。原因在于需求说明书把验收写成了“系统运行稳定、查询响应及时”。解决方法是把验收标准全部量化看板刷新时间不超过3秒、追溯一条SN全链路查询不超过10秒、系统年可用性不低于99.5%、报工数据准确率不低于99.9%。这几个数字不写进文档验收环节就永远是黑匣子。5.5 需求说明书版本不冻结开发到一半需求还在飞现象开发进行到第三个月车间主任说“当时你们理解错了我们现在的工艺已经改了”翻文档发现需求说明书还是三个月前的版本。原因是没有建立需求基线和变更流程。解决办法是在说明书里加一页“文档版本记录”——版本号、修改日期、修改内容、修改人、审批人同时约定文档签署后即冻结任何变更必须走需求变更单。没有这个机制119页的说明书就是一张废纸随时可能被口头需求覆盖。6. 让需求说明书当项目守门员评审、冻结与变更控制文档签完字不是终点是起点。我建议在正式开发前组织三轮评审第一轮业务评审只看第2、4章确认流程没有描述错第二轮技术评审重点看第6、7章的接口和字段表确认开发团队能按数据字典开工第三轮管理层评审确认第9章的验收标准是组织认可的防止验收时项目负责人换人导致口径变化。每次评审都要有评审记录不能开完会就算。关于需求变更我的习惯是设立一个双周变更评审机制需求方提出变更 → 实施方评估工作量 → 变更评审会确认 → 回写需求说明书并升版。回到说明书里改一版重点不是改那几个字而是让所有人知道基线变了。有一年我给一家零部件工厂做MES落地上线前一个月客户提出要加条码打印规则按习惯先走变更单评估后确认要动三个接口和两个报表排期后延两周。如果我当时顺着口头答应项目大概率要在上线验收时背上一个未完成需求。我踩过最大的坑是需求说明书评审时只让IT参加车间主任签字是最后一天匆匆补的。结果上线试运行时车间说“这不是我们要的东西”——一张追溯报表的字段口径IT按成品编号查车间要按生产批次查一个字段差讨论了三天。我后来的习惯是每一份需求说明书必须附一张“关键干系人签字页”流程章节让车间主任签集成章节让IT负责人签验收标准让项目出资人签。签字的意义不是为了免责而是逼他们真正读完自己负责的那一章。执行层的需求变更永远存在但基线清晰、版本回写、变更评审这三件事做到位MES项目翻车的概率会小得多。希望帮到你。本文还有配套的精品资源点击获取
