企业官网建设流程全解析

上周去一家连接器工厂协助排查 MES 排产不生效的问题，车间主任拿着对讲机在产线边上急得团团转，计划员在办公室盯着 ERP 订单干瞪眼——订单明明下了，产线却不知道先做哪个。这个场面我见过太多次了。问题不在于企业有没有系统，而在于计划层和执行层之间隔了一层“黑匣子”，MES（制造执行系统）就是用来填平这层鸿沟的。

这篇内容写给三类人：刚接手 MES 项目的制造业 IT 运维人员、想搞清楚车间到底需要什么的车间主管、还有准备转行做 MES 开发或实施的软件工程师。我会从概念讲起，再延伸到选型落地、技术实现、监控运维和上线后最常见的那些坑，尽量用“车间里能听懂的话”把整条链路说清楚。

1. MES 到底是什么：制造现场的操作系统

很多人第一次接触 MES 的时候，会被厂商的 PPT 绕晕。什么精益制造、数字孪生、全流程追溯，一堆概念砸下来，最后也没搞明白它和 ERP 有什么区别。换个角度理解就简单了：ERP 管的是“该做什么、花了多少钱”，MES 管的是“现场到底在做什么、做到哪一步了、做得怎么样”。它是连接 ERP 计划层和车间设备控制层之间的那个中间调度层。

1.1 从一张生产工单说起

你去车间里随便找一个工位，问操作工今天干什么活。没有 MES 的时候，他可能翻出一张纸质派工单，或者看一眼墙上白板；有了 MES，他的工位屏上会自动跳出当前要做的任务，扫码枪扫一下物料条码，系统就能告诉他这道工序的工艺参数、图纸编号、检验要求。

这个过程背后其实是一条清晰的数据流：ERP 接到客户订单后生成生产订单，MES 把生产订单拆成多个生产工单，按照设备负荷排产，再把工单下派到具体工位。操作工点“开始生产”算开工，做完扫描报工，系统记录下用了多少时间、消耗了多少物料、谁做的、用的是哪台设备。质检员在旁边录入首检和巡检结果，最后产品装箱，扫描序列号绑定客户订单。

这样一圈走下来，MES 实际上把车间里原本靠口头传达和纸质单据流转的信息，变成了可查询、可统计、可追溯的电子数据。老板想知道这批订单做到哪了，不用再打一圈电话，打开看板一看就知道：哪个工单还在排队、哪个已经在返工、哪个已经入库了。

1.2 MES 的五大核心能力

市面上的 MES 产品模块很多，功能树拉出来能写两页纸，但真正在车间里产生价值的是下面五个核心能力。

第一，生产排程与派工。它解决“先做哪个、用哪台设备做”的问题。不需要做到 APS（高级排程系统）那么复杂，但至少要把插单、急单、设备故障导致的任务调整在线完成。现实情况是很多工厂还在靠 Excel 排产，排程员的个人经验成了瓶颈，MES 至少能把规则沉淀下来。

第二，工单执行与报工。这是 MES 运转的底座。每个工单从哪里开始、经过了哪些工序、每一步是谁做的，系统都要如实记录。扫码报工是最常见的方式，简单说就是“干完活扫一下”，但为了防止串工序、漏报工，又要在软件层面做防错校验。

第三，质量追溯。这个能力在汽车零部件、电子、医疗器械行业是刚需。客户要求批量追溯，甚至单件追溯，一旦出问题要能查到那个批次用了哪批原材料、哪些设备加工过。没有 MES 的时候，追溯一场客诉要翻三天纸档记录，有 MES 后一条 SQL 就能查出来。

第四，设备监控与点检。采集设备状态、计算开机率、统计故障停机时间，顺便把每天/每周的设备点检电子化。很多工厂的设备数据其实非常丰富，但散落在 PLC（可编程逻辑控制器）里没人去看，MES 的价值是把这些数据转成 OEE（设备综合效率）这类管理层看得懂的指标。

第五，绩效与统计分析。产量、直通率、不良率、工时达成率，这些数据如果能实时来自报工记录，车间管理者和老板就可以在每天班前会上看到真实数字，而不是月底从 Excel 里再统计一遍。

提示：入门阶段别被 MES 的功能清单吓到，先跑通报工、追溯、看板这三条主线就够了，其他功能都是在这三条线上长出来的枝叶。

2. 选型和落地：从业务梳理到系统上线

选型之前先梳理业务，这是 MES 项目跟普通 IT 项目最大的区别之一。一个标准的进销存软件买回来按培训操作就行，但 MES 必须面向你车间里的实际工位、设备、工艺和人员来配置。同一家软件公司做出来的 MES，在五金厂和电子厂的用法完全不一样。

2.1 先梳理车间业务，再谈软件

我在项目里经常先给客户做一次“车间体检”，流程大概是这样的：画出从原材料入库到成品出库的业务流程图，标出每个工序节点的输入输出；确定唯一数据源，比如工单号、批次号、序列号，到底以谁为准；明确数据采集点，哪些位置必须扫码，哪些位置要自动采集；定义追溯粒度，是批次追溯还是单件序列号追溯；最后把流程表单发给车间主管确认，避免实施后返工。

这个阶段最容易被忽略的是“追溯粒度”。很多工厂嘴上说要做单件追溯，但产线上根本没有打序列号的能力，标签打印又频繁出错，最后只能退回批次追溯。与其这样，不如前期就定清楚：普通物料批次追溯，关键安全件单件追溯，这样既控制了成本又满足了客户要求。

业务梳理的产出，应该是一份包含了工序字典、物料编码规则、设备台账、班次模型的《业务流程说明书》。别小看这份文档，后续 MES 的数据库表结构设计、界面字段设计，全都基于它来落定。没有这份东西直接开建系统，多半会在上线前一个月推翻重来。

2.2 数据采集与设备对接怎么做

车间数据的采集方式，决定了 MES 的实施难度和体验好坏。我把常见的方式列个表，你可以对着自己车间的情况勾选：

我建议中小工厂从扫码枪和工位屏起步，先让数据“转起来”，再逐步打通 PLC 和 OPC UA。一上来就想把所有设备都自动采集，项目周期会无限拉长，极易烂尾。

2.3 与 ERP、WMS 的数据边界

MES 不是一个孤立系统，它至少要跟 ERP 和 WMS（仓储管理系统）打交道。很多项目出问题，不是 MES 本身不行，而是系统之间的数据边界没划清楚。

通常的边界是这样的：ERP 负责物料主数据、BOM（物料清单）、工艺路线、生产订单和生产成本；MES 负责工单执行、质量数据、在制品状态、设备数据和人工工时；WMS 负责成品入库和原材料出库。MES 做完工单后，要把物料消耗、人工工时、完工数量回传给 ERP，ERP 才能算成本、做结算。别让 MES 直接改财务数据，也别让 ERP 去管工位级别的报工。

落地时我一般推荐用“接口表”的模式：ERP 把要下发的数据写到中间表，MES 定时拉取；MES 要回传的数据也写到中间表，ERP 定时读取。这个模式虽然土，但排查问题特别方便，数据对不上时打开数据库看一眼就知道是哪一步断了。

3. 技术视角拆解：如何搭一套轻量级 MES

我注意到最近很多人搜索“基于若依框架的 MES”。若依是国内很流行的 Java 快速开发平台，底层是 Spring Boot 加 Vue，自带用户权限、菜单管理和代码生成器。用它来做 MES 的底座，确实是一条性价比很高的路子。

3.1 为什么很多人选若依框架做底座

如果你找个成熟的商用 MES 厂商来报价，动辄几十万起步，而且要按工位、按模块额外收费。对于预算有限、又希望系统贴合自己车间流程的中小工厂，找一个开源框架做二次开发是现实的选择。若依能火起来，一是因为 Spring Boot + Vue 的生态成熟，招人容易；二是它已经帮你把登录、用户管理、部门管理、操作日志、定时任务这些东西做好了，MES 项目组可以把精力集中在车间业务逻辑上。

单从 MES 的角度看，若依还有几个很受用的能力：代码生成器能快速生成单表的增删改查页面，物料台账、客户信息、设备台账这类基础资料模块可以直接生成后改一改；支持多数据源，可以连 MySQL 以外的实时数据库；自带部门数据权限，天然适合“车间主任只能看本车间数据”的管控要求。

任何一个框架都有学习成本，选若依的前提是你手里有 Java 团队，能看懂这个框架的代码并做二次开发。如果没有开发团队，还是回过去选成熟的商用产品更稳妥。

3.2 核心模块设计与权限模型

结合我自己做过的项目，用若依做 MES，核心模块一般可以拆成这六块：

• 基础资料：物料、工序、工艺路线、设备、工装、员工。
• 计划管理：生产订单导入、工单拆分、排程派工。
• 执行管理：开工、报工、转序、不良、返工、拆批合并。
• 质量管理：检验计划、首件检验、巡检记录、不合格品处理。
• 设备管理：点检保养、故障报修、运行记录。
• 看板报表：工位任务推送、车间大屏、日产量报表。

权限模型上，我建议在若依默认的角色权限之上增加一层“班组-设备组”的数据范围。具体说，就是每个用户挂在一个班组下，工单派工只能看到本班组范围内的设备，质检员能看到全车间但不允许修改别人报工记录。这样既能防止车间之间互相看到数据，又避免了权责不清导致的质量数据篡改问题。

3.3 工位终端和车间大屏的实现思路

轻量级 MES 的工位终端一般就是一个装浏览器触屏模式或者安卓 App 的平板。报工请求通过 HTTP 接口发给后端，核心接口像这样：

@RestController @RequestMapping("/api/shopfloor") public class ShopFloorController { @PostMapping("/report") public Result report(@RequestBody ReportVO report) { // 核心业务：校验工单状态、记录报工明细、计算完工数量 reportService.saveReport(report); // 通知大屏和相关工位刷新数据 wsService.pushStatistic("workshop:update", report.getWorkshopId()); return Result.success(); } }

这里有几个容易忽略的点：报工接口必须是幂等的，否则操作工双击“保存”就会产生两条报工记录；记录生产时间时不要用操作工本地时间，要用服务器时间，防止设备时钟不准导致数据错乱。车间大屏的数据不建议让前端每秒轮询查数据库，更好的做法是把日报、OEE、在制量这类统计结果存在 Redis 缓存里，每 30 秒左右重算一次，大屏通过 WebSocket 接收变更通知。

4. 监控与运维：SkyWalking 能部署到 MES 制造系统吗

回答一下大家搜到的问题：SkyWalking 能部署到 MES 制造系统上面吗？能，而且很适合。MES 本质是一套 Java Web 应用，SkyWalking 是开源的应用性能监控（APM）系统，它跟车间里的机械设备完全不冲突，部署在应用服务器侧，用来盯 MES 服务自身的健康状态。

4.1 APM 在 MES 里看什么

先要明白 MES 系统出问题时的典型表现：车间那台工位屏转圈圈转很久、扫码上传半天没反应、大屏数据不刷新了、夜班的时候某个功能的接口突然变慢。如果没有监控工具，运维只能靠用户反馈和事后翻日志，非常被动。SkyWalking 这类 APM 能帮你直观看到，某个工单查询接口平均耗时是多少、最慢的时候出现在哪个时间段、瓶颈是在数据库还是在远程调用、有没有线程池阻塞。

我比较关注 MES 里的这几项指标：服务拓扑图里各模块之间的调用关系是否出现大量超时；P99 延迟是否突破 3 秒红线（工位终端超过 3 秒用户就会开始暴躁）；慢 SQL 有没有集中在某张业务大表上；JVM 内存曲线是否在涨，有没有频繁 Full GC；消息队列相关的异步任务积压情况。

MES 的并发量虽然不像互联网电商那么夸张，但它的特点是强交互、低容错。生产报工这个动作如果卡住，整条产线都要停下来等，影响远比一个网页慢要严重，所以 APM 监控对 MES 运维来说不是锦上添花，而是刚需。

4.2 部署 SkyWalking 的组件和资源

SkyWalking 本身由三个部分组成：Java Agent 探针，用来收集服务端应用的数据；OAP 服务端，用来接收、聚合和存储这些数据；UI 界面，用来展示链路和指标。

小规模 MES（比如一两百个工位、应用服务器两台）部署建议如下：应用服务器上装 Java Agent；OAP 单独一个节点，2 核 4G 起步；存储默认最简单的是 H2，但生产环境不要用，常见用法是 Elasticsearch，或者 MySQL 存储模式小规模使用。用 MySQL 做存储时，需要把对应版本的 mysql-connector-j 驱动放到 OAP 的 libs 目录下，并在 application.yml 里把 storage.selector 改为 mysql，然后初始化数据库脚本。

如果你们公司不允许引入额外的存储组件，MySQL 模式是更轻的选择。但要注意 SkyWalking 的 OAP 查询能力在 MySQL 模式下会弱一些，日志保留周期也建议调短，避免磁盘空间涨太快。索引和清理策略要在运维手册里提前写清楚，否则上线半年后磁盘被监控数据塞满，那就很尴尬了。

4.3 Spring Boot 服务接入 Agent 的实操

假设你的 MES 服务就是标准的 Spring Boot 应用，接入方式非常简单，一行启动参数搞定。下面是以若依框架为基础的 MES 服务启动命令示例：

java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \ -Dskywalking.agent.service_name=mes-server \ -Dskywalking.collector.backend_service=10.10.20.5:11800 \ -Xms2g -Xmx2g \ -jar mes-server.jar

几个注意点：Agent 版本和 OAP 服务端版本的大版本要一致，否则探针上报的数据可能解析异常；MES 和 OAP 之间的 11800（gRPC）端口和 12800（HTTP）端口要在防火墙里放行；如果 MES 和 SkyWalking 分别在车间内网和办公网，要评估网络策略是否允许上报数据穿透。

监控部署完成后，别着急去看那些花花绿绿的拓扑图，先自己打几个典型场景来验证：登录一次、做一个报工、查一次工单列表，确认 SkyWalking 里能对应看到这些链路和耗时再交接给运维。

5. 上线后的常见问题与排查实录

MES 上线只是开始，真正考验人的是在车间里跑起来的头三个月。我把自己踩过的坑和一些高频问题整理成一份速查表，基本覆盖了大多数 MES 项目的上线初期阵痛。

5.1 我的排查顺序

车间报障“MES 卡顿”或者“报工不上”，我一般会按固定顺序排查：先看服务日志和 SkyWalking 错误链路，确认是不是接口报错；然后看数据库慢查询日志，重点查工单、报工、追溯这几张大表；再看 Redis 缓存是否失效导致缓存击穿，比如大屏查询直接打到数据库；接着看网络层，车间里的无线 AP 是否老化、扫码枪连接的 WiFi 是否丢包；最后看前端终端环境，浏览器版本太老或者工位屏内存不够，也可能造成卡顿假象。

这个顺序的核心原则是“先服务端后终端”。车间报障的时候操作工往往会一口咬定是“系统坏了”，但很多时候问题出在无线网络覆盖盲区或者工位平板硬件老化上。作为实施方，你能做的就是提供一套可排查的证据链，而不是跟现场人员争辩。

5.2 高频坑汇总

下面这些坑我基本都亲历过，写出来供你提前防范：

5.3 一个可复制的 MES 上线案例

如果你依然觉得抽象，我分享一个比较典型的电子组装厂案例：200 个工位，主要做 PCBA 代工，客户要求批次追溯。项目用的是轻量级 MES，一期三个月上线。第一个月，主要做基础资料导入、网络改造和工位终端部署，扫码枪全部换成支持 UTF-8 编码的型号；第二个月，先只跑首件检验和关键工位报工，其余工序仍然沿用纸质流转单，保证产线不停；第三个月，把质量追溯和返工流程跑通，同时上了车间大屏。

这个项目的关键点在于把握好节奏。第一、二个月虽然系统只有部分工序在用，但数据链已经真实跑通，管理者能通过看板看到效果，操作工也逐渐适应扫码报工的操作习惯。到了第三个月，质量追溯数据已经积累起来了，再做追溯查询演示，老板自然愿意继续投入做二期设备联网。

反过来，我见过很多项目一上来就是“全工序强制卡控”，结果某个工位扫码设备不好用，整条产线就停在那里等 IT 处理，车间主任第二天就把系统停了。对于没上过 MES 的工厂，一定记住四个字：先松后紧。

结尾：一点踩坑后的心里话

搞了这么多年的 MES，我最大的体会是：这个系统的技术难点远没有业务习惯的转变难。很多项目最终没跑起来，不是因为 SQL 写得不够优化，也不是因为框架选得不好，而是没能让现场操作工和管理者真正信任这套数据。操作工不想每做一次工序就多点两次屏幕，班组长觉得系统里的报表和自己手头的 Excel 对不上，于是系统慢慢就被晾在一边了。

想让 MES 真正落地，除了把系统功能做好，更重要的是走到车间里去，听操作工抱怨，看他们手上的动作，把界面做得足够“不添麻烦”。系统上线以后，也一定要有人长期在车间巡回收集反馈，每周迭代一次界面和流程。技术只是起点，让现场的人愿意用它，才是 MES 项目真正结束的那一天。