Finally a clear explanation of what MES is!

I was browsing the blogshpere and came across this post explaining what MES is in real world terms. Since Gartner has now coined MES as MOM the author of this blog uses an analogy with mom (as in mother) to explain what MES is. I think this is a great way to explain the very complicated domain in simple terms. This is also what I tried to do in the my previous "What is it that I do" post.

Here is an excerpt:

 An MES system is:

Software (mom’s brain)

That connects to multiple plant and business systems (spouse, children, school, work, home)

Collects relevant data (children’s and spouse’s schedules; play dates; doctor’s appointments; clothing and shoe sizes of every family member; contents of pantry and refrigerator; supplies needed for school/daycare; immunizations required; daily intake of children’s fruits and vegetables; recommendations on pediatric dentists; educating oneself about any number of topics, not to exclude best techniques for discipline, potty training and how to get your child to broccoli; birthdays; anniversaries; dates of holiday family gatherings on both sides; … uh, not to mention everything required for any work that’s outside the home)

And presents it as easy-to-understand, real-time intelligence (may exist in rudimentary lists, a calendar, or electronic planner, but probably all three; also, constant verbal communication to tell spouse and children everything that needs to be done)

For productivity analysis, data mining, querying and reporting (to coordinate activities and process information in the most succinct and orderly way possible so mom, spouse and children can make the best decisions and achieve optimum life satisfaction and achievement)

The blog is named "On the Night You were Born" and I could not find the name of the blog's owner, but I have to extend out thanks from the MES/MOM community. All that remains is counter with a DAD system explanation.

What is a Manufacturing System - Part I

This is a post that is long overdue. A central discussion topic on this blog is Manufacturing Systems and I have not yet really explained what I mean by a Manufacturing System. I have talked about manufacturing system that are agile and Holonic, so it is about time that I posted a more practical or at least clear description of what I mean.

Most definitions of Manufacturing System are focused on describing a solution, or more precisely the functionality and architecture of a Manufacturing System solution. For example the MESA model presents number of functional categories from a business perspective, where as the ISA-95 (S-95) model provides a solution architecture based on functional decomposition. All these are of course relevant and useful yet it seems that the problem only interesting to academia – try to Google it. It is assumed that we in industry all know what it is – a dangerous proposition to have.

We all agree that the key to a successful deployment of a Manufacturing System is the understanding of the problem that it is designed to solve. This obviously not a novel approach – it is what everybody attempts to do with the system’s requirement or URS. Yet my experience shows that even in the requirement phase many resort to using the existing models, thus reverting to describe the problem with the solution itself. Quite confusing isn’t it?

So here is my take on what a Manufacturing System is, or in other words the Shop Floor Management Problem. I like to describe it as the problem of integrating 3 important flows in a manufacturing organization. The 2 vertical flows provide Product and Logistical information while the horizontal flow is the physical flow of material, equipment and people.

The Shop Floor Management problem is therefore: How to make use of the information provided by the Product and Logistical flow to efficiently and effectively manage the physical flow of Resources and Materials (also known as the production process). Simple isn’t it - that is what a Manufacturing System is designed to do. Try to imagine a seasoned and effective production supervisor or plant manager – the Shop Floor Management problem is very close to his real life job duties.

It is obviously not that simple and there is of course much more detail that is yet to be discussed. I plan to provide some of this in upcoming posts (hence this post is named Part I). Also this is not meant to take away from the importance and complexity of product development, process engineering, operations, and planning. It is a model that is focused on explaining the particulars of managing a shop floor (yes this is my disclaimer).

More detail to come in future posts…

"Lean technology" a Manufacturing Systems perspective

My colleagues and I are in the process of preparing an educational session that will be held at the ISPE annual event in November. So as usual I spend some time looking through my archives for relevant material that I already have – I call it 're-cycling' :-). This time I came across something that I never published or used and so I thought I would share it here. It is an attempt to explore the synergies of the Lean and Manufacturing Systems concepts. Read and tell me what you think…

Manufacturing Technology; A familiar phrase considered part of the everyday vocabulary. What about Lean Technology? Not a common phrase, but the idea of lean manufacturing supported through technology should be as much a part of the vocabulary as Manufacturing Technology. Lean thinking advocates simplification of manufacturing units so they can be more easily shifted to enable the flow of value. So in essence the “lean technology” concept supplements lean thinking by combining state-of-the-art manufacturing with advanced software systems in an integrated environment.

Using information systems in lean manufacturing is not a new concept, nor is it new to the lean movement. Many examples exist that prove that manufacturing (software) system can support a lean organization. Unfortunately most commonly information technology systems for manufacturing tend to become large monolithic systems of great complexity. They are designed to provide generic functionality to fit major industry verticals that can be configured specifically for each implementation. At the same time the uniqueness and the complexities of the specific manufacturing operations make the ability to only configure these solutions more a myth than reality. Most of the system vendors will of course argue against this - however the reality is that in order to meet the requirements of the manufacturing businesses they are forced to implement complex customizations. That is what I wrote on my post about Customize or Compromise.

Although lean thinking advocates the application of a set of specific common concepts, the actual implementation of these concepts in real life tends to be unique to each production line and plant. Information systems that are used to support these lean lines and plants have to be able to provide common functionality to support these concepts. Yet, they also have to be able to support the uniqueness of each implementation. Furthermore they need to be able to support the changes that are inherent in a lean system due to the continuous improvements as they are accomplished.

In summary here is my suggestion for the general functionality of a Manufacturing System that can support a Lean manufacturing environment. (BTW I know that these go against the grain by not using a problem-oriented approach – I will have to redefine this ASAP)

• Value stream: We all know that value is identified by the specific needs of the customer hence the Manufacturing System should be usable and implementable to support only these specific processes that add value. In other words the system once implemented should not require or be constrained to use extra processes or involves extra steps if they are not directly part of the value flow.
• Implement flow: The Manufacturing System should employ a value centric process model that is easily managed and accessible to all the relevant people. This will allow a transparent view of the value flow and thus allow engineers and operators to ensure production flow, be it a one-piece flow, supermarkets, or other relevant Lean solutions.
• Execute Pull: This is kind of the obvious requirement that involves the enablement of pull execution and dispatching of WIP. This may include features and functionality to enable or enforce flow and managing kanbans, supermarkets, balancing, etc.
• Enable Perfection: Enable perfection by providing the production and process visibility needed for the continuous improvement efforts. This is the part of the system that provides Intelligence (a topic that I have written a few relevant posts about). In addition the Manufacturing System should provide adequate configurability, extendibility and customizability that support continuous improvement.

Using metrics and what it tells us about Manufacturing Intelligence

In continuation to some of the other posts in the topic of metrics and KPIs, this time I would like to discuss the use of metrics. So, not so much what the metrics are or which metrics are most important, but how do we use them. If we look at how analysis is performed we may be able to gain some insight into how the data should be collected and structured. This may be for example to support lean or process improvement initiatives. The idea regardless of methodology requires that the team or person gain an understanding of the process and its behaviour based on the data at hand.

I think the best way to frame this up is to tell the story of a persona in a simple scenario. Let’s consider Patrick Process Engineer who is trying to understand yield fluctuations specifically and maybe the yield’s behaviour in general. He is perplexed about why he cannot accurately predict yield given that most of the processes are “in control” (yes, another one of these myths about processes). What he really is striving for is an understanding the process and the best way to investigate it – in other words analyze the process.

Obviously Patrick will be looking at the Yield metric(s) and once he sees some fluctuation he will embark on an analysis. Typically he will perform what I call a high-level analysis, which is kind of a “look-around” in the data and maybe other related metrics to determine patterns. But wait, why patterns. Well whether we like it or not when we analyze processes we naturally look for patterns since that is what complex processes really exhibit. I guess I need to write a bit more about the complex adaptive behavior of manufacturing systems, but let me leave that for a future post. For now let’s just say that the patterns really tell us about the dependencies between the different metrics and parameters in the system.

OK, once Patrick has performed is “high-level” analysis he may then start digging a bit deeper in to some of the areas that may lead him to the root-cause of the fluctuation. He may perform some more detailed analysis, maybe choose to monitor some specific metrics, define some additional more detail or focused metrics. If he really is trying some advanced analysis he may try and observe dependencies between metrics for a period of time. That means monitor maybe a few metrics and how they change in relation to each other.

What is described here is really a simple scenario of human behavior exhibited when we perform troubleshooting. Although this as simple behavior for us, when we think about the data and data structures that we need to support what Patrick is trying to do, we may quickly realize that the complexity abounds. Modern business intelligence concepts such as multidimensional analysis, OLAP, and practices for data aggregation provide the tools. However it takes a lot of work and process knowledge to transform the base process data to such information structures.

This I believe is the main challenge in modern manufacturing systems. Compounding this problem is that effective analysis needs to use information from all the host of system that may reside in a manufacturing business, i.e. ERP, MES, Automation, Historians, LIMS and others. Most manufacturing intelligence tools that are in the market today simply do not address this simple scenario. If we do our inbound marketing work correctly and draw up the scenarios above, with Patrick our main persona, the problem definition is straightforward; however the engineering task required to solve it is not.

Inbound and Outbound Marketing according to Pragmatic Marketing

This may be redundant information but I wanted to make sure that it is persisted somewhere for reference. It is really a summarized version of some of the teachings from Pragmatic Marketing.

Inbound Marketing

Understanding of the markets that are targeted by the company's/products' "distinctive competencies". The idea is to gain unequivocal understanding of the market, the people working in this market, and specifically the problems that they have. The goal is to provide product features that directly solve the problems in the market. In order to do that the product management activities are focused on defining and prioritizing these problems and conveying them to the product development as market requirements. The driving concept is that a product (and its features) need to do a job for the customer. For example: Online bill pay. the job is to pay bills, if you did not have this capabilities you would have to do it manually which is time consuming and tedious. Therefore it is a Market Oriented feature it solves a distinct problem for the customer.

Outbound Marketing

These activities involve the positioning and messaging of the product. It involves traditional marketing as well as what is now widely adopted "the new rules of marketing" using the internet as the main conduit. Using "viral marketing", new media, blogs and eBooks are some of the methods. The goal of all of these activities is to generate demand and leads that can be turned into license revenue by the sales team. One of the methods to expose the products to the market is using a concept called  "Marketecture". The idea is to describe the product (and its features) to the market not by its technical functionality, but by the problems that it solves for the users. In other words it is a market oriented description of the product that is developed as a result of the "Inbound" activities.