介紹
什么是制造運營管理 (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,以便為制造經理提供正確的決策資訊,那些不改變思路的制造企業,在系統開發方面將會停滯不前,
“老天爺給你的任何機會,你也不會珍惜,更不會深入下去,你認為自己就是窮命,最喜歡通過脈脈閱讀免費的職場技巧,如果你還是杠精思維,任何事情,跑上來先論證困難,給自己一個不干不參與的充分理由,那你完了,人生不過是短短十五年的機會,到了四十歲,你還在屌絲堆里,啥也不干,那你沒希望了,”轉載請註明出處,本文鏈接:https://www.uj5u.com/qiye/393237.html
標籤:其他
