尧图网站建设 
简介车间制造执行系统(MES)需求说明参考文档是一部面向制造业信息化项目经理、需求分析师及软件实施顾问的模板型资料。文档以技术规格书方式组织先概述项目范围、总体技术要求再分模块梳理系统功能需求。总体技术要求强调基于Web的纯B/S架构、HTML5跨平台以及数据库与Web服务器支持集群和负载均衡等非功能设计功能需求可见生产建模包括物料主数据、生产资源建模、工艺建模排程与调度涉及装配准时化排程、机加工序基于约束有限能力排程、计划下达与监控、工序流转卡管理物料管理涉及配送模式、托盘管理及物料追踪。此外还涵盖了日历、工位、设备、人员等基础数据设计并有与ERP、PLM/CAPP系统集成的要求。整份文档条款式编写既有需求描述又留有待补充项便于结合实际项目快速裁剪成正式的需求说明书或招标技术规格书。资源仅含1个PDF文件大小454KB目前已有334人学习下载适合正在规划MES系统或需要规范需求文档的团队参考。1. 车间制造执行系统(MES)需求说明先想清楚“要什么”再谈“怎么做”MES需求说明不是应付招标用的厚本子更不是产品经理自嗨的功能堆砌。我见过太多生产制造企业上MES第一步就走偏了——花三个月写出来的需求说明车间主任看不懂软件开发看不懂等系统上线两个月现场工人说“这玩意儿还没我Excel好用”。问题不在选型在于需求说明把“车间到底怎么干活”这件事讲岔了。需求说明参考本质上是车间的施工图把现状流程、痛点、目标、功能边界、数据来源、异常处理一次性钉死让实施方、开发方、车间三方对同一件事有同一个理解。这份文档服务的人很明确信息化负责人用它立项招标MES产品经理用它拆功能清单开发用它对接口字段车间主任用它验收系统好不好用。我建议你先别急着找模板先想清楚你的车间是“按订单生产”还是“按库存生产”是“单品小批量”还是“大批量重复”这两件事没定后面所有章节都是白写。2. 先摸清车间底数再写功能需求说明的第一部分是“现状与目标”2.1 用一张表把车间底数梳理清楚别让开发靠猜写需求说明最忌讳的事情是上来就写“系统应支持生产工单管理”。这句话没有信息量。你得让一个从来没进过你车间的开发人员通过第一章就能在脑子里还原出你这个车间的运转方式。我一般会先做一份车间底数表放在需求说明最前面内容大致是这样信息大类需要写清楚的内容举例车间物理布局产线数量、设备数量、关键瓶颈设备3条装配线47台CNC瓶颈为热处理炉生产模式按订单/按库存、单件流/批次流按订单生产批次流转每批200件人员组织班次安排、工种、是否一人多机两班倒每班12人一人看2台CNC计划来源排产由谁做、用Excel还是ERP计划员用Excel排产每日从ERP导入订单数据现状当前有没有条码、RFID、PLC联网只有产品条码设备无联网全靠人工记录痛点清单当前最让车间头疼的3个问题工单进度靠问、质量问题追不到批次、报表靠手工汇总这张表是给整个文档定调的。后续需求说明里所有功能描述都应该是从这张表推出来的。比如你写了“47台CNC设备无联网”那后面就必须有设备数据采集的章节如果你写了“工单进度靠问”那后续必须有什么功能解决这个问题。需求说明最怕写成了“别人家的MES功能介绍”你有哪条产线、哪个工序卡脖子、哪些数据现在拿不到——这些现状描述比功能清单更值钱。我把这段称作“给车间建档”建不清楚后面全是空中楼阁。2.2 把建设目标写到能验收的程度不要写“提高效率”“提高生产效率”“降低在制品库存”——这种目标写了等于没写。需求说明里的目标必须是可量化、可验证的否则项目验收的时候就是扯皮现场。我见过最靠谱的写法是把目标拆成三个层次生产管理指标、数据质量指标、系统使用指标。生产管理指标要落到具体数字上例如“在制品数量降低30%”“报工及时率达到当日95%”“批次追溯时间从2小时缩短到10分钟”。这些数字在需求调研阶段就要跟车间主任确认清楚他认了这个数验收时他就得认这个结果。数据质量指标也很关键比如“关键工序数据录入完整率100%”“设备状态数据采集准确率98%”。系统使用指标是很多人会漏掉的一条如果系统太别扭现场工人三个月后又用回Excel了你还得写“系统日活率不低于车间人数的90%”。这里我要提醒一句目标不是写得越高越好而是写得越“跟现状差距合理”越好。你的车间如果至今没有一张电子化的工艺路线表就别指望MES上线三个月就能做实时排产。需求说明里建议写明“本期目标”和“远期目标”本期目标解决眼下的痛点远期目标给系统留出扩展空间——但扩展空间要用“预留接口”来描述不要写到本期范围里。把目标写死是给项目上保险不然开发做完说“我们功能都实现了”你一看“报工倒是能报但工序流转一股脑儿全靠人工选”验收立刻变成扯皮。2.3 范围边界写清楚不做哪些事情比做哪些更重要MES项目最常见的失控原因是范围蔓延。本来只想做生产跟踪结果工艺部门说“顺便把工艺文档传到工位上吧”质量部门说“那不良品记录也一起做了”设备部门说“设备保养提醒也加一个”。需求说明里如果没有一章节专门写“本系统不做什么”那开发就会默认什么都做然后什么都做不好。按我的习惯边界至少要写三条。第一条是系统边界MES与ERP、PLM、QMS、WMS之间各管什么事数据以谁为准。常见做法是主数据物料、BOM、工艺路线以ERP或PLM为准MES不维护库存账以WMS为准MES只管线边库质量数据以QMS为准MES负责采集现场数据并推送。第二条是组织边界哪些车间、哪些产线在第一期上线哪些留在二期。不要妄图一次性覆盖所有车间不同车间的生产模式如果差异很大宁可先做一个车间做透。第三条是流程边界异常处理流程里哪些角色必须在MES里操作哪些角色仍然走线下。比如“设备故障报修”如果不在本期范围就写清楚“设备报修沿用线下流程MES仅做故障停机记录”。边界写明白的最大好处是让软件供应商报价的时候不敢乱报。你说“工单管理”供应商说“我们有标准功能”你说“不做设备维保、不做排产优化、不做质量管理统计”供应商就得掂量掂量哪些模块是可以砍掉的。需求说明里把“本期不做”列清楚不是缩小系统价值而是把每一分预算都砸在刀刃上。3. 按车间真实流转拆功能模块工单、报工与返工返修怎么落笔3.1 工单管理与派工需求说明里要把“谁建单、拆不拆工序、怎么派”写死工单管理是MES的起点也是需求说明里最容易被写成一堆术语的地方。我不建议你写“系统应支持工单管理”这是废话。你需要写清楚的是三个问题工单从哪里来、到车间后怎么拆、派工给谁。工单来源要明确是MES从ERP自动拉取生产订单还是计划员在MES里手工创建如果有紧急插单谁来批、流程怎么走我建议你写清楚“正常订单通过WebService接口从ERP自动导入插单由生产计划员在MES手工创建但需要车间主任审批”。流程不写清楚开发就会按最简单的方案做结果就是插单无法追溯。第二个问题是工序拆分ERP下达的是生产订单到了车间MES是按照工艺路线自动展开成工序还是计划员手工调整如果你的工艺路线在ERP里本来就不准那MES里的工单拆分会跟实际车间流转大相径庭这时候你要么花力气整顿工艺路线要么在需求说明里写明“首期由计划员在MES中手工维护工序明细MES工艺路线模块二期启用”。第三个问题是派工是计划员在电脑上做“集中派工”还是工人在工位PDA上“自主抢单”这两者的逻辑完全不同前者重计划管控后者重工时采集需求说明里写错一个词开发做出来的交互就天差地别。关于工单状态我强烈建议在需求说明里画一份状态流转图。工单从“创建”到“下达”到“开工”到“完工”到“关闭”中间还有“暂停”“挂起”这两个边缘状态很多需求说明就漏了这两个结果车间一道工序被质检卡住工单挂在“开工”状态回不去也关不掉。用文字描述状态流转比用功能列表管用得多。需求说明是给人看的不是给系统设计的把流程讲清楚比列十个按钮管用。3.2 报工与工时采集多报、漏报、补报是需求说明的必答题报工模块要是只写“工人报工系统记录”那基本等于没写。做过MES的人都清楚报工是现场抵触情绪最大的环节——工人觉得多点一下就是耽误产能领导觉得报工数据不准就等于白做。需求说明里至少要把报工方式、防错逻辑和异常处理三件事写到能开发的程度。报工方式要选定一个主要线索。常见的是“按工序报工”工人干完一道工序在工位终端上刷工单条码、填数量、点提交另一种是“按设备报工”一台设备一个班次加工了哪几个工单、各多少件设备操作工在班次结束时统一汇报。我不建议你在需求说明里让两种方式并存并存就是双轨双轨就会有一个没人填。你还要把“谁来报”写清楚是操作工自己报还是班组长代报代报场景在装配车间很常见代报没问题但必须写明审批关系。防错逻辑是报工需求说明里的重头戏。你需要写清楚三个校验规则第一报工数量不能大于工单剩余数量多报要拦住第二报工工时不能小于该工序的标准工时下限比如一个标准工时5分钟的工序报工工时0.1分钟明显是乱填要么校验拦住要么提示确认第三报工人必须与工单派工人一致除非有代理关系。这三条写在需求说明里开发照做现场才不敢乱来。补报与反冲也要占一小节。工人忘了报第二天想起来要补报这个流程必须有。补报是否要走审批超过多少小时补报需要班长确认返工工时是单独报还是并到原工序这些异常不写清楚上线后工人就只能找开发改后台数据库。我见过最荒唐的项目月末对账发现报工差异很大原因是工人报错工单后无法修改车间主管直接去Oracle数据库里update了。所以需求说明里必须写“已报工数据允许发起冲红/反冲但保留原始记录”给现场一颗后悔药。3.3 返工返修模块需求说明里最容易一笔带过的环节生产制造企业的MES项目里返工返修如果只写“实现返工单管理”六个字上线后一定翻车。返工返修在所有业务模块里最特殊因为它不是一条线性流程而是一条不断分岔的流程。拿汽车水冷板生产线举例一个批次在钎焊工序发现密封性不合格到底是整批返工、还是只返工不良件、还是直接报废返工后是回到原工序、还是走专门的返工工艺路线重新上线检验是回到原检验工序、还是按加严比例抽检这些需求不写清楚开发只能按最粗暴的逻辑实现——“返工单关联原工单重新走一遍工艺路线”然后车间就会发现返工品混进了正常批次质量追溯彻底断掉。返工返修模块的需求描述我建议拆成三个子场景。第一种是“产品返工”产品不合格退回上道工序重新加工。第二种子场景是“产品返修”不拆开、不做整道工序只是补焊、补钻、打磨。返修跟返工的处理方式完全不同返修往往不经过完整工艺路线而是走专线流程。第三种是“降级使用”或“让步接收”不返回生产直接由质量部门判定放行。这三种场景在需求说明里分开列功能点开发才可能把流程设计对。返工返修的数据逻辑也要写透。返工单必须关联原始工单和原始批次否则返工后产品上的新批次号和旧批次号对不上追溯链就断了。返工后的再检验结论如果仍然不合格是允许二次返工还是强制报废返工的工时和材料成本要不要单独统计还是摊到原工单里这些成本核销的问题是你做MES需求说明必须帮财务和生产想清楚的也是MES项目中最常见的模糊地带我建议你用表格把返工类型、触发条件、处理路线、成本归属四项列出来一张表替开发省掉无数个问题。提示返工返修的流程设计不要凭想象写“系统应支持无限次返工”。要限制最大返工次数超过后强制报废。这是给现场一个“止损机制”否则一个零件返工七八次还挂着在制品账永远对不上。4. 数据采集与接口设计从设备联机到WebService把“最后一公里”铺实4.1 数据采集方案选型PLC、扫码枪、RFID还是人工录入需求说明里要写明数据采集是MES落地的硬骨头。需求说明里不要笼统写“系统支持设备数据自动采集”你要写明哪些工序用自动采集、哪些工序用人工录入、哪些工序两种模式并存。判断依据很直白数采的目的是为了拿什么数据。如果只是为了报工数量人工扫码录入就够了没必要花十几万做PLC改造如果是为了监控设备状态和节拍那必须从设备控制器取数。我建议在需求说明里单独做一张“数采点清单”一步到位免去后续扯皮。这张表按工序列出工序名称、设备型号、控制器品牌型号、是否支持联网采集、已有点表/无点表、建议采集方式PLC直采/IO采集/扫码录入/PDA人工录入。对于已经联网的数控机床你还要写明白是采用设备厂商的通讯协议如Fanuc FOCAS、Siemens SINUMERIK还是通过OPC UA统一对接。这条决定了数采开发的难度。有一个坑我必须提醒你很多老旧设备虽然带RS232口但输出的数据格式乱七八糟跟设备厂商工程师扯了两个礼拜才拿到协议文档。需求说明里如果涉及老设备改造一定要写“设备方需提供通讯协议文档且配合MES实施方完成联调测试”把“改设备谁出钱、谁的工程师到场、联调时间怎么算”写清楚写不清后面全是扯皮。人工录入场景也要想清楚。什么样的工序必须扫码确认什么样的工序允许手工填数量需求说明里建议明确规定凡是上了条码/RFID的物料必须扫描批次条码才能报工确实无法扫码的工序例如热处理炉整炉进出允许按炉批号手工录入但必须记录录入人和时间。防呆和可追溯是数据采集章节的核心你要保证任何一个动作都能知道是谁、在哪台设备、什么时间干的。4.2 与ERP/PLM的WebService接口接口清单比功能清单更能暴露问题MES不可能独立存在它上接ERP拿工单和物料下接设备拿状态数据中间还要跟PLM要工艺路线。需求说明里的接口章节不建议写“系统应提供与ERP的标准接口”——这等于把球踢给实施方。你要做的是打开ERP的接口文档跟IT部门的同事一起逐个字段核对。先列接口方向。ERP到MES的主数据接口物料主数据、物料清单BOM、工艺路线、生产订单。MES到ERP的反馈接口报工数量与工时、良品与不良品数量、完工入库信息、物料消耗。如果ERP系统是SAP那你还得在需求说明里明确是用RFC、IDoc还是WebService——这个决定必须在需求文档里写死不然后期实施方和ERP顾问会在这个问题上互踢皮球。拿WebService接口举例需求说明里对每个接口至少写清楚以下信息我一般直接给出这样的表格模版接口名称方向触发方式频率关键字段生产订单下载ERP→MESERP推送/定时轮询每10分钟订单号、物料号、数量、计划开工/完工时间报工结果回传MES→ERP实时触发事件驱动工单号、工序号、报工数量、工时、操作工、设备编号物料消耗回传MES→ERP实时触发事件驱动工单号、物料号、消耗数量、批次号完工入库回传MES→ERP实时触发事件驱动工单号、物料号、完工数量、批次号、仓位字段不下来接口联调的时候就有得吵ERP管“生产订单号”叫OrderNoMES侧叫ProductionOrderID两边开发各写各的最后靠搞一张映射表。所以在需求说明的接口章节里我强烈建议你追加一句“字段映射表由实施方提供初稿甲方IT与ERP顾问确认后作为需求附件。”接口标准定了后面联调少受很多气。4.3 追溯链设计批次与序列号的关系是需求说明里的“硬骨头”可追溯性在汽车零部件、电子制造和医疗器械行业是刚需。需求说明里如果只写“系统应支持产品追溯”那开发一定会给你做个“查询产品序列号显示加工记录”——这远远不够。追溯要回答的问题不是“哪个零件打过什么螺栓”而是“这批零件用了哪家供应商的哪一批原材料、经过了哪些设备、操作工是谁、热处理炉的炉次号是多少”。追溯到工序级还远远不够你至少要追到“物料批次设备人员工艺参数”。这在线索之间需要一层层关联表去支撑。需求说明建议用一句话点透追溯范围“正向追溯从原材料批次查到成品批次及发货去向反向追溯从成品序列号查回原材料的批次、工序流转记录、检验记录、设备参数记录。”然后分条写明必须记录的数据项。我见过有些需求说明把追溯写得很大而全结果实施的时候发现第一步就卡住了——很多关键工序的数据没有采集上追溯链根本拼不起来。所以追溯这一节不要写愿景就写“本期追溯的深度和广度”是什么范围哪些数据必须落库哪些历史批次不需要补录。5. 避坑MES需求说明里最常翻车的5个地方5.1 工序流转状态与报工逻辑冲突数据对不上账现象MES上线后车间里一道工序干了三个班次都没报完工工单卡在“已开工”状态后面的工序发不下去。车间主任天天来信息部门投诉说这系统比Excel还难用。原因需求说明里只写了“按工序报工”没有定义“工序开工”和“工序完工”之间的边界。工人理解的是“活干完才报工”系统理解的是“报工即完工”两道工序之间根本没有“开工”确认环节。工序流转断在了“已开工”到“已完工”之间。解决在需求说明里明确每个工序状态的触发条件。建议写明“工人扫描工单条码并点击‘开工’后系统记录开工时间点击‘完工报工’并输入数量后系统记录完工时间”。如果你不想做得太重至少要写清楚“报工数量达到工单数量时自动置为完工未达到时工单保持开工状态”。这种状态机的定义应该在需求说明正文里给出一张表格一列状态、一列触发动作、一列操作角色开发拿到手直接建状态机。5.2 返工返修流程被设计成死循环批次号已流转到后道工序现象返工品回到原工序后又重新生成了新的工序流转记录但后道工序已经扫过旧条码入库了。返工品混在正常品里扫码一查发现同一个序列号出现在两条流转记录里数据直接乱掉。原因需求说明里没有限制返工次数也没有定义返工后批次的“重打码”规则。返工流程与正常流程混用同一套报工逻辑系统无法识别返工批次与原始批次之间的父子关系。解决需求说明里写一条硬规则返工单必须关联原始生产工单号和原始批次号返工完成后生成新的批次号但在系统内部维护“批次追溯关系表”记录新旧批次的替换关系。同时限制返工次数最多3次超过则强制报废。这条规则不需要开发做多复杂的逻辑但在需求阶段不下定论上线后就是一场数据灾难。5.3 接口字段明明对齐了联调时还是报错原因是两边维护的数据标准不一致现象ERP推下来的生产订单在MES里查不到物料号。IT查了半天发现ERP里物料号是30位的字母数字混合MES数据库设计成了20位字符截断之后后面全是乱码。原因需求说明里写了字段名称但没有写字段类型、长度和校验规则。两边开发都以为自己“按标准做了”其实是各做各的。解决需求说明中每个接口除了字段名还要规定类型、长度、是否必填、缺省值。ERP的物料号如果是30位MES这边字段就得设计成32位。同时写清楚“主数据一致性校验规则”MES每日启动时对一次物料主数据长度不一致或类型不匹配的直接报错并停用传输不允许“先入库后补全”。接口字段定义不是开发阶段的事而是需求阶段就要锁死的事。5.4 权限模型只分了“管理员”和“操作工”结果车间主任要改数据谁也拦不住现象车间主任觉得工单数量不对直接让信息技术人员把数据库锁解开自己改了报工数量月底对账发现跟ERP差异巨大追也追不回来。原因需求说明里的权限管理只写了“不同角色登录可见不同菜单”没有写“谁可以修改哪些关键业务数据、是否需要审批”。解决权限描述不能只写角色要把“对象动作范围”写全。比如操作工可以修改“当天本人的报工记录”不能修改“已完成确认报工数据”车间主任可以修改“未流转至下道工序的报工数量”但每笔修改需留痕并触发审批通知。修改已入库工单数据必须走“冲销重报”流程。审批流的设计要在需求说明里画出来哪怕只是文字描述每个环节的角色与动作。5.5 需求说明没有异常处理章节上线后遇到“设备宕机、扫码枪损坏、断网”就抓瞎现象车间里扫码枪坏了工人没法报工直接拿纸笔记录半天下来二十几个工单都没录进系统。等扫码枪修好工人补了三个小时还漏了两个。原因需求说明里所有流程都按“正常情况”写的没有一处写“如果扫码枪坏了怎么办”。补录、离线模式、冗余设备这些兜底机制一个字母都没提。解决需求说明增加一个“异常场景处理”小节至少覆盖四类场景断网时允许离线报工数据保存在本地缓存网络恢复后自动上传扫码枪故障时允许手工输入工单号报工但记录异常标记设备宕机时的工单挂起与恢复流程月末系统对账发现差异时的调整权限和流程。每一类都要写清楚谁发现、谁处理、有没有审批、数据怎么补。MES是车间里的生产工具不是实验室的系统绝对不能设计成“不可中断”。6. 用需求评审清单给MES需求说明做“竣工验收”让问题在招标前现形需求说明写完不要急着发给供应商先组织一个评审会。评审会不要只叫IT和信息化部门要把车间主任、工艺工程师、质量工程师、生产计划员、设备管理员叫到一张桌子上逐条过功能清单去确认这个文档跟车间的实际流转匹配不匹配的地方当场改。一个高效的评审方式是拿着需求说明去车间现场逐条走一遍走到设备旁边就问“这个设备支持自动采集吗”走到检验台就问“不合格品这个流程你们是这么操作的吗”需求说明是不是靠谱看一段就知道。评审会上要重点确认三个反向问题哪个功能本期不做哪个流程跟现在不一样哪个数据要录而我们目前没有这三个问题过完需求说明的正式版就可以定了。为了让评审过程更高效我习惯把需求说明的最后一面做成一张“需求确认清单”里的每一行是一个核心需求点后面留三列由评审人逐条签字。这张评审清单不用列得很碎抓关键事项即可工单状态流转是否符合现场各岗位权限是否与组织架构匹配报工数据是否真实反映车间产能返工返修流程是否存在失控风险接口字段定义是否与ERP一致异常场景处理是否全覆盖。把这些评审项走完一份合格的需求说明才算是真正落地了。最后说一点我的体感MES需求说明是一份“写的时候难受、用的时候真香”的文档。我经手过一个项目需求说明写了两个月车间里每个工位都蹲过一开始车间主任很反感到最后他也承认“要是当初没写这份东西光扯皮就够喝一壶的”。做MES系统需求说明不是给软件公司看的是给你的车间、你的管理、你的未来信息化留一份底稿。把我上面说的这些坑和判断标准带进你的项目里希望你少走我走过的弯路希望帮到你。本文还有配套的精品资源点击获取 如何写好MES需求说明？从车间现状到功能落地的完整指南
简介车间制造执行系统(MES)需求说明参考文档是一部面向制造业信息化项目经理、需求分析师及软件实施顾问的模板型资料。文档以技术规格书方式组织先概述项目范围、总体技术要求再分模块梳理系统功能需求。总体技术要求强调基于Web的纯B/S架构、HTML5跨平台以及数据库与Web服务器支持集群和负载均衡等非功能设计功能需求可见生产建模包括物料主数据、生产资源建模、工艺建模排程与调度涉及装配准时化排程、机加工序基于约束有限能力排程、计划下达与监控、工序流转卡管理物料管理涉及配送模式、托盘管理及物料追踪。此外还涵盖了日历、工位、设备、人员等基础数据设计并有与ERP、PLM/CAPP系统集成的要求。整份文档条款式编写既有需求描述又留有待补充项便于结合实际项目快速裁剪成正式的需求说明书或招标技术规格书。资源仅含1个PDF文件大小454KB目前已有334人学习下载适合正在规划MES系统或需要规范需求文档的团队参考。1. 车间制造执行系统(MES)需求说明先想清楚“要什么”再谈“怎么做”MES需求说明不是应付招标用的厚本子更不是产品经理自嗨的功能堆砌。我见过太多生产制造企业上MES第一步就走偏了——花三个月写出来的需求说明车间主任看不懂软件开发看不懂等系统上线两个月现场工人说“这玩意儿还没我Excel好用”。问题不在选型在于需求说明把“车间到底怎么干活”这件事讲岔了。需求说明参考本质上是车间的施工图把现状流程、痛点、目标、功能边界、数据来源、异常处理一次性钉死让实施方、开发方、车间三方对同一件事有同一个理解。这份文档服务的人很明确信息化负责人用它立项招标MES产品经理用它拆功能清单开发用它对接口字段车间主任用它验收系统好不好用。我建议你先别急着找模板先想清楚你的车间是“按订单生产”还是“按库存生产”是“单品小批量”还是“大批量重复”这两件事没定后面所有章节都是白写。2. 先摸清车间底数再写功能需求说明的第一部分是“现状与目标”2.1 用一张表把车间底数梳理清楚别让开发靠猜写需求说明最忌讳的事情是上来就写“系统应支持生产工单管理”。这句话没有信息量。你得让一个从来没进过你车间的开发人员通过第一章就能在脑子里还原出你这个车间的运转方式。我一般会先做一份车间底数表放在需求说明最前面内容大致是这样信息大类需要写清楚的内容举例车间物理布局产线数量、设备数量、关键瓶颈设备3条装配线47台CNC瓶颈为热处理炉生产模式按订单/按库存、单件流/批次流按订单生产批次流转每批200件人员组织班次安排、工种、是否一人多机两班倒每班12人一人看2台CNC计划来源排产由谁做、用Excel还是ERP计划员用Excel排产每日从ERP导入订单数据现状当前有没有条码、RFID、PLC联网只有产品条码设备无联网全靠人工记录痛点清单当前最让车间头疼的3个问题工单进度靠问、质量问题追不到批次、报表靠手工汇总这张表是给整个文档定调的。后续需求说明里所有功能描述都应该是从这张表推出来的。比如你写了“47台CNC设备无联网”那后面就必须有设备数据采集的章节如果你写了“工单进度靠问”那后续必须有什么功能解决这个问题。需求说明最怕写成了“别人家的MES功能介绍”你有哪条产线、哪个工序卡脖子、哪些数据现在拿不到——这些现状描述比功能清单更值钱。我把这段称作“给车间建档”建不清楚后面全是空中楼阁。2.2 把建设目标写到能验收的程度不要写“提高效率”“提高生产效率”“降低在制品库存”——这种目标写了等于没写。需求说明里的目标必须是可量化、可验证的否则项目验收的时候就是扯皮现场。我见过最靠谱的写法是把目标拆成三个层次生产管理指标、数据质量指标、系统使用指标。生产管理指标要落到具体数字上例如“在制品数量降低30%”“报工及时率达到当日95%”“批次追溯时间从2小时缩短到10分钟”。这些数字在需求调研阶段就要跟车间主任确认清楚他认了这个数验收时他就得认这个结果。数据质量指标也很关键比如“关键工序数据录入完整率100%”“设备状态数据采集准确率98%”。系统使用指标是很多人会漏掉的一条如果系统太别扭现场工人三个月后又用回Excel了你还得写“系统日活率不低于车间人数的90%”。这里我要提醒一句目标不是写得越高越好而是写得越“跟现状差距合理”越好。你的车间如果至今没有一张电子化的工艺路线表就别指望MES上线三个月就能做实时排产。需求说明里建议写明“本期目标”和“远期目标”本期目标解决眼下的痛点远期目标给系统留出扩展空间——但扩展空间要用“预留接口”来描述不要写到本期范围里。把目标写死是给项目上保险不然开发做完说“我们功能都实现了”你一看“报工倒是能报但工序流转一股脑儿全靠人工选”验收立刻变成扯皮。2.3 范围边界写清楚不做哪些事情比做哪些更重要MES项目最常见的失控原因是范围蔓延。本来只想做生产跟踪结果工艺部门说“顺便把工艺文档传到工位上吧”质量部门说“那不良品记录也一起做了”设备部门说“设备保养提醒也加一个”。需求说明里如果没有一章节专门写“本系统不做什么”那开发就会默认什么都做然后什么都做不好。按我的习惯边界至少要写三条。第一条是系统边界MES与ERP、PLM、QMS、WMS之间各管什么事数据以谁为准。常见做法是主数据物料、BOM、工艺路线以ERP或PLM为准MES不维护库存账以WMS为准MES只管线边库质量数据以QMS为准MES负责采集现场数据并推送。第二条是组织边界哪些车间、哪些产线在第一期上线哪些留在二期。不要妄图一次性覆盖所有车间不同车间的生产模式如果差异很大宁可先做一个车间做透。第三条是流程边界异常处理流程里哪些角色必须在MES里操作哪些角色仍然走线下。比如“设备故障报修”如果不在本期范围就写清楚“设备报修沿用线下流程MES仅做故障停机记录”。边界写明白的最大好处是让软件供应商报价的时候不敢乱报。你说“工单管理”供应商说“我们有标准功能”你说“不做设备维保、不做排产优化、不做质量管理统计”供应商就得掂量掂量哪些模块是可以砍掉的。需求说明里把“本期不做”列清楚不是缩小系统价值而是把每一分预算都砸在刀刃上。3. 按车间真实流转拆功能模块工单、报工与返工返修怎么落笔3.1 工单管理与派工需求说明里要把“谁建单、拆不拆工序、怎么派”写死工单管理是MES的起点也是需求说明里最容易被写成一堆术语的地方。我不建议你写“系统应支持工单管理”这是废话。你需要写清楚的是三个问题工单从哪里来、到车间后怎么拆、派工给谁。工单来源要明确是MES从ERP自动拉取生产订单还是计划员在MES里手工创建如果有紧急插单谁来批、流程怎么走我建议你写清楚“正常订单通过WebService接口从ERP自动导入插单由生产计划员在MES手工创建但需要车间主任审批”。流程不写清楚开发就会按最简单的方案做结果就是插单无法追溯。第二个问题是工序拆分ERP下达的是生产订单到了车间MES是按照工艺路线自动展开成工序还是计划员手工调整如果你的工艺路线在ERP里本来就不准那MES里的工单拆分会跟实际车间流转大相径庭这时候你要么花力气整顿工艺路线要么在需求说明里写明“首期由计划员在MES中手工维护工序明细MES工艺路线模块二期启用”。第三个问题是派工是计划员在电脑上做“集中派工”还是工人在工位PDA上“自主抢单”这两者的逻辑完全不同前者重计划管控后者重工时采集需求说明里写错一个词开发做出来的交互就天差地别。关于工单状态我强烈建议在需求说明里画一份状态流转图。工单从“创建”到“下达”到“开工”到“完工”到“关闭”中间还有“暂停”“挂起”这两个边缘状态很多需求说明就漏了这两个结果车间一道工序被质检卡住工单挂在“开工”状态回不去也关不掉。用文字描述状态流转比用功能列表管用得多。需求说明是给人看的不是给系统设计的把流程讲清楚比列十个按钮管用。3.2 报工与工时采集多报、漏报、补报是需求说明的必答题报工模块要是只写“工人报工系统记录”那基本等于没写。做过MES的人都清楚报工是现场抵触情绪最大的环节——工人觉得多点一下就是耽误产能领导觉得报工数据不准就等于白做。需求说明里至少要把报工方式、防错逻辑和异常处理三件事写到能开发的程度。报工方式要选定一个主要线索。常见的是“按工序报工”工人干完一道工序在工位终端上刷工单条码、填数量、点提交另一种是“按设备报工”一台设备一个班次加工了哪几个工单、各多少件设备操作工在班次结束时统一汇报。我不建议你在需求说明里让两种方式并存并存就是双轨双轨就会有一个没人填。你还要把“谁来报”写清楚是操作工自己报还是班组长代报代报场景在装配车间很常见代报没问题但必须写明审批关系。防错逻辑是报工需求说明里的重头戏。你需要写清楚三个校验规则第一报工数量不能大于工单剩余数量多报要拦住第二报工工时不能小于该工序的标准工时下限比如一个标准工时5分钟的工序报工工时0.1分钟明显是乱填要么校验拦住要么提示确认第三报工人必须与工单派工人一致除非有代理关系。这三条写在需求说明里开发照做现场才不敢乱来。补报与反冲也要占一小节。工人忘了报第二天想起来要补报这个流程必须有。补报是否要走审批超过多少小时补报需要班长确认返工工时是单独报还是并到原工序这些异常不写清楚上线后工人就只能找开发改后台数据库。我见过最荒唐的项目月末对账发现报工差异很大原因是工人报错工单后无法修改车间主管直接去Oracle数据库里update了。所以需求说明里必须写“已报工数据允许发起冲红/反冲但保留原始记录”给现场一颗后悔药。3.3 返工返修模块需求说明里最容易一笔带过的环节生产制造企业的MES项目里返工返修如果只写“实现返工单管理”六个字上线后一定翻车。返工返修在所有业务模块里最特殊因为它不是一条线性流程而是一条不断分岔的流程。拿汽车水冷板生产线举例一个批次在钎焊工序发现密封性不合格到底是整批返工、还是只返工不良件、还是直接报废返工后是回到原工序、还是走专门的返工工艺路线重新上线检验是回到原检验工序、还是按加严比例抽检这些需求不写清楚开发只能按最粗暴的逻辑实现——“返工单关联原工单重新走一遍工艺路线”然后车间就会发现返工品混进了正常批次质量追溯彻底断掉。返工返修模块的需求描述我建议拆成三个子场景。第一种是“产品返工”产品不合格退回上道工序重新加工。第二种子场景是“产品返修”不拆开、不做整道工序只是补焊、补钻、打磨。返修跟返工的处理方式完全不同返修往往不经过完整工艺路线而是走专线流程。第三种是“降级使用”或“让步接收”不返回生产直接由质量部门判定放行。这三种场景在需求说明里分开列功能点开发才可能把流程设计对。返工返修的数据逻辑也要写透。返工单必须关联原始工单和原始批次否则返工后产品上的新批次号和旧批次号对不上追溯链就断了。返工后的再检验结论如果仍然不合格是允许二次返工还是强制报废返工的工时和材料成本要不要单独统计还是摊到原工单里这些成本核销的问题是你做MES需求说明必须帮财务和生产想清楚的也是MES项目中最常见的模糊地带我建议你用表格把返工类型、触发条件、处理路线、成本归属四项列出来一张表替开发省掉无数个问题。提示返工返修的流程设计不要凭想象写“系统应支持无限次返工”。要限制最大返工次数超过后强制报废。这是给现场一个“止损机制”否则一个零件返工七八次还挂着在制品账永远对不上。4. 数据采集与接口设计从设备联机到WebService把“最后一公里”铺实4.1 数据采集方案选型PLC、扫码枪、RFID还是人工录入需求说明里要写明数据采集是MES落地的硬骨头。需求说明里不要笼统写“系统支持设备数据自动采集”你要写明哪些工序用自动采集、哪些工序用人工录入、哪些工序两种模式并存。判断依据很直白数采的目的是为了拿什么数据。如果只是为了报工数量人工扫码录入就够了没必要花十几万做PLC改造如果是为了监控设备状态和节拍那必须从设备控制器取数。我建议在需求说明里单独做一张“数采点清单”一步到位免去后续扯皮。这张表按工序列出工序名称、设备型号、控制器品牌型号、是否支持联网采集、已有点表/无点表、建议采集方式PLC直采/IO采集/扫码录入/PDA人工录入。对于已经联网的数控机床你还要写明白是采用设备厂商的通讯协议如Fanuc FOCAS、Siemens SINUMERIK还是通过OPC UA统一对接。这条决定了数采开发的难度。有一个坑我必须提醒你很多老旧设备虽然带RS232口但输出的数据格式乱七八糟跟设备厂商工程师扯了两个礼拜才拿到协议文档。需求说明里如果涉及老设备改造一定要写“设备方需提供通讯协议文档且配合MES实施方完成联调测试”把“改设备谁出钱、谁的工程师到场、联调时间怎么算”写清楚写不清后面全是扯皮。人工录入场景也要想清楚。什么样的工序必须扫码确认什么样的工序允许手工填数量需求说明里建议明确规定凡是上了条码/RFID的物料必须扫描批次条码才能报工确实无法扫码的工序例如热处理炉整炉进出允许按炉批号手工录入但必须记录录入人和时间。防呆和可追溯是数据采集章节的核心你要保证任何一个动作都能知道是谁、在哪台设备、什么时间干的。4.2 与ERP/PLM的WebService接口接口清单比功能清单更能暴露问题MES不可能独立存在它上接ERP拿工单和物料下接设备拿状态数据中间还要跟PLM要工艺路线。需求说明里的接口章节不建议写“系统应提供与ERP的标准接口”——这等于把球踢给实施方。你要做的是打开ERP的接口文档跟IT部门的同事一起逐个字段核对。先列接口方向。ERP到MES的主数据接口物料主数据、物料清单BOM、工艺路线、生产订单。MES到ERP的反馈接口报工数量与工时、良品与不良品数量、完工入库信息、物料消耗。如果ERP系统是SAP那你还得在需求说明里明确是用RFC、IDoc还是WebService——这个决定必须在需求文档里写死不然后期实施方和ERP顾问会在这个问题上互踢皮球。拿WebService接口举例需求说明里对每个接口至少写清楚以下信息我一般直接给出这样的表格模版接口名称方向触发方式频率关键字段生产订单下载ERP→MESERP推送/定时轮询每10分钟订单号、物料号、数量、计划开工/完工时间报工结果回传MES→ERP实时触发事件驱动工单号、工序号、报工数量、工时、操作工、设备编号物料消耗回传MES→ERP实时触发事件驱动工单号、物料号、消耗数量、批次号完工入库回传MES→ERP实时触发事件驱动工单号、物料号、完工数量、批次号、仓位字段不下来接口联调的时候就有得吵ERP管“生产订单号”叫OrderNoMES侧叫ProductionOrderID两边开发各写各的最后靠搞一张映射表。所以在需求说明的接口章节里我强烈建议你追加一句“字段映射表由实施方提供初稿甲方IT与ERP顾问确认后作为需求附件。”接口标准定了后面联调少受很多气。4.3 追溯链设计批次与序列号的关系是需求说明里的“硬骨头”可追溯性在汽车零部件、电子制造和医疗器械行业是刚需。需求说明里如果只写“系统应支持产品追溯”那开发一定会给你做个“查询产品序列号显示加工记录”——这远远不够。追溯要回答的问题不是“哪个零件打过什么螺栓”而是“这批零件用了哪家供应商的哪一批原材料、经过了哪些设备、操作工是谁、热处理炉的炉次号是多少”。追溯到工序级还远远不够你至少要追到“物料批次设备人员工艺参数”。这在线索之间需要一层层关联表去支撑。需求说明建议用一句话点透追溯范围“正向追溯从原材料批次查到成品批次及发货去向反向追溯从成品序列号查回原材料的批次、工序流转记录、检验记录、设备参数记录。”然后分条写明必须记录的数据项。我见过有些需求说明把追溯写得很大而全结果实施的时候发现第一步就卡住了——很多关键工序的数据没有采集上追溯链根本拼不起来。所以追溯这一节不要写愿景就写“本期追溯的深度和广度”是什么范围哪些数据必须落库哪些历史批次不需要补录。5. 避坑MES需求说明里最常翻车的5个地方5.1 工序流转状态与报工逻辑冲突数据对不上账现象MES上线后车间里一道工序干了三个班次都没报完工工单卡在“已开工”状态后面的工序发不下去。车间主任天天来信息部门投诉说这系统比Excel还难用。原因需求说明里只写了“按工序报工”没有定义“工序开工”和“工序完工”之间的边界。工人理解的是“活干完才报工”系统理解的是“报工即完工”两道工序之间根本没有“开工”确认环节。工序流转断在了“已开工”到“已完工”之间。解决在需求说明里明确每个工序状态的触发条件。建议写明“工人扫描工单条码并点击‘开工’后系统记录开工时间点击‘完工报工’并输入数量后系统记录完工时间”。如果你不想做得太重至少要写清楚“报工数量达到工单数量时自动置为完工未达到时工单保持开工状态”。这种状态机的定义应该在需求说明正文里给出一张表格一列状态、一列触发动作、一列操作角色开发拿到手直接建状态机。5.2 返工返修流程被设计成死循环批次号已流转到后道工序现象返工品回到原工序后又重新生成了新的工序流转记录但后道工序已经扫过旧条码入库了。返工品混在正常品里扫码一查发现同一个序列号出现在两条流转记录里数据直接乱掉。原因需求说明里没有限制返工次数也没有定义返工后批次的“重打码”规则。返工流程与正常流程混用同一套报工逻辑系统无法识别返工批次与原始批次之间的父子关系。解决需求说明里写一条硬规则返工单必须关联原始生产工单号和原始批次号返工完成后生成新的批次号但在系统内部维护“批次追溯关系表”记录新旧批次的替换关系。同时限制返工次数最多3次超过则强制报废。这条规则不需要开发做多复杂的逻辑但在需求阶段不下定论上线后就是一场数据灾难。5.3 接口字段明明对齐了联调时还是报错原因是两边维护的数据标准不一致现象ERP推下来的生产订单在MES里查不到物料号。IT查了半天发现ERP里物料号是30位的字母数字混合MES数据库设计成了20位字符截断之后后面全是乱码。原因需求说明里写了字段名称但没有写字段类型、长度和校验规则。两边开发都以为自己“按标准做了”其实是各做各的。解决需求说明中每个接口除了字段名还要规定类型、长度、是否必填、缺省值。ERP的物料号如果是30位MES这边字段就得设计成32位。同时写清楚“主数据一致性校验规则”MES每日启动时对一次物料主数据长度不一致或类型不匹配的直接报错并停用传输不允许“先入库后补全”。接口字段定义不是开发阶段的事而是需求阶段就要锁死的事。5.4 权限模型只分了“管理员”和“操作工”结果车间主任要改数据谁也拦不住现象车间主任觉得工单数量不对直接让信息技术人员把数据库锁解开自己改了报工数量月底对账发现跟ERP差异巨大追也追不回来。原因需求说明里的权限管理只写了“不同角色登录可见不同菜单”没有写“谁可以修改哪些关键业务数据、是否需要审批”。解决权限描述不能只写角色要把“对象动作范围”写全。比如操作工可以修改“当天本人的报工记录”不能修改“已完成确认报工数据”车间主任可以修改“未流转至下道工序的报工数量”但每笔修改需留痕并触发审批通知。修改已入库工单数据必须走“冲销重报”流程。审批流的设计要在需求说明里画出来哪怕只是文字描述每个环节的角色与动作。5.5 需求说明没有异常处理章节上线后遇到“设备宕机、扫码枪损坏、断网”就抓瞎现象车间里扫码枪坏了工人没法报工直接拿纸笔记录半天下来二十几个工单都没录进系统。等扫码枪修好工人补了三个小时还漏了两个。原因需求说明里所有流程都按“正常情况”写的没有一处写“如果扫码枪坏了怎么办”。补录、离线模式、冗余设备这些兜底机制一个字母都没提。解决需求说明增加一个“异常场景处理”小节至少覆盖四类场景断网时允许离线报工数据保存在本地缓存网络恢复后自动上传扫码枪故障时允许手工输入工单号报工但记录异常标记设备宕机时的工单挂起与恢复流程月末系统对账发现差异时的调整权限和流程。每一类都要写清楚谁发现、谁处理、有没有审批、数据怎么补。MES是车间里的生产工具不是实验室的系统绝对不能设计成“不可中断”。6. 用需求评审清单给MES需求说明做“竣工验收”让问题在招标前现形需求说明写完不要急着发给供应商先组织一个评审会。评审会不要只叫IT和信息化部门要把车间主任、工艺工程师、质量工程师、生产计划员、设备管理员叫到一张桌子上逐条过功能清单去确认这个文档跟车间的实际流转匹配不匹配的地方当场改。一个高效的评审方式是拿着需求说明去车间现场逐条走一遍走到设备旁边就问“这个设备支持自动采集吗”走到检验台就问“不合格品这个流程你们是这么操作的吗”需求说明是不是靠谱看一段就知道。评审会上要重点确认三个反向问题哪个功能本期不做哪个流程跟现在不一样哪个数据要录而我们目前没有这三个问题过完需求说明的正式版就可以定了。为了让评审过程更高效我习惯把需求说明的最后一面做成一张“需求确认清单”里的每一行是一个核心需求点后面留三列由评审人逐条签字。这张评审清单不用列得很碎抓关键事项即可工单状态流转是否符合现场各岗位权限是否与组织架构匹配报工数据是否真实反映车间产能返工返修流程是否存在失控风险接口字段定义是否与ERP一致异常场景处理是否全覆盖。把这些评审项走完一份合格的需求说明才算是真正落地了。最后说一点我的体感MES需求说明是一份“写的时候难受、用的时候真香”的文档。我经手过一个项目需求说明写了两个月车间里每个工位都蹲过一开始车间主任很反感到最后他也承认“要是当初没写这份东西光扯皮就够喝一壶的”。做MES系统需求说明不是给软件公司看的是给你的车间、你的管理、你的未来信息化留一份底稿。把我上面说的这些坑和判断标准带进你的项目里希望你少走我走过的弯路希望帮到你。本文还有配套的精品资源点击获取