Manufacturing Execution Systems (MES) have been the focus of manufacturers for over 10 years in their desire to achieve greater automation and visibility to the plant floor operations. While the original MES promise was a bold one in defining capabilities for managing the execution of every element on the manufacturing shop floor, this promise has had challenges in becoming a reality and few successful examples exist.
The Myth of MES
Manufacturing Enterprise Solutions Association (MESA) introduced some structure by defining 11 functions that set the scope of MES. In 2000, the ANSI/ISA-95 standard merged this model with the Purdue Reference Model (PRM).
The intent was to provide more real-time visibility to plant floor operations and define processes and methods for the day-to-day execution of product orders and maintain the equipment and environment where they are produced.
This required a collective view of data typically coming from different Level 2 systems as well as a method of directing machine operations at Level 1. But it also required higher level processes for maintenance, scheduling & dispatching orders, quality management, and reporting.
Gathering detailed information from the production machine provides the specific build elements of the product, i.e., what pressures, dimensions, tolerances, etc. that were used to build the product. This information linked to the actual finished product provided some valuable data regarding defect management in the form of traceability.
The process elements were more challenging as the functional needs vary between departments, and a mature process may have existed. For instance, computerized maintenance management systems (CMMS) were quite mature, as they provided:
- better methods for managing the equipment reliability
- visualization solutions that presented data better
- quality management systems (QMS) that held more specific functions for managing variance, etc.
Where MES Went Wrong
With MES, the attempt to be "all things" was probably a set up from the start.
Product traceability is where MES started and it's where MES got stuck. The appeal of MES is that if you find a defect in a product and identify the contributing setting or value, you can easily trace the history of how that product was built.
This helps you find other parts produced with that same setting or value. With the ability to trace data, you can more easily quarantine product and find detective parts.
The goal was to get traceability in place and then move toward recipe management. Recipe management refers to the ability to configure the machine to build products in an automated fashion. For example, you get an order in for a model part and tell the machine how to configure itself to build those parts by setting the correct parameters.
Recipe management is the holy grail of MES...but MES never really matured to be the answer because integrating equipment is no small task. The complexity of PLC programming both from the machine level instruction and for the skill required by engineering staff set a very high threshold that many manufacturers couldn't overcome.
MES: Traceability vs. Recipe Management
Comparatively, traceability is easier. It's one-way management. Recipe management is on another level of programmatic complexity and requires two-way management, as well as information management regarding the specifics of the part or product to produce. To implement recipe management, one would need:
- to understand the PLC and how to get it to interface with MES for each of the disparate machines & models.
- astorage and publishing method for the bill-of-materials and machine settings required.
- control plans for validation that finished product conforms to the desired standard.
- a considerable understanding of programming languages, which have gotten more sophisticated (and each manufacturer has their own unique behaviors).
As a result, plants may try to build their own MES, but that may still pose too many hurdles to achieving success.
Buying vs. Building Your MES
Most manufacturing floors leverage a number of disparate applications to achieve production. Expecting one system to provide all the competencies required in supporting disparate functions (maintenance, production control, scheduling, cost reporting, etc.) is a tall order. The specific requirements of each function require function-specific processes and information.
This is a very broad list of features, and MES doesn't do maintenance management well. Most don't even do product management well. And very few have scheduling capabilities.
Whether you buy or build, MES requires significant customization. That process is expensive and laborious, and knowing what feature behavior will work is hard to determine.
If you have an engineer who has a reasonable grasp of higher level programming languages like Python/Java and relational databases, you might attempt creating your own MES to align with the business requirements. After all, you know your environment and your equipment.
BUT this also requires school and training in how to develop using code and practices on error handling, code standards and source code controls to assure it can be debugged and maintained once built.
Enterprise MES solutions may seem to be an alternative. If you go for an industry solution like SAP or PRISMO, you still have to customize the crap out of it as they don't come ready to run. But because these have wizards that make things easier to build, this is a little easier than building an MES from scratch.
As enterprise solutions, expertise exists within the vendor to provide assistance in configuring or customizing. Support for the customization and platform are available in support contracts.
To Buy or to Build?
In both cases (whether learning to build code yourself or buying an enterprise solution), the primary hidden risk is code maintenance. Once built, this application will of course require maintenance (bug fixes) and support (i.e., when a feature doesn't work in a specific situation).
The result is increasing code debt. "Code debt" is code that is not under regular maintenance, and it is an escalating risk to the business. This occurs with customization of enterprise software just as much as writing code.
Code debt is a very real and risky thing for companies. This risk comes in the form of future risk to the business. What happens when the person who wrote it leaves the company or moves to a different role? When the vendor releases a new version, what customization will be able to port vs. have to be rewritten?
The Problem(s) with Building Your MES
People began building their own MESs because they were't available. MES solutions have only surfaced in commercial offerings over the past 10 years or so, but manufacturing automation goes back to the 90's and before.
Unlike areas such as finance (ERP) or maintenance (CMMS), where mature solutions exist, there was no where to turn.
You may be tempted to just build your own, but building your own MES poses several challenges:
Code Maintenance. An engineer goes and writes their own MES. It sounds like we've written this awesome custom solution, but we rarely consider what it will take to maintain the code (i.e., many hours and a whole lot of dedication). Scaling such solutions to other areas or plants is often not considered, so the working MES at one plant has no way of deploying to other plants.
Theory vs. Application. Plant engineering teams may understand their environment, but they don't know what they don't know. So, they actually don't know whether what they think will work is going to work in the real world or meet the business requirement. Experience in building and delivering MES is required, as well as experience in building applications people use.
The Cost of Uncertainty. The pitfalls come quickly and continue to surface along the long road of internal development as the internal authors & coders discover what they thought was right won't work. This can make internal development much more expensive and certainly unpredictable regarding expected delivery of a solution or in expected results.
Changing Roles. Engineers in that role tend to change jobs and leave as well. Now who really knows how it works? Was it well documented? Where is the source code? What code components required licencing? Those who remain don't understand how the program was built and it works and struggle to support any changes, fix it when it breaks or understand where to go to add new features.
The Problem(s) with Buying Your MES
The danger of losing your system's expert is less present if you go with a more standard industry solution like SAP or DELMIA Apriso, but expertise in the application is still required for success.
You may have a number of resources in the market that can decipher the code and figure out how to support you BUT:
- your unique environment and customization is still specific to you.
- this gets very expensive when you have to bring in the vendor to make changes or updates.
- there is still significant code debt that requires maintenance and support.
In fact, even with an industry solution you still have to spend a ton of money on custom code. The cost of upgrading that system can be horrific because all custom code has to be ported to new version. Vendors may suggest that using their tool to create the customization means you're safe in an upgrade, but the methods are too extensive to test and each customer becomes it's own test bed.
Industries where compliance must be maintained require full testing and verification on all elements to assure both data integrity is preserved as well as access and audit details are preserved.
MES was never able to fulfill its lofty promises of recipe management and becoming "one system to rule them all." In fact, MES today are often a source of frustration and unnecessary cost for manufacturers. Stay tuned for part two of Why Your Mes Doesn't Justify the Expense, where we'll address how to evaluate the true cost of an MES and the secret to circumventing almost all of those costs.