在制造业的工业2.0中应用MOM系统

介绍

什么是制造运营管理 (MOM) 系统和 IT 架构的最佳实践？

行业专家对制造类型和供应网络有何建议？

管理思维和企业文化是否因不断变化的全球市场而过时？

MOM 技术是否过于昂贵，IT 架构是否无法快速适应市场变化？

长期以来，制造企业一直不愿为运营工作流程采用新思维。在工厂设备不断发展的同时，支持智能设备的工作流程仍然主要基于纸质交易来执行生产订单，仿佛在说：“我们的方法已经运行了多年，为什么现在要改变它们？” 有了这种想法，智能技术的世界已经向前发展，并将制造公司甩在了后面。全球很少有制造公司能跟上智能操作方法的最新发展，只有真正进步的公司才采用这些智能制造发展，通常是通过 10 到 15 年的试错过程。

正如 2008 年 Aberdeen Group 和 2010 年 MOM 研究所示，这些 20% 的“同类最佳”进步公司通过更快、更轻松地适应市场变化而胜过竞争对手。它们不受难以更改的不灵活的遗留系统或阻止应用程序更改和更快推出新产品的众多“点对点”接口的限制。他们的 MOM 系统的灵活性使他们能够产生更高的整体设备效率 (OEE) 并增加完美订单，从而降低了工厂运营和供应链现金到现金的成本。他们灵活的 MOM 系统使他们能够实时响应制造指标，并通过更好的沟通来实际改进运营，从而减少浪费并提高效率。这些公司的制造软件应用程序的总体拥有成本 (TCO) 通常也较低，从而进一步降低了运营成本并提高了竞争优势。

不幸的是，大多数制造公司正处于一种真正令人悲哀的境地。非进步公司的制造技术专家，即组织中负责实施和维护制造执行系统 (MES)、MOM 和自动化等制造技术的人员，显然通过专注于基于部门的单点解决方案而让他们的公司失望。然而，这不仅仅是制造技术人员的错。制造技术供应商以及没有远见卓识的老式终端用户管理，必须首当其冲。

大多数制造系统供应商宁愿将他们的研究资金花在改进他们当前（通常是过时的）的架构和为过时的软件添加新功能上，而不是开发新的、渐进的架构。将集成技术作为应用程序的一部分，而不是将其从应用程序中抽象出来并将其作为 Web 服务提供，这也是一个更好的商业案例。如果集成可以作为服务提供，那么客户为什么要在扩展时“拆除并替换”或继续支持已安装的应用程序？即使多年前 OLE for Process Control (OPC) 出现，这种想法在少数分布式控制系统 (DCS) 供应商和自动化协会中仍然盛行。只有在进步的最终用户开始请求（甚至坚持）OPC 连接性之后，OPC 才成为自动化级别的事实上的标准。

根据Aberdeen 的研究，80% 以上的最终用户制造技术人员不知道什么是更好的；他们接受技术供应商告诉他们的有关服务支持的任何内容并且不再考虑它，因为他们经常被供应商软件所谓的“新的和改进的”功能所蒙蔽。

那么，最终用户制造技术人员和制造软件供应商（MES/MOM 供应商）需要改变什么思维？

这些小组需要接触由 Gartner Group 开发的 Manufacturing 2.0 (Mfg. 2.0) 的思想和概念，然后得到 MESA 和 ISA-95 Best Practices 等行业组织的案例研究和最佳实践研究的支持工作小组。一旦制造公司开始要求基于 Mfg. 2.0 架构的灵活 MOM 系统，供应商将不得不效仿（如上所述，即使是 DCS 供应商最终也会接受 OPC 连接，即使不情愿）。

本文探讨了上述“同类最佳”进步公司必须克服的四个主要观念和障碍，如此才能使其 MOM 系统架构被企业广泛接受为公司战略。

本文讨论了四种障碍或看法，以证明最终用户制造技术人员和供应商的思维不是主动进取的，而是被动的。这些是：

1. 为什么是 MOM 而不是 MES？

2. 为什么在制造业中使用面向服务的架构 (SOA)？

3. 为什么选择将MDM用于制造业？

4. EMI 的最佳定位是针对商业智能 (BI) 还是与商业智能 (BI) 搭配？

对于这些概念中的每一个，它们的含义和适合的位置都将被单独探索，以使制造技术人员了解这些概念以及接受并朝着这一愿景努力。本文最后评估了多年来使用的不同集成方法，并将它们与当前提出的“最佳实践”和 Mfg. 2.0 进行了比较。

为什么是MOM而不是MES？

新的思维早已经超越了老旧的 MES，进入了制造运营管理或 MOM（包括 MES）领域。

制造运营管理本身并不是什么新鲜事物；它的存在时间比 MES 还长。新的是 MESA 和 ISA 采用了 ISA-95 标准中的 MOM 定义，而不是“旧”的 MES 概念。

是什么让 ISA-95 MOM 与众不同？ISA-95 MOM 包括许多运营活动和功能，这些活动和功能传统上不是 MES 的一部分，因为它由 AMR Research（Gartner Group）定义。ISA-95 MOM 的覆盖范围也比 MESA 在 1990 年代开发的传统 11个域要广泛得多。不能使用这些过时的 AMR 或 MESA 模型来指导和设计系统。另外，MES这个词，虽然年代久远，但一直让人迷惑不解。如果请 10 个人定义他们理解中的MES，请准备好获得 10个不同的定义的情况。另一方面，MOM 更容易定义，因为它使用 ISA-95 第 3 部分 (MOM) 标准中的框架。

APICS（运营管理协会，前身为美国生产和库存控制协会）将运营管理定义为：

1. 将投入转化为成品和服务的活动的计划、调度和控制。

2. 重点研究领域。通过研究设计工程、工业工程、管理信息系统、质量管理、生产管理、库存管理、会计和其他影响功能的概念，对制造或服务组织进行有效的计划、调度、使用和控制组织的运作。

3. 制造执行系统是参与车间控制的程序和系统，它使用： (1) 用于直接和监督控制制造设备的程序逻辑控制器和过程控制计算机；(2) 收集历史性能信息，然后生成报告的过程信息系统， (3) 图形显示；(4) 警报/告警/触发器，通知操作人员工厂当前和最近发生的情况。

根据 ISA-95 第 3 部分的定义，还收集质量控制信息，其中实验室信息管理系统：（LIMS）或质量管理系统（QMS）可能是此配置的一部分，以将工作流程和转换流程条件与质量数据联系起来. 从而可以确定、分析因果关系并主动将其编程到系统中。这就是制造智能。有时，质量数据会影响用于满足产品规格的控制参数，无论是动态的还是离线的。MOM 系统可以是支持此功能的任何系统。

ISA-95 MOM 的标准定义为指定系统的功能、任务和数据交换提供了所需的框架。ISA-95 第 3 部分将 MOM 定义为“制造设施第 3 级内协调制造中的人员、设备和材料的活动、功能和交流。” 它包括生产运营管理、维护运营管理、质量运营和库存运营管理（见图 1-1，第三层）。

尽管自 2000 年以来它一直在 ISA-95 中，但只有中等数量的制造技术人员和数量有限的供应商已将 MOM 接受到他们的解决方案中。积极构建和支持 ISA-95 MOM 的工作的更少，而坚持使用过时的术语 MES的更多。

在一般小组讨论中对术语“ISA-95 MOM 系统”的思考和使用向听众表明，技术专家或供应商可能实际上已经阅读、看到或听说过 ISA-95 标准。

图 1-1：制造公司的 ISA-95 功能层次模型

为什么在制造业中使用面向服务的架构 (SOA)？

制造公司落后的下一个证据是他们缺乏基于标准的集成愿景。控制MES/MOM级别的技术标准化与基于集成的愿景不同。由于使用点对点接口和缺乏协调的信息模型，这种缺乏会导致大数据完整性问题。“复刻和替换”计划不是基于标准的集成愿景。对于大多数公司来说，这些标准化举措是成本过高且不切实际的。

什么是基于标准的集成愿景？

首先，这是一个愿景，其中数据传输和传输功能从应用程序本身抽象到基于标准的服务层，作为独立于不断变化的业务流程运行的制造信息模型。

那些参与过企业集成项目的人认为这是面向服务的体系结构（SOA），但SOA通常是制造业中的一个脏话- 不是因为这个概念不合理，而是因为制造技术专家及其供应商对SOA的了解不够，无法接受它，并与希望在制造业中应用SOA技术的企业架构师合作。毕竟，基于项目思维，点对点集成比长期实施基于 SOA 的集成要快得多、容易得多。制造技术人员宁愿保护自己的集成愿景，将企业架构师排除在外，也不愿尝试理解和应用该技术。制造工程和企业 IT 之间的这种文化差距是一个长期存在的战场。

大多数制造技术人员认为，将SOA概念应用于制造业是令人发指的，而且永远不会奏效。大多数与企业架构师交谈过的人都意识到，企业架构师只是不了解制造环境的复杂性。因此，制造技术人员长期以来一直对任何 IT 架构讨论持怀疑态度，例如作为 SOA 基础的 Web 服务。但持怀疑态度的制造技术人员必须根据 Gartner 和 MESA 了解 SOA 的实际作用，然后思考它如何应用于制造业，特别是MOM。制造系统技术人员和企业 IT 之间分歧的最终结果是，基于独立系统的独立数据模型集的数据完整性普遍较差。因此，当一个典型的工业工厂需要 15 到 20 个系统来处理一个生产订单时，数据损坏是常态，因为数据被汇总到报告、调度、计划和供应链活动中。SOA允许从独立的、自描述的和可互换的代码模块（称为"服务"）创建复合业务应用程序。这些服务可在服务总线上使用，在服务总线上，它们使用流程编排排列到业务流程或复合应用程序中。当SOA被用作集成策略时，它带来了一个自描述的原子业务服务目录，这些服务一起用于创建业务流程（包括制造操作流程）。

对于 SOA，我的想法是业务和市场的需求驱动IT系统，而不是IT系统决定业务的运行方式。这带来了灵活性，这是 MOM 系统的主要要求之一，因为制造要求经常变化。

许多公司（包括制造公司）已经实施了企业服务总线（ESB），专门用于简化集成。这些 ESB 架构尚未深入到制造本身，这是有充分理由的。企业层（第4层）和制造运营层（第三层）不相同，工作不相同，并且具有完全不同的优先级、数据类型、事务类型以及业务与操作流程。只有一小部分制造过程数据可以上升到企业级，然后通常仅以汇总形式进行。但是，大量制造过程数据在工厂的第1层到第3层内共享，以处理 15 到 20 个系统中的单个生产订单。

由此我们可以得出：“对于 MOM，由于事务数量大、参数数据负载高以及操作应用程序的近乎实时的要求，因此需要单独的制造服务总线（MSB）。MSB可以缩小到一个工厂或工厂的一个区域，或者跨多个生产设施，具体取决于工厂应用程序支持的操作工作流程的事务/数据负载和响应要求。”

因此，我们需要为工作流程定义制造业SOA（GSOAm），它看起来与支持企业业务流程的SOA非常不同。我们还将在我们的制造企业架构中拥有一个 ESB 和一个 MSB。问题是，我们如何将这个概念卖给企业架构师和制造技术人员？他们每个人都有一个特定的世界视，如图 1-2：企业 SOA — 正在进行的工作。

SOA 显示为功能层，如图 1-2 所示。底层由现有或旧版应用程序组成，这些应用程序为如何使用业务数据奠定了基础。这些是"任务关键型"应用程序，可保持业务的日常运行。下一层提供集成。在 SOA 中，集成层是使用企业服务总线（ESB）实现的。ESB 层提供安全性、传输、中介和事件服务。它还可以提供业务指标和工作流或业务流程引擎。

业务服务（中间）层是服务的抽象层，用于基础IT系统。这些服务是 SOA 中的工作。它们使用包装业务应用程序的 Web 服务描述语言（WSDL）进行表示。

业务流程层由通过组合业务服务层中的服务以生成复合应用程序而创建的业务流程组成。复合应用程序是在 SOA 中执行应用程序开发的新方法（后面的将更详细地讨论）。

图 1-2：企业 SOA-A 正在进行的工作“

门户/仪表板层由数据聚合和可视化组成。图 1-2 的问题在于，制造运营（或 MOM）系统只是需要与其他企业系统集成的众多其他系统之一。然而，对于大多数公司而言，这些其他（非 MOM）系统已经整合并在企业级别运行，其中 MOM 系统是不同的并在工厂或站点级别运行。MOM 系统通常不是每个站点的单个系统，而是可能由多个系统组成，这些系统都基于可用资源执行实时工作流程。这使事情变得复杂，并且是尚未使用基于 ESB 的体系结构集成第3层系统的最大原因之一。

然而，希望是有的，因为有一些案例研究表明，有些公司已经在本文提出的第 3 层内应用了 SOAm。这些案例研究来自 Gartner、ARC、Aberdeen和MESA。

Gartner 和 MESA 在白皮书 #27 "SOA in Manufacturing Guidebook"中提出的 SOAm 体系结构如图 1-3 所示：面向制造业的 SOA。（SOAm）一些关键的实时差异。如图1-3所示，架构与该架构密切相关。企业体系结构如图 1-2 所示。

在图 1-3 中，MOM 系统被描述为组件，而企业应用程序仅被描述为需要连接到制造服务总线的多个系统之一。图 1-3 强调，如上所述，由于大量事务、高参数数据负载和操作应用程序的近实时要求，因此需要单独的 MSB。根据工厂应用程序支持的操作工作流的事务/数据负载和响应要求，MSB 可以缩小到一个工厂或一个工厂区域，或者扩展到多个生产设施。Mfg. 2.0 的一个关键方面是，解释了制造主数据管理 (mMDM) 不同于企业业务流程ESB 上的 MDM。Mfg MDM 为一组不同的制造运营管理应用程序提供服务，例如调度、路线执行以及警报和事件应用程序，它们比代表企业计划的 MDM 具有更精细的对象、属性和生产规则集，（主）调度和物流。

图 1-3：制造用 SOA (SOAm)：一些关键的实时差异

因此，该架构是相似的，但用于不同的目的。考虑到这一观点，制造技术人员有一个很好的对立面，可以与企业IT架构师讨论非特征化工作流程的实时架构，并向他们传达企业视图（图1-2）和制造视图（图1-3）之间的区别。基于优化所需的高度变化，制造技术人员现在可以证明需要将MSB与ESB隔离（即使使用相同的技术）。

那么，在一家全球企业中，合适的 MSB 数量是多少？每个制造工厂或园区一个？

根据需要支持事务流量？对此我们并不清楚，但每个地理站点至少有一个 MSB 链接到 ESB 是有意义的。如果没有将MSB作为通用基础架构元素的架构策略和路线图，并且不会使任何单个软件项目承担安装MSB本身的负担，则很难为每个站点实现总线。这种缺乏长期的制造架构愿景可能是 SOA 作为应用程序概念尚未被广泛接受的另一个原因。

为什么选择将MDM 用于制造业？

很少有制造技术人员听说过主数据管理 (MDM)，也很少有人了解 MDM 的实际含义。这进一步证明了 80% 以上的最终用户的保守思想。企业解决方案长期以来一直依赖于 MDM 系统来确保不同企业级解决方案之间的命名一致性和数据转换。制造技术人员甚至没有考虑过这一点，正如制造系统之间点对点接口的激增所看到的那样。

在图 1-2 和 1-3 中应该注意的一件事是每个体系结构中的不同 MDM 组件。MDM 是用于关联不同应用程序之间的数据的工具。

那么，什么是主数据，为什么它很重要？

“主数据管理 (MDM) 包括一组流程和工具，这些流程和工具一致地定义和管理组织的无事务数据实体（可能包括参考数据）。MDM 的目标是提供用于收集、聚合、匹配、整合、保证质量在整个组织中持久保存和分发此类数据的流程，以确保在持续维护和应用程序使用这些信息时的一致性。”

MDM 解决方案中常见的流程包括源标识、数据收集、数据转换、规范化、规则管理、错误检测和纠正、数据整合、数据存储、数据分发和数据治理。

为什么需要区分企业 MDM 和制造 MDM (mMDM)？据 MESA 的说法，在绝大多数情况下，工程物料清单（BOM），路线或企业资源规划（ERP）或配方/产品生命周期管理（PLM）系统的一般配方缺乏必要的详细程度：

通过共享的商店资源运行详细的路线。
设置批次系统执行的处理逻辑。
调整批量大小以匹配本地设备资产并为这些资产提供有限的容量调度。
设置详细的机器设置。

异构遗留系统、对受控 MOM 系统的信任/不信任、数据所有权问题和数据不一致使这个问题更加复杂。缺乏强大的通用数据架构会促进不受监管的数据定义激增、点对点集成和狭隘的数据管理策略。在制造环境中，所有这些都会转化为多种类型的浪费和增加的成本。

执行生产流程所需的主数据高度依赖于各个流程、资产和特定站点的考虑因素，所有这些都以比典型的企业流程（例如新产品引入、持续改进、订单输入或应付账款处理）高得多的频率发生变化。因此，制造主数据混合了与站点级别详细信息（例如客户 ID 或企业订单输入系统和工厂之间共享的高级产品规格）以及特定于站点或“本地”的详细信息，例如作为设备运行特性（可能因当地湿度、温度和驱动速度而异）甚至当地原材料特性。数据要求也可能因文化或国家/地区而异，例如货车运输法规、运输时间和海关要求，这些可能都会影响生产和运输计划。

此外，即使物理制造过程相似，财务法规也可能会影响各种工厂运营的布线、划分和整合方式，以及原材料转化为成品的核算方式。

企业主数据与“本地”或制造主数据之间的这种自然划划分，建议了菜单分解主数据管理 (mMDM) 的特定架构方法，该方法大量借鉴了企业 MDM 模型，但已针对制造环境的特定要求进行了调整。

想想一家随着时间的推移收购了各种制造实体的公司。它已经整合了其企业系统，但在站点级别，情况有所不同。不同的地点可能对相同的原料有不同的称呼（例如，11% HCl、盐酸、池酸、11% 盐酸），这种相同的原料在批次系统、SCADA 系统、LIMS、存储系统、调度系统和 MOM 系统中也可能具有不同的名称。这种一致性的缺乏使得首席运营官很难从 COO 的角度报告盐酸的消耗量，因为如果没有 mMDM，则必须为每个站点和系统定制消耗量查询，以便提取订单消耗量。

当然，另一种方法是启动命名标准化工作，这可能需要数年时间才能完成，因为大多数第2层和第3层的系统都需要进行更改。这甚至没有考虑到可视化的重新开发和操作员的再培训。问题是，一旦命名标准化完成：

谁拥有主命名权和命名规则？
随着新产品、材料、流程和设备的添加和更改，谁确保工厂不会随着时间的推移再次发生分歧？

上面的例子是一个非常简单的例子，对于一种原材料，但它也必须应用于其他资源、公用事业、设备、操作参数、配方、WIP 和产品。否则，数据损坏就是经过验证的结果。例如，如果一家公司实施了条形码扫描解决方案，则特定产品或组件的物料编号可能因供应商而异。将此提升到全球层面，考虑一下语言翻译和当地法规如何影响系统中对象的名称以及如何对对象进行分类，以及不仅以屏幕显示对象数据，而且以用户的本地语言显示数据的复杂性，同时仍然使数据可用于整合。

系统如何知道哪些产品/组件已收到或已发给工厂，而无需在某个地方进行一些翻译？

因此，mMDM 解决了当今制造公司在第3层和第4层系统之间实现更灵活集成时遇到的许多问题。

图 1-4 显示了 mMDM、MDM、SOA 和 SOAm 之间的关系以及它们如何协同工作。

提议的企业和工厂之间架构拆分的目标是在不降低系统之间集成的有效性和效率的情况下提高应用程序的灵活性。它还将接口机制从应用程序中抽象为无论应用程序发生更改都可以运行的服务。这种方法将阻止许多点对点接口损坏数据，并使系统在适应不断变化的条件方面更加灵活。

图 1-4：供应网络是 E-SOA 和 SOAm 的融合

SOAm 体系结构还将业务流程及其编排从各个应用程序抽象到操作业务流程管理层。现在，一个人可以与多个应用程序交互以跟踪或管理生产订单，甚至没有意识到他/她正在应用程序之间跳转。

图 1-4：供应网络是 E-SOA 和 SOAm 的融合，阐明了 SOAm 角色与企业 SOA 的关系。Mfg 2.0 是一种 SOA 方法，而不是一个在需求驱动的制造业中包含多样性、复杂性和新活力的应用程序，同时：

利用稀缺的制造人才。
“ 放弃和利用制造业投资，而不是撕掉并用更好的“老鼠夹”取而代之。”
消除软件可用性和僵化数据模型作为构建、部署和采用制造应用程序的障碍。
在内部和扩展的企业产品和运营流程上进行协作。
转变为擅长以低成本轻松更改业务和运营流程的应用程序和治理。

即使使用 SOAm 和 mMDM，除非消息结构和数据交换采用标准格式，否则集成也不会高效和有效。

这就是 ISA-95 在确保接口有效性和一致性方面再次发挥重要作用的地方。如果没有标准化的数据交换结构和模式，甚至 mMDM 和 SOAm 都无法实现接口重用。

ISA-95 提供了信息交换标准以及基于由 World Batch Forum（WBF，现在与 MESA International 合并）开发的企业到制造标记语言 (B2MML) 的标准化数据结构和 XML 消息模式，包括用于数据交换的动词和名词。在整个制造运营中实现标准化可确保开发标准服务以适应多种应用。

EMI 最适合还是反对商业智能 (BI)？

制造系统思维落后状态的最后一个证据是企业制造智能（EMI）在制造业中的采用率缓慢。大多数工厂经理和首席运营官都希望使用 EMI，但他们的制造技术人员却无法采用 EMI，而传统商业智能 (BI) 技术已在企业层面得到应用。因此，制造业被迫应用并非为实时数据和流程设计的企业 BI 解决方案。这导致了大量失败的项目以及报告、调度和计划以及供应链中完整性较差的数据。

但是，如果公司已经实施了BI解决方案，为什么还要实施呢EMI？

要回答这个问题，请参见图 1-4。在这种隔离的架构中，同时显示了 BI 和 EMI（图中称为 OI 或操作智能）。EMI 和 BI 有不同的目的，它们针对的是问题集和受众。表单 MDM 与 MDM 的适用理由相同，因为特定于制造的报告和智能在BI中数据的内容、上下文和数据频率是不同的。

BI 解决方案中的数据通常以与 ERP 系统中相同的低频率进行交易，例如每日价值。对于想要了解轮班或每小时发生的情况的工厂经理来说，BI 是不够的。BI 工具的设计和实施通常不会考虑制造操作的实时性及其非常高的数据速率。因此，BI 无法处理制造运营所需的高频率数据接收和报告/可视化所需的快速响应时间。

高管使用 BI 工具作为公司的战略分析和决策工具。从他们的 BI 系统中，他们可以看到一段时间内各个工厂和站点的盈利能力，这使他们能够做出决策，例如是否关闭工厂或改变制造策略。由于它们的数据基于定义的时间段，因此与实时工作流程的 EMI 相比，BI 系统通常处理更容易确认和验证的数字和结果；高管们希望确保他们在做出决策时拥有准确的数据。

验证/确认或审计步骤通常会在实际事件和数据最终进入 BI 解决方案之间增加相当长的时间。

然而，现场级生产人员不能等得到审核和验证的细节后再采取行动。如果报告或 EMI 仪表板指示出现问题，他们有责任进行调查并采取纠正措施。如果进料率低于计划，生产经理不会等到明天 BI 系统中等待确认的结果再采取纠正措施。他/她要调查，或者让其他人调查，如果结果是误报，一切都很好，危机避免了。如果出现问题，经理会采取纠正措施，或者没有，否则，经理至少知道并预计明天不会有来自 BI 系统的不良结果。生产主管讨厌惊喜，即使是好的惊喜。

因此，EMI 系统具有三个目的：

对潜在问题进行实时预警，以便人员做出决策或采取行动。
提供有关历史数据的“切片和切块”数据以改进流程。
为第2层的设备和第3层的系统的接口寻址提供大型库和方法。

EMI 拥有以个人提供的粒度和频率提供的数据、应用程序。这可以从几秒钟到几天不等，具体取决于特定的操作要求。数据也可用于每个设备、生产线或处理单元，并且可以汇总为小时、班次、天或周。EMI 系统的粒度更接近实时，它们通常被用作运营经理的实时仪表板。

集成方法的演变

除了上述问题之外，Mfg 2.0愿景采用缓慢的原因是不同的公司以不同的速度发展。制造技术人员的集成愿景基于经验、新思维和企业当前的集成状态而发展。多年来，随着技术的改进和发展，集成理论发生了变化并适应了新知识。每个公司在创建愿景时都会根据公司的需求采用自己的愿景或战略，很少有公司根据新知识定期审查和更新他们的愿景或战略。

考虑到这一点，ISA、OAGi 和 MESA 等行业组织所宣称的企业集成“最佳实践”是什么，它们是如何随着时间演变的？

以应用为中心

第一种也是最简单和最常用的企业集成方法,是“以应用程序为中心”的方法，如图 1-5 所示。在此方法中，生成代码以建立应用程序之间的点对点数据传输。由于项目心态，它仍然广受欢迎，因为它快速且便宜（至少在最初阶段）并且现场人员不需要新的培训。因此，可以在确定需求后立即开始开发。

图 1-5：以应用为中心的企业集成方法

这种方法的问题在于，新接口通常每次都是从头开始开发，并且重用率最低，从而增加了开发成本。使用这种方法意味着所有项目都以自定义方式实现。由于系统之间的数据转换通常是手动或硬编码的，因此这反过来又很可能导致数据不一致。对一个应用程序的任何更改都意味着需要对接口进行昂贵的自定义更改，并且由于这些接口是自定义开发的，因此它们很脆弱且更改缓慢。由于需要在多个系统之间进行集成，因此需要以不同自定义格式提供相同或类似的数据，因此需要为每个需求开发新的接口。这种自定义点对点接口的激增，常常导致难以管理的接口“意大利面”效应。当应用程序或接口的原始开发人员从他或她的“超级用户”角色晋升时，这种方法的高度应用，会使成本会大大增加。

以数据为中心

下一个演变是“以数据为中心”的方法，如图 1-6 所示。在这种方法中，建立了一个中央数据库或数据仓库，将来自多个应用程序的数据整理到一个公共数据存储中。提取、转换、加载 (ETL) 工具用于将数据从应用程序移动到数据存储中。需要一个数据建模环境来确保数据存储中数据的正确上下文化，并且通常使用数据仓库环境和数据质量工具来确保数据有效性和存储。还需要与数据仓库相关的报告工具来确保数据的有效可视化。

图 1-6：以数据为中心的企业集成方法

这种方法提供了一个中央、通用的数据源，其中标准报表和仪表板为所有用户提供相同的视图。可以执行复杂的分析，并可以根据趋势预测运营绩效。该方法通过重新聚合的数据提高了“交付”性能。这种方法可以在简单的报告和分析过程中有效的使用，在这些过程中，决策是在几周和几个月内做出的，而不是在几天、几小时或几分钟内做出。

这种方法的问题在于数据模型难以更改，因此需要预先充分了解数据使用情况。此外，由于 ETL 延迟或异步更新频率，数据可能很旧。因为只有单向数据流，这主要是一种报告方法而不是数据集成方法。

以接口为中心

图 1-7 所示的“以接口为中心”的方法在适配器开发环境中使用了企业应用程序集成 (EAI) 工具，例如 WebSphere、Tibco 和 Vitria。开发适配器不是开发点对点接口，而是将数据提取（或发布）到公共 EAI 总线中。总线传输数据；和其他订阅的适配器将数据加载（或使用）到需要数据的应用程序中。

图 1-7：以接口为中心的企业集成方法

这种方法用于公司范围的集成，其中一个中央传输介质必须能够访问所有数据，并且发布和订阅是必不可少的。总线通常有一个规则引擎，用于编写规则来管理总线环境中的业务和操作流程。该方法还管理消息传递并提供有保证的数据传递。它通常是单一供应商解决方案，可通过单一集成环境降低复杂性。它还具有从应用程序本身抽象出接口的优点，这意味着对应用程序的更改不一定需要更改适配器。

这种方法的问题在于用户必须遵守专有的 EAI 供应商标准，因此应用程序供应商无法开发开放的行业标准解决方案。所有信息也流经中央总线，阻碍了该方法的可扩展性。此外，EAI许可证通常非常昂贵。

以模型为中心

“以模型为中心”的方法，其中开发服务而不是适配器。使用的工具通常包括注册表/存储库、BPM或工作流工具、安全性、监控以及用于治理和生命周期管理的服务开发环境。

当业务和运营流程或基础 IT 技术频繁更改以配置不同站点的业务流程或技术的变化时，此方法特别有用。因此，这种方法非常适合当今的运营环境，因为在这种环境中，更改频繁，并且每个全球站点都有自己的基础结构、过程和工作方法。

这种方法有助于开发和采用诸如机器信息管理开放系统联盟 (MIMOSA)、ISA-95、开放应用程序组集成规范 (OAGIS)、企业到制造标记语言 (B2MML) 等接口的行业标准. 任何 ERP 或 MOM 供应商都可以提供集成功能，从而提供必要的敏捷性和灵活性，以便在不影响接口服务或数据交换的情况下快速更改流程。在这种方法中，IT 技术与业务流程分离。数据传输服务也像“以接口为中心”的方法一样从应用程序中抽象出来，业务流程规则引擎也是如此。这种方法还可用于将传统技术与“最佳实践”方法相结合，从而使渐进式采用成为可能。

这种“最佳实践”方法没有被更广泛采用的原因是它需要开发人员陡峭的学习曲线；需要全面的治理和服务管理；它需要“良好”的服务才能最大程度地重复使用。此外，供应商在发布与 Web 服务兼容的应用程序和服务方面非常缓慢。

这种方法也被 MESA 定义为 Mfg 2.0体系结构的一部分。

ERP/MOM 集成“最佳实践”

随着集成方法随着时间的推移而发展，标准化在技术层面上进行了尝试（首先是数据仓库，然后是EAI）。以模型为中心的方法（Mfg 2.0 架构）不仅将接口从应用程序中抽象出来，而且还将应用程序从基础技术基础架构中移除。

要使 Mfg 2.0 架构发挥作用，需要在制造公司内定义和实施标准。根据 Gartner（并由 MESA 承保）的说法，“应用程序互操作性需要接口标准化。只有5%的接口是中间件的功能。另外95%是应用程序语义的函数。” 因此，重要的是应该减少对技术标准化的关注，而应更多关注数据交换过程中使用的语义的标准化。这种与 ISA-95 相结合的 Mfg 2.0 架构不仅提供了零活集成架构的映射，还提供了使真正集成成为可能的通用标准和通用语言。

结论

从当前的遗留系统和集成转向基于标准的集成愿景显然不会在一夜之间发生。现在需要的是一种务实的方法，将当前的整合工作与实现基于标准的愿景的分阶段方法结合起来。

基于遗留系统构建的实用 Mfg 2.0 架构，在这种实用方法中，为尚未集成或基于 SOAm 架构的系统开发标准服务，然后实施。对于已经集成的应用程序，开发服务以将旧技术与新架构相连接。这些遗留应用程序会随着时间的推移逐步淘汰，如果这种淘汰是适当的，或者在被替换之前保留到生命周期结束，则不会失去对实时工作流程的支持。

通过这种务实的方法，遗留基础设施与新思维相结合。但是，要使这种务实的方法取得成功，企业将需要一个由热情的制造技术人员支持的长期 Mfg 2.0 战略。要使制造技术人员对 Mfg 2.0 充满热情，他们必须克服偏见，拥抱企业架构师，并开始研究和应用新思维。

因此，他们需要开始使用 MES 而不是 MOM，因为这将使他们处于正确的心态。他们需要开始了解 SOA，并且必须摆脱“以应用程序为中心的集成”，因为服务的概念是 Mfg 2.0 架构的基础。他们需要开始找出 MDM 如何帮助并停止采取简单的方法，促进“接口扩散”。他们需要通过了解 BI 的实际作用以及 EMI/OI 和 BI 的不同之处来正确定位 EMI 或 OI，以便为制造经理提供正确的决策信息。那些不改变思路的制造企业，在系统开发方面将会停滞不前。