Can Sustainable Manufacturing Operations Management Exist without some sort of Master Data Management?

Over the last couple of months we have seen customers increasing investigating the strategies to answer this question: “how to enable alignment across “level 3” operational applications”. 

This area of aligning the level 3 applications without rip and replace will become one of the core requirements in making Manufacturing Operations Management sustainable and effective.   

Syncing between systems, people look at data warehouses , they do manual binding, but these are just not practical in a sustainable and every changing world. There are many systems usually upwards of 20 + systems which come from different vendors and even if they do come from the same vendor they implemented by different cultures in the plants. The thought pattern on “just asset naming” is different between these groups.

Again Borrowing from As Gerhard Greeff – Divisional Manager at Bytes Systems Integration put it in his paper"When last did you revisit your MOM?"

MDM or Master Data Management is the tool used to relate data between different applications.

So what is master data and why should we care? According to Wikipedia, “Master Data Management (MDM) comprises a set of processes and tools that consistently defines and manages the non-transactional data entities of an organization (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 organization to ensure consistency and control in the ongoing maintenance and application use of this information.”

Processes commonly seen in MDM solutions include source identification, data collection, data transformation, normalization, rule administration, error detection and correction, data consolidation, data storage, data distribution, and data governance.

Why 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 your ERP or formulation/PLM systems simply lack the level of detail necessary to:

1. Run detailed routing through shared shop resources

2. Set up the processing logic your batch systems execute

3. Scale batch sizes to match local equipment assets

4. Set up detailed machine settings

This problem is compounded by heterogeneous legacy systems, mistrust/disbelief in controlled MOM systems, data ownership issues, and data inconsistency. The absence of strong, common data architecture promotes ungoverned data definition proliferation, point-to-point integration and cost effective data management strategies. Within the manufacturing environment, all this translates into many types of waste and added cost.

The master data required to execute production processes is highly dependent upon individual assets and site-specific considerations, all of which are subject to change at a much higher frequency than typical enterprise processes like order-entry or payables processing. As a result, manufacturing master data will be a blend of data that is not related specifically to site level details (such as a customer ID or high-level product specifications shared between enterprise order-entry systems and the plant) and site-specific or “local” details such as equipment operating characteristics (which may vary by local humidity, temperature, and drive speed) or even local raw material characteristics.

This natural division between enterprise master data and “local” or manufacturing master data suggests specific architectural approaches to manufacturing master data management (mMDM) which borrow heavily from Enterprise MDM models, but which are tuned to the specific requirements of the manufacturing environment.

Think of a company that has acquired various manufacturing entities over time. They have consolidated their 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 standardization exercise that can take years to complete as changes will be required on most level 2 and 3 systems. That is not even taking into account the redevelopment of visualization and the retraining of operators. The question is, once the naming standardization is complete, who owns the master naming convention and who ensures that plants don’t once again diverge over time as new products and materials are added?

The example above is a very simple one, for a raw material, but it can also be applied to other area.

But when you are talking to customers you see comments and projects and so many are trying to deal with this issue without really looking at the big problem and plan.

If a company has for instance implemented a barcode scanning solution, the item numbers for a specific product or component may differ between suppliers. How will the system know what product/component has been received or issued to the plant without some translation taking place somewhere? 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.

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. This will get rid of numerous “point-to-point” interfaces and make systems more flexible in order to adapt to changing conditions. The mSOA architecture also abstracts business processes and their orchestration from the individual applications into an operations business process management layer.  Now, one person is able to interact with multiple applications to track or manage a production order without even realizing that he/she is jumping between applications.

Even with mSOA and mMDM, integration will not be efficient and effective unless message structures and data exchange are in a standard format. This is where ISA-95 once again plays a big part in ensuring interface effectiveness and consistency. Without standardized data exchange structures and schemas, not even mMDM and mSOAm will enable interface re-use.

ISA-95 part 5 provides standards for information exchange as well as standardized data structures and XML message schemas based on the Business-to-Manufacturing Mark-up Language (B2MML) developed by WBF, including the verbs and nouns for data exchange. Standardizing these throughout the manufacturing operations ensures that standard services are developed to accommodate multiple applications. Increasingly we are seeing the process industries such as Oil and Gas, Mining, looking towards these standards, and developing them to address this growing challenge of expansion, vs sustainability.

Commentary Feedback on “Third Time Lucky for MOM/ MES!!!! YES, it does have a significant chance this time!!

It is an interesting writing this blog as there is little comment feedback in the blog, but I receive a lot of email on certain subjects with substantial input. The topic of “Third time lucky for MES” I received a lot of both email and discussion face to face, this blog expands on the topic.

The first comment from many people was “that MES has been around for years and has been implemented successfully”, and I agree, but the first 2 generation architectures involved significant services while they have run extremely well for a number of years, but with limited ability to absorb change without significant cost and risk. Also, companies are expanding in multi sites and the requirement to enforce operational practices over multiple sites, again this requires alignment of sites. So yes MES has been successful in concept, but not in a sustaining mechanism.

Charlie’s comment in “The MOM Chronicles” reflects this:

“The first two MOM attempts occurred in the 1990s, and 2000s, actually were also found a primary hindrance to continuous improvement efforts because the MOM system owners were typically understaffed, under skilled, and un governed to support real innovation. “

So what is different this time? Was a common question, as mentioned in the original blog the SOA (service Orientated Architecture) actually been adopted correctly with conforming service contracts at the ERP side and business side with the “Enterprise Service Buses” (ESB) becoming a norm, not just a term. This flowing down into the operational world with vendors looking at aligning with web services, but also model centric alignment vs point integration is key. The figure below taken from “The MOM Chronicles” illustrates the concept:

The experience we have MES implementations at Invensys has pushed us to evolve our architecture, and the key areas are:

1/ The MES functional Capability has evolved in richness

2/ The plant events are now linked into the System Platform, using templates so now plant equipment and events can be templates and managed, also validation is achieved as close to source as possible.

3/ The Human interaction and the business rules and processes are no long programmed they are implemented in a model driven (workflow) environment. So now face plates/ forms that present information and interact with humans validate the data entry as early as possible and with no code but in graphical modeling environments. This area alone is transformational as I have sat down with process/ operational teams with these graphical workflows and worked through with them relative to their process, we mark up the diagram and implement fast. No longer programmers are involved in business rules it is the operational/ business / process teams work know their rules and behaviors they require and they implement.

The diagram below shows the realization of the aspects of the Invensys MES architecture, and it is all three aspects that make this a sustainable solution, that scale, and also work in a multiple site situation. But most of all it is agile aware been able to absorb change.  Again this is a different approach to tradition MES solutions which have at MES Functionality, but honestly depended on coding around the system for events, human interaction and business rules. This architecture is SOA so it is plug and play and services like the MES can run in different locations, leaving open the opportunity for MES data bases and rules to run in an elastic “cloud”, combining with the on premise interactions with the plants and people.

 

Manufacturing 2.0 what is it?

If you have been watching AMR now Gartner for the past 3 years they introduced the concepts of “Manufacturing 2.0", which looked at where manufacturing and industrial architectures could go. Many of the concepts were not new, but they did a good job showing a whole picture and the components needed to make this architecture real. Too often you get a concept thrown forward but it is only part of what is required, and people miss the whole picture.

But this concept of Manufacturing 2.0 has been picked up by MESA in their push on educating the market, and they now run certification courses on the concept of Manufacturing 2.0. These courses are good for hybrid, discrete and process companies and system integrators, even if you have been doing MES for years you will learn techniques and concepts.

The diagram below shows two levels of Manufacturing 2.0, one from the enterprise level, where the manufacturing is fitting into a corporate SOA architecture. Down in the bottom right hand corner is “manufacturing”, now the second diagram drills into the next level, showing a real SOA architecture in industrial landscape.

I was having dinner Gerhard Greeff last week who trains the MESA courses on Manufacturing 2.0. I have known Gerhard a couple years he has written some good papers on the topic, (especially one titled “When was the last time you saw your MOM?”) and it is always rewarding debating concepts, and validating many of the areas we working on.

Some key points we discussed what they call the Manufacturing Service Bus, and our proposal and work around what we developing called the ArchestrA Service Bus, which is a true web service bus, for the industrial landscape. This is currently going into beta and will be released in it' s initial form with data services in the System Platform 2012R2 releases due at the end of the year. The data services will be just an inherent component/ function of the ArchestrA infrastructure extending it to enterprise and multi-site. A first step to what we refer to as ArchestrA 2.0 our new evolution of the core technology and architecture of system that will go to enterprise.

You can think of ArchestrA 1.0 as unifying the plant, and ArchestrA 2.0 as unifying the industrial enterprise, which is where many companies are coming to. Allow multiple plants to become “loosely coupled but aligned", with standards driven over the sites, yet the uniqueness, individualism of the sites is sustained. Too many companies say they are SOA, but it is key to using true services, that have defined contracts, that will be sustained through changes of technology and versions. As we move towards Federation of more than automation systems but other applications and multiple sites that implemented differently the ability align, and relate data models through standard contracts will be key.

The challenge I have with “Manufacturing 2.0” being rolled out is that there is not an “off the shelf “ sustainable solution to achieve the goal. Because the other main goal required beyond aligned federation is to have solutions that are sustainable “limit custom code”. Can you build services YES, but it is key to build them into your architecture and culture to make them sustainable, that is why we working on many evolutions to achieve Federation in a sustainable manner. Let’s discuss this over the next couple of weeks.