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.

How do you Achieve Orchestration in Industrial Internet of Things without Managed Configurations and Standards?

Last week I was at mining conference and had a rare chance to sit back and listen to people’s thoughts on innovation, and the future. It was good to hear the topics of partnership are key to innovation, (relating to my blog of a month “Participation architecture and culture key to Innovation”).

As expected the “internet of things” came up a lot, in many contexts, like it did at the Dairy conference the week before. With this cam the usual many definitions of IOT and the impact it will have on the mining industry. I just wondered how many people really comprehend the value, and complexity that it brings?

One evening I was on call with France with a partner discussing smart cities and IOT and he made the interesting comment:

“The Internet of Things has moved beyond big data and analysis to how will we align the devices and people into an orchestrated operational strategy that achieves a repeatable agile outcomes.”

I sat back with a big smile as he had articulated the change I had been seeing. As decisions and data is nice but it must go from data, information, knowledge to wisdom where actions can be taken, no matter if that action is taken by a device, or human.

Then I saw this categories of maturity in the internet of things, I had seen something similar but in a week of much discussion on this topic I thought this one would do. It shows devices going from a data sources with intelligent data / I hope actually Information. Evolving to control of devices in orchestrated way, no matter if the control is in the thing or in cloud the things know how to work together in a coordinated strategy. Once you have all the things working together you can move to tuning their operational behavior and effectiveness. This seems simple but things require access to control strategies, and orchestrations that guide these things, now we talking 100s to 1000s of things in this coordinated community. Eventually you end up autonomy or semi autonomy “managed by exception”.

In another discussion with a large network hardware supplier we were discussing a mining extraction alignment solution that could be enabled by IOT unlike today. So we took a practical look at the application, and saw 10s of like machines and a few classes of machines. Then you look at the operational processes they executing and again see repetition, but we are now talking 1000s look at devices.  Yet we had a customer wanting achieve level 3 in the above model “Optimization”. I thought back to many industrial sites I have been on in the last few years where there are 10s of PLCs programmed with larger control strategies but programmed at different times and by different people (even if from the same vendor) and how customers were having a significant cost of ownership in evolving these strategies. This why organizations like OMAC and PACKML have come about defining standard control strategies for operations/ devices that could span vendors.

So I ended back at my conflict, as we move to landscape where we will have 1000s of devices often smaller than traditional PLCs but each with their own monitoring, or control strategies, and then high level strategies that enable the orchestration of these devices/ things into a an effective operational strategy.

I asked how are we going sustain and evolve these strategies without having an “Enterprise Standards Management Framework” that enable standards to built for an operation? These are then deployed over 100s of similar operations on different devices. Now we shifted to managed, agile and sustainable solution.  

The thought of 100s of people programming 1000s of devices and then trying tune and evolve these seems un practical, plus if we enable standards management the reuse of IP and rapid rollout is achieved, while leveraging the revolution to smart devices and lower cost devices that execute these strategies.

A food for thought!!!!!

Industrial Ethernet/ “Internet of Things” Is it About putting Data in the Cloud? Or Interactivity?

Sorry for missing last week, time seems short when on the road with short flights.

As I fly the final leg home after a month on the road many brainstorming multi day workshops around different strategic thinking, but without a doubt the “Internet of Things’ applied in industrial/ manufacturing space brought up many ideas and many questions.

Certainly the discussion of “Cloud” vs “Internet of things” is it about getting to data from all types of devices and making that more available? Certainly that is one case, but certainly it is not a compelling case.

The “Internet of things” is about self-configuring devices, these could instruments, motors trucks, and mobile devices, fixed and roaming devices. Too many of you the IOT definition I believed was clear, but the workshops showed the confusion between taking and existing industrial application to the “Cloud” connecting through safe but tradition device integration paradigms, vs an interactive “self-configuring” environment of devices and systems, that is a new device integration, management paradigm.

Also, it is important to note it is not just about gathering data from devices to the cloud, and exposing it, the real opportunity comes in the interaction between devices, that the environment make the devices “self-aware” and able to interact. A natural example is that mobile devices of a roaming user is interacting with the other devices in the immediate area. Enabling interacting, and constant awareness and warnings of the current environment state, relative to a stability, and safety. Combine this with ever increasing transformation to managing Operational work vs monitoring, where the “work” or “activity” includes the information, action in the context of “activity”.

The fact that a device is now “self-configuring”, so you can from an IOT system “discover” the devices out there and configure the co-ordination system in the cloud, making other systems aware of them. This is a clear case for segments that are physically distributed such as cities, airports, upstream gas fields, mining, pipelines etc. Where the cost of aligning the devices has been too expensive, now with wireless but even more 4G networks like we seeing in the remote “Pilbara” region on Western Australia, the opportunity for plug and play devices that are “edge/ GPRS” enabled, and IOT enabled can be discovered, configured and aligned. As devices are swapped in and out no matter site the size, the configuration moves from an instrumentation job to anyone. This frictionless experience is key in configuration/ and sustaining. The increased speed of systems, decisions and agility required drives up complexity of systems, but this cannot drive up lifecycle cost, and this can only go away through Self Configuration, enablement of anyone to enable the system to run, this become clear as the key requirement of the IOT.

The chart below shows the expected industry segments to adopt, many are well engaged.

But why is there a slow take up, mainly I believe to unawareness, lack of understanding, and readiness? But this is changing, the IOT platforms are coming on to the market that will drive down the cost of achieving IOT, but it will still be a journey. The diagram below shows from one of the workshops the key challenges in adoption, I expect these to fall away fast over the next 2 to 3 years. I cannot see how we going achieve the agility, with the dynamic market, operational workforce at a sustainable cost that is reasonable without this paradigm shift, to IOT as interactive landscape. In the many sessions I held with end users, engineers and people across the company and industry, the real initial opportunity is not in the big plants it is in the “collaborative Industrial Landscape” of small plants and assets aligning with people and processes.

 Certainly the interest, like cloud is growing, and the infrastructure is maturing that this will be reality in helping to addressing the modern industrial landscape challengers in a very different landscape than we had in 90s, 2000s, and 2010s, I will discuss more on this fundamental event next week.

Why SOA in industrial/ manufacturing space?

This is a question I have heard a lot, I have also heard SOA been thrown about in  Industrial market limited real understanding of the potential value.

So this week to add to the discussion I have included an extraction from “When last did you revisit your MOM?” By Gerhard Greeff – Divisional Manager at Bytes Systems Integration

“You may think that the SOA concept applied to manufacturing is outrageous and that it will never work. After-all, you have talked to the Enterprise Architects and they just don’t get the complexities of the manufacturing environment. But before you skip this section, do yourself a favour and read what SOA actually does according to Gartner and MESA and then think how you can apply that to manufacturing and MOM specifically.

A number of companies (including manufacturing companies) have implemented Enterprise Service Bus’s (ESB’s) specifically to ease integration. These ESB architectures have not however made their way down into manufacturing itself, and with good reason. The enterprise layer (level 4) and the manufacturing layer (level 3) are not the same, don’t work the same and have completely different priorities, data types and business processes. Only a fraction of manufacturing process data make its way up to the enterprise level and then typically only in aggregated form. A lot of manufacturing process data however is shared within levels 1 to 3.

MESA for instance states, “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. The MSB may be scaled down to a plant or an area of a plant or across multiple production facilities depending on the transaction/data load and response requirements of the operations workflows being supported by the plant applications.””

These comments I agree with, and the more you look and investigate what the leading thought leaders in industrial companies they are trying to solve this massive challenge of inter-operability at level 1 to 3 and horizontally across these levels. But unlike level 4 there will not be domination of one system, or a few, there are just too many specialities. The challenge is also the criticality to life, and operations, that these different systems cannot evolve at the same pace. As explained above SOA provides a infra-structure that allows this alignment, but at an evolutionary approach.  But the critical item is that services need to abide by the service structure, so they align, so others implementing that contract/ service can consume or contribute to that inter-operability. The concept of a separate Service Bus for the industrial sector is correct, when you look at the determinism, and performance needed. But can a service bus perform as we come to trust in this market. I am pleased say Invensys has been working down this service bus for the industrial market and before the end of year will release a true service bus that performances as we expect or are use too. But this is only an initial step on this road, as we move into this “federation” vs replace mode and look at the real opportunity we have when we align the assets, people, systems and applications especially horizontally at level 2, and 3.

“SOA architecture allows for the creation of composite business applications from independent, self-describing and interchangeable code modules called “services.” These services are available for use on a services bus and can be arranged into a business process or a composite application using process choreography. When SOA is employed as an integration strategy, it brings about a catalogue of self-describing, atomic business services that are used together to create a business process (including manufacturing operations process).