ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

MES核心功能、返工返修与开源选型实战解析

MES核心功能、返工返修与开源选型实战解析 车间里那种最典型的混乱场面做过制造的人应该都眼熟计划员手里拿着ERP下出来的生产订单却说不清这批活今天到底排在哪台设备上班长靠纸质流转卡和群聊安排工作质检员把检验结果敲进Excel到月底品控想追溯某批凌晨出货的水冷板用了哪一批原料、在哪台炉子上钎焊、操作工是谁翻遍表格也还原不出来。这种“有计划、没执行”的状态几乎就是MES系统缺位的标准画像。计划层ERP管不到车间设备层PLC又只关心参数能把“订单、人、物料、设备、质量”串成一条线的正是MES。这篇文章我就从一个实施过多个制造项目的旁观者角度把MES的核心功能、返工返修、开源选型、系统集成这些大家问得最多的话题摊开聊一聊不管是车间主任、IT负责人、MES产品经理还是第一次接触MES的实施顾问应该都能找到有用的部分。1. MES到底补的是谁漏出来的空缺1.1 计划层与设备层之间的“最后一公里”ERP的本职工作是管“资源计划”采购、库存、财务、订单。它的数据粒度通常是“天”甚至“周”以订单为维度对车间内部“哪个工序、哪台设备、哪个班组在什么时候干什么”并不敏感。生产计划下达之后ERP就把接力棒交给了车间车间跑得好不好ERP只能靠事后报工回填。车间里面真正发生的过程ERP往往是一笔黑账。底层设备层则是另一套语言。PLC、传感器、SCADA系统掌握着温度、压力、节拍、转速这些实时参数它们知道设备此刻在运转但不知道这个工件属于哪个销售订单、用的是哪一批物料、下一道工序该去哪里。设备数据是“物理真实”但不带任何业务语义。MES就卡在这个中间层。它要做的事是把ERP的计划翻译成车间能执行的工序级任务同时在设备执行过程中把设备数据接住再带着工单、批次、人员、质量信息回传给ERP。用制造行业常说的ISA-95分层来看ERP和SCADA之间那一层就是制造运营管理层也就是MES的地盘。这个位置决定了MES的核心矛盾既要接得住上层计划的变化又要扛得住下层设备的实时数据。1.2 没有MES时车间靠什么在“运转”很多工厂的排产和调度其实是由班组长、计划员的经验和Excel表格完成的报表是下班前让统计员手动汇总的产品出问题后的追溯靠纸质批次卡和人的记忆。这种情况在产品种类少、产量不大、客户不追根究底的时候还能凑合一旦订单变多客户要求把追溯批次细化到单个产品手工这套体系很快就会崩塌。我见过一家做汽车零部件的工厂上MES之前全厂有几千份纸质随工单。月底客户审计要追溯一批产品的原料批次和检验记录四个人翻了两天单据最后结论是其中一叠单据缺失只能给客户一个大概结论。客户当场就停止下单这个代价比一套MES软件本身贵得多。MES不是解决所有问题的银弹它解决的核心问题是把制造过程从“靠人记、靠口传、靠经验”变成“靠系统记录、靠流程约束、靠数据说话”。很多团队一上来就讨论该上哪个厂商的MES其实不如先想清楚你这个车间到底有多少信息目前是靠“人肉”在维护的2. 核心功能拆解从工单下达到产品入库数据是怎么一路走的完整MES的功能模块很多但如果你想理解它的骨架重点看六个方面工单与排产、物料与批次、质量与缺陷、设备与数据采集、人员与绩效、报表与分析。下面按一条产品在车间里的完整流转路线来讲。2.1 工单接收与工序级排产把订单拆到“工序”才算开始MES和ERP之间的第一件事是接收生产订单。但只把订单接到系统里是远远不够的MES要做的是把生产订单进一步拆成工序计划哪些订单投放到哪条产线、在哪台设备上加工、什么时间开始、什么时间结束。工序级排产要考虑的不只是产能还有设备状态、工装模具是否空闲、物料是否齐套、人员技能是否匹配。比如一台加工中心既要承担新品试制又要做量产件如果排产时不知道这台设备当前的实时任务就会造成频繁换型实际产出远低于理论产能。虽然有专门的高级计划排程APS产品但大部分企业上MES首先能实现的是把手工排产搬到系统里让计划员在一个界面上看到所有订单在各工序的当前状态然后把指令精确下达到工位。排产做扎实之后车间执行就是按计划报工。操作工在工位终端或PDA上进行开工、报工、完工报工触发后续的物料消耗、工时统计、工单状态更新。很多人问“MES和ERP的区别是什么”最直观的区别就在这里ERP里一个订单的状态通常是“下达、执行、完工”而MES里的工单会细到每一道工序都有“排队、就绪、运行、暂停、完成、关闭”这样的状态。提示不要在第一版就追求“全自动智能排产”。先做到计划员在系统里手动排、现场按系统计划执行再逐步引入优化算法否则数据和规则都还没稳定排出来的结果没人敢用。2.2 物料流转、批次绑定与正反向追溯扫码防错只是入门上MES的第一步往往是把物料台账移进系统给物料打条码或绑定批次。到货时收料员用PDA扫码入库发料时按BOM自动跳出的料号清单去备料投料时操作工扫码确认“当前工单、当前工序、当前物料”三者匹配。如果某道工序要求必须使用指定批次的物料系统还能做物料防错扫错条码时直接报警拒绝投料。追溯是制造业客户最看重的功能之一尤其汽车零部件、食品药品和电子行业。追溯分两个方向正追是从原料批次出发查到这批料被投放到哪些生产订单、哪些产品序列号SN最终出货去了哪里反追是从一个成品SN出发反查它用了哪几批原料、经过了哪些设备、哪些检验项目、哪些人在什么时间操作了哪些工序。实现追溯的前提是MES在每道关键工序把“SN、物料批次、设备、工装、人员、工艺参数、检验结果”这几个对象绑定起来。绑定关系越全追溯链越完整采集成本也越高。到底绑定多少道工序必须和业务部门逐条确认不能想当然地做全工序采集那会把操作工逼疯也会让系统沦为摆设。2.3 质量检验、SPC与不良品处理质量不是统计出来的是被流程管出来的很多企业原本的质检流程是“巡检员现场抽检结果记在纸上下班后录入Excel”。MES的质检模块做两件事一是把检验计划和检验项目录入系统按产品、工序、频次自动触发检验任务二是检验结果直接在线采集自动进入质量台账不用二次录入。检验不合格时触发不良品处理流程包括隔离、评审、返工返修、让步接收或报废每一步都有系统记录。对批量生产的工序还能引入SPC统计过程控制。系统实时算控制图的均值、极差超限时自动报警而不合格品单又和物料批次绑定。等到追溯时质量数据是判断批次放行或扣留的重要依据。一个批次一旦出现严重不良质量工程师可以在系统里对该批次做“质量扣留Quality Hold”把库存和车间里所有关联该批次的产品全部卡住避免不良品继续流转。质量模块上线后的第一件事不是急着做自动SPC报警而是先把“不合格品处理单”跑通。很多项目SPC的算法都很专业可现场根本不录入不良数据分析得再漂亮都是白搭。2.4 设备数据采集与OEE自动报工只是顺带的好处设备层的采集是实现MES实时性的难点。常见的采集方式有三种。最简单的是操作工在终端扫码报开工、报完工设备状态基本靠人点。带PLC的设备可以走OPC UA、Modbus或以太网直接采设备状态和工艺参数比如冲压机的模具计数、加工中心的当前程序号、热处理炉的炉温曲线。还有一种是加装传感器和数据网关把非智能设备的电流、振动信号抓上来判断设备是在干正常活、空转还是停机。设备数据接上来之后最常用也最容易被乱算的指标就是OEE设备综合效率。OEE 可用率 × 性能 × 良率。举个例子一台设备计划开机8小时实际切机7小时可用率是87.5%运行期间理论节拍是每分钟2件实际平均每分钟只做了1.6件性能率是80%良率是95%那OEE就是0.875 × 0.8 × 0.95 ≈ 66.5%。这个数字比“设备今天转没转”更能反映浪费在哪里。不过要注意OEE算法里的时间口径很多至少要提前和现场定清楚什么是计划停机、什么是故障停机、什么是换型时间否则指标出来之后大家各说各话。从设备自动采集还能带来一个隐性好处自动报工不再依赖操作工决定什么时候按“完工”按钮而是设备加工完成一个或一批后自动触发产量计数。这样能有效减少漏报和补报也为后续效率分析提供干净的数据源。2.5 人员资质与绩效把“人”接进数据闭环如果系统里没有人员维度追溯链就断了一环。MES里的人员模块通常管三类信息一是人事主数据同步员工工号、班组、班次从HR系统或Excel导入二是岗位资质比如叉车证、电焊证、某些特殊工序的上岗证系统可以在派工时校验“该员工是否具备该工序的技能”三是个人绩效数据合格产量、一次合格率、工时利用率这些数据全部来自前面的报工和检验不需要再做一层手工统计。人员模块做得太细会遭现场抵触做得太粗又没法用。我的经验是第一版先保证“每个报工动作都有人员工号”同时把关键工序的上岗证校验做上。绩效报表排到后面等大家养成扫码习惯之后再展示数据否则一上来就出个人绩效排名现场很容易把矛盾对准系统。3. 返工返修模块为什么做得好的人不多但决定系统口碑3.1 正常路径跑通之后异常路径才是分水岭很多MES项目在蓝图设计阶段会重点画正常流来单、排产、投料、加工、检验、入库一切看起来完美。一旦上线后产品出现不良现场第一反应是用系统外的方式处理评审放在微信上返工单写在白板上返工后再按原工序偷偷报工或者干脆把返工产品夹在下一批正常产品里重新走一遍。这样做的结果是不良记录有了返工动作却完全没有被系统记录返工后的复测数据也找不到。等到客户投诉某批次产品系统追溯出来是“不合格”但后续状态到底“已放行”还是“已返工”根本说不清。这就是返工返修模块做得不好的典型下场。要判断一套MES能不能真正落地我的经验是先去问车间主任不良品在系统里怎么走如果他说“有返工单流程”那就还有救如果他支支吾吾那系统多半是摆设。3.2 返工返修流程设计的几个关键点返工流程的本质是给不良品开一条“特殊工艺路线”。设计上要注意几点。第一返工单要和原工单、原SN强绑定。系统里要能看到这个SN原本属于哪个工单、在哪道工序被判不合格、不合格编码是什么。第二返工也要有工艺路线。它可能是原路线的某几道工序也可能是新增的专门工序比如拆解、清洗、补焊、复测。需要在系统里建好返工工艺路线模板不能允许操作工在现场自己决定跳过哪一步。第三状态机要闭环。返工单创建后至少有“待返工、返工中、待检验、已放行、已报废”这几个状态每一步转序必须由指定角色触发。第四原始质量记录不能被覆盖。返工前的检验数据和返工后的复测数据要并存不能把不合格记录“改”成良品。第五返工次数要限制。连续返工两次还不合格的强制报废不然容易出现无限返工。第六返工成本要单独统计。返工工时、返工损耗的物料、返工检验成本都是质量成本分析的重要输入如果混在正常的生产成本里成本报告会失真。3.3 一个具体的场景汽车水冷板的返工返修怎么做汽车水冷板是新能源车电池热管理系统的关键件主要用来给电芯冷却散热。它的典型工艺路线大概是铝板机加工、钎焊把水腔和流道密封焊接起来、清洗、气密检测、涂装、终检入库。钎焊和水道密封是质量关键不良也往往出在钎焊和气密这两个环节。水冷板钎焊不良常见的有钎着率不足、局部未熔合、气孔或泄漏。在MES里气密检测设备自动把泄漏率数据传到系统一旦某个SN的泄漏率超出标准系统自动判定不合格产品进入“质量扣留”队列。这时质量工程师在系统里新建返工单选择返工工艺路线中的“补焊→再清洗→再气密测试”同时记录本次返工的原因是“气密不合格泄漏率0.32”而不是让产线工人直接把这件板子混进下一批正常产品里重新过炉。返工执行时操作工扫码SN系统显示的生产指令是“返工”工艺参数另存一套返工配方不能直接调用正常生产的钎焊配方。复测通过后返工单关闭SN被释放回合格品库。此时追溯链里完整保留了原始首测不合格记录、返工单、返工后的测试记录。如果同一个SN在系统里已经有两次返工记录第三次再被判不合格时系统会直接提示“建议报废”禁止它继续流转。水冷板一旦漏液可能造成整套电池包报废追溯和责任判定的压力非常大返工返修这个模块如果不扎实质量和交付都容易失控。4. 开源MES的现实一套免费的盒子到底能装进多少东西4.1 为什么很多企业会盯上开源MES“MES系统开源一套足以让生产制造企业用起来”——这种说法我在不少技术社区都看到过。对预算有限的中小工厂开源MES的吸引力确实明显软件免许可费、源码可拿到、理论上能按自己工厂的流程做二次开发还能避免被厂商锁定。有一些开源项目也确实提供了基础的生产工单、物料、报工功能跑个Demo是能看的界面也算现代。尤其当企业已经有一个信息化团队、只是缺一套MES时很多人会觉得“买商业软件不如基于开源改造”。这种想法不是不行但需要先搞清楚开源MES的真实边界和隐性成本。4.2 开源项目的真实瓶颈我研究过的几个开源MES项目能覆盖“工单→工序→报工→简单库存”这条主线的已经算不错了但到了制造企业的核心诉求差距就很明显。典型问题包括数据模型偏通用没有行业模板汽车行业的SN单件追溯、半导体行业的Recipe管理、医药行业的批记录与审计追踪开源项目基本不会预置质量模块通常很浅只有“检验”和“不合格记录”没有完整的不良品处理流程、SPC和质量管理闭环追溯链不完整报表能力弱很难满足客户审计要求文档和社区支持跟不上出了问题响应基本靠自觉。更关键的是二次开发成本。开源项目的底层数据模型和商业MES一样复杂本地化改造下来花的人力成本往往比买商业产品还高而且数据模型一旦改得和上游不兼容后续升级基本没戏。源码免费不等于实施免费、维护免费、能力免费。4.3 什么场景适合选开源什么场景真的别碰我的建议可以总结成一张判断表。评估维度适合开源MES建议商业产品或深度定制工艺流程简单、稳定、通用工序少复杂、多分支、行业特殊要求多追溯要求按批次即可不追到SN单件SN追溯、客户审计严格IT团队有专职开发能持续二次开发没有开发力量只想买来用预算软件费用批不下来有预算更看重上线周期与兜底合规要求无强制法规约束药械、食品、车规级需要严格验证哪怕是从开源起步的项目也不要幻想“装上就能用”。要把二次开发、实施、培训、数据整理的预算都当成完整项目预算来估算。项目成败不在代码而在实施。5. 系统集成与可观测性数据要在三个方向上流得动5.1 ERP、MES、PLC三层的接口边界MES不是一个孤岛它要同时和上层ERP与下层设备打交道。向上最常见的是ERP和MES之间的主数据同步物料主数据、BOM、工艺路线、生产订单从ERP推给MESMES把报工数量、物料消耗、完工数据、不良品数据再推回ERP。向下MES要把作业参数、配方、工单信息下发给设备或PLC再从设备采集状态和工艺参数。接口方式各有取舍。直接共享数据库表最直接两边都认同一套中间表就行但耦合也最高字段一改就要同步改逻辑。WebService是很多老ERP的标配SOAP报文比较啰嗦但跨系统兼容性比较好。MQ消息队列是我更推荐的方式订单下达、完工回传都通过消息异步解耦就算下游系统临时宕机消息积压也不会丢数据。不管用哪种方式接口设计的第一原则是明确主数据源物料编码只能有一个出处防止两边各改各的。5.2 对接WebService这类老接口最容易翻车的地方“WebService和MES能不能对接”这个问题实践里问的人很多。能对接但踩坑也多。老系统提供的往往是SOAP接口字段命名、命名空间、编码格式都要严格对齐。对接时最容易翻车的几个点一是字符集老系统常用GBK新的MES默认UTF-8中文物料名发过去直接乱码二是报文格式时间的格式、数量的小数精度一旦对不上回传的完工量和当地ERP台账对不齐三是重试与幂等网络超时后把同一个请求重发一次如果系统没有幂等处理仓库就多了一次入库记录。我的做法是正式联调前一定先向对方要接口文档和两三个真实样例报文把每个字段和本地字段逐一对齐做好字段对照表再开发。联调时专门准备一套测试数据模拟超时、重发、部分失败这些异常场景把这些情况都跑一遍会比只跑正常流程更早暴露问题。5.3 微服务化的MES能不能用SkyWalking来监控这个问题在技术圈问得越来越多。我的回答是能而且如果你的MES已经拆成微服务架构SkyWalking这类APM工具几乎是刚需。原因很简单微服务化之后一次报工请求可能要经过网关、工单服务、物料服务、质量服务、消息队列和数据库任何一个环节慢整条链路都会卡住。SkyWalking用Java Agent对应用做探针注入业务代码基本不用改就能看到服务之间的调用拓扑、每个接口的调用耗时、数据库慢查询以及错误分布。对排查“某个MES页面为什么这么慢”这类问题非常有效。java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \ -Dskywalking.agent.service_namemes-workorder-service \ -jar mes-workorder-service.jar如果你用的是单体老MES或者大量依赖手工报工的系统SkyWalking也能部署但可观测性价值会弱很多没有服务间调用关系只能看单个接口的方法级耗时。另外特别提醒一句SkyWalking监控的是应用性能和调用链它替代不了对PLC设备的工业数据采集。一个是看软件系统健康程度一个是看车间设备状态两者不要混为一谈。6. MES项目里真正吃时间的往往不是功能开发6.1 基础数据不干净系统越强错得越猛MES上线前最容易被低估的是基础数据整理。物料编码规则不统一、同一个物料在仓库叫A在车间叫B、BOM版本混乱、工艺路线标准工时从来没校正过。这些问题不解决系统上线后要么报工找不到工单要么成本计算的数值偏差很大。我在一个项目里花了一个月时间和业务部门一起逐条核对物料主数据后来上线顺利靠的就是那一个月。有的团队指望“系统能帮我清理数据”现实是系统只会放大你的脏数据。原来靠人还能兜底系统一开错误流程直接被固化后面改起来比上线前整理麻烦得多。6.2 车间网络和扫码硬件比想象中更容易拖后腿MES是离不开现场设备的。无线网络在车间的部署比办公楼麻烦得多产线设备大量金属会挡信号AGV通道上需要无漫游切换扫码枪在高速产线上的读码率要求很高标签打印机打出来的条码不能被车间油污和灰尘污染。很多项目软件功能没出大问题反倒是PDA连不上网、条码扫不上导致操作工不愿意用。还有紫外固化、空压机房、大型冲压设备附近的电磁干扰或者AGV行走路线的信号盲区这些在规划时就要做现场网络勘测。最朴素的做法是上线前把每一台终端、每一把扫码枪在真实工位的信号强度和扫码成功率完整测一遍别等问题到上线当天才暴露。6.3 第一版别贪多先做“记录”再做“优化”MES能做的事情很多排产、调度、仿真听起来都很有价值但第一版最好聚焦两件事第一把现场发生的每个关键动作记录下来——谁、在什么时候、对哪个工单、用了哪些物料、在哪台设备上、做出了多少件、检验结果怎么样第二把异常路径管住尤其是返工返修和不良品流转。记录做得扎实之后后续的报表、OEE、优化排产才有数据基础。一上来就搞智能排产往往卡在“数据还不准、建模还太粗”这个坑里排产结果没人敢用。商业案例里不少实施到一半失败的MES都是死在什么都想要的阶段。6.4 上线只是开始数据质量需要一只持续盯的“眼”MES长期运行的质量取决于扫码率、报工及时率、检验录入完整率这三个日常指标。扫码率掉到80%以下追溯链就开始有漏洞。我的建议是上线后第一年专门安排一个数据管理员每天出一份数据质量日报把漏扫、漏报工、未关闭工单这几类问题清单发给车间主管让问题在当天被消化掉。没有专人盯着再好的系统也会慢慢回到“系统一套、实际一套”的状态。常见现象根因对策扫码率越来越低终端卡顿、条码识别率差现场网络和硬件巡检工单长时间不关闭异常工序没人处理每日数据质量日报追溯结果对不上物料批次绑定不规范加强投料与检验环节的绑定校验返工走线下系统返工流程太麻烦简化返工界面和操作步骤我在好几个项目里最深的体会是MES能不能发挥价值不取决于选了多高端的软件而取决于现场的人愿不愿意把真实数据交给系统。你可以用很好的技术把功能做得很完整但如果操作工觉得多扫一次码是在耽误节拍计划员觉得系统排产不如自己的Excel好用这个系统就会慢慢变成摆设。所以我的习惯是做MES项目先跟班组长聊问他们每天最烦什么从他们愿意接受的小功能开始做数据一点点积累系统一点点长出来最后回头看比一开始画一个宏伟蓝图要稳得多。
返回列表