企业官网建设流程全解析

简介：这是一份面向车间制造执行系统（MES）建设项目的需求说明参考文档，适合制造业信息化规划、MES 选型实施、需求分析与方案设计等场景，目标读者包括项目经理、需求分析师、开发工程师和车间管理人员。文档以项目范围开篇，规定了基于 Web 的 B/S 架构、HTML5 跨平台、数据库集群与负载均衡等总体技术要求，并系统展开生产建模、物料主数据、生产资源与工艺建模、排程调度、计划下达监控、工序流转卡、物料配送等核心模块的功能需求；装配准时化排程、机加工序约束有限能力排程、配送计划生成等细节，能直观反映实际生产中的业务约束。文档还明确了与 ERP、CAPP/PLM 等系统的集成关系，并给出物料主数据、工艺模型来源建议，有助于厘清 MES 上下游系统边界；条款细致，为后续补充完善预留空间。资源共包含 1 个 PDF 文件，资源包大小 454KB，已有 334 人学习下载。对正着手梳理 MES 需求或评审技术规格的团队而言，这份参考文档能提供可复用的功能清单与架构约束，帮助快速建立需求框架、识别重点模块与接口边界，减少从零编写需求说明的工作量。

1. 车间制造执行系统（MES）需求说明到底在解决什么问题

车间制造执行系统（MES）的需求说明，在很多工厂里是两种极端：要么厚到一百多页没人看，要么薄到实施时全靠猜。标题里“需求说明（参考）”这六个字，道破了这份文档真正的用处——它不是交付物，而是甲乙双方在动工前对齐口径的共识基线。我见过不少工厂，ERP跑了好几年，车间却还在Excel里排产、在纸票上报工，MES需求就这样不上不下地悬着。这篇笔记就顺着这份参考需求说明讲清楚：车间建模、计划排产、报工采集、质量追溯这几块需求怎么写才能落地，以及最容易返工的那些坑，给打算上MES的制造工程师和信息化负责人一条可复用的梳理路径。

2. 先把车间拆成系统能认的模型：生产建模与基础数据需求

MES需求说明里，最容易被跳过的就是第一章“生产建模”。很多人上来就写界面、写报表，结果工单一下发，发现产线都不知道挂在哪个车间下。生产建模的实质是先给车间里每一层物理对象定编码、定层级、定责任归属，后面所有工单流转、产量统计、质量追溯都依赖这套骨架。骨架歪了，后面每一层都跟着歪。

2.1 车间/产线/工序/工位四层结构怎么定义才不返工

常见的建模套路是四层：车间workshop、产线production line、工序operation、工位workstation。车间是行政或物理区域，产线是产能组织单元，工序是工艺路线里的步骤，工位是实际加工发生的坐标。举个例子：冲压车间-冲压1线-落料工序-3号压力机工位，这样一个工件的每次报工都能落到具体坐标上。

这里最常见的返工点，是把“设备”当“工序”。一台设备可以执行多道工序，比如同一台数控加工中心先铣面再钻孔，如果你在建模时只挂设备不挂工序，后面工艺路线就没法描述换刀、换工装的动作。反过来，把两道独立工序合并成一个工位，又会让产能统计失去粒度。需求说明书里需要为每一层定义这样一组字段：编码、名称、上级编码、是否产能单元（决定排产和报工是否挂数量）、是否质量采集点（决定是否强制报检）、启用状态。

我一般建议编码规则保持简短：车间W开头、产线L开头、工序P开头、工位S开头，后面跟两位流水号。不要在设计阶段就把编码扩到十几位，车间员工记不住，扫码也容易错。

四层结构确定后，一定要在主数据里加一个“启用状态”字段，先让旧数据停用而不是物理删除。原因是MES上线前通常要做历史数据迁移，物理删除会让报表里的同比数据对不上。把停用标记挂在每个表上，切换维护起来要省心得多。

2.2 物料与批次主数据：条码规则和唯一性约束

物料主数据在MES里的地位，比在ERP里还要敏感。MES要同时面对原材料批次、半成品周转、成品序列号三条链。最省事的做法是物料编码继续沿用ERP编码，只在MES里建一张映射表维护ERP物料编码和MES物料条码的关系，避免两套编码并行带来的对账问题。

批次和序列号是需求说明里必须分清楚的两个概念。原材料和中间品通常管到批次，一个批次是一个供应商来料或一次投产形成的集合；成品往往要管到序列号，也就是一物一码。条码规则建议用“短前缀+日期+流水号+校验位”，前缀用两位物料类别码，日期用年月日，流水号按当天从0001开始。校验位很重要，后面讲解包装扫码的时候会说到扫码枪误读，这是避免误读的关键设计。

唯一性约束至少写三条：物料条码全局唯一、批次号在物料范围内唯一、同一个批次不能同时挂在两个未完工的投料记录下。第三条是很多MES翻车的重灾区，同一个批次被两个工单同时领走，库存账面上还看不出问题，直到做质量追溯才发现一物多卖。顺带提醒，不要把“发货批次”和“生产批次”混在一个字段里管理。发货批次是销售物流的粒度，一个生产批次可以拆成多个发货批次，两者出现的时间点和维护角色完全不同，混在一起会让追溯结果变得不可信，需求文档里最好直接分成两张表。

2.3 用SQL盘点一遍基础数据：重复编码、孤儿工序、无主设备

需求确认阶段，不要只开会讨论字段。接上临时数据库，把主数据表建出来，再跑一遍下面这三个SQL，很快就能摸清现有的基础数据能不能支撑MES上线。

-- 1) 查重复物料编码，防止一码多物 SELECT material_code, COUNT(*) AS cnt FROM mds_material GROUP BY material_code HAVING COUNT(*) > 1; -- 2) 查挂在停用产线下的工序，以及没挂产线的孤儿工序 SELECT p.line_code, op.operation_code, op.operation_name FROM mds_operation op LEFT JOIN mds_production_line p ON op.line_id = p.id WHERE p.is_enabled = 0 OR op.line_id IS NULL; -- 3) 查没有挂到产线的无主设备 SELECT eq.device_code, eq.device_name FROM mds_device eq LEFT JOIN mds_production_line p ON eq.line_id = p.id WHERE p.id IS NULL;

第一个SQL用GROUP BY加HAVING COUNT(*) > 1，目的是找出编码唯一性约束失效的数据。物料编码重复在导入阶段很常见，尤其当ERP里存在停用后又被重新启用的物料。第二个SQL用LEFT JOIN保留工序表全量记录，再在WHERE里筛出两类问题数据：一类是产线被停用但工序还在用，一类是工序没挂产线。第三个SQL查无主设备，逻辑类似，LEFT JOIN后右表主键为空的就是孤儿设备。注意，这几个SQL里的表名和字段名是我常用的命名风格，接实际项目时按自己的建模表名替换。

这三个脚本跑完，把结果按问题类别打印出来，直接在需求评审会上逐条过，比争论“产线编码要不要带车间前缀”有效率得多。主数据责任也要写进需求说明。很多工厂把物料编码归ERP维护、设备编码归设备部维护、工序编码归工艺部维护，看起来分工明确，实际上一旦某个工序改名，MES里没人同步。常见做法是在MES主数据表上增加来源系统字段和最后同步时间，并在需求文档里写明每个主数据对象的维护责任部门和更新频率。

3. 从手工排产到系统派工：计划与工单模块需求要点

生产建模定了，下一个核心是工单。MES里的工单和ERP生产订单不一样，MES工单更关注执行粒度：谁在哪个工位、按哪个工艺路线、加工多少数量、当前处于什么状态。需求说明里如果只写“工单管理、工单下达、工单报工”这十几个字，实施方一定会按自己的理解去做，最后肯定对不上。

3.1 工单状态机设计：RELEASED、STARTED、CLOSED的流转边界

我一般会把工单状态定义成六个：已创建CREATED、已下达RELEASED、已开工STARTED、已完工FINISHED、已关闭CLOSED、已取消CANCELED。下达后不允许直接改数量，开工后不允许换工艺路线，完工数量超过计划数量时必须走超量审批，这些就是状态机的边界条件，必须在需求文档里逐条写清楚，而不是让工人在界面上乱点。

状态流转需求最好是画成一张表：当前状态、触发动作、下一状态、允许角色、是否必须填写批次或备注。这张表比任何文字描述都严谨，实施方可以直接拿去做后端校验。特别要注意的是“已下达”到“已开工”之间往往有物料齐套检查，需求文档里要写清楚：如果物料不齐，系统是允许强制开工还是必须等齐套。

这里送一个检查脚本。很多MES上线后出现工单“装死”——下达了但一直不开工，也没有人处理，就是因为需求里漏了超时预警。用下面的SQL可以找出这类工单：

-- 找出下达超过24小时仍未开工的工单，验证是否缺超时预警需求 SELECT work_order_no, product_code, plan_qty, release_time, TIMESTAMPDIFF(HOUR, release_time, NOW()) AS idle_hours FROM mes_work_order WHERE order_state = 'RELEASED' AND TIMESTAMPDIFF(HOUR, release_time, NOW()) > 24 ORDER BY idle_hours DESC;

TIMESTAMPDIFF函数在这里按小时计算当前时间和下达时间的差值，第二个参数是单位，第三个和第四个参数是起始时间和结束时间。24这个阈值不是固定值，按车间节奏来，单件流车间可以压到8小时，重装备车间放到72小时也合理。重要的是把“工单超时无人处理”写进异常管理需求，系统自动给班组长推送提醒。

3.2 排产方式选型：一期上不上APS，需求文档里怎么写

需求说明里出现频率最高、也最容易被过度承诺的词是“自动排产”。很多工厂看完供应商演示的APS（高级计划排产）就要求写上，但上了线才发现约束条件没定义，算法排出来的计划还不如老师傅用Excel排得快。我的建议是一期做可视化手工排产加冲突检测，二期再考虑要不要上APS。

APS想要真正可用，至少要定义四类输入约束：物料齐套时间、设备日历和模具约束、工艺路线顺序、人员技能分布。这四类数据如果不准，APS排出来的计划就是一堆废数据。需求文档里与其写“自动排产”三个字，不如写清楚“系统根据设备负载率、物料齐套状态、工单优先级给出建议计划，计划员可在甘特图上手工拖拽调整，系统实时提示冲突”。这个描述既清楚又不容易被实施方钻空子。

我见过一个折中方案，效果很好：用Excel排产模板先跑两个月，把设备产能、换型时间、模具寿命这些参数收集齐，再让实施方按这些真实参数配置排产引擎。这样需求里的排产功能从第一天就有真实数据支撑，而不是拍脑袋填产能。需求文档的排产章节最好附这样一张约束表：约束类型、数据来源、更新频率、责任人。比如设备日历来自设备维护模块，每天更新，设备员负责；物料齐套状态来自库存模块，每两小时更新，计划员负责。有了这张表，实施方才知道数据从哪里来，需求方也知道上线前要准备什么数据。

3.3 工单拆批与合并的边界条件，及超时预警

车间经常要拆工单：一批工件分成两半，一半先加工，一半等材料到齐再加工。需求里如果只写“支持拆批”，实施方可能真的做一个“把数量一分为二”的功能，但拆出来的新单号和原单号的父子关系没有维护，后面质量追溯全断了。拆批必须写明触发条件：设备容量不够、交货批次不同、来料批次不同、质量隔离要单独走一个批。拆批的数量下限也要写，比如最小拆批数量不低于原单的20%，否则不予拆分，这是为了防止车间为了提前报产量把工单拆得七零八落。

合并则要严格得多：不同产品编码不能合并，不同工艺路线不能合并，优先级差距超过一级不能合并。合并操作必须保留原工单号作为追溯依据，不能让系统只留下一个合并后的新单号。对应到需求文档，工单主表至少要有这些字段：工单号、产品编码、计划数量、已报工数量、优先级、当前状态、计划开工/完工时间、实际开工/完工时间、上级工单号、拆分来源单号。前面那个超时预警SQL里用到order_state，就来自这个状态机设计。字段不要求一次到位，但“上级工单号”这类追溯字段应该出现在第一版需求里，后期再加会让历史数据没法补。

4. 数据从设备上不来，MES就是空中楼阁：报工与数据采集需求

MES的产量、质量、设备效率OEE，所有可视化报表都建立在报工数据上。但报工恰恰是车间里最不受欢迎的操作，工人觉得这是在给系统打工。需求说明里这一段不能只写“支持扫码报工”，要把报工方式、数据粒度、校验规则、异常补偿都定清楚，否则上线的第一天就会因为数据不准失去所有人信任。

4.1 四种报工方式怎么选：键鼠、扫码枪、PDA、PLC直采

先给一张常用报工方式对比表：

选型时别只看点位数量，要看出错代价。人工键鼠报工最容易出现“昨天忘报了今天补”，数量还经常填错位；扫码枪至少能规避条码录错的问题；PLC直采精度最高，但前提是设备控制器里已经有计数信号，而且需要信息部门能拿到设备点位表，否则就是黑匣子。需求文档里要把报工粒度写死：按工单、按工序、还是按序列号。按工单粒度最粗，适合流程简单的产线；按序列号最细，适合装配类产品做单件追溯。粒度越细，报工界面需要扫的码越多，现场效率越低，所以要在追溯需求和操作效率之间找平衡。

还有一个常被忽略的字段是“报工人员工号”。不管用哪种方式报工，系统都必须记录是谁、在哪个工位、哪个班次报的工。这个字段是产量统计和绩效考核的基础，也是质量追溯里责任人追溯的依据。需求文档里报工记录表的必填字段列表：工单号、工序号、设备编号、操作工工号、报工数量、物料批次、时间戳，一条都不能少。

4.2 设备接口协议约定：OPC UA、Modbus TCP、HTTP API

设备联机是MES实施里变数最大的部分。协议对接的需求不要在实施阶段才谈，需求说明里就要把设备清单和接口协议建好。常见三类协议：OPC UA适合数控机床和PLC设备，可以读设备状态、加工计数、报警信息；Modbus TCP适合老设备改造或传感器采集，寄存器读写简单直接；HTTP API适合已经有数据中台的第三方系统，对方直接把数据推过来。

需求文档里为每台设备生成一张表：设备编号、接口协议、采集点名称、数据类型、采集周期、断线重连策略。采集周期不要一概而论，MES做产量统计通常1秒一次就够，做设备状态监控可以放到5秒一次，只有做振动分析这类场景才需要毫秒级，而那一般不属于MES范畴。把周期定在需求里，能避免实施方为了演示效果把采集频率调到10毫秒，把车间网络打爆。

协议字段有一项必须写：数据时间戳由谁产生。设备端产生的时间戳最可信，但老设备往往没有时钟或者时钟不准；如果由采集网关产生时间戳，就要考虑数据延迟会不会把两个班次的产量算串。需求的写法是“优先采用设备端时间戳，设备端无时间戳时以网关时间戳为准，并在数据表中记录时间戳来源”。协议里最容易漏的还有点位表。很多项目签合同时没要求设备供应商提供控制器的点位表，联机调试时才发现要一个信号地址要拖两周。需求文档里把“供应商需提供OPC UA节点列表或Modbus寄存器地址表，并配合MES联调”直接写进设备接口章节，采购合同也同步引用。

4.3 采集数据与工单的关联：没有工单号的产量是黑匣子

设备直采最容易出现一个尴尬局面：产量数据上来了，但不知道这些产量是哪个工单的。因为PLC只负责数数，它不知道当前加工的是哪张工单。解决这个问题的标准做法是“工单-设备绑定”：生产开始前先在MES里把工单和设备绑定，设备产量自动累加到这张工单上；换单时重新绑定，中间切换时间单独记录。

需求文档要写明绑定的触发方式：人工在HMI上选工单、扫工单条码自动绑定、或者通过上游排产结果自动绑定。自动绑定看起来最聪明，但一旦绑定错，后续产量全乱。我一般建议一期用扫码绑定，让操作工扫一下工单条码，成本低、出错可控、还有操作痕迹。下面这个SQL是验证采集数据能不能归集到工单的好工具，上线后定期跑一遍，会很快暴露“有产量无单号”的孤儿数据：

-- 验证设备加工记录能否关联到有效工单，查不到工单的记录就是黑匣子 SELECT we.device_code, we.start_time, we.end_time, we.report_qty FROM mes_work_equipment we LEFT JOIN mes_work_order wo ON we.work_order_no = wo.work_order_no WHERE wo.work_order_no IS NULL ORDER BY we.start_time DESC LIMIT 100;

这个查询的关联键是work_order_no，如果采集记录里这个字段为空，LEFT JOIN后右表字段全是NULL，WHERE条件就能把它们筛出来。LIMIT 100是防止无主数据太多导致查询卡顿，实际排查时可以去掉限制并按天看数量趋势。这里想表达的是，采集方案设计时就要把work_order_no作为必传字段设计进去，而不是等数据上来之后再“猜”产量属于谁。设备联机不是“数据联网”那么简单，关键是让每一个数字都能落到工单上。

5. 需求说明阶段最容易踩的5个坑（避坑实测）

需求说明还挂着参考两个字，意味着它有机会被改好。但有些坑一旦写进去、照着实现，后面要翻出来重做就是大工程。这里按项目里的血泪经验整理五条最高频的，每一条都按现象、原因、解决来写，评审时可以拿着逐条对照。

5.1 把ERP的BOM直接当MES的工艺路线

现象：需求文档里列了完整物料清单，每道工序后面都跟着一串物料编码；实施方照做后，报工界面要填一堆物料，工人看不懂，库存账也对不上。

原因：写需求的同事把ERP的BOM直接抄成了工艺路线。BOM描述的是“产品由哪些物料组成”，工艺路线描述的是“产品按什么顺序经过哪些工序”。两者有关联但粒度完全不同，照抄的后果是工序级物料消耗和实际投料对不上。

解决：需求里把两个概念拆开：工艺路线只定义工序顺序、工序名称、标准工时、所需工装设备；物料消耗放到独立投料单据里，不在报工操作中强制录入。若确实需要按工序控制投料，单独设计投料界面，并注明校验逻辑是“按工艺路线用量上限控制”而不是“每道工序都要扫一遍物料”。工艺路线表建议字段为：工序号、工序名称、工序类型（加工/检验/暂存）、标准工时、是否报工点、是否质检点、下道工序号。

5.2 质量追溯字段没放在报工界面，事后补数据补到崩溃

现象：上线三个月后客诉，要做批次追溯，发现关键原材料批次号在系统里查不到，只能翻纸质记录，两个班次追两天没追齐。

原因：需求文档里追溯模块写得很完整，有追溯链、有查询报表，但追溯数据的源头，也就是报工和投料界面里，根本没有原材料批次录入字段。数据没进门，报表做得再漂亮也是空壳。

解决：做需求评审时，把每一条追溯报表倒推到操作界面，确认它依赖的字段具体在哪里录入。原材料批次放在投料/开工步骤强制扫码，成品序列号放在完工报工步骤强制录入，半成品批次在工序转移时自动生成。凡是界面清单里找不到出处的追溯字段，一律划掉。可以在需求文档里加一张“追溯字段与界面来源对照表”，字段、产生界面、是否必录、谁负责录入，一行一个。

5.3 条码规则设计成“万能编码”，上线后打印不出来

现象：条码规则定了二十多位，包含公司代码、产品族、年份、版本、颜色、流水号，小包装标签一打出来就模糊，扫码枪识别率掉到七成以下。

原因：需求阶段想把所有信息都塞进条码，做成“万能编码”。条码密度超过标签打印精度后，读码率会急剧下降。尤其是包含颜色、版本这类描述性信息，编码一改，条码就要重新分配。

解决：编码回归唯一性和必要分类。条码主体用“两位类别码+年月日+四位流水”就够，其他属性全部作为数据库字段存储，不塞进条码。校验位一定要加，它是防误读的最后一道保险。需求文档里加一条硬性约束：条码总长不超过二十位，超过二十位评审会必须解释用途。标签纸和打印精度的匹配测试在小批量试运行阶段就做，不要等大批量上线再挑战。

5.4 需求文档里写“自动排产”，却没人定义约束条件

现象：需求里写“自动排产”，上线后实施方给出的排产结果要么撞了模具，要么排到已停用设备上，计划员最后还是手工改。

原因：自动排产的结果质量完全取决于约束条件，但需求里只写了目标和期望，没有写输入、约束、数据来源。实施方做出来的自动排产只是按优先级排序，没考虑车间真实约束。

解决：把需求措辞改成“排产建议加冲突检测”，并列出至少四类必定义的约束：物料齐套时间、设备日历和模具可用、工艺路线顺序、人员技能等级。每个约束还要标数据来源和更新频率，来源没有系统的就先补充基础数据，不上自动排产。建议一期先上线可视化拖拽排产，类似甘特图人工调整，系统做冲突提示，跑两个月的真实数据后再评估APS。

5.5 报工走两级审批，车间操作工直接不点

现象：报工功能上线一周，产量数据不涨反跌，操作工反映报一次工要点三个页面、等两级审批，干脆先记纸上，回头再补。

原因：把MES当ERP用，所有单据都套审批流。MES的核心是实时和准确，审批越长操作工越不愿意报，数据越失真。

解决：报工保存即生效，零审批。审批只保留给异常场景，比如超量完工、废品数量超阈值、强制开工。需求文档里的审批流清单逐条过：凡是不涉及钱、不涉及账实不符的，一律删除。报工界面填写字段不超过五个，多于五个就自动带入或由线边专人用PDA代录。班组长要看的异常列表单独做一个查询界面，不需要通过审批流实现。

这五条其实都指向同一个原则：MES需求说明里的每个文字，都要能翻译成一个界面字段、一张表、一次操作。翻译不出来，就不要写进参考版需求里。这条检查方式也适合拿自己的需求说明逐行过一遍，能少走很多弯路。

6. 拿若依框架做需求原型：让车间在动工前看到MES长什么样

需求说明终归是文字，车间主任对文字不敏感，他们只对能点的界面敏感。我常用的落地技巧是，在需求评审阶段同步做一个可点击原型——基于若依框架去快速搭一个MES原型，是当前开源社区里最省力的路线之一。若依这类基于Spring Boot加Vue的开源快速开发平台，把工单、报工、物料这几张核心表生成一遍后台管理页面，拿进车间让班组长试用。代码生成器一导入，前后端CRUD和权限菜单自动生成，两三天就能有一个能看的MES雏形。

6.1 用若依代码生成器把工单表变成可操作页面

先建一张最小的工单表：

CREATE TABLE mes_wo_proto ( wo_no varchar(64) NOT NULL COMMENT '工单号', product_code varchar(64) NOT NULL COMMENT '产品编码', plan_qty decimal(10,2) NOT NULL COMMENT '计划数量', report_qty decimal(10,2) DEFAULT 0 COMMENT '累计报工数量', order_state char(1) DEFAULT '0' COMMENT '工单状态:0新建,1已下达,2开工', PRIMARY KEY (wo_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='若依代码生成器验证用工单表';

这张表故意只保留五个核心字段，不要塞满需求文档里所有列。用若依框架时，在系统工具里导入这张表的SQL，代码生成器会自动产出列表页、新增页、编辑页和对应的后端接口。拿这个页面给车间看，他们才会说“这里缺一个批次字段”“这里我要能按状态筛选”。这就是需求原型先行的价值。这里有一个具体踩过的坑：测试原型时不要直接改若依自带的系统表和菜单表，权限配置错了会连登录都进不去。正确做法是新建一个mes_前缀的模块，和系统管理模块分开。原型验证完，这些页面可以直接作为正式MES第一版的前端骨架，不用推倒重来。

车间制造执行系统（MES）的需求说明不是给IT部门自嗨的文档，它的每一章都必须能回答车间一个问题：这套系统上线后，我怎么排活、怎么报工、怎么追溯。先把数据模型用SQL验证一遍，再把界面用若依这类快速框架生成出来给车间点，最后回到需求表逐条确认约束条件。这套流程走下来，MES项目就不会停留在需求说明（参考）这四个字上。这是我做了多个MES项目后最想保留的习惯：先让数据说话，再让界面说话，最后才让文字说话。希望帮到你。

本文还有配套的精品资源，点击获取