简介《制造执行系统MES系统 用户需求说明书》是一份用于制造执行系统项目需求梳理的中文文档以厦门建霖公司为背景面向实施顾问、需求分析人员与制造业信息化管理者帮助解决项目前期需求范围不明、业务模块界定不清等问题。压缩包内为1个Word文档共119页整体大小约15.49MB除需求正文外还包含版本历史、术语表和详细目录便于快速定位各章节。内容覆盖生产计划管理、生产执行、质量管理、物料管理、设备管理、模具管理及系统集成等核心业务域并对用户角色、批次管理、载具管理、组装作业、包装作业等场景给出了具体需求描述。这份文档既可作为MES需求调研与蓝图设计的参考样例也可为同类用户需求说明书的编写提供结构、术语和业务描述方法上的借鉴。目前已有944人浏览学习。1. 一份119页的MES用户需求说明书业务需求的“底账”做MES项目的人最怕的不是技术选型而是需求评审会上业务部门各说各话计划部要一个排产按钮车间说要能扫码过站质量部说不良品要能录进去最后实施时才发现这几拨人讲的根本不是同一件事。这份119页的制造执行系统MES用户需求说明书就是用来终结这种混乱的。它以注塑、电镀、装配等多条真实产线为背景把计划、生产、质量、设备和模具的需求按AS IS现状与To Be目标两条线拆开写清楚连ERP同步、批次追溯、载具管理这种细节点都落到了字段级描述。适合MES售前顾问、实施项目经理、制造企业信息化负责人也适合刚转行做制造数字化、想快速理解一套MES到底管什么的新人。2. 拆文档骨架版本历史、术语表与AS IS/To Be四段式2.1 从版本历史能读出需求演进路线这份URD的版本历史页信息量很大不只是一页流水账。整理一下可以看到一份119页的需求说明书是怎么从一个空模板长成完整业务的版本发布日期关键补充内容0.12016-03-21建立文档模板0.22016-03-24补充物料、计划需求业务描述0.32016-03-25补充项目范围、目标、工艺、生产业务描述0.42016-03-28补充质量需求业务描述0.62016-03-28补充设备需求业务描述1.02016-03-28合并各模块形成初版1.12016-04-01版本合并修订1.22016-04-10补充用户角色、生产计划与生产管理的To Be描述新增批次管理、载具管理、组装作业、包装作业补充质量管理、物料管理、设备管理、模具管理To Be内容及总流程图、系统集成这段历史说明了三件事。第一好的URD不是一次写成的而是由计划、工艺、质量、设备多个角色并行写各自模块最后再由一个人合并收口。合并版本才到1.0后面1.1、1.2都是在评审中不断补细节这是正常的节奏如果一上来就要求交付完整版反而容易写出空中楼阁。第二1.2版本把批次管理、载具管理、组装作业、包装作业补了进来说明这些内容通常是在第一轮评审时被业务提出来追加的——做MES需求批次追溯和载具绑定很少在第一版就想全。第三版本从0.1到1.2只用了三周这种短周期迭代在项目启动阶段非常实用先搭骨架、分头填肉、合并评审比闷头写一个月再给业务看要稳得多。我拿到一份MES的URD第一步就是看版本历史和作者分工能快速判断这份文档是真实调研产物还是从别处抄来的框架。如果版本历史里只有一次创建记录、没有任何细分工多半要打个问号。2.2 术语表先把黑话对齐再聊功能这份URD在第4页开始列术语表几乎每个实施MES踩过坑的人都明白这页有多重要。项目里最消耗精力的往往不是技术难题而是「工单」「生产订单」「制造编号」这些词在不同人口中含义不同需求讨论好几个小时最后发现说的是两个东西。挑几个关键术语说一下这几个词在全文中反复出现理解它们才能读得动后面的需求术语文档里的定义要点工单MES工单与ERP工单一一对应一个产线加工过程对应一张工单工序 / 工位工序是工位上执行的工作内容多个工序线性组合成工艺路线MES只关心关键工序SN一个产品一个SN一个唯一管控的关键件也对应一个SN关键件关键物料需要有唯一条码或批次条码作为追溯码需要工人操作中扫描OEEOEE 时间稼动率 × 性能稼动率 × 合格率不良现象 / 不良原因 / 维修动作 / 不良责任归属质量记录的四层描述由不同角色在不同环节填写工单发料清单 / 线边仓工单生产所需物料明细原材料按发料清单配送至线体后存入线边仓我的习惯是读URD前先花二十分钟把这些术语过一遍尤其注意「工单」和「生产订单」是否混用、「SN」和「PN」是否分得清。这份文档把PN定义为物料编码、SN定义为制造编码一个产品一个SN关键件也对应SN这就把追溯的最小单元定死了。术语表的另一个隐藏价值是暴露系统边界——术语表里同时有ERP、PLM、ESOP、PDA这些词汇说明这套MES不是孤岛要和外围系统做集成后面4.2节也确实单独写了ERP数据同步。2.3 AS IS/To Be四段式写URS最稳的骨架这份URD的目录结构很有特点几乎所有业务模块都按同一个套路组织业务流程(AS IS)、流程单据(AS IS)、业务流程(To Be)、业务说明(To Be)。我第一次见到这个结构时觉得啰嗦后来发现这才是URS该有的样子。AS IS部分回答「现在怎么跑的」用业务流程和现有单据把现状钉住To Be部分回答「以后怎么跑」用流程描述加业务说明把目标讲清楚。两套东西放在一起评审时一眼就能看出变革点在哪里。比如生产计划管理里计划下达一节AS IS先梳理现状下计划靠什么单据、走什么流程To Be再讲ERP物料主数据与工单数据如何同步进MES。如果只写To Be业务部门会问「现在这样跑得好好的为什么要改」AS IS就是用来回答这个问题的。这套四段式的实际价值在于防止「上来就画理想流程图」。我见过不少URD通篇都是To Be流程图没有AS IS结果业务不认账因为现状调研根本没做透。这份文档给了一个可复用的模板每节四段先现状后目标流程配单据改动配说明。写URS的新人完全可以照这个骨架套能少走很多弯路。提示判断一份MES需求文档是真实调研还是抄来的最快的方法是看AS IS部分有没有具体单据名称。抄来的文档普遍只有To Be流程图没有现有表单。3. 先工厂后功能产线布局与七条工艺路径决定MES粒度3.1 工厂布局和工作站MES是挂在产线上的这份URD用了专门一章写工厂布局与产品很多人读URS会跳过这种章节觉得是背景介绍实际这是最不该跳的部分。MES不像ERP以单据为中心MES是跟着产线走的——每条产线有哪些工作站、每个工作站执行什么工序、物理布局怎么排直接决定了系统里要建多少工位、在哪些点设采集。文档把产品、产线、工作站拆开描述再到工艺路径流程这是一条很清晰的建模顺序产品决定加工方式加工方式组织出产线产线拆成工作站工作站执行工序。实施MES时基础数据里的「工厂-车间-产线-工位」四层结构就是从这里来的。我一般会在评审URS时把工厂布局章节当成第一个确认项让业务确认产线划分是否准确。这个环节翻车最隐蔽——业务口头说的「三号线」和系统里的「Line_003」对不上后面所有工单、报工、报表全错位。URD里先把「产线工作站」写成章节就是在物理层面先对齐再谈功能。3.2 七条工艺路径MES该在哪些工位设管控点文档列了七条工艺路径注塑、抛光、电镀、拉丝、套络、PVD/喷漆、装配。这七条路径决定了MES的功能边界和管控粒度因为它们对应的采集方式完全不同工艺路径MES通常要盯的管控点注塑机台参数、模次计数、设备OEE、上下模记录抛光工位过站、报工、良品与不良品分流电镀槽液批次、料架批次、工艺参数记录拉丝过站扫描、表面质量首检、参数固化套络物料批次绑定、工序防错PVD/喷漆炉次批次追溯、工艺参数记录、首件确认装配关键件SN绑定、BOM核对、包装SN关联比如注塑MES要管的不是工人扫不扫码而是注塑机当前在打哪副模、打了多少模次、这台设备的OEE是多少所以需求里要重点写设备数据采集和模次计数。电镀和PVD/喷漆这类批量处理工艺一个料架或一个炉次的产品共用同一批工艺参数追溯单元就应该是批次而不是单件。装配线则完全不同关键件要扫SN绑定到成品需求里必须写清楚扫描规则。同一套MES在不同产线的采集深度不一样这份URD用工艺路径把差异标了出来方案评审时就能一条线一条线去对。3.3 ERP工艺路线与MES工艺路线的边界财务账和生产账别混文档术语表里有一句非常关键的话ERP的工艺路线通常是为财务成本统计设立的一般很简短MES的工艺路线由MES管控的工序组成。这句话值得单独划出来讲。很多做MES基础数据的人习惯直接把ERP里的工艺路线导过来建MES工艺路线这是最常见的翻车点。ERP的工艺路线是给财务算成本用的工序设置可能只有三五道对应的是成本中心。MES的工艺路线是为了管控要在每道需要扫描、报工、检验、采集参数的工序上设点两者粒度不一样。如果直接照搬ERP结果就是MES里工序太少该管控的节点漏掉反过来如果把MES每个细分工序都同步回ERPERP的BOM和成本核算会被拖垮。这份URD在术语表里提前把两个系统的工艺路线划清了界限后面4.4节再讲工艺路径维护和标准工时维护时就不会出现「到底以谁为准」的争议。MES管工艺路径只维护MES管控的工序ERP管财务两边靠工单关联。这个边界想清楚系统集成方案里接口要传哪些字段也就清楚了。4. 核心需求拆解计划、生产与质量三条主线的设计要点4.1 生产计划管理下达、执行、结案、变更生产计划管理在URD里被拆成计划下达、计划执行、计划结案、计划变更四个子流程这个拆分本身就是很好的需求分析方法论。计划下达的重点是ERP数据同步。文档明确写到物料主数据与工单数据要从ERP同步到MESMES工单与ERP工单一一对应。这里的关键参数是同步对象物料编码、BOM、数量、交期。需要注意的是同步不等于只读MES里工单状态变化后要不要回写ERP这是需要确认的接口边界。计划执行阶段关注的是按工单齐套发料URD术语表里的「工单发料清单」和「线边仓」就是在这个环节用的——根据发料清单把原材料从原材料仓配到线边仓MES记录发料批次。计划结案常被忽略反而是工时和追溯的源头。报工数量达成不等于可以结案尾数怎么处理、报废怎么扣数都要有明确规则。计划变更则是四个子流程里最容易漏需求的工单取消后已发物料怎么退、已生成的条码怎么作废、已绑定的关键件怎么解绑。如果URD里没有写变更后的数据补救规则实施时碰到变更工单就只能手工改数据库。4.2 生产管理从条码到包装的七件事4.5节是这个URD最厚的一节从条码管理一路写到包装作业表面看是七个小节实际是一条完整的追溯链路条码定义 → 生产执行 → 生产报工 → 批次管理 → 载具管理 → 组装作业 → 包装作业。条码管理要最先确认因为后面所有环节都依赖它。URD里写得很明确SN是制造编码一个产品一个SN一个唯一管控的关键件也对应一个SN关键件在操作中必须扫描。这条规则定义了追溯的最小数据单元——成品SN下挂关键件SN中间经过的所有工序都要过站记录。原材料条码则按条码编码规则定义原材料批次条码或唯一条码要能关联到工单发料清单。生产执行和生产报工要分开理解。执行是过站报工是数量确认。实际项目里经常把这两个动作合并成一个扫码但如果是计件场景或者工序间有库存缓冲就要分开设计。批次管理说明不是所有物料都要单件追溯用批次条码也能满足追溯要求关键在于「关键件」的界定。载具管理比较特殊载具本身不是产品但载具和产品的绑定关系会影响追溯和防错URD里专门列了这个小节说明业务方确实遇到过载具混料问题。组装作业和包装作业则是追溯链的末端组装环节把关键件SN绑进成品SN包装环节建立SN与装箱的层级关系。这一节的核心就一句话每一步操作都要回答「扫了什么码、在哪里扫、留了什么记录」。URS把这些逐个写成业务说明开发阶段才能设计出对应的表结构和界面字段。4.3 质量管理把不良现象和不良原因分开录质量管理章节开头先给了一张AS IS流程图和一张To Be流程图然后落到基础数据定义这个顺序值得学习。质量模块最容易犯的错误是一上来就画检验流程而忘了先定义数据字典。URD把质量基础数据拆成不良现象定义和不良原因定义还定义了这四个词不良现象、不良原因、维修动作、不良责任归属。这是我见过最实用的质量数据模型——把一次不良拆成四个维度由不同角色在不同环节填写。操作员或检验员在发现不良时只能初步判断不良现象比如划伤、毛刺、色差经过维修检查后才能确定不良原因维修动作和责任归属则是维修环节再补录的。如果把这四个字段放到一个录入界面里让工人一次填完就会出现大量错误数据因为操作员并不知道根本原因是谁造成的硬填最后全是「待定」。质量管理还细分成供应商品质管理、来料检验IQC、首检记录信息几类。每类都对应不同的检验场景和单据。来料检验管供应商送来的料首检管产线开始生产时的那几件SQC管供应商整体品质表现。这套URD在每个质量小节里都附了现有表单清单——纸质的来料检验单、首检记录表这些表单电子化就是MES质量模块的需求来源。5. 写MES需求说明书避坑六个现场翻车记录5.1 坑一AS IS和To Be写反现状没对齐就画未来现象评审会上生产经理指着To Be流程图问「我们现在的流程不是这样的你这图画错了吧。」项目组才发现调研时只听了车间主任口头讲了几句就照着想象画了未来流程AS IS草草两页带过。原因写URS的人急于展示To Be方案忽略了现状调研或者觉得业务反正要改现状写不写无所谓。解决每个模块强制按「AS IS流程、AS IS单据、To Be流程、To Be说明」四段写AS IS没确认前不允许动笔写To Be。如果业务方说「现在没有流程」那也要写成「现状为线下纸单传递」不能留空。5.2 坑二术语表定了没人维护各模块黑话交叉现象计划模块写「工单」仓库模块写「生产订单」质量模块写「批号」三个模块对同一批数据的叫法三个样。到开发阶段数据库字段名被迫在一套系统里兼容三种叫法。原因术语表在文档开头建了但各模块由不同人编写没人统一口径后期评审也没有逐词核对。解决把术语表当成评审检查项版本更新时先过术语表再进正文。这份URD在1.2版本里专门补充了用户角色内容就是版本管理中同步维护术语表的例子。5.3 坑三把ERP工艺路线直接搬进MES现象MES工艺路线里的工序和ERP一模一样只有四五道结果MES里找不到扫码点来记录关键件绑定被迫在实施中大量修改基础数据。原因没有理解ERP工艺路线是为财务成本统计设计的工序粒度粗而MES需要按管控点设工序。解决写需求前先划清边界——MES工艺路线只保留需要扫描、报工、检验、采集参数的工序。ERP那边维持成本工序不动两边通过工单关联不要试图把两套工艺路线合并成一套。5.4 坑四让操作员一次录完不良现象和不良原因现象上线后质量报表里不良原因大量堆积为「其他」工人抱怨录入界面要选好几级。原因把四个维度放在同一个录入界面期望操作员发现不良时一次填完但操作员在现场根本判断不了根本原因。解决拆成两次录入。现场发现不良时只录不良现象后续维修人员检查后再补录不良原因、维修动作和责任归属。字段拆分是表象关键是梳理录入角色和录入时机。5.5 坑五产线和工位没有统一编码现象URS里写了「三号线」「喷漆线」「A线」等各种叫法实施时排查发现有些是同一产线有些是包含关系工位编码只能现场重新编。原因调研时用了业务口头叫法没有在建需求前定义编码规则。解决URD一开始就建好工厂-车间-产线-工位的编码表所有需求描述引用编码。工位编码定了后面的设备挂接、工艺路线、人员报工才能挂得上。5.6 坑六设备需求写成了资产台账现象设备管理章节列了每台设备的型号、厂商、购买日期但没写MES要采什么数据、怎么采。原因把设备管理当成固定资产台账来写没有从MES的视角思考设备是数据源。解决从OEE公式反向推导设备需求。时间稼动率要采哪些设备的开动/停机时间性能稼动率要采哪些设备的节拍和产量合格率要取哪个检验环节的数据。写清楚这三个要素的数据来源设备管理需求才真正和MES挂钩。6. 落地前最后一关用三张图两张表把URS对齐到实施边界URD读完不等于可以开发中间缺一步转换。我每次拿到一份MES的URD都会在启动实施前强制走一遍提炼流程产出三张图两张表把119页文档压缩成项目组共同对齐的实施边界。第一张图是「产线-工序-管控点」图。把第三章的七条工艺路径逐条画出来标注每条产线有哪些工序、MES在哪个工序设置扫描、哪个工序设置参数采集、哪个工序设置检验。这张图就是MES基础数据的底稿也是后续配置工艺路线时的唯一依据。第二张图是「单据流」图。从AS IS部分把所有现有单据列出来再对照To Be部分标注每张单据的去向哪些被MES电子化替代哪些继续留在ERP哪些由两个系统共同维护。这张图决定了系统集成的接口清单。比如ERP的工单在MES里同步后MES报工完成要不要回写ERP在单据流图里一眼就能看出来。第三张图是「角色权限矩阵」。URD 4.1节有用户角色描述把它扩展成矩阵计划员能看能改什么、车间班组长能确认什么、质量检验员能录不良单还是只能看报表。MES的权限设计不需要复杂的RBAC模型但必须在实施前把角色和动作钉死否则上线后账号权限要被业务来回调。两张表里第一张是关键件追溯清单列出哪些物料需要SN级追溯、哪些批次级即可、在哪个工序绑定第二张是质量字典表把不良现象、不良原因、维修动作、责任归属部门整理成可维护的码表。这两张表是追溯和质量模块的配置源头早一天确认早一天省事。完成这三张图两张表之后我再回头读URS里的每一条To Be业务说明基本都能对应到具体的功能点。URD写得好不好不在于页数多不多而在于能不能从这里提炼出一张可执行的地图。从那以后我每次接触MES相关文档都强制自己先翻术语表再问一句「现有的流程到底怎么跑的」把AS IS对齐了才敢聊To Be。这个习惯救过我不少次希望帮到你。本文还有配套的精品资源点击获取
