简介制造执行系统MES处于企业资源计划ERP与车间底层设备之间承担着从工单下达到产品完工的全过程管理。明确的系统边界与结构化需求是MES落地的核心前提。一份合格的需求文档需拆解生产工单、排产调度、物料追溯、数据采集等模块并定义追溯粒度、设备接口、断网兜底等非功能性指标。本文结合真实项目经验从功能模块拆解、接口关系、术语统一到需求评审验收系统梳理MES需求文档的编写方法与避坑指南帮助甲方与实施方对齐预期降低交付风险。 去年年底我给一家机加工企业做MES选型咨询对方项目负责人发来一份PDF文件名就叫“车间制造执行系统(MES)---需求说明(参考).pdf”。我当时扫了一眼第一反应是这年头能拿出一份像样需求说明的甲方不多了。看完后发现这份文档虽然是“参考版”但结构、颗粒度都挺到位基本把MES项目前期最容易扯皮的事都讲清楚了。这份需求说明并不长但对“MES系统有哪些功能”“MES和ERP怎么分工”“现场数据怎么采”这些问题都有明确回答。这篇文章我就以这份需求说明为引子结合我在多个MES项目里踩过的坑把车间制造执行系统需求文档该怎么写、怎么读、怎么落地这件事掰开揉碎聊一遍。不管你是甲方项目经理、车间主任还是刚入行的实施顾问只要你想搞清楚MES项目到底要做什么、需求要细化到什么程度这篇文章应该能帮你省下不少弯路。1. 需求说明究竟解决什么问题先别急着谈功能定位比功能重要MESManufacturing Execution System制造执行系统被夹在ERP和底层设备之间很容易被误解成“ERP的子系统”或者“高级版报工软件”。我见过太多企业上ERP时觉得够了后来发现车间里全是信息孤岛才回头补MES。这份需求说明的第一页就在讲这件事MES管的是从工单下达到产品完工之间的所有执行过程核心目标是让车间“透明化、可追溯、能改善”。1.1 用一个车间调度员的视角理解MES的边界你可以把ERP理解成企业的“大脑”它负责算物料需求、下采购计划、排财务账。但大脑下了指令之后手脚怎么动是MES的事。工单到车间之后先做不做、先做哪个、这台设备够不够、物料齐不齐、加工到哪一步了、这个批次用了哪些原料、质检有没有过——这些在ERP里往往是黑盒而在MES里是逐条记录、实时反馈的。需求说明里写得比较清楚MES要承接ERP的生产订单向下要采集设备、人员、物料、质量数据向上要把完工信息反馈给ERP。这句话听起来简单但真正落地时大部分吵架都发生在边界问题上。比如ERP已经下了生产订单但车间临时调整了加工顺序这个信息要不要回传质检不合格要返工ERP库存怎么扣如果需求文档里没有提前定义这些交互规则后面就是无休止的接口扯皮。1.2 一份合格需求说明的三层结构这份PDF的结构我拆解下来无非三层业务现状与目标、功能需求按模块分、非功能需求性能、接口、权限、追溯要求。很多企业写需求文档时只写功能列表比如“要有排产模块”“要有质量模块”这其实只是目录不是需求。真正的需求要能回答三个问题谁来用角色、做什么动作功能、出了问题怎么办异常流程。比如“班组长可以在Pad上对工单进行开工操作并录入实际开始时间”——这算一条能落地的需求。而“系统应支持生产调度”这种纯属浪费纸张。需求说明里最好每个功能项都带编号、带优先级、带验收标准后面做UAT用户验收测试时才能逐条核对避免“做完之后才发现不是我要的”。2. 核心功能模块的拆解从工单到追溯每个模块都有隐藏的坑这份需求说明把MES功能分成六大块生产工单管理、排产与调度、数据采集与追溯、质量管理、设备管理、绩效与看板。这基本覆盖了市面上主流MES的标准范围。但每个模块里都有一些细节需求文档里未必会展开而恰恰是这些细节决定项目成败。2.1 生产工单与排产调度需求要从“异常场景”写起工单管理不只是把ERP的订单接进来再转给车间它还要处理拆单、合并、插单、改单这些日常操作。比如一个1000件的大订单车间不可能一次投料往往要按批量拆成多个生产批。需求里要明确拆单规则按数量拆还是按工艺路线拆拆出来的子工单要不要单独算成本插单加急单进来后原有排产计划怎么调整我在一个项目里就吃过亏客户提“系统要支持插单”结果实施时才发现他们的“插单”不是把新单排到最前面而是要把某条产线上正在做的半成品全部下线换成急单做完再换回来。这个操作涉及物料回退、工时重算、质量状态变更远比“调整优先级”复杂。如果需求阶段没把这些异常场景聊透开发到一半需求变更项目周期直接翻倍。排产调度这块需求说明一般不会要求“自动排产”大多数企业现阶段能接受的是“排产辅助”。也就是系统展示设备负载、工序工时、物料齐套情况调度员人工拖拽调整。真正全自动的APS高级排程牵扯约束条件太多不是MES的核心任务。写需求时建议把“人工排产为主、系统提供可视化辅助”作为默认基调能省掉很多不切实际的预期。2.2 物料追溯与数据采集追溯粒度是第一个要拍板的事凡是涉及追溯的需求第一件事就是定粒度批次级追溯还是单件级追溯。批次级的意思是这一批料用到哪个生产批、成品去了哪能追溯到“一批”的层面单件级则是每一件产品都有唯一SN码能查清楚这个SN用了哪个炉批的钢材、哪台机床加工、哪个操作工做的、检测数据是多少。这两个方向的工作量天差地别。批次级一般靠“工单物料批次号”绑定扫描工作量小单件级则需要每件产品贴码、每道工序扫码对产线节拍有要求。需求文档里如果只写“实现正反向追溯”而不写粒度报价和排期都没法估准。我建议在需求阶段就明确“追溯的最小单元是什么”“追溯到工序还是追溯到设备”“是否要求首件记录和过程参数绑定”。数据采集方式也要提前定。常见的三种PLC自动采集设备有接口、扫码枪半自动采集人工扫工单和SN、Pad手动录入适用于没有自动化条件的工位。需求文档里要对每个数据项标注来源方式比如“设备状态通过PLC每5秒采集一次”“完工数量操作工在Pad上手工录入”。这个细节决定了现场的网络布点、硬件选型甚至影响整个项目的预算量级。2.3 质量、设备与绩效那些容易被忽视的隐性需求质量管理模块大多数需求文档会写“来料检验、过程检验、完工检验、不合格品处理”。但真正决定质量模块好用不好用的是它和工单、物料、设备的数据打通程度。比如过程检验发现一批料不合格系统能不能自动锁定相关工单、禁止继续投料返工流程走完之后检验记录能不能保留原始数据而不是覆盖这些都值得写进需求。设备管理重点不只是“点检保养”更是OEE设备综合效率的计算口径。需求文档里要定义清楚OEE的时间损失怎么算计划停机比如保养、换型算不算进理论运行时间一条产线有多台设备OEE按瓶颈设备算还是按产线整体算不少企业看到系统里的OEE觉得“不准”原因就是口径没在需求阶段锁定。绩效与看板模块需求文档里容易写成“展示产量、合格率、设备状态”。但实际实施时如果工位、班组、产品的关系没定义清楚看板上的数据分分钟错乱。我建议绩效报表的需求先梳理“组织和岗位维度”也就是谁看这张报表、按什么维度分组、数据刷新频率是多少。MES看板的技术栈用C#开发后台、Web前端展示是非常常见的组合因为工厂里Windows生态占主流运维团队熟悉.Net的比熟悉别的多需求文档里不用规定语言但可以写明“看板需支持网页访问方便投到车间大屏”。3. 非功能性需求和接口决定系统能不能真正活下来功能需求决定系统“有没有”非功能性需求决定系统“好不好用、能不能用住”。很多需求文档重功能、轻性能结果系统上线后天天被车间吐槽“转圈圈”。这一部分我重点聊三件事性能与可靠性、接口关系、术语统一。3.1 性能指标、断网兜底和数据安全性能指标必须量化。比如“扫码响应时间不超过1秒”“看板数据刷新延迟不超过3秒”“支持200个并发用户在线操作”。这些数字不用多专业但一定要写因为它直接决定架构设计和硬件选型。工厂车间网络环境不比写字楼经常有电磁干扰、跨厂房光纤距离远的问题需求里最好明确“无线网络覆盖所有作业区域关键数据采集点有线备份”。更关键的是断网兜底。车间里设备可以停网络不能保证永远不抖。需求文档里最好写明“当MES服务不可用时现场客户端应支持离线缓存网络恢复后自动补传数据”。这个需求如果不提供应商大概率不做因为离线逻辑做起来很麻烦。但是产线不能因为MES挂了就停摆所以离线能力必须白纸黑字写进合同。数据安全方面需求里至少明确三件事操作员权限分级比如工艺员能改工艺参数、操作工只能报工关键操作留痕谁在什么时间改了什么数据数据库定期备份策略。很多工厂的MES最后沦为“大号Excel”就是因为权限太乱谁都能改数据数据失去公信力。3.2 与ERP、测试软件、看板的接口关系MES的价值很大程度体现在跟周边系统的连接。需求文档里要单独列“接口清单”每个接口写清楚系统名称、接口方向数据谁给谁、同步频率、触发方式、异常处理。和ERP接口是重头。常见的交互包括ERP下发生产订单给MESMES回传完工数量、不良数量、工时信息MES请求物料信息ERP回传库存可用量。这里要特别注意主数据的归属问题物料编码、BOM、工艺路线到底以哪个系统为准我见过最混乱的项目ERP一套编码、MES又建一套两个系统对不上账。正确做法是主数据统一由ERP分发MES只读不新建。文中热词里还有“mes与测试软件”“langgraph结合mes布置在工厂”前者是测试数据回传比如产品检测设备测完自动把数据发给MES做SPC分析后者是今年圈里炒得比较热的方向——把大模型Agent用在工厂排产和异常处理上。说实话这类需求目前属于“探索性项目”需求文档里可以不写但如果企业有数字化团队想试点可以考虑预留一个“具备调用外部算法服务的能力”这样的扩展性条目。3.3 术语表让业务和技术讲同一种语言需求文档里一定要有术语表这不是凑页数。MES行业里的英文缩写实在太多而且同一个词在不同企业可能含义不同。比如工单和生产批有的厂认为是同一个东西有的厂严格区分SN是序列号指单件唯一码**批次号Lot No.**则对应一批物料**工位Workstation和设备Equipment**也不是一回事一台设备可以对应多个工位需求里如果不区分后面排产和质量追溯都会乱。还有**Andon安灯**这个热词在MES里指的是异常呼叫系统比如员工发现物料短缺或设备故障按一下按钮看板上就亮灯报警。这个词从丰田生产系统来的很多工厂叫“呼叫”“报警”但需求文档里统一用Andon大家就不会误解。**SPC统计过程控制**也是一种常见需求用控制图监控生产过程稳定性。建议需求文档最后附一张术语对照表把中英文、解释、举例都列出来评审的时候能省一半解释的时间。4. 从需求说明到落地评审要点、验收标准和避坑实录需求文档写得好不好最终要拿到项目里去验证。我见过太多MES项目需求文档写得像小说真到开发阶段每个模块都返工。下面这部分是我在实际项目里的经验总结围绕需求评审、功能编号、验收标准再放几个真实的坑。4.1 需求评审时必须当场确认的十个问题拿到一份需求说明去做评审不用逐字读抓住十个关键问题问清楚基本就能判断这份需求水平如何追溯粒度是批次级还是单件级工单拆分的触发规则和权限归属是谁插单/改单的作业流程系统怎么支持数据采集哪些靠自动化、哪些靠人工设备状态数据从哪来PLC点位是否已有点表质检不合格后的处理流返工/报废/让步接收谁审批OEE和绩效报表的计算口径是否跟财务口径一致断网、宕机时的业务连续性方案是什么主数据物料、BOM、工艺路线由哪个系统维护项目验收依据哪条需求清单逐条核对还是只做演示这十个问题里最容易被忽视的是第二和第三。很多车间管理靠车间主任“人肉记忆”你问他插单怎么处理他说“到时候现场临时安排”。需求评审阶段如果不把一个具体的场景按流程走一遍开发出来的功能大概率是拍脑袋的。4.2 功能需求编号化每一条都得有验收标准一份好的需求文档每个需求都应该有唯一编号、优先级、验收标准。比如“F-M-01优先级高生产主管可在工单列表页对未开工工单进行批量拆分拆分后子工单继承父工单的物料清单和工艺路线验收标准1000件工单拆成3批操作耗时小于2分钟ERP接口不产生重复数据。”有了这种写法开发阶段才有据可依测试阶段才能写用例验收阶段才不会争议。我推荐用“模块缩写-功能序号”的方式编号比如“F-WO-01”代表工单管理模块第一条需求“F-QC-02”代表质量管理模块第二条需求。这样一条条列下来哪怕300条需求管理起来也不乱。优先级一般分三类P0不做就不能上线、P1重要但可后续优化、P2锦上添花。需求文档里有了优先级供应商做报价和排期时就不会把所有需求都按P0算企业也能看明白钱花在哪些刀刃上。4.3 常见问题与排查技巧实录我把这几年在MES需求阶段和上线初期遇到的问题整理一个速查表每一条都是真金白银换来的教训问题表现根因分析解决建议看板产量数据和ERP库存对不上工位定义混乱同一批产品被多个工位重复报工需求阶段统一“工位-设备-工序”关系一个报工动作只能关联一个工位追溯查不到某个批次扫描节点缺失某道关键工序没设采集点画工艺流程图时严格走查“物料经过的每个节点”设备和MES之间数据断断续续现场网络有线无线混用跨厂房光纤丢包需求里明确全网有线覆盖关键点位无线仅用于移动扫码报表数据看起来“不对”报表的口径和业务规则不一致每个报表需求附一个口径说明举一个具体计算示例系统上线一个月后没人用了操作工觉得录入麻烦一线不认可需求里预留“操作友好性”要求移动端优先减少纯键盘录入还有一个容易被忽略的点需求说明不要写成“甲方爸爸的梦想清单”。比如有人会写“系统应实现车间全面智能化”这类话对开发毫无指导意义。我在评审时就遇到过这种情况最后只能一条条追问硬是把“全面智能化”拆成了“设备数据采集点位表”“异常自动报警规则”“生产日报自动生成”这三个具体需求。需求文档的读者是开发团队不是领导所以每一句话都要能指导编码和测试。4.4 需求文档的篇幅和写法建议以这份参考PDF为例企业级MES需求说明建议控制在30到60页太短说明没想清楚太长说明需求提炼能力不行。功能模块部分多用表格每条需求一行比大段文字好维护得多。文档里尽量放流程图描述业务现状但不要空谈目标要画清楚“现在怎么走”“将来怎么走”两条路径这样供应商能快速理解差距。另外需求文档写完后一定要组织一次跨部门评审生产、工艺、设备、IT、财务都要到场。生产代表确认现场操作流程工艺代表确认工序和参数设备代表确认采集接口财务代表确认和成本相关的数据要求IT代表确认和ERP、OA的接口范围。我每次做MES项目启动会最头疼的就是“需求文档签字确认”这一步但这一步省不了它决定后续变更怎么谈。5. 写在最后一点个人体会我在实际项目里看过太多需求文档最大的体会是MES项目失败很少是技术不行大多是需求没对齐。车间里的人以为系统“全自动”管理者以为系统“立刻透明”IT部门以为系统“接上ERP就能跑”三拨人抱着三个预期最后做出来的东西谁都不满意。而一份像样的需求说明恰恰是逼着所有人把预期摊到桌面上一条条确认这是省钱省时间的最好方式。最后再分享一个小技巧拿到任何MES需求文档先别急着看功能清单先找“术语表”“接口清单”“非功能性需求”这三章。如果三章都有实质内容这份需求大概率靠谱如果没有哪怕功能写得再漂亮后面都有足够多的坑等着你。MES是个慢工出细活的领域需求阶段多花一个月实施阶段能少折腾半年。本文还有配套的精品资源点击获取 MES需求文档怎么写？从功能拆解到落地避坑指南
简介制造执行系统MES处于企业资源计划ERP与车间底层设备之间承担着从工单下达到产品完工的全过程管理。明确的系统边界与结构化需求是MES落地的核心前提。一份合格的需求文档需拆解生产工单、排产调度、物料追溯、数据采集等模块并定义追溯粒度、设备接口、断网兜底等非功能性指标。本文结合真实项目经验从功能模块拆解、接口关系、术语统一到需求评审验收系统梳理MES需求文档的编写方法与避坑指南帮助甲方与实施方对齐预期降低交付风险。 去年年底我给一家机加工企业做MES选型咨询对方项目负责人发来一份PDF文件名就叫“车间制造执行系统(MES)---需求说明(参考).pdf”。我当时扫了一眼第一反应是这年头能拿出一份像样需求说明的甲方不多了。看完后发现这份文档虽然是“参考版”但结构、颗粒度都挺到位基本把MES项目前期最容易扯皮的事都讲清楚了。这份需求说明并不长但对“MES系统有哪些功能”“MES和ERP怎么分工”“现场数据怎么采”这些问题都有明确回答。这篇文章我就以这份需求说明为引子结合我在多个MES项目里踩过的坑把车间制造执行系统需求文档该怎么写、怎么读、怎么落地这件事掰开揉碎聊一遍。不管你是甲方项目经理、车间主任还是刚入行的实施顾问只要你想搞清楚MES项目到底要做什么、需求要细化到什么程度这篇文章应该能帮你省下不少弯路。1. 需求说明究竟解决什么问题先别急着谈功能定位比功能重要MESManufacturing Execution System制造执行系统被夹在ERP和底层设备之间很容易被误解成“ERP的子系统”或者“高级版报工软件”。我见过太多企业上ERP时觉得够了后来发现车间里全是信息孤岛才回头补MES。这份需求说明的第一页就在讲这件事MES管的是从工单下达到产品完工之间的所有执行过程核心目标是让车间“透明化、可追溯、能改善”。1.1 用一个车间调度员的视角理解MES的边界你可以把ERP理解成企业的“大脑”它负责算物料需求、下采购计划、排财务账。但大脑下了指令之后手脚怎么动是MES的事。工单到车间之后先做不做、先做哪个、这台设备够不够、物料齐不齐、加工到哪一步了、这个批次用了哪些原料、质检有没有过——这些在ERP里往往是黑盒而在MES里是逐条记录、实时反馈的。需求说明里写得比较清楚MES要承接ERP的生产订单向下要采集设备、人员、物料、质量数据向上要把完工信息反馈给ERP。这句话听起来简单但真正落地时大部分吵架都发生在边界问题上。比如ERP已经下了生产订单但车间临时调整了加工顺序这个信息要不要回传质检不合格要返工ERP库存怎么扣如果需求文档里没有提前定义这些交互规则后面就是无休止的接口扯皮。1.2 一份合格需求说明的三层结构这份PDF的结构我拆解下来无非三层业务现状与目标、功能需求按模块分、非功能需求性能、接口、权限、追溯要求。很多企业写需求文档时只写功能列表比如“要有排产模块”“要有质量模块”这其实只是目录不是需求。真正的需求要能回答三个问题谁来用角色、做什么动作功能、出了问题怎么办异常流程。比如“班组长可以在Pad上对工单进行开工操作并录入实际开始时间”——这算一条能落地的需求。而“系统应支持生产调度”这种纯属浪费纸张。需求说明里最好每个功能项都带编号、带优先级、带验收标准后面做UAT用户验收测试时才能逐条核对避免“做完之后才发现不是我要的”。2. 核心功能模块的拆解从工单到追溯每个模块都有隐藏的坑这份需求说明把MES功能分成六大块生产工单管理、排产与调度、数据采集与追溯、质量管理、设备管理、绩效与看板。这基本覆盖了市面上主流MES的标准范围。但每个模块里都有一些细节需求文档里未必会展开而恰恰是这些细节决定项目成败。2.1 生产工单与排产调度需求要从“异常场景”写起工单管理不只是把ERP的订单接进来再转给车间它还要处理拆单、合并、插单、改单这些日常操作。比如一个1000件的大订单车间不可能一次投料往往要按批量拆成多个生产批。需求里要明确拆单规则按数量拆还是按工艺路线拆拆出来的子工单要不要单独算成本插单加急单进来后原有排产计划怎么调整我在一个项目里就吃过亏客户提“系统要支持插单”结果实施时才发现他们的“插单”不是把新单排到最前面而是要把某条产线上正在做的半成品全部下线换成急单做完再换回来。这个操作涉及物料回退、工时重算、质量状态变更远比“调整优先级”复杂。如果需求阶段没把这些异常场景聊透开发到一半需求变更项目周期直接翻倍。排产调度这块需求说明一般不会要求“自动排产”大多数企业现阶段能接受的是“排产辅助”。也就是系统展示设备负载、工序工时、物料齐套情况调度员人工拖拽调整。真正全自动的APS高级排程牵扯约束条件太多不是MES的核心任务。写需求时建议把“人工排产为主、系统提供可视化辅助”作为默认基调能省掉很多不切实际的预期。2.2 物料追溯与数据采集追溯粒度是第一个要拍板的事凡是涉及追溯的需求第一件事就是定粒度批次级追溯还是单件级追溯。批次级的意思是这一批料用到哪个生产批、成品去了哪能追溯到“一批”的层面单件级则是每一件产品都有唯一SN码能查清楚这个SN用了哪个炉批的钢材、哪台机床加工、哪个操作工做的、检测数据是多少。这两个方向的工作量天差地别。批次级一般靠“工单物料批次号”绑定扫描工作量小单件级则需要每件产品贴码、每道工序扫码对产线节拍有要求。需求文档里如果只写“实现正反向追溯”而不写粒度报价和排期都没法估准。我建议在需求阶段就明确“追溯的最小单元是什么”“追溯到工序还是追溯到设备”“是否要求首件记录和过程参数绑定”。数据采集方式也要提前定。常见的三种PLC自动采集设备有接口、扫码枪半自动采集人工扫工单和SN、Pad手动录入适用于没有自动化条件的工位。需求文档里要对每个数据项标注来源方式比如“设备状态通过PLC每5秒采集一次”“完工数量操作工在Pad上手工录入”。这个细节决定了现场的网络布点、硬件选型甚至影响整个项目的预算量级。2.3 质量、设备与绩效那些容易被忽视的隐性需求质量管理模块大多数需求文档会写“来料检验、过程检验、完工检验、不合格品处理”。但真正决定质量模块好用不好用的是它和工单、物料、设备的数据打通程度。比如过程检验发现一批料不合格系统能不能自动锁定相关工单、禁止继续投料返工流程走完之后检验记录能不能保留原始数据而不是覆盖这些都值得写进需求。设备管理重点不只是“点检保养”更是OEE设备综合效率的计算口径。需求文档里要定义清楚OEE的时间损失怎么算计划停机比如保养、换型算不算进理论运行时间一条产线有多台设备OEE按瓶颈设备算还是按产线整体算不少企业看到系统里的OEE觉得“不准”原因就是口径没在需求阶段锁定。绩效与看板模块需求文档里容易写成“展示产量、合格率、设备状态”。但实际实施时如果工位、班组、产品的关系没定义清楚看板上的数据分分钟错乱。我建议绩效报表的需求先梳理“组织和岗位维度”也就是谁看这张报表、按什么维度分组、数据刷新频率是多少。MES看板的技术栈用C#开发后台、Web前端展示是非常常见的组合因为工厂里Windows生态占主流运维团队熟悉.Net的比熟悉别的多需求文档里不用规定语言但可以写明“看板需支持网页访问方便投到车间大屏”。3. 非功能性需求和接口决定系统能不能真正活下来功能需求决定系统“有没有”非功能性需求决定系统“好不好用、能不能用住”。很多需求文档重功能、轻性能结果系统上线后天天被车间吐槽“转圈圈”。这一部分我重点聊三件事性能与可靠性、接口关系、术语统一。3.1 性能指标、断网兜底和数据安全性能指标必须量化。比如“扫码响应时间不超过1秒”“看板数据刷新延迟不超过3秒”“支持200个并发用户在线操作”。这些数字不用多专业但一定要写因为它直接决定架构设计和硬件选型。工厂车间网络环境不比写字楼经常有电磁干扰、跨厂房光纤距离远的问题需求里最好明确“无线网络覆盖所有作业区域关键数据采集点有线备份”。更关键的是断网兜底。车间里设备可以停网络不能保证永远不抖。需求文档里最好写明“当MES服务不可用时现场客户端应支持离线缓存网络恢复后自动补传数据”。这个需求如果不提供应商大概率不做因为离线逻辑做起来很麻烦。但是产线不能因为MES挂了就停摆所以离线能力必须白纸黑字写进合同。数据安全方面需求里至少明确三件事操作员权限分级比如工艺员能改工艺参数、操作工只能报工关键操作留痕谁在什么时间改了什么数据数据库定期备份策略。很多工厂的MES最后沦为“大号Excel”就是因为权限太乱谁都能改数据数据失去公信力。3.2 与ERP、测试软件、看板的接口关系MES的价值很大程度体现在跟周边系统的连接。需求文档里要单独列“接口清单”每个接口写清楚系统名称、接口方向数据谁给谁、同步频率、触发方式、异常处理。和ERP接口是重头。常见的交互包括ERP下发生产订单给MESMES回传完工数量、不良数量、工时信息MES请求物料信息ERP回传库存可用量。这里要特别注意主数据的归属问题物料编码、BOM、工艺路线到底以哪个系统为准我见过最混乱的项目ERP一套编码、MES又建一套两个系统对不上账。正确做法是主数据统一由ERP分发MES只读不新建。文中热词里还有“mes与测试软件”“langgraph结合mes布置在工厂”前者是测试数据回传比如产品检测设备测完自动把数据发给MES做SPC分析后者是今年圈里炒得比较热的方向——把大模型Agent用在工厂排产和异常处理上。说实话这类需求目前属于“探索性项目”需求文档里可以不写但如果企业有数字化团队想试点可以考虑预留一个“具备调用外部算法服务的能力”这样的扩展性条目。3.3 术语表让业务和技术讲同一种语言需求文档里一定要有术语表这不是凑页数。MES行业里的英文缩写实在太多而且同一个词在不同企业可能含义不同。比如工单和生产批有的厂认为是同一个东西有的厂严格区分SN是序列号指单件唯一码**批次号Lot No.**则对应一批物料**工位Workstation和设备Equipment**也不是一回事一台设备可以对应多个工位需求里如果不区分后面排产和质量追溯都会乱。还有**Andon安灯**这个热词在MES里指的是异常呼叫系统比如员工发现物料短缺或设备故障按一下按钮看板上就亮灯报警。这个词从丰田生产系统来的很多工厂叫“呼叫”“报警”但需求文档里统一用Andon大家就不会误解。**SPC统计过程控制**也是一种常见需求用控制图监控生产过程稳定性。建议需求文档最后附一张术语对照表把中英文、解释、举例都列出来评审的时候能省一半解释的时间。4. 从需求说明到落地评审要点、验收标准和避坑实录需求文档写得好不好最终要拿到项目里去验证。我见过太多MES项目需求文档写得像小说真到开发阶段每个模块都返工。下面这部分是我在实际项目里的经验总结围绕需求评审、功能编号、验收标准再放几个真实的坑。4.1 需求评审时必须当场确认的十个问题拿到一份需求说明去做评审不用逐字读抓住十个关键问题问清楚基本就能判断这份需求水平如何追溯粒度是批次级还是单件级工单拆分的触发规则和权限归属是谁插单/改单的作业流程系统怎么支持数据采集哪些靠自动化、哪些靠人工设备状态数据从哪来PLC点位是否已有点表质检不合格后的处理流返工/报废/让步接收谁审批OEE和绩效报表的计算口径是否跟财务口径一致断网、宕机时的业务连续性方案是什么主数据物料、BOM、工艺路线由哪个系统维护项目验收依据哪条需求清单逐条核对还是只做演示这十个问题里最容易被忽视的是第二和第三。很多车间管理靠车间主任“人肉记忆”你问他插单怎么处理他说“到时候现场临时安排”。需求评审阶段如果不把一个具体的场景按流程走一遍开发出来的功能大概率是拍脑袋的。4.2 功能需求编号化每一条都得有验收标准一份好的需求文档每个需求都应该有唯一编号、优先级、验收标准。比如“F-M-01优先级高生产主管可在工单列表页对未开工工单进行批量拆分拆分后子工单继承父工单的物料清单和工艺路线验收标准1000件工单拆成3批操作耗时小于2分钟ERP接口不产生重复数据。”有了这种写法开发阶段才有据可依测试阶段才能写用例验收阶段才不会争议。我推荐用“模块缩写-功能序号”的方式编号比如“F-WO-01”代表工单管理模块第一条需求“F-QC-02”代表质量管理模块第二条需求。这样一条条列下来哪怕300条需求管理起来也不乱。优先级一般分三类P0不做就不能上线、P1重要但可后续优化、P2锦上添花。需求文档里有了优先级供应商做报价和排期时就不会把所有需求都按P0算企业也能看明白钱花在哪些刀刃上。4.3 常见问题与排查技巧实录我把这几年在MES需求阶段和上线初期遇到的问题整理一个速查表每一条都是真金白银换来的教训问题表现根因分析解决建议看板产量数据和ERP库存对不上工位定义混乱同一批产品被多个工位重复报工需求阶段统一“工位-设备-工序”关系一个报工动作只能关联一个工位追溯查不到某个批次扫描节点缺失某道关键工序没设采集点画工艺流程图时严格走查“物料经过的每个节点”设备和MES之间数据断断续续现场网络有线无线混用跨厂房光纤丢包需求里明确全网有线覆盖关键点位无线仅用于移动扫码报表数据看起来“不对”报表的口径和业务规则不一致每个报表需求附一个口径说明举一个具体计算示例系统上线一个月后没人用了操作工觉得录入麻烦一线不认可需求里预留“操作友好性”要求移动端优先减少纯键盘录入还有一个容易被忽略的点需求说明不要写成“甲方爸爸的梦想清单”。比如有人会写“系统应实现车间全面智能化”这类话对开发毫无指导意义。我在评审时就遇到过这种情况最后只能一条条追问硬是把“全面智能化”拆成了“设备数据采集点位表”“异常自动报警规则”“生产日报自动生成”这三个具体需求。需求文档的读者是开发团队不是领导所以每一句话都要能指导编码和测试。4.4 需求文档的篇幅和写法建议以这份参考PDF为例企业级MES需求说明建议控制在30到60页太短说明没想清楚太长说明需求提炼能力不行。功能模块部分多用表格每条需求一行比大段文字好维护得多。文档里尽量放流程图描述业务现状但不要空谈目标要画清楚“现在怎么走”“将来怎么走”两条路径这样供应商能快速理解差距。另外需求文档写完后一定要组织一次跨部门评审生产、工艺、设备、IT、财务都要到场。生产代表确认现场操作流程工艺代表确认工序和参数设备代表确认采集接口财务代表确认和成本相关的数据要求IT代表确认和ERP、OA的接口范围。我每次做MES项目启动会最头疼的就是“需求文档签字确认”这一步但这一步省不了它决定后续变更怎么谈。5. 写在最后一点个人体会我在实际项目里看过太多需求文档最大的体会是MES项目失败很少是技术不行大多是需求没对齐。车间里的人以为系统“全自动”管理者以为系统“立刻透明”IT部门以为系统“接上ERP就能跑”三拨人抱着三个预期最后做出来的东西谁都不满意。而一份像样的需求说明恰恰是逼着所有人把预期摊到桌面上一条条确认这是省钱省时间的最好方式。最后再分享一个小技巧拿到任何MES需求文档先别急着看功能清单先找“术语表”“接口清单”“非功能性需求”这三章。如果三章都有实质内容这份需求大概率靠谱如果没有哪怕功能写得再漂亮后面都有足够多的坑等着你。MES是个慢工出细活的领域需求阶段多花一个月实施阶段能少折腾半年。本文还有配套的精品资源点击获取