Help Operators move from “Coping” to beyond “Optimizing”

This is a great blog from Stan DeVries, really opening some of the challenge thinking.

"A recent meeting with a customer discussed the best practices for centralized control rooms and integrated operations centers.  They summarized 4 levels of operator performance:

•         Coping
•          Aligning
•          Optimizing
•          Stretching

While the focus of the meeting was on optimizing, the customer pointed out that we must enable the newer operators who begin by “coping”.  It is worthwhile to consider the differences between these 4 levels:

•         Coping requires high concentration on operations activity and events, where the operator has little flexibility to adapt to teamwork with other operators.  The operator has been qualified to work in a centralized control room or integrated operations center, but they have difficulty to maintain pace.
•   Aligning requires moderate concentration, where the operator can safely and reliably adapt to most of the teamwork activity, but reaching team targets is still difficult, such as value chain efficiency or throughput.
•   Optimizing requires a different type of concentration, where the operator has learned how to cope and how to align, but now the operator focuses on achieving the team targets, and the targets change periodically – in some industries (e.g. power generation and natural gas liquids processing) the targets change every 15 minutes.
•   Stretching is achieved by “error free” operators who have learned how to beat the optimization targets.

The key question is how can operators achieve and sustain best performance?  A quick answer is more training, but too often the training paradigm isn’t adequate.  Best practices have shown that the effective method is treating the targets like a game, and applying newer visualization to support it.  Before we look at any example of a “game” or possible visualization, we need to consider the innovation in the training approach:

•          Training becomes holistic – the students learn about how to perform in team settings
•          Training moves beyond the classroom – classroom training is essential, but structured on-         the-job training becomes very important
•          Operator performance becomes less “private” – team performance is visible and shared.

So what can the new training experience feel like?  Consider an example which has been published in regional industry conferences, where the initial focus was optimizing energy across multiple sites and all operating shifts:

The dark blue diamonds is hourly efficiency performance over a wide range of throughput, across all sites and all shifts.  The magenta squares are the result of one month of teamwork, and the yellow triangles are the results after two months.  Please observe a few key characteristics of this experience:

• Very dynamic operating conditions
• “Blind” presentation – operator names are not shown
• Graphical context – instead of bar or gauge displays, operators see how their performance compares with others.

The operator is given other detailed displays both during training and for normal operation, but the exercise is focused on teamwork.  Consider the significant improvement in the above displays."

Top 10 Manufacturing Operations Blogs for 2014

Many of you probably already are subscribed to MOM blogs, but just in case you not I though these top 10 showed some interesting thoughts.


http://cerasis.com/2014/12/22/top-10-manufacturing-blog-posts-2014/


On my blog the two topics which had a number of blog posts, but had highest hits were around:

1/ Situational Awareness , and change in the way we must design based upon impact
2/ Internet of Things and Cloud.

Interesting the year before cloud and internet of things created very little interest, but this aligns with significant growth in interest in these topics in 2014, and will only grow further into solid reality in 2015.
Enjoy 

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.

 

Third Time Lucky for MOM/ MES Architectures?

For the last 15 to 20 years companies have implemented MES (Manufacturing Execution System)  systems, and MOM (Manufacturing Operations Management) systems, remembering MOM is a super set of MES. These implementations executions have been both custom, and using off the shelf applications for MES, and success has varied, but even the successful ones are struggling to evolve to current agile requirements due to the method of implementation. One end user asked me on the flight “has MES been successful?”, I stepped back and thought about a couple customs who have implemented end to end MES. Based on one MES system so that manufacturing master data is managed by one system, with the customer stating their MES has been the most valuable software implementation on the plants, it just works and is the heart of their manufacturing. So the answer is yes, but the fact of the question allowed me to reflect on the normal bumpy roads MES implementations have had.

I was read Charlie Gifford’s latest book “The MES Chronicles” (ISA 95 best practices book 3.0), which has a set of articles around Gartners’ Manufacturing 2.0, explaining the concepts, and reality to the concepts. It is well worth the read if you are looking at the industrial/ manufacturing operations space.

 

 

In the introduction,  Charlie does an excellent job raising the challenges of MES, and the fact that we now with Manufacturing 2.0 going through actually the third architectural attempt at MES. How true his comments are when I reflect on my own career which had gone through all 3 since 1995 when we released InTrack (original MES Product).  A key consideration to this discussion is that MES is a concept of managing the executing the manufacturing, with the off the shelf solutions and customer systems built for a particular industry  with rules and practices for that industry. So looking at Invensys’s first generation MES system InTrack it was built for the semi conductor/ electronic industry, and the outstanding success stories I referred to were from that industry. Invensys’s second generation product built Wonderware MES for food and Beverage industry, and again has worked remarkably well in that industry and related industries. This does not mean they cannot be applied in other industries, but the “glove fits well”. That is why I do not like the generalization of MES, we should categorizing them by industry types, to help selection, and stop companies force fitting the wrong models into their practices.

Charlie in his book reflected on the three generations of MES/ MOM as:

“20% of advanced manufacturers discovered that the first two MOM attempts lead to:

• High cost MOM systems with extremely poor data integrity
• High cost change during new production introductions, production scaling time to market and continuous improvement.”

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

His % might be low, but the point is that MES / MOM solutions have typically been architected in a “point to point” / application integration, with high levels of customization restricting evolution to the original developer. Many of the original InTrack MES implementations have maintained the database well, and the rules within it, but significant custom code has been developed for human interaction and data validation, and data validation on automated events acting on the system.  Like highly customized ERP implementations the ability to evolve , upgrade the systems become an anchor on manufacturing agility. Yet that is the reason why people put these systems to increase efficiency and consistency of production, but the issue is manufacturing practices, new product introduction is constantly changing and evolving, and the systems must be able to absorb this change naturally if the implementation are going to allow for the required agility needed today.

So the third attempt at MOM with the Manufacturing 2.0 concepts undoubtedly lead to:

·         An SOA (service orientated Architecture) that allows plug and play of the 15 to 20 Operational applications required to run a plant, allow the inter-operability to set up using messages through sustained services vs application integration.

·         This integration is a model based using tools such as workflow and sustainable environment.

·         Validation and data entry rules will be model driven, so that embedded best practices, that can evolve in a sustainable way as staff evolve in the organization.

·         Semantic information, and data management models based on proven models such as ISA 95 will enable existing and different models of the different operational applications to align.

The book outlines many of the concepts. MES are not a standalone product, it is  an architecture that merges level 2 events from automation, with validation of data, events in a structure asset/ operations model that can interact with the different operational applications through the life of a manufacturing operation. Key is the acceptance of  architecture which has model driven interoperability (so the model can evolve with governance) and the introduction of workflow to be a natural part of the operational system to capture the procedures as embedded operations that again have governance so can evolve as the practices of the plants change. Like successful ERP implementation, customization must be avoided, configuration within the tools provided make the system sustainable, but this will be a mind shift for people. Too often people talk about APIs, and taking coding tools to build a solution, this is fine for the short term, but will come back and bite when time for change and evolution. The project and program owners at the end users need to take a more holistic view and enforce an architectural cadence of configuration vs programing and making sure the “human to application”, and “application  to application” integration are model centric approach where configured services  using workflow configuration is key.

 

 

Can Sustainable Manufacturing Operations Management Exist without Master Data Management? NO,

Again last week the discussion of operational integration raged in few project discussions with customers, without really understanding the arguments and I needed to pull out a log from mid last year on Operational Data Management. Data Model Alignment will be key in a viable interoperability architecture for level 3 applications with out “rip and replace approach” in making Manufacturing Operations Management sustainable and effective.    

Synching 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. So the concept of Master Data Management (MDM) for Industry is a hidden one, but we believe is a key one for the future of sustainable solutions that are federating multiple systems together, so expect to see investments and products to trying to address this. In this blog I want to have a discussion on why MDM what it is, and Gerhard has done a good job, and I will expand on it.

 

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. The same issue of naming happens with Assets between the Alarming system, MES system, Batch System, and EAM system for example. The capacity or size of a asset(Eg Tank) is key to their operations but often changes are made to the actual asset and then say the EAM and alarming systems are updated but the others are not realized, and the plant starts up with half the systems updated. Yes now you get faults and plant delays, and trouble shooting. Imagine having a system that is aware of all the systems that are modeling an aspect of that asset in their data models, now you can have a “master change management” over it been changed at one location and making sure it is changed at all systems prior to start up, even if updates are manual.

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 routings 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 parochial 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 resources, utilities, equipment, operating parameters, recipes, WIP and products. 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.

Figure blow shows the relation between mMDM, MDM, SOA and SOAm and how they are meant to operate together.

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 SOAm 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 SOAm 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 SAOm will enable interface re-use.

ISA-95 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. “

Why not a central directory “Yellow Pages” that manages this relationship without replication????