去年在一位汽车零部件工厂的信息化评审会上，我见过一张让我印象深刻的"MOM架构图"——标题是MOM，图里却密密麻麻画着OA办公、HR考勤、财务共享中心，PLC和SCADA挤在左下角，SAP用一根粗箭头连着"全系统"，仿佛所有数据都在一个池子里打转。评审专家第一个问题就是："你这张图里，MOM到底管什么？边界在哪？"

这不是个例。MOM（制造运营管理系统）是这几年制造业信息化里最热也最容易画错的概念之一。很多人以为MOM就是MES换个名字，或者觉得架构图上模块越多越显专业。但实际上，一张合格的MOM架构图背后，是对ISA-95标准、车间业务流、技术和集成边界的一整套判断。这篇文章我从架构视角出发，把MOM系统的分层逻辑、内部模块、数据主线、技术选型、SAP集成方式，以及画图时的实操方法，一次讲透。

1. 先回答绕不开的问题：MOM到底是不是MES换个名字

在聊架构图之前，这个灵魂拷问必须先解决。因为它直接决定你画出来的图是"新瓶旧酒"还是真正覆盖了制造运营全画面。

1.1 MES和MOM的核心差异不在名字，在边界

MES全称是Manufacturing Execution System，核心定位是"执行"，解决的是车间里工单怎么开工、在制品怎么流转、工序怎么报工、追溯怎么做。它本质上是围绕"生产执行"这条纵线展开的。

MOM全称是Manufacturing Operations Management，概念更宽。它不只管"执行"，还管整个制造运营域，包括计划和排程的详细落地、质量管控、设备维护、物料协同、人员资质、绩效分析。你可以简单理解为：MES管的是"从工单下达到产品完工"这一段；MOM管的是"整个车间级制造运营如何良性运转"这个面。

举个例子。一条装配线上，MES关注的是当前这批工单干到哪个工序了、报工数据准不准、序列号和批次能不能对上。MOM还会继续问：下一批订单的物料齐不齐？设备当前的健康状态能不能支撑连续生产？质量检验计划有没有随工单自动触发？今天这条线的人员资质是否覆盖所有关键岗位？OEE掉下去的原因到底是停机还是换型？这些问题加起来，才是MOM的完整范围。

1.2 ISA-95的Level 3: MOM在架构图里的锚点

MOM这个概念能成立，底层依据是ISA-95（在部分企业也对应IEC 62264）标准对制造企业信息化层级的划分。这个标准把企业从上到下分成几个层级，我用表格列一下：

MOM的位置就是Level 3。它上面承接L4的ERP，把经营计划转成可执行的生产工单；下面衔接L2的SCADA和控制设备，把自动化系统的实时状态接收上来，再把工艺指令传递下去。

这个分层直接决定了架构图怎么画。你画MOM系统架构的时候，底部一定是设备与数据采集层，顶部一定是ERP和周边业务系统，MOM自己位于中间这层。很多人把MOM画成一个大框把生产线包进去，这不是在画MOM架构，这是在画"数字化工厂全景图"。两者用途不同，别混。

1.3 什么场景选MES，什么场景该上MOM

说实话，单车间、工艺相对固定、项目预算有限的情况下，一套成熟的MES就能把执行问题解决大半。但如果你面临的是下面这些情况，我更建议以MOM视角来规划：

• 集团多工厂、多基地，需要统一的制造运营规范和KPI口径；
• 质量追溯要求高，比如汽车零部件、医疗器械、军工，要覆盖人机料法环全要素；
• 计划排产、设备维护、质量管理三个系统割裂严重，数据对不上；
• 管理报表需求多，SMT车间、总装、机加车间都要OEE、良率、异常分析。

MOM不是MES的完全替代，而是从"执行"向"运营"的一次升维。架构图里面，MES像一条纵向贯穿的线，MOM更像一张覆盖多个运营域的网络。想清楚这一点，后面所有模块绘制才站得住脚。

2. 从ISA-95的Level 3出发，理解MOM的上下游边界

架构图最忌讳的是"什么都往里面塞"。一个MOM系统的边界在哪里，上游下游各是什么，这是一张图能不能通过评审的关键。

2.1 MOM的上游和下游到底挂什么系统

站在ISA-95的Level 3来看，MOM的上下游关系其实非常清晰：

上游系统，主要是两类。一类是ERP（常见就是SAP），给MOM下发生产订单、物料主数据、BOM和工艺路线基础数据；另一类是PLM/PDM，提供产品设计数据、工艺文件、图纸签名版本。上游数据的特点是"准确性高、变更受控"，MOM基本不修改它们，而是接收、缓存、按需引用。

下游系统，一类是SCADA/DCS/PLC，采集设备状态、工艺参数、产量计数；另一类是自动化立库、AGV调度系统、检测设备、打印设备等，MOM要向它们下发任务指令。下游数据的特点是"实时性强、量大、格式异构"。

这套上下游关系画清楚之后，MOM自己的生态位就定了：它是站在ERP和自动化设备之间、负责把所有指令翻译成车间听得懂的语言、再把车间真实情况翻译回管理层看得懂的报表的系统。

2.2 常见的边界误判：多画或少画都不及格

我见过不少架构图，问题出在边界判断上。几个高频翻车情况：

一是把ERP的财务、成本核算功能画进来。MOM会提供工单成本归集的数据源，但成本核算本身是ERP的活，画到MOM内部会把图搞得很臃肿，也容易让评审专家质疑你对系统边界理解不到位。

二是把设备层完全忽略。有些图从应用系统直接跳到PLC，中间没有数据采集层和边缘网关。实际上MOM和PLC之间很少直接通讯，一般中间有一层边缘网关或SCADA做协议转换和数据暂存。这层不画出来，技术评审时会被追着问数据怎么来的。

三是把WMS整个画进MOM。仓库管理确实和MOM有大量交互，尤其线边库和原料仓的领料、入库。但成熟的WMS是独立系统，MOM和WMS之间是协同、不是吞并。如果企业已经有独立WMS，架构图上MOM的物料域应标成"与WMS联动"，而不是把WMS画成自己的一部分。

2.3 边界清晰后，图才具备"评审语言"

为什么MOM架构图最好以ISA-95为通用语言？因为参与评审的人背景差异很大：IT的人懂技术栈、OT的人懂设备、生产的人懂工艺。ISA-95的分层是制造业信息化领域最大公约数，能让大家在同一套坐标系里讨论问题。你把自己的系统定位在Level 3，评审专家自然就知道MOM和SCADA、ERP的关系是什么，需要追问的细节是哪一块。

这也是我给每一个准备画MOM架构图的团队的建议：先别急着打开绘图工具，先花半天时间把ISA-95的层级模型研究透，把自己系统的上下游设备、相邻系统列一张清单。边界理清了，架构图就成功了一半。

3. 纵向拆一层：MOM内部的模块拓扑与数据流主线

边界定了之后，第二步是把MOM系统内部的模块拆出来。这里有一个关键认知：MOM内部不是一堆功能堆在一起，而是围绕工单生命周期和制造运营目标组织起来的模块网络。

3.1 七大业务域：一个都不能少，但可以分批建设

按照我的经验，一个完整的MOM系统通常包含以下业务域：

这个划分参考了MESA国际对制造运营管理的定义框架，几乎每一个正式MOM项目都需要覆盖这些域。不同的只是落地顺序：有的从执行域起步，有的从质量和追溯切入，有的先做计划排程。规划架构图时要画全七大域，但项目路线图上完全按优先级分步实施。

3.2 一条主线穿起所有模块：工单生命周期

模块画在图上容易，让评审专家觉得"你这个架构是有机整体"则需要数据流设计。我在做MOM架构时，最核心的一条主线就是"工单生命周期"。

一个生产工单从SAP下发到MOM之后，会经历这样一条链路：计划域接收并排产，物料域做齐套检查，执行域派工和开工，质量域在关键工序触发检验，设备域在加工过程中采集状态数据，报工后物料域做完工入库，最后绩效域汇总产量、OEE和异常。每一步都有数据产生，每一步都要落到某个模块里。

所以架构图上模块之间的连线，不是"觉得有关联就画一条"，而是每条线都对应一段真实业务流。画图之前，我习惯先画一张业务流程图，标清楚每个节点的输入输出和负责模块，然后架构图自然就出来了。反过来，如果你先画架构图再补业务流程，很容易画出"满天星"式的图——所有模块都连到一条总线上，看不出主次和先后。

3.3 网状关系收敛为五条主线

现场业务是网状的，但画架构图要收敛。我习惯把MOM内部的数据流归纳成五条主线：

1. 计划主线：ERP订单 -> 计划域排产 -> 工单下发 -> 执行域开工。
2. 执行主线：工单 -> 工序派工 -> 报工 -> 完工 -> 入库。
3. 质量主线：质量计划 -> 检验任务 -> 结果录入 -> 判定 -> 追溯 -> 改进。
4. 设备主线：设备状态采集 -> 点检/保养 -> 故障报警 -> 维修工单 -> OEE分析。
5. 绩效主线：各域数据汇总 -> KPI计算 -> 报表/看板展示。

架构图上把这五条主线标出来，评审专家一眼就能看到数据是怎么组织的。比随便拉几条带箭头的线要可信得多。

4. 技术架构实战：微服务怎么切、数据怎么放、断网怎么办

MOM系统的技术架构，这几年有一个很明显的趋势：从单体MES走向微服务化、平台化。但制造业场景有它的特殊性，不能照搬互联网那套。

4.1 三种建设路线，先看适不适合再谈先进

我接触过的MOM建设路线基本是三条，各有适用场景：

我的建议是：千万别只看产品demo就拍板。把企业目前的工艺复杂度、预期并发量、未来扩展方向、团队维护能力这四个维度列个打分表，拿分数说话。MOM不是买一台家电，上完以后要跟着车间跑五年十年，选型失误的代价非常高昂。

4.2 微服务拆分：按业务域聚合，不按表单切

MOM系统做微服务化，第一个问题就是服务粒度。我看到过最糟糕的案例，把一张检验单据拆成一个微服务，结果部署架构图上有三百多个服务，开发和运维全部被拖垮。

正确的做法是"按业务域聚合"。推荐的服务划分如下：

• 计划中心服务：接收ERP订单、存储排产结果、发布车间计划。
• 执行中心服务：工单管理、工序流转、报工事务。
• 质量中心服务：检验任务、SPC计算、不合格品流程。
• 设备中心服务：点检计划、报修流程、设备状态缓存。
• 物料中心服务：齐套、批次追踪、库存移动记录。
• 主数据服务：物料、BOM、工艺路线、工序、设备台账。
• 集成网关服务：对接SAP、SCADA、WMS等外部系统的统一出口。
• 基础服务：认证授权、权限、消息通知、文件存储、审计日志。

这种拆分的粒度下，每个服务都是一个完整的业务能力单元，团队分工和边界都清晰，不会出现一个改动牵全身的情况。而且服务之间通过接口通讯，落到架构图上就是清晰的"服务中台"层，而不是一堆杂乱无章的小框。

4.3 数据架构：关系库、时序库、缓存各司其职

MOM的数据是典型的多模态混合。我一般把数据分成四类，放不同的存储里：

第一类：业务单据和账务数据，比如工单、检验记录、出入库记录、报工记录。这类数据强调事务一致性，放在关系型数据库里，常见是PostgreSQL或SQL Server。

第二类：高频设备数据，比如PLC点位值、设备状态、产量计数、工艺参数。这类数据写入频次高、带时间戳、分析时按区间查询，放在时序数据库里，比如InfluxDB、TDengine或ClickHouse，按现场点位数和数据保留周期规划存储量。

第三类：实时状态数据，比如当前设备运行/停机状态、当前派工人、当前任务队列。这类数据强调低延迟读写，放Redis缓存，业务模块直接从缓存拿，避免频繁查关系库。

第四类：非结构化文件，比如SOP图纸、质检照片、操作视频、追溯附件。放到对象存储或NAS里，数据库只存路径索引。

很多MOM项目翻车就翻在数据架构上。最常见的问题是把设备点位的秒级数据写进关系库，跑了一个月表和索引就膨胀到不可收拾。我的建议是，数据架构设计阶段就把四类存储的分工定死，写进开发规范里，谁都不能随便越界。

4.4 边缘节点与断网续传：车间现场最容易忽视的环节

MOM和互联网系统的最大区别之一是：车间环境不稳定，网络可能会断。所以技术架构里必须考虑"边缘节点"和"断网缓存"。

生产现场的工控机、智能设备、扫描终端，都应该通过一个边缘网关和核心系统打交道。边缘网关负责设备协议的接入（OPC UA、Modbus TCP、S7等）、数据采集的预处理（过滤、聚合、清洗），以及断网时的本地缓存。我见过实际架构里是这样的：车间网络断开后，边缘网关继续采集设备数据、记录人员报工和扫码数据，暂存在本地的轻型数据库里；网络恢复后，按时间顺序自动补传到MOM中心服务，同时标记数据上传时间，避免因延迟造成统计口径混乱。

这个设计在MOM架构图上一定要体现出来。不画边缘层，评审时懂现场的人第一个问题就来了："车间网络断了，MOM还能用吗？"答案如果是不行，那这套方案在大多数制造企业里都过不了关。

5. 与SAP的集成到底落在哪些模块：PP、MM、QM、PM逐项拆

有朋友专门问"MOM与SAP接口主要是哪个模块"，这个提问很典型。答案是：MOM和SAP之间不存在只挂某个单一模块的情况，而是以PP（生产计划）模块为主干，与MM（物料管理）、QM（质量管理）、PM（设备维护）联动的一组接口矩阵。架构图上集成层的所有连线，应该落在下面这六个方向。

5.1 集成方式怎么选：RFC/BAPI和消息中间件双层配合

技术上，MOM和SAP的集成一般分两条路。

一条是实时接口通道，适合生产订单下发、报工确认这类高时效场景。SAP侧常用BAPI/RFC方式，MOM侧通过SAP .NET Connector、JCo或REST API调用。另一条是批量/异步通道，适合主数据同步、质量结果批次回报这类对实时性要求不高的场景。可以用SAP的IDoc机制，配合SAP PO/PI中间件，或者走MQ/Kafka加定制消费程序。

我强烈建议MOM和SAP之间不要做点对点直连。哪怕企业只上了MOM和SAP两套系统，中间也应该有一个集成中台或者ESB。原因有三个：一是解耦，SAP宕机不能阻塞车间报工，报工数据可以暂存队列；二是可以做协议转换和数据映射，字段长度、编码规则、单位换算都放在中间层处理；三是留审计日志，接口跑了多少数据、哪些失败、失败原因是什么，都能追踪到。

5.2 集成设计最容易被低估的三个坑

第一个坑是数据字典不一致。SAP的物料号可能长达40位，但MOM的字段设计时只给了20位；SAP的计量单位用"PC"，MOM里存的是"件"。这些在纸面方案阶段看不出来，但联调时全是泪。所以集成架构评审时，必须有一份字段映射评审表，逐字段核对长度、类型、单位、为空规则。

第二个坑是报工数据的幂等性问题。车间操作工双击报工按钮，导致同样一条报工请求发了两次，如果SAP侧没有去重机制，库存和工单状态就乱了。集成网关里必须设计请求ID和去重逻辑，这在架构设计阶段要写进集成规范。

第三个坑是压力测试。演示环境里几百条数据跑接口看不出问题，真实车间一天报工上万次，加上SAP批量任务并发，很容易出现线程池溢出或超时。我建议集成联调阶段就准备6万条以上真实量级的数据做压测，别用demo数据糊弄。

6. 画一张能被评审通过的MOM架构图：分层结构、画法和常见翻车点

技术逻辑理清楚了，最后落到"架构图"本身。这正是整个标题的核心落点。

6.1 一张完整的MOM架构图应有哪几层

我推荐的分层方法是五层加一个集成侧边：

从上往下，第一层是展示层，包括PC端网页、车间看板、移动端、工业大屏，解决谁通过什么界面看到什么内容的问题。

第二层是应用层，把七大业务域的模块分列出来，比如计划排程、生产执行、质量管理、设备维护、物料协同、人员管理、绩效分析。

第三层是服务中台层，包括认证授权、主数据管理、消息服务、任务调度、规则引擎、文件服务等公共能力。应用层各模块都调用这一层的公共服务，架构图上这层能明显体现"平台化"思路。

第四层是数据层，包括关系数据库、时序数据库、缓存Redis、对象存储，以及数据汇聚和报表服务的组件。

第五层是边缘与设备接入层，包括边缘网关、协议解析器（OPC UA、Modbus、S7）、断网缓存、设备直连的工控机。

集成侧边区域放SAP、PLM、WMS、SCADA/DCS、LIMS、AGV调度系统等外部系统，用箭头标出数据方向并备注接口协议。架构图最右侧写清楚职责边界和主要集成规范，比如主数据以SAP为准，执行数据以MOM为准。

这套结构画出来，评审专家一眼能看到：系统边界是否清晰、各层职责是否明确、数据流走向是否合理、外部集成是否完整。四类问题全部有答案。

6.2 画图工具和具体操作建议

工具方面说句实在话：

• 如果公司规定文档要交付Visio格式，就用Visio，注意提前定义好图层和配色规范，别让每个人画的颜色都不一致。
• 如果希望团队在线协作、免费又轻量，draw.io（diagrams.net）很好用，网页版和桌面版都能导SVG、PDF。
• 如果要做企业架构标准建模，有ArchiMate语言的工具（如Archi）更适合，算是制造业信息化方案里逼格和实用性兼备的选择。
• 国内在线协同可以用ProcessOn，模板多，导出美观，适合方案快速产出。

画图时几个具体建议：一是每个模块框里写中文名称和英文缩写，便于和外部供应商沟通；二是数据流箭头旁边标注接口类型，比如RFC、REST、Kafka、MQ；三是图层颜色不要超过三种，别把架构图画成彩虹图。

6.3 三个高频翻车点，评审前自己先检查一遍

第一，把所有与制造不直接相关的系统画进来。OA、HR、财务共享这些系统如果在图上，不等于显得全面，反而说明你没有忍住"什么都想画"的冲动。架构图不是组织架构图，画的是系统边界和数据流，信息要素要克制。

第二，数据流向画反或画成"全互通"。有些图把所有系统用一条条箭头全部双向连接，看起来到处都是数据，实际等于什么信息也没有。一张好的架构图，每条箭头都要能讲清楚什么数据从哪来、到哪去、为什么是这个方向。

第三，把业务功能模块和技术组件混在一层。故障排查、微服务框架、数据库集群这些是技术架构层面的东西，业务功能模块是应用层面的东西，混排会让读者非常混乱。两者分开画，一层画"应用视角"，一层画"技术视角"，中间通过服务中台衔接。

6.4 目标架构图和稳态架构图，分开画

这是我自己反复踩坑后沉淀出的实战技巧。MOM项目建设周期通常跨两三年，如果把三年后的目标架构和当前第一阶段的实施范围画在同一张图里，评审会上一定吵得不可开交。正确的做法是准备两版架构图：

目标架构图展示完整蓝图——七域齐全、微服务全部落位、集成侧全部打通；稳态架构图标注当前阶段实施范围——第一年只做执行域加质量和接口，其他域用灰色标注"下一阶段建设"。评审时先讲清楚这是目标还是现状，再讨论范围，会议效率会高很多。

我自己实操下来的体会是，MOM架构图的真正价值不在"画得好看"，而在"画完之后大家对边界、模块、数据流有了统一认知"。它是一张沟通地图，用来对齐信息化负责人、车间主管、IT运维、供应商四方对系统的理解。所以别急着追求模板化的精美，先把逻辑写对。边界清楚了，流程理清了，数据流标明了，这张架构图就能在项目里真正发挥它的枢纽作用。