骆金松 | MES能被拆掉吗?

数字化转型,成为企业的必经之路。而对于传统MES的看法,则出现了分歧。有些观点认为,按人、机、料、法、安、环、测生产要素进行拆分,每个生产要素都提供一些单点应用或融入到已有的应用,借助集成平台、容器化、工作流引擎等将他们互相集成起来。从这个角度看过去,一种“拆掉MES”的看法正在浮现,在微服务的进攻掩护下,MES似乎在劫难逃。

骆金松 | MES能被拆掉吗?

图1  拆掉MES

微服务强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用,这些小应用之间通过服务完成交互和集成。微服务在支撑“拆掉MES”上是不谋而合的。

微服务有很多好处,例如模块化、低耦合等,但是拆解并不容易。当使用微服务对MES/MOM进行拆解的时候,就会进入泥泞的细节。MES/MOM不同业务之间存在复杂的协同和交互,比预期的更具挑战性。对于MES/MOM来说,很难找到合适的划分方法,能够同时很好实现服务的独立部署、以及服务之间的低耦合。

创建微服务看起来不错。但企业级应用,要使用微服务架构必须谨慎,它可能带向一条错误的道路上。笔者从事MES/MOM相关的软件规划和架构设计十余年,经历了产品多次重构,下面是笔者的一些思考。

生产是制造的核心

生产环节从来就是各种信息和各种业务的汇集地,工厂几乎其他所有的业务环节都是为生产产品服务的,这一点本质上决定了核心是支撑生产的MES系统与其他业务板块存在复杂的协作。如下图,从产品生命周期维度、价值链维度、信息化层次等维度来看,生产都是信息和业务汇聚的核心。

骆金松 | MES能被拆掉吗?

图2  生产是各信息和业务的汇聚点

生产是集大成者,是制造的核心,是实现产品价值增值的过程。计划排程、仓储物流、生产执行、质量控制、资源维护等业务环节在制造过程中各自发挥着作用,为生产提供支撑,虽然各部分有一定的独立性,但各业务之间也存在紧密的协作。

骆金松 | MES能被拆掉吗?

图3  若干核心业务领域的协同

MES/MOM业务之间紧密协作的例子非常之多,如果将MES/MOM拆分为生产排程、生产执行、质量控制、资源维护、仓库管理、物流执行几个微服务,如下图,画出了这些微服务之间比较典型的调用关系。事实上,微服务可能需要拆分为更小的粒度,那么这些微服务之间的调用关系会更复杂。

骆金松 | MES能被拆掉吗?

图4  MES/MOM微服务之间的依赖关系举例

例如计划排程驱动生产执行,排程和调度依赖于众多的紧急插单、资源能力、物料齐套、生产进度等实时状态。这需要很多的前置状态和平行状态的情况。设备、工具、人员、物料几乎参与到所有的环节,生产、检验、仓储、物流、维护业务,而微服务化意味着重复存储、数据一致性和完整性风险。

微服务的主要目标就是加强服务的内聚性,减少服务之间的耦合。然而,服务之间依赖越强,服务隔离也就越困难,因此也就越难单独进行测试和部署。根据上面的分析,上图中的每一个微服务几乎与其他所有的微服务都存在双向的依赖。这决定了微服务没法独立部署、无法实现高内聚/低耦合、无法实现单向依赖等微服务所预期的好处。如果必须将这些微服务组合部署,那实际上是变相的单体应用,还是会引起很多的冲突。

冲突和困惑接踵而来。

职能与流程的冲突

生产管理部、生产车间、采购部、品管部、设备管理部等都是比较典型的工厂组织架构,它是按照组职能划分部门。这种在工业化时代“职能分工制”理论基础上形成的“职能驱动型”组织,已很难适应现代管理的需要。企业中按组织职能部门实施上线的信息系统比比皆是,已经形成了各种信息孤岛。

MES/MOM的一个核心价值就是帮助建立流程驱动型组织,实现跨职能横向的高效协作。按生产要素“人机料法环测”的拆掉MES/MOM的方法,很大概率会成为新型架构技术下的新的信息孤岛。这种方法基本与按组织职能拆分应用的方法基本一致,同样容易导致数据烟囱、信息孤岛和碎片化,造成横向沟通和协同的困难。

边界和集成的困扰

首先,企业信息系统的建设,集成从来都是成本比较高的,对于MES系统的实施,与MES相关系统的集成所占的成本通常高达20%以上。如果将MES进一步拆分为一系列微服务,而且这些应用还是不同厂家提供的,各微服务的API缺少统一的标准,集成这些微服务的难度将进一步增加,必将付出大量额外的成本。

最麻烦的是,单点应用之间的边界也不是绝对清晰的,存在复杂的重叠和交叉。究竟是什么构成一个单一的微服务,人们对此存在很多困惑。如果要将MES/MOM拆分为微服务,100个团队必定有100种完全不同的拆分方法,网络上关于微服务拆分方法的讨论随处可见。

例如仓库管理系统WM与物流执行系统LE通常作为MOM的一个模块,他们就存在交叉重叠。做WM的,通常会提供库内管理以及少量物料配送功能;而LE也会提供物料配送模块,而且同时还提供在制品物流、委外物流、直供物流等仓库以外的物流。由于二者使用相同的基础数据,例如物料、批次、容器、载具等,那么公用的部分,是否应该拆分为独立的微服务?

将这些零散的不同厂商提供的单点应用/微服务集成起来是个性化的和高难度的。首先,不同单点应用的差异和不同的组合,每个客户都是不一样的,实现这样的集成都是高度个性化的,能否成功依赖于强有力的集成服务商。而且另一决定因素,很大程度取决于各个应用厂商的配合程度。

因为不同应用之间的边界不够清晰,要进行这样的集成,有时候需要某些供应商做某些让步和修改,这经常会触及到某些供应商的利益,大多数问题都通常可以通过商务谈判和金钱解决。但是如果有一两家厂商拒绝配合,或者配合程度很低,可能导致整个项目的失败。

供应商之间普遍存在竞争,需要集成的各个应用提供商可能难以合作,这使得客户可能成为牺牲品。某工厂的一个MES项目,供应商A之前实施了WMS系统,但未选择其MES系统;而当供应商B的MES系统与WMS对接,要实现物料精准配送时,出现了巨大的信息裂缝。虽经过多轮艰难谈判,即使客户方也去跟A方斡旋,仍然困难重重。最终MES的成交价,仍超出5倍的预估成本。这是前期规划不足,给后期MES实施所留下的坑。

整体解决方案尚且如此,如果将MES进一步拆分为微服务,如果这些微服务由不同供应商提供,而这些供应商通常在许多方面存在相关产品的竞争。这种供应商之间非技术原因背后的明争暗斗,这对于客户来说简直是灾难。

内部复杂性的暴露

计划排程、生产执行、质量检验、仓储管理、物流执行、设备维护等这些服务没办法单独部署和运行,许多模块之间存在双向的集成和协同,这与微服务之间尽量解耦、单向依赖是有冲突的。

MES/MOM系统如果没有拆分为微服务,那么模块间集成和测试是系统内部的事情,但是一旦拆分为多个微服务,那么这种集成就变成外部第三方的事情,或者必须要显性的事情。如果这些微服务由不同厂商提供,无疑将更多的内部复杂性暴露了出来。

要做到完全微服务模块独立,那么数据库也拆分开了,开发模式和效率上就会带来巨大的变化。数据库间还不能随便相互连接和访问,只有这样微服务模块才能做到独立部署和管理。那么跨表查询无法实现了,只能通过接口,这不但影响了性能,也导致了复杂性,数据分析也变得困难了。

骆金松 | MES能被拆掉吗?

图5  复杂的微服务依赖关系

当服务的数量增加,业务之间的协作变得频繁和紧密,服务调用关系越来越错综复杂。如果维护一个这样的架构,你每天的宝贵时间可能都浪费在了维护服务和接口的调用关系上,浪费在不同供应商的争吵之中,系统变得越来越来越难以运维,为此失去了钻研更有价值的业务的精力。

例如,对于MES所拆分出来的几乎所有微服务,都需要访问到物料、设备、工装、工具、人员、批次、产品序列号、容器等主数据,如果将每个服务的数据库拆分,只有个别服务数据库保存这些主数据,其他服务将需通过集成接口访问这些数据,导致性能的下降。如果每个数据库都保存这些数据,意味着大量的重复存储,存在完整性和不一致的风险。

某供应商使用微服务架构开发ERP系统,但是其数据库是所有微服务共享数的,这破坏了微服务的自治性,而高内聚、低耦合、服务自治正是微服务的优势所在。首先,多个微服务共享数据库,在数据库层的耦合让不确定性变大,一个服务对数据库结构的变更很有可能影响其他服务。其次,数据库的故障导致多个服务同时故障,无法做到故障隔离。

对客户的要求太高

微服务的运维要求比较高,如果有专家这可能不是问题。的确通过有效的自动化、监控和编排微服务,这一切都是可能的,但挑战是找到能够有效使用这些技术的人。包括容器管理、容器编排与配置管理、服务监控、故障恢复与业务调度、快速扩展、资源效率管理这些技能需求非常高,相关技能的人可能很难找到。如果你没有找到合适的人,你可能掉到技术的泥潭里。

另外,顶层架构分解和接口设计能力不在单个微服务模块开发商手里,客户通常需要具有较强IT规划和架构设计能力,才可能一开始就划分好微服务模块并且设计好微服务模块间的接口,而且需要持续驱动供应商提供符合客户规划设计要求的微服务应用的能力,但是制造业客户通常不是IT行业的专家,而且你可能没法总是具备对供应商这样的驱动力。

使用微服务架构意味着你无法使用市场上成熟的MES/MOM系统,而MES/MOM系统的复杂性超出了绝大多数客户的驾驭能力。笔者从事工业软件研发超过20年,MES/MOM平台不是一种常规的企业管理软件,作为一种工业软件,需要长时间沉淀行业Know how,优秀的MES/MOM系统都经过了长期的迭代甚至多次重构。佰思杰MES/MOM涉及的数据库表超过3600张,拆分出的微服务可能超过30个。

大多数团队及其管理层低估了微服务开发和管理的复杂性,例如各个微服务的资源分配和优化反而会成为负担。基于集群架构,应用共用一个集群资源,资源可以在所有模块间共享使用。然而在微服务架构下,存储和计算资源更加碎片化,性能瓶颈可能在各微服务间漂移,性能的监控、资源分配和优化,微服务需要精细化的运营,对资源进行“削峰填谷”反而会成为负担。

在企业IT建设中,如果连粗粒度的业务系统以及它们之间的集成都管理不好,那么更没有能力管理细粒度的微服务模块。

与国际标准相背

谈起MES/MOM,就不得不提ISA-95标准、IEC/ISO62264国际标准。迄今为止,这两个标准仍然是定义MES/MOM的最好标准。ISA-95定义了MOM(Manufacturing Operations Management,制造运营管理)的概念,该标准正是在软件厂商各自为战,概念和术语不一致、集成和协同问题严重这种背景下诞生的。ISA-95标准、IEC/ISO62264国际标准的一个重要目标,就是要统一概念和术语,统一基础数据模型,实现生产执行(Production)、质量控制(Quality)、物流执行(Inventory)、资源维护(Maintenance)等制造业务领域之间的紧密协同。显然“拆掉MES”与这个理念背道而驰。

骆金松 | MES能被拆掉吗?

图6  MOM在信息化中的位置

从术语和概念角度分析,国际标准的第一部分定义了统一的术语和概念,基于标准实现的MES/MOM系统自然使得工厂的不同业务板块使用统一的语言进行交流。如果拆掉MES,这种术语和概念统一性就难以保证了,不同的厂商总会创造出不同的术语来,就像中国不同地方有不同的方言,即使单点应用之间只存在少量的差异,也足以让人感到困惑。

从数据模型角度分析来看,国际标准第二、四部分定义了对象数据模型,设备模型、人员模型、物料模型、计划模型、产品定义、绩效模型、能力模型等,这些公共模型广泛应用于各个MES/MOM的各个业务模块。基于标准实现的MES/MOM系统可以确保单一的数据源,确保信息的共享和相互链接关系。例如设备不仅用于设备维护,生产需要下发工艺参数到设备、驱动设备生产、监控设备运行状态,质量检验需要使用检验设备,物流过程需要使用AGV等物流设备,维护过程中也会使用维修设备进行维修。拆掉MES会导致这些数据分散在许多单点应用之中,存在大量的冗余存储,很容易形成信息孤岛,数据集无疑会增加复杂度和成本,会使得信息经常需要进行分发、同步,数据存在一定的延迟,导致数据一致性和完整性风险。

从业务流程的协同角度,每个业务板块之间的数据流和协同关系,至关重要。

骆金松 | MES能被拆掉吗?

图7  国际标准关于MOM边界划分及数据流分析

国际标准的第三部分定义了MOM的活动模型,对生产、质量、物流、维护等核心业务进行了抽象,定义了:定义管理、资源管理、详细调度、分派管理、执行管理、数据采集、分析管理、溯源管理等活动。通用模型经过实例化,可适用于生产、维护、质量等业务过程,标准同时也定义了业务之间的协同关系。下图展示了PLM、ERP、MOM、SCADA等系统集成关系,也体现了设计与生产、计划与生产、生产与质量、生产与采购、仓储与生产、生产与设备管理等跨职能部门的协同流程。

骆金松 | MES能被拆掉吗?

图8  MOM平台相关的核心流程

如果将MES/MOM拆掉,本来MES/MOM内部复杂性就暴露给了外部。本来统一的概念和术语可能变得不统一,单一的数据源的数据变得分散,存在数据一致性和完整性风险,不同单点应用之间的业务协同本来是MES/MOM的内部实现,现在也变成外部的问题。

微服务不是唯一方案

微服务技术虽然快速发展,但它适合的领域是有限的。对于MES/MOM来说,应用拆分和微服务不带来显著的价值,相反其带来的弊端却很明显。可以说,微服务技术,不适合应用于企业信息系统。

互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力,而MES/MOM并没有如此巨大的海量数据和并发需求,并不存在太多的大量级的突发流量,通过代码优化、数据库调优和集群部署完全可以达到要求。

模块化有许多种方式,微服务化只是其中的一种方式。如果MES/MOM能够很好的模块化,清晰定义各个模块的边界,即使是单体应用也可以实现不同的部分独立开发,也可以实现每个模块的高内聚和低耦合。

生产相关的业务之间的本来就是紧密协作的,为啥子非要解耦呢?微服务的“微”,并不是一定要将紧密相关的业务拆分。当服务的粒度太小的时候就会遇到沙粒陷阱。微服务的微并不意味着服务越小越好。该拆的拆,不该拆的就不应该拆,与应用的大小无关。

MES/MOM产品对于其中有一定独立性的部分,与其他部分低耦合的部分也可以拆分成独立的应用或服务,甚至是集成第三方的应用和服务。

MES/MOM系统的业务复杂,各种业务耦合度、后台业务逻辑复杂度远高于那些互联网应用。微服务单独伸缩所带来的好处价值不大,而且制造企业基本不存在类似互联网应用的单个微服务的突发流量。相反,频繁穿透多层服务的调用导致的性能下降将严重影响用户体验,而且使得性能的优化变得非常困难。

进化的MES可以有机的拆分

当然,有远见的MES厂商必须注重产品的标准化、实现分层扩展、打造合作伙伴生态,否则将很难做大规模。对于MES和MOM来说,下图是建议的分层的扩展方式。

对于MES和MOM来说,更有价值的不是按组织职能、或生产要素进行拆分,而是进行分层,下图是建议建议的分层方式。

骆金松 | MES能被拆掉吗?

图9  MES/MOM更好的拆分方式是分层

1.技术平台可以解决架构和技术问题,屏蔽技术细节和复杂性,并提供低代码开发的相关能力,提高整个系统的扩展性和灵活性。

2.MES/MOM产品平台解决提供覆盖制造运营全业务流程的共性模块,从而最大限度实现重用,满足共性需求,满足跨组织的协同要求,封装内部的复杂性。

3.行业扩展满足特定行业的扩展,例如提供各个行业层的扩展,实现对细分领域的深耕,从而更好为细分领域客户创造价值。

4.客户扩展是为单个客户而开发的,满足单个客户的共性需求。

其中,第1、2层应该由业界有实力的公司研发,需要很大的投入。第3、4层可以由具有领域Know How和商业资源的集成服务商、实施服务商承担,这样可以很好分工,发挥各自优势,建立合伙伙伴生态。

选择成熟的平台

IT本身就是互联网企业核心竞争力,互联网企业的IT系统或运营的APP就是其核心竞争力,但是IT通常不是制造企业的核心竞争力。业务驱动而非技术驱动,IT系统的建设和架构选型要匹配业务目标,选择当前最合适的架构方案,包括业务价值实现和IT投入产出最大化。

制造运营的业务复杂度是非常高,选择成熟的MES/MOM产品平台,可以大幅度降低实施MES/MOM项目的风险,实现合适成本、更高质量、更快地交付。一般来说,MOM平台的成熟度能力可以参考如下,根据企业的具体情况适当进行增补和裁剪,成熟的MES/MOM产品平台主要体现在全制造链覆盖、跨职能部门协同、中央治理等多个方面:

骆金松 | MES能被拆掉吗?

图10  MOM平台成熟度能力

以精益为本的智能管控,可以很好地解释一个成熟的MES/MOM平台。

精益生产的理念是减少浪费,消除制造多余的、不必要的消耗。这就需要通过IT系统掌握具体的、实时的生产信息,支撑对生产过程准确分析。精益管理的水平依赖于数据管理水平,MOM平台可以为精益管理提供相关的数据,是支撑实现精益生产理念最重要的信息平台。

骆金松 | MES能被拆掉吗?

图11  信息化对精益的支撑

许多企业更多的精益改善是在单点级,现在需要提高精益改善的层次,通过避免数据孤岛,更大范围内的协同,实现从单点到车间、再进一步到工厂、甚至供应链的优化。

骆金松 | MES能被拆掉吗?

图12  更高层次的精益改善

精益生产既是智能制造的基础,也是智能制造的目标,让精益生产贯穿制造整个生命周期。MOM平台是支撑精益和智能制造的重要平台,智能制造在MOM平台中的技术手段主要包括:拉动式供应链规划、有限产能排程、智能物流管控、制造过程的防呆防错、预防性质量控制、工艺参数优化、预防性设备维护、管理的自动化、自适应与自主决策,人机协同与决策等。

基于MOM平台获取准确、实时的采购、生产、质量、物流、设备、安全、环境、人员等数据,让数据和流程驱动业务和管理,进行监控、预测、控制和决策优化,实现精益成长,依靠跨业务的数据融合分析实现增殖。

传统模式下缺少量化绩效体系,问题不容易暴露,失去了改善的机会。而且以不信任的方式去监管、控制给干部或员工很不好的感觉。MOM平台变“主观的监控”为“客观的监控”,变“人的监管”为“数据的监管”,这些问题得以解决。

精益成长是企业数据驱动的核心目标。MOM平台不能仅仅利用数据为日常的生产运作提供支持,更重要的是,利用MOM平台的数据,为不同的业务部门、以及更高层的管理对计划、生产、物流、质量,以及他们之间的协作等进行持续优化,实现精益成长。

当然,安全和自主可控也是非常重要。中兴事件、华为事件,无不昭示国人,核心技术问题不解决,不管是在硬件还是软件领域,中国的制造和持续发展就会始终受制于人。知识产权自主可控对于集团性企业,尤其是国防军工企业是至关重要的,甚至是生死攸关的。

骆金松 | MES能被拆掉吗?

图13  MOM平台安全自主可控的要求

在国家强力政策推动及需求快速提升的双重作用下,包括佰思杰公司在内的国产MOM平台正在快速完善,与国外MOM平台的差距越来越小。

总结

制造运营平台MOM是制造系统的大脑,要实现多生产资源的计划排程和动态调度,确保生产资源的优化和高效利用。必须实现MOM中信息流和实物流的一致,并通过工业智能、自主控制实现对工厂的动态调度和优化,从而实现大脑的作用。应该考虑建设统一的MOM平台,兼顾局部优化和全局优化,避免信息系统碎片化,避免多脑指挥。而对于微服务的处理,则需要谨慎应对。

当投资能力有限时,要避免缺少总体规划,各自为战的局面。集成这些单点应用的难度很大,它会使得后续升级的成本和时间的代价,都非常高。由于投资能力的限制,尽量可以选择成熟一体化可扩展的平台,避免过多的定制开发,优先选择部分重要的模块,对核心的业务进行支撑,未来再考虑增加模块。就这一点而言,微服务并不具备自由伸缩的能力。而成熟MES/MOM的模块化能力,则是有力的支撑。

本文来源知识自动化。