MES: take the time upfront

Businesses have been touting the financial benefits of manufacturing execution systems (MES) software ever since it became available in the early 1990s. Unfortunately, MES has followed a path similar to that of enterprise resource planning (ERP), meaning that many early implementations did not reach their promised goals.

Claimed benefits of MES such as immediate 10% reductions in work-in-process and inventory costs, and ROIs of a year, were all within reach, but the systems never produced.

These third-party systems were all-in-one or multi-module packages based around a central database with a complex schema designed to integrate information into the desired manufacturing reports. Until recently, there were no standards for data type and formats or even for which data should be gathered and stored. Interface protocol standards did not exist, so every design required a series of one-off coding exercises to extract the data from the legacy process and business systems.

Some industries chose to pass on the one-size-fits-all, third-party systems and developed in-house systems that were specifically tailored to their processes. Unfortunately, this path brings its own set of software maintenance and modification problems. In many cases, hardware obsolescence issues create a need for the total replacement of these systems after 10 years.

Groups like ISA, WBF and MESA have further refined standards such as ISA-95, resulting in greater consistency at the middle and lower business levels. The definition of MES is changing from manufacturing execution systems, as a middle layer, to a broader manufacturing enterprise system architecture definition. Its primary focus is now on manufacturing operations management (MOM), which entails providing data collection, system interconnection, data reporting, formula management, and inventory reporting and control in a real-time environment. ERP can certainly do some of these tasks, but the real-time, instantaneous nature of the plant floor precludes ERP from delivering the value needed for the floor to operate.

The process of definition, design, implementation and testing can be a time-consuming affair, but a properly designed, well-implemented and comprehensive MES system can deliver the promised financial rewards — with leaner manufacturing and more focused, more timely production planning and delivery.

Addressing the plant-floor and business culture is also critical to successful implementation. Most importantly, a business must approach this process with the pretence of developing an automatic system versus automating a manual system. Every manufacturing plant in the world has MES. Some are highly automated and most are a combination of manual forms and spreadsheets that all magically work together to produce the right answers most of the time. However, when these combination systems face abnormal conditions, manufacturing costs rise quickly due to increased waste, manpower and inventory.

The danger of lacking upfront definition

Unlike process control systems, which are narrow in scope and specific to one part of the manufacturing standardised process or business system, MES is broader in its functionality and affects the business and process flow of the entire plant. MES captures data from all business and plant areas so they can be easily combined into information that crosses the standard business, sales, process and quality data boundaries.

In most cases, an MES must model a plant's specific way of doing business in order to successfully do its job. Generally within an industry vertical, the physical way a similar product is made is almost identical from one plant to the next. However, most of the tasks and processes done outside of this common process can and do change from plant to plant. Effective modelling of these businesses and manufacturing practices is critical for obtaining data and the resulting accurate, real-time production information.

The success or failure of MES hinges on the amount of time and effort invested in the upfront discovery and definition phases of the project. The process of defining all the specific process steps and individual procedures that occur during the normal and, more importantly, the abnormal workflows of a plant requires significant effort. Taking the time to correctly perform this important task will yield extensive benefits, including the discovery of additional improvements that can be made in the workflow, such as the elimination of duplicate steps and nonessential data as well as streamlining data flow. Unless the manufacturing process is evaluated holistically, these gains can easily be overlooked and in many cases will cost the business more, as unnecessary work will be done to develop the new system.

For many reasons, it is best to bring in outside resources to facilitate the definition process. For example, an outside resource can help identify common assumptions to ensure that they are excluded from the specifications, as they can cause costly rework if they are discovered after the project is underway. An outside resource assists in this process by offering an objective point of view, unclouded by company politics. The task of upfront definition can appear impossible, but assigning a third party to the development of the definition package will keep the project moving forward and process clean. If the primary resource responsible for driving the definition phase also has to keep the plant running, we all know which important task will take priority.

User requirements

Concurrent with the above detailed definition of steps and procedures that define the manufacturing process workflows, the first step in defining the actual MES requirements is to develop a user-centric set of requirements. These are typically captured in a document called the user requirements specification (URS). Requirements are collected, analysed and prioritised into 'required' and 'desired' groups. At this point in the design, the project is platform-independent and concentrates on the needs of the business and the user. The URS is a formal list of 'wants' based on information needs. It is written in terms of the specific information needs that correspond to the business and manufacturing steps and procedures also being defined. Even if the MES software package is preselected, the URS should not be written around the capabilities of the specific package.

In most cases, the specific areas of plant operations, such as sales, planning, scheduling, inventory and quality, know their individual information requirements and desires. The personnel in these areas know what data they need to impact the operation and what data they are collecting simply because someone requires it on a report. They also usually know if they can trust the data they are collecting. It is the job of the requirements gathering team to research and trace all of these data points back to the physical points where the data are generated. If data does not come directly from production (that is, it is manually collected or imported from other spreadsheets), it must be validated and the risks of collection errors must be identified.

One of the best methods for capturing these requirements is by interviewing selected members of all the affected areas of the plant. A report summarising these interviews according to operational area is a tremendous tool for developing the URS.

An additional benefit of following this method is that by capturing all of the requirements, a future state model can be developed. That model can be used to develop an overall roadmap for future phases of the effort.

Requirements for beginning system development

With the URS generated, the first of the important project reviews takes place. During this review, each interviewed area examines its section of the document for accuracy and completeness. The next effort is to translate the information requirements listed in the URS to a set of MES functionalities. From these functionality requirements, a set of capable vendor packages can be generated and ballpark cost estimates can be ascertained per package and per function.

This effort supplies the data necessary for the most important review and consultation before the final commitment to the selection of the software package and the design, development and implementation of the MES. This review is usually where the decision is made as to which functionalities will be implemented in which phases. Ideally, the project will be phased, with the implementation schedule based on an evaluation of the functionalities most needed, along with costs and returns. Only after this functionality analysis should the MES package be selected based on its specific capabilities and cost relative to the required functionality. Discovery and definition of the specific information needed for the system design can be completed after this critical decision.

Tools to support definitions

During the discovery and definition phase of the project, two separate but equally important and interlinked data sets have been identified. The steps and procedures of the plant workflows, with their individual input and output data sets, form the complete information set that the MES must produce to satisfy its defined functional requirements.

Flowcharts are the first level of definition for a workflow, but by themselves are not sufficient. A true workflow step or procedure exactly defines a required and unique step in the process of making whatever the plant is producing. It is characterised by a generation or change in information so that data input produces different data output, and an event, automatic or operator-driven, changes a status, etc. Each change in data needs to be rigorously defined to model the current process in the MES and to provide the operational baseline for future improvements.

Data dictionaries must explicitly define all the aspects of process, business and MES-level data according to their sources, as well as the level of reliability and age limit required for how they will be used.

Reporting requirements defined in the URS are sometimes the best way to preliminarily ascertain the MES-level data and information, and the MES functionality required to obtain it.

The future of MES

MESA, along with several large corporations and at least one MES software vendor, is developing and perfecting a new direction in MES. As with many other software-based technologies, service oriented architecture is taking a foothold in this space. This not just web service technology, it is a paradigm shift in the organisation of manufacturing software functionality. In its mature state, it can provide a plug-and-play type connection with lower-level process and enterprise systems through a fully standardised enterprise or manufacturing bus, and a workflow engine that controls execution of those steps and procedures and the data that are associated with them. On some systems, this workflow and business process management configuration software is based on existing Microsoft workflow software. In this scenario, the front-end definition of steps and procedures provides this workflow engine with all the defined steps and procedures of a process. These are easily configurable and changeable, allowing easy process management changes that can be automatically passed down to the MES model. Stay tuned for advances in this area of MES development and deployment.

Conclusion

MES by its nature spans the entire enterprise, capturing and summarising disparate data into a clear vision of a whole plant's operation. It provides real-time, instantaneous interaction with the plant floor systems and bridges the divide between batch- or transaction-oriented systems such as ERP. For these reasons, sufficient time must be allocated at the beginning of the design effort to accurately capture and organise the information that defines the existing operation and the desired results of the MES. Outside, independent resources can help drive the definition process forward and help to keep it as efficient as possible. This effort can be longer than is desired, but the success of the MES system depends on it.

*Tom Gill is a Senior Consultant, and Dean Ford is Director of Enterprise Application Integration at Maverick Technologies

ZI-Argus (Vic) Pty Ltd
www.zi-argus.com
Maverick Technologies
www.mavtechglobal.com