介紹

多年來，使用基于制造運營管理 （MOM） 的應用程序的制造 IT 顧問試圖說服制造商這些類型的應用的高價值。實時 MOM 解決方案是唯一一組能夠精確優(yōu)化工廠日常運營的 IT 應用程序，可為其可用性流程帶來可創(chuàng)造的價值，但制造商在認識到實施 MOM 的任何給定部分所產生的可操作指標與用于可見性和界面的定期關鍵績效指標 （KPI） 之間的差異方面上進展緩慢。

決策者通常非常不愿意在他們的工廠或企業(yè)中開始任何類型的MOM實施，因為這些項目的規(guī)模很大，風險很高，成本很高。從歷史上看，由于客戶對軟件的了解不夠，許多 MOM 項目在按時或按預算結束時都存在重大問題。這通常是由于項目中的某個人，無論是銷售人員、程序員，甚至是客戶，試圖在解決方案的第一個 MOM 項目中使解決方案 100% 地滿足客戶的需求。所有各方都不同意可實現(xiàn)的MOM項目和功能路線圖。因此，項目參與者往往忽視了項目的真正和可實現(xiàn)的目標。

本文中描述的 I³ 概念基于眾所周知的標準，包括 ISA-95 和 B2MML，并為企業(yè)資源規(guī)劃 (ERP) 系統(tǒng)和過程控制系統(tǒng)之間的集成添加了一些進一步的功能。

本文描述了 I³ 方法，并提供了一個如何在“現(xiàn)實生活”中應用標準的示例。

MOM 項目受到運營部門和企業(yè)集團之間相互沖突的優(yōu)先級的影響，因此當目標在時間功能范圍內相距甚遠時，保持項目重點總是很困難的。當項目團隊不關注近期目標時，最初的目標幾乎永遠不會實現(xiàn)。

在 MOM 領域，公司面臨著“永恒的軟件困境”，使用商用現(xiàn)貨 (COTS) 軟件工具應用簡單的解決方案，只需配置（無需編程）即可執(zhí)行項目功能和任務；節(jié)省大量開發(fā)時間和資金（但會增加接口和報告成本），最終得到僅滿足您 80% 需求的解決方案，或應用編程工具并修改解決方案以完全滿足您的需求，盡管這樣做需要大量的編程、較長的時間和良好的架構技能。

在I³方法論，這兩者都有一些元素——一些標準軟件和一些編程。

最好的做法是從小處著手解決文化采用和一致性問題，然后將功能擴展到路線圖，而不是強迫公司實施所謂的全面 MOM 解決方案。本章節(jié)中詳細介紹了一種稱為“智能集成接口”(I³) 的項目方法。

MOM 項目和功能路線圖對于長期（例如，X年）業(yè)務目標和/或包含項目利益相關者需求的已定義和指定策略的成功至關重要。有了這樣的路線圖，項目成員就可以將這些目標和策略作為項目中的指導里程碑，并隨時重新審視它們以確認它們是否走上正軌。

但要在預算內按時實現(xiàn)指導性里程碑，應始終明確定義短期目標并進行有效溝通，以便容易看到和實現(xiàn)這些目標。

在 I³ 項目中，任何 MOM 解決方案的核心功能都在 IT 系統(tǒng)之間的集成中得到解決，以簡化實施以適應客戶的業(yè)務需求。基于已建立的集成基線，當客戶及其組織準備好并需要擴展時，可以稍后擴展該功能。這是讓客戶通過全面的 MOM 解決方案取得成功的最可靠和最安全的方式的最佳實踐。

無論解決方案提供商是軟件供應商還是獨立于軟件的咨詢公司，本文中描述的許多相同問題在每個項目中都會面臨。

從制造商到制造商，甚至從工廠到工廠，MOM 領域中的解決方案在規(guī)模和復雜性上都大不相同。

本文是 MESA/ISA-95實踐的一部分，描述了開發(fā)基于 ISA-95 MOM 標準的制造運營管理系統(tǒng)的實踐。

說服和教育基于MOM的解決方案

ISA-95 標準詳細地描述了相關領域測層次。然而，這個過于簡化的數(shù)字經常用于與 MOM 相關的文章和銷售演示。因此，在看過許多這些演示文稿的生產經理的心目中，這就是 MOM 系統(tǒng)或體系結構的外觀和工作方式。在生產經理的心目中，MOM 解決方案只是安裝在 ERP 層和過程控制層之間的“白盒”。

在許多公司，經驗豐富的 MOM 顧問多年來一直試圖說服工廠經理和生產經理，MOM 解決方案是優(yōu)化其日常運營和增加業(yè)務價值的唯一解決方案。MOM 系統(tǒng)被宣傳為包含唯一有效的功能集來控制工作流程變化和最小化浪費。通過事件和警報驅動的響應，MOM 系統(tǒng)使用可操作的指標來最小化異常條件或次優(yōu)操作狀態(tài)的影響。

在分析他們工廠中已有的功能類型后，制造商發(fā)現(xiàn)大部分 MOM 功能（根據(jù) ISA-95 的定義）已經存在，甚至可能在工廠經理或生產經理都沒有意識到的情況下。但是，不同系統(tǒng)之間沒有適當?shù)募桑麄€工廠也沒有通用、一致的定義。該功能通常分布在許多不同的系統(tǒng)上，包括基于紙張的、文字處理、電子表格和數(shù)據(jù)庫應用程序——一些是商業(yè)產品，另一些是由員工創(chuàng)建的。如果工廠人員被問及用于質量保證、維護、可追溯性等的軟件應用程序，他們通常會說公司使用 Excel、數(shù)據(jù)庫或為此目的設計的 COTS 軟件包來處理 MOM 功能和任務。

實際上，運營商并沒有意識到他們的 ERP 系統(tǒng)和過程控制系統(tǒng)（ISA-95 模型中的第4層和第2層）和其他周圍系統(tǒng)之間，以及內部不同 ISA-95 第 3 層系統(tǒng)之間的巨大集成差距的大小。公司可以從彌補這些差距中獲得巨大價值，因為他們將受益于在所需響應時間內交換所需數(shù)據(jù)的自動化界面，從而最大限度地減少意外事件的影響。自動化數(shù)據(jù)收集和界面消除了生產區(qū)域的紙質表格和手動數(shù)據(jù)輸入（隨之而來的轉錄、打字和翻譯錯誤），以提供可靠、實時的信息作為決策依據(jù)。

從軟件提供商的角度來看，縮小集成差距的一種方法是向公司出售一種新的 MOM 解決方案，該解決方案將替代或替換所有這些不同的“不同數(shù)據(jù)的 MOM 孤島”。但是，最佳實踐是建議從小處著手，首先將一組高價值系統(tǒng)整合到階段 1 MOM 解決方案中。第 1 階段 MOM 解決方案根據(jù)商定的 MOM 路線圖與具有可防御投資回報 (ROI) 的小項目一起發(fā)展，從而在公司里建立對 MOM 解決方案的更多理解和接受。

在采用這種方法的情況下，從核心 MOM 功能開始的建議，應基于在規(guī)劃層（ISA-95 中的第 4 層）和過程控制層（ISA-95 中的第 2 層）之間建立一個集成基線。因此他們可以以智能高效的方式交換數(shù)據(jù)。I³ 方法比僅僅集成或連接系統(tǒng)更進一步；它還為解決方案增加了一些智能，以便在工廠運營中有效執(zhí)行和響應。

這就是 I³ 作為集成概念發(fā)揮作用的地方。

I³ 是什么？

I³ 概念基于將軟件功能塊置于規(guī)劃層和控制層之間，形成 MOM 解決方案（ISA-95 中的第3層）。I³涵蓋了制造運營的某些部分（ISA-95 中的第 3 層）和 ISA-95 第 3 部分中定義的一些生產運營管理活動模型。這將在本文后面進一步描述。

該解決方案由以下三層構成：

• 第 1 層 - 接口

    該層處理與控制層中不同類型的軟件系統(tǒng)和硬件組件之間的通信。如果需要和需要，該接口層還可以處理與其他周圍系統(tǒng)的通信。

• 第 2 層 — 隊列

    第 2 層接收、排隊和處理從接口層快速傳入的數(shù)據(jù)。它存儲數(shù)據(jù)，直到業(yè)務邏輯層準備好處理它們并將消息序列保存到下一層。

• 第 3 層 - 業(yè)務邏輯

業(yè)務邏輯層從隊列中取出消息，主要處理與ERP、產品生命周期管理（PLM）、供應鏈管理（SCM）或客戶關系管理（CRM）等企業(yè)系統(tǒng)的通信。但除了與這些系統(tǒng)的基本通信外，如果通信中出現(xiàn)問題，該層還提供“智能”錯誤和/或異常處理。如果需要，該層還可以提供用于監(jiān)控制造操作的可視化和各種儀表板。該層是該解決方案中最“智能”的層，也可以描述為異常處理層。

這三個層將在以下各節(jié)中進一步詳細描述。

接口（第 1 層）

該模型中第 1 層的主要功能是與過程層中的控制硬件進行通信。以及其他周邊系統(tǒng)：

• 可編程邏輯控制器 (PLC)
• 操作面板（OP面板）
• 其他 I/O（條碼閱讀器、條碼打印機、秤等）

其他可能接收信息的周邊軟件系統(tǒng)：

• 監(jiān)督控制和數(shù)據(jù)采集 (SCADA)
• LIMS/QA 實驗室信息管理/質量保證）
• 分布式控制系統(tǒng) (DCS)
• 計算機化維護管理軟件 (CMMS)
• 包含 ISA-95 第 3 部分中定義的功能的其他系統(tǒng)

從圖 7-1 的底部開始，第 1 層，接口，通過“I/O 通信”塊從控制層硬件和軟件接收過程數(shù)據(jù)或事件記錄。在與生產車間的 PLC 等過程控制硬件進行通信時，OPC 服務器可以大大降低與生產車間的過程控制硬件的通信難度。通常，需要與更簡單的硬件或其他軟件系統(tǒng)進行 MOM 通信；因此，I/O 通信塊處理例如串行接口和基于文件的接口。

“確定  事務/命令”塊獲取傳入消息，提取所需的命令/事務類型，并確定消息來自流程行中的何處。

在通過“提供命令”塊將其傳遞到隊列（第 2 層）之前，“為命令附加Id”塊中的命令虛擬地附加了一個唯一 ID。ID 標識哪個設備或軟件系統(tǒng)發(fā)送了命令。該信息本地存儲在“提供命令”塊中供以后使用。

“提供命令”塊簡單地接受命令并將其放入層隊列。由于隊列基于數(shù)據(jù)庫中的表，“提供命令”塊使用普通的結構化查詢語言 (SQL) 插入命令。

第 1 層查看第 2 層隊列以查看是否有準備處理的結果或消息。這是在圖右側的“獲得下一條消息”塊中完成的。

圖 7-1：第 1 層，接口

上述唯一 ID 用于“結果Id”塊中，通過“I/O 通信”塊將結果或消息引導回正確的設備。消息發(fā)送后，標志重新設置到“獲得下一條消息”塊中，指示 I/O 通信塊已準備好處理下一條消息。

當然，其他功能，如可視化、報警處理和數(shù)據(jù)采集，也可以添加到這一層。

第 1 層通常基于 Wonderware、Rockwell、Siemens、GEIP 等公司的 SCADA/HMI 軟件包等標準軟件。

隊列（第 2 層）

隊列層被添加到解決方案中，以將 PLC 和 SCADA 系統(tǒng)的“實時”世界與業(yè)務邏輯事務的較慢世界（一個非常重要的功能）分開，而不會丟失傳入消息的順序（先來的）從第 1 層開始。在大多數(shù) MOM 解決方案中，維護事件的順序尤為重要。因此，隊列層實現(xiàn)為先進先出 (FIFO) 隊列。

作為獎勵，隊列層會緩沖消息/事件，以防與 ERP 系統(tǒng)或過程控制級別的連接丟失。

隊列層實際上分為兩個隊列：

• 生產計劃
• 生產業(yè)績

生產性能隊列包含與來自流程的事件相關的消息，而生產計劃隊列包含要從 ERP 系統(tǒng)發(fā)送到流程的消息。兩個隊列的名稱取自 ISA-95 標準。

第 2 層的功能可以編程，但也可以由 Microsoft Message Queue、IBM 的 MQ 系列或類似的標準中間件處理。

在 MOM 項目中，最佳實踐是根據(jù) ISA-95 對生產進度和生產性能的定義，在數(shù)據(jù)庫結構中構建第 2 層的兩個隊列。

如前所述，第 1 層中的“提供命令”塊從物理過程中獲取消息，并將數(shù)據(jù)插入到數(shù)據(jù)庫的生產性能表中的正確表中。

第 1 層的“獲得下一條消息”塊從數(shù)據(jù)庫的生產計劃部分的不同表中獲取新消息。

當然，像 ISA-95 這樣的 MOM 標準的優(yōu)點之一是，國際標準使得更改周圍層之一（例如，使用標準中間件或最新版中間件）變得更加容易，只要新層其數(shù)據(jù)結構和接口符合 ISA-95 標準。

業(yè)務邏輯（第 3 層）

溝通

I³ 概念的第 3 層充當與 ISA-95 模型的規(guī)劃級別（第 4 層）的主要通信接口。該接口必須基于現(xiàn)場或公司的 ERP 系統(tǒng)來實現(xiàn)。一些ERP系統(tǒng)直接支持基于ISA-95的標準協(xié)議B2MML，這使得直接從隊列層中基于ISA-95的表中處理數(shù)據(jù)變得更加容易。例如，其他 ERP 系統(tǒng)使用高級編程接口 (API) 或基于文件(CSV、XML)的接口。

確定推薦和應用的協(xié)議取決于具體的 ERP 系統(tǒng)、公司的雄心和項目的規(guī)模。

如果可能，與I³接口的最明顯方式是使用 B2MML，因為 MOM 解決方案的數(shù)據(jù)庫基于 ISA-95 結構。但與解決方案的其余部分一樣，沒有必要使界面變得比滿足項目需求所必需的更復雜。在某些情況下，基于文本文件的簡單界面可能綽綽有余。通過分析現(xiàn)在和未來接口的完整業(yè)務需求，并選擇合適的接口協(xié)議，流程和系統(tǒng)的適應性可以成為設計的一部分，從而顯著降低解決方案的總擁有成本。

錯誤處理

第 3 層包含檢測通信錯誤（例如，與 ERP 系統(tǒng)的連接丟失）和在發(fā)送/接收的消息內容不正確時處理數(shù)據(jù)錯誤的能力。

為了使這一層正常工作，首先要實現(xiàn)的事情之一是能夠真正意識到從通信對方返回的消息中存在錯誤。ISA-95 的第 5 部分描述了如何以標準化方式處理此特定功能。在第 5 部分中，消息接收器（正在處理數(shù)據(jù)）被定義為響應一條消息，說明請求是被接受、拒絕還是修改。

在本文后面的實際示例中，這正是處理通信錯誤所需的功能，這些錯誤最初是在解決方案的每個新項目中手動定義和編程的。

業(yè)務邏輯

第 3 層最重要的功能是用于處理預期情況或用例的規(guī)則集。特殊和定制的規(guī)則（“邏輯規(guī)則”）處理日常運營和業(yè)務中需要公司或站點特定決策的情況，其中公司的手動程序無法在沒有代價高昂的損失的情況下覆蓋這種情況。如今，很多公司都會向操作員或管理層發(fā)送有關此類錯誤的警報，然后一個人做出決定并進行流程、工單、設定點等的手動調整。

第3層盡可能地自動化對不同錯誤場景的響應。

如圖 7-2 所示，每當“準備接收下一條消息”標志被設置時，“獲得下一條消息”塊用于從第 2 層的數(shù)據(jù)庫表中選擇下一條消息（由時間戳確定）。“確定事務”塊獲取消息并解碼處理消息所需的 ERP 事務。接下來，區(qū)塊取出消息的相關參數(shù)，將交易發(fā)送到ERP系統(tǒng)。如前所述，所使用的協(xié)議取決于 ERP 系統(tǒng)。

圖 7-2：第 3 層，業(yè)務邏輯

當收到來自 ERP 系統(tǒng)的“結果”消息時（自動。通過輪詢數(shù)據(jù)，或通過其他功能——同樣取決于實現(xiàn)的接口），“錯誤處理”塊首先檢測它是否是異常（不是錯誤）消息或返回錯誤。

如果是正常消息，則“提供消息/結果”塊將數(shù)據(jù)寫回到正確的第 2 層表中，從而設置“準備接收下一條消息”標志。

如果 ERP 系統(tǒng)返回錯誤消息，則激活“業(yè)務邏輯”塊。業(yè)務邏輯塊嘗試自動處理這種情況，然后（如果需要）向 ERP 發(fā)送不同的事務。

一般來說，這一層應該能夠處理本地（特定于站點）的規(guī)則。業(yè)務邏輯層還處理全局（企業(yè)范圍）規(guī)則，例如公司的質量保證規(guī)則是否允許將正常物料放置在已保存環(huán)境監(jiān)管物料的存儲箱中。

業(yè)務邏輯層的一大挑戰(zhàn)是業(yè)務邏輯規(guī)則（當然）非常不同，并且從一家公司到另一家公司，有時甚至在同一家公司的各個站點之間是非常不同的。因此，很難將許多功能從一個項目重用到另一個項目。從歷史上看，該層及其塊因此已針對每個項目進行了編程。

例子

應用業(yè)務邏輯層的情況有很多種（錯誤場景）。下面描述了這些情況的一些示例。

• 示例 1：機器在生產線上發(fā)生故障。首先，必須決定是否應暫停或在另一臺機器上處理生產或工作單元訂單。如果要在另一臺機器上加工，則必須確定替代路線和/或機器。然后，必須決定是否需要更改生產計劃，例如將訂單拆分為較小的批量或將訂單合并為較大的批量。此示例中的某些特定功能可以（并且經常）由配方或路線建模軟件直接涵蓋，但如果不存在此類外部功能，則決策邏輯會自動涵蓋，無需操作員干預此塊。
• 示例 2：通常需要業(yè)務邏輯來管理連續(xù)加工設施（如動物飼料廠或面粉廠）中的存儲位置。

例如：當 ERP 系統(tǒng)想要將物料裝入特定的料倉時，許多經驗豐富的 MOM 集成商都會猶豫究竟應該使用哪一種方案。

• 示例1：根據(jù) ERP 系統(tǒng)，特定的料倉有足夠的空間來裝運物料，但實際上（由于物理測量不準確或物料粘在內部）料倉在所有物料全部裝滿之前實際上已滿。 MOM 業(yè)務邏輯層需要自動決定剩余物料將被引導到哪個倉，并使用所有批次的實際數(shù)量和位置更新 ERP。此決策和邏輯取決于許多加權因素，例如，之前可用垃圾箱中的內容（以避免物料交叉污染或避免混合受環(huán)境監(jiān)管的物料和正常物料）或基于對下一個容器的了解的最佳位置卸載物料。
• 示例2：將谷物接收到 100 噸倉中后，倉“高”容積傳感器感應到倉已滿，并將“100 噸”報告回 ERP 系統(tǒng)。一段時間后，物料會壓縮成較小的體積。操作員實際檢查料箱以觀察現(xiàn)在有更多物料的空間，因此他手動將更多物料導向該料箱。然后，過程控制系統(tǒng)報告物料已移至（根據(jù) ERP 系統(tǒng)）已經裝滿的料箱。同樣，MOM 業(yè)務邏輯層需要使用所有批次的實際數(shù)量和位置自動更新 ERP。
• 示例 3：業(yè)務邏輯塊處理的一個常見問題是當大量物料相互分層時的批次跟蹤。場景是批次 2 被物理添加到已經包含批次 1 的垃圾箱中。實際上，包含分層批次的垃圾箱在排放過程中以錐形形式相互作用，其中兩種物料發(fā)生了少量混合。這種類型的混合流變很難在任何類型的軟件中建模和編程邏輯，因此通常選擇其他兩種模型之一。

     “偽物料”（1+2）邏輯模型在兩層之間使用“偽物料”層（data-wise）來覆蓋兩種物料的混合，需要當物料從料倉流出時放置。

    后進先出 (LIFO) 模型表示物理裝入料箱頂部的新物料在邏輯上（數(shù)據(jù)方面）始終放置在料箱底部. 實際上，這與實際發(fā)生的情況很接近，但物理混合流變學很難在物料可追溯性應用中建模和實施。

為了定義這些類型的站點或公司特定場景的規(guī)則，必須通過一系列工程來完成經驗建模，以對物理過程的工作方式以及它們應該如何建模和編程進行徹底的分析應用。

需求分析

當要對業(yè)務邏輯層進行編程時，一個挑戰(zhàn)是讓客戶以可編程的形式實際定義他或她的業(yè)務和運營邏輯規(guī)則。如果它們不是 100% 定義的，則無法將它們編程到解決方案中。

根據(jù)項目的復雜性，有多種定義和指定規(guī)則的方法。在一些簡單的情況下，客戶直接快速地說明規(guī)則是什么。但大多數(shù)情況下，必須對業(yè)務、運營和物理流程進行徹底分析，以確定交互、依賴關系以及不同情況的處理方式。對于業(yè)務和運營流程，業(yè)務流程管理 (BPM) 方法將業(yè)務規(guī)則和流程描述為“公認地”。對于物理過程，必須通過一系列工程測試來完成經驗數(shù)據(jù)的收集和建模。通常應用實驗設計 (DOE) 方法。本文不涉及 DOE 方法和經驗建模。

定義業(yè)務和運營邏輯規(guī)則的第一步，是使用由最終用戶工作組組成的流程操作團隊。他們由制造組織各個層次和職能的人員組成。該流程行動團隊描述了公司如何處理流程、信息流、錯誤處理等。這些討論產生了 BPM 圖。MOM 的 BPM 圖以圖形方式顯示業(yè)務和運營如何處理不同的日常情況以及要使用的規(guī)則。這使得在此處描述的解決方案中更容易實現(xiàn)規(guī)則。

將 I³ 映射到 ISA-95

I³ 概念的核心部分在很大程度上依賴于 ISA-95 標準。

在第3層內以及第2層和第4層間定義運營管理功能、任務和交換的標準是全球制造商設計下一代 MOM 解決方案的絕佳方法。

ISA-95 標準中的一些模型解釋了 I³ 的功能如何映射到標準。圖 7-3 顯示了 ISA-95 第 3 部分中描述的生產運營管理活動模型的哪些特定部分已在解決方案中實施。

圖 7-3：生產運營管理的活動模型

使用“生產數(shù)據(jù)收集”是因為生產數(shù)據(jù)是從流程中收集并交換到 ERP 系統(tǒng)的。之所以使用“生產跟蹤”，是因為已向 ERP 系統(tǒng)報告了所用資源（物料、位置和機器）和生產物料（中間和成品、實際與計劃）的摘要。

“生產調度”的一小部分是通過為操作員提供一個簡單的生產訂單調度列表來使用的。

可以使用 B2MML 消息與 ERP 進行通信，以建立公司對預定義接口的集成基線標準。在某些情況下，B2MML 接口可以從 ERP 系統(tǒng)通過 I³系統(tǒng)應用到過程控制系統(tǒng)。當然，如果以后需要，這可以更輕松地從一個系統(tǒng)更改為另一個系統(tǒng) (ERP-I³-PCS)。

結論

從任何 MOM 解決方案的核心功能（IT 系統(tǒng)之間的集成）開始，將使項目和解決方案變得簡單，使其適應制造商的當前需求，同時以更低的成本滿足未來的需求。如果這樣做，隨著全球市場推動制造商組織的變化，擴展功能可能會被迅速部署。制造商的成功歸功于適應性強的 MOM 和集成解決方案本身。由于 I³概念是在模塊中構建的，因此構建所需的內容然后稍后添加功能非常簡單。只需“離線”將功能添加到正確的模塊，測試功能和接口，然后交換舊模塊和新模塊。

所描述的概念 (I³) 最適合已安裝 ERP 系統(tǒng)和過程控制系統(tǒng)（負責大部分執(zhí)行部分）并且只需要兩者之間的通信接口的工廠。

盡管 I³是解決制造過程和 ERP 系統(tǒng)之間通信問題的簡單方法，但在一些現(xiàn)場實施此解決方案仍然可能是“矯枉過正”。I³應該被視為基于未來功能需求的選項，即使接口保持更簡單，例如，可能不需要處理該站點的業(yè)務邏輯和/或異常。

另一方面，如果處理業(yè)務邏輯的需求非常復雜，建議考慮標準化的現(xiàn)成解決方案，而不是嘗試從頭開始對解決方案進行編程。這將為公司節(jié)省時間和金錢。

如果制造商擁有從頭開始實施系統(tǒng)的新建工廠，在這種情況下，通常最好的方法是從核心功能開始，然后擴展功能。

本文中描述的解決方案不是“產品”。它只是一種處理生產和 ERP 之間接口的方法或概念，許多創(chuàng)新制造商已成功應用。從一個項目到下一個項目已經并且將會有一定數(shù)量的重用。但是在新項目中，需要對 MOM 和接口要求進行分析，以確定必要的功能并決定 I³是否是最佳方式。

MOM 轉型路線圖對于長期（例如，X年）業(yè)務目標以及包含項目利益相關者需求的已定義和指定戰(zhàn)略的成功仍然至關重要。如前所述，始終牢記總體目標和畫面，并對公司現(xiàn)在的業(yè)務需求、未來的預期以及系統(tǒng)的價值進行初步分析，這一點至關重要。可以在X年內找到（即定義指導里程碑）。如果您不了解或不了解 MOM 解決方案的可能性以及可能存在的陷阱（例如，集成許多不同的 IT 系統(tǒng)），這將很難甚至不可能做到。

因此，制造商的最佳做法是與經驗豐富的 MOM 顧問合作，他們以前嘗試過類似的事情，并且可以將解決方案引導到正確的方向。