What is Global Best Practice for manufacturing operations management (MOM) systems and IT architecture? What practices are recommended by MESA and other industry experts? Is our thinking outdated, too expensive to own and unable to adapt rapidly to market change?
Manufacturing companies have long been reluctant to adopt new thinking. If things worked for 20 years, why change them now? With this thinking, the world of technology has moved on and left manufacturing companies behind. Very few of these companies have kept up to date with new developments and only the truly progressive have adopted these innovations within manufacturing itself.
Manufacturing operation management (MOM)
The first proof of this state of affairs is clear by the continued use of the term MES that is so yesterday’s news. The new thinking has gone beyond MES and into the realm of MOM (of which MES is but a part). A system cannot be specified and designed using the AMR or the MESA MES definitions from the 1990s anymore and so another definition is required. MOM is a lot easier to define.
ISA-95.00.03 defines MOM as ‘activities within Level 3 of a manufacturing facility that coordinate the personnel, equipment and material in manufacturing’ and includes production operations management, maintenance operations management, quality operations management and inventory operations management. This is a lot more sensible and embracing than the traditional MES definitions.
Standards-based integration vision
The second proof that manufacturing companies have fallen behind is the lack of a standards-based integration vision. Standardisation of technologies at the control and MES levels is not the same as having a standards-based integration vision. ‘Rip and Replace’ programmes are not standards-based integration visions. For most companies, these types of ‘standardisation’ initiatives are cost-prohibitive and impractical.
A standards-based integration vision is a vision where the data transfer and transport functionality are abstracted from the application itself into a standards-based services layer (typically within a service bus) that operates independently from changing business processes. Those that have been involved in enterprise integration projects will recognise this as service oriented architecture (SOA), but this term is typically a swear word within manufacturing.
You may think that the SOA concept applied to manufacturing is outrageous and that it will never work, but do yourself a favour and read what SOA actually does according to Gartner and MESA and then think how you can apply that to your manufacturing company and MOM specifically.
A number of manufacturing companies have implemented enterprise service buses (ESBs) specifically to ease integration. Few of these ESB architectures have however made their way down into manufacturing itself, and with good reason. MESA, for instance, states that: “For MOM, a separate manufacturing services bus (MSB) is required due to a high number of transactions, a high parametric data load and near real-time requirements for operations applications.” There are success stories about MSB implementations, so the concept is viable and proven.
Master data management (MDM)
The third proof of this conservative thinking is that very few manufacturing technologists have ever heard of MDM and fewer understand what it actually means. Enterprise solutions have long relied on MDM systems to ensure naming consistency and data translation between disparate enterprise-level solutions. Manufacturing has not even given this a thought as can be seen by the proliferation of point-to-point interfaces between systems.
According to Wikipedia, “Master data management comprises a set of processes and tools that consistently defines and manages the non-transactional data entities of an organisation (which may include reference data). MDM has the objective of providing processes for collecting, aggregating, matching, consolidating, assuring quality, persisting and distributing such data throughout an organisation to ensure consistency and control in the ongoing maintenance and application use of this information.”
Is it necessary to differentiate between enterprise MDM and manufacturing MDM (mMDM)? According to MESA, in the vast majority of cases, the engineering bill-of-materials (BOM), the routing, or the general recipe from the ERP or formulation/PLM systems simply lack the level of detail necessary to communicate effectively with plant systems such as scada.
Think of a company that has acquired various manufacturing entities over time. It has consolidated the enterprise systems, but at site level, things are different. Different sites may call the same raw material different things (for instance 11% HCl, hydrochloric acid, pool acid, hydrochloric 11% etc). Then this same raw material may also have different names in the batch system, the scada, the LIMS, the stores system, the scheduling system and the MOM. This makes it extremely difficult to report for instance on the consumption of hydrochloric acid from a COO perspective, as without a mMDM for instance, the consumption query will have to be tailored for each site and system in order to abstract the quantities for use.
The alternative of course is to initiate a naming standardisation exercise that can take years to complete as changes will be required on most level 2 and 3 systems. mMDM will thus resolve a lot of issues that manufacturing companies are experiencing today in their strive for more flexible integration between level 3 and level 4 systems.
How do we bring these together?
This is all good and well, but what does it mean? How do we take these concepts and issues and combine them into one architectural model that will satisfy the requirements from both enterprise and manufacturing operations perspectives? Figure 1 shows the relation between mMDM, MDM, SOA and SOAm and how they are meant to operate together.
Due to the differing nature and context of the data and information, a logical split in function and architecture is required. The objective of the proposed split in architecture is to increase application flexibility without reducing the effectiveness and efficiency of the integration between systems. It also abstracts the interface mechanisms out of the application into services that can operate regardless of application changes.
Enterprise manufacturing intelligence (EMI)
The last proof of the backwards state of manufacturing systems thinking is the slow adoption rate of enterprise manufacturing intelligence (EMI) within manufacturing. I often get asked why a company should implement an EMI solution if they already spent money on a BI solution. They already have the ‘slice and dice’ and analytical ability within BI, so why waste money on an EMI solution?
To answer this question, I want you to refer to Figure 1. Within this segregated architecture, we have both BI and EMI (called OI or operations intelligence in the picture). EMI and BI have different purposes and they are aimed at a different audience. The same reasons for mMDM vs. MDM can be applied, as manufacturing-specific reporting and intelligence is different in content and data frequency than the data in BI.
Data in a BI solution is typically at the same low frequency as that of the ERP system such as daily values. For a plant manager who wants to know what is happening on a shift or hourly bases, BI will therefore be inadequate.
Executives use BI as strategic analysis and decision-making tools for the company. They typically work on confirmed and validated numbers and results as they want to ensure they have accurate data when they make the decision. These validation/confirmation or auditing steps often add considerable time between the actual event and the time the data end up in the BI solution.
Site-level production personnel however cannot wait for the niceties of auditing and validation before they take action. If a report or an EMI dashboard indicates that something is wrong, it is their responsibility to investigate and take corrective action immediately.
A pragmatic approach
Moving from current legacy systems and integration toward the standards-based integration vision is obviously not going to take place overnight. What is required is a pragmatic approach that combines current integration efforts with a phased approach towards the standards-based vision. This approach is shown in Figure 2.
Standard services are developed for systems not yet integrated (IT components at the bottom) based on the SOAm architecture and implemented. For applications already integrated (applications A,B,C,D on the left), services are developed to interface old technologies with the new architecture. These legacy applications are phased out over time without a loss in support of the real-time work processes or left until end-of-life before being replaced.
References
* International Society of Automation (ISA): ISA-95.00.03 Enterprise-Control System Integration Part 3: Activity Models of Manufacturing Operations Management.
* MESA International: SOA in Manufacturing Guidebook.
* MESA International: Data Architecture for MOM: The Manufacturing Master Data Approach.
* MESA International: Lean Manufacturing Strategic Initiative Guidebook.
For more information contact Gerhard Greeff, Bytes Systems Integration, +27 (0)82 654 0290, [email protected], www.bytes.co.za
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version