The Challenges of Integrating Enterprise Resource Planning and Manufacturing Execution Systems

Though vital for effective plant floor management, plant-level execution systems have rarely taken “front and center” on the enterprise solution stage. Management has often treated production support needs such as manufacturing execution systems (MES) as a necessary, but very low, priority. However, the detriment of information silos resulting from poor data-sharing has long been felt, and now the push to demolish information silos is occurring on the manufacturing floor. As a result, enterprises are considering integrating back-office and shop floor systems. For a detailed discussion, see The Importance of Plant-Level Systems.

ERP Is from Venus and MES Is from Mars?

According to two reports by AMR Research, ERP-based Manufacturing: Challenging MES Assumptions and ERP Myths Boost MES Realities, the functional depth and scope of enterprise resource planning (ERP) is increasing in manufacturing. This coupled with the need for global coordination has spawned the need for a more predictable demand-adaptive manufacturing and responsive logistics execution. As a result, global manufacturers are forced to revisit their assumptions about plant-level systems and assess expanding enterprise applications within manufacturing departments.

Yet, while enterprise applications solutions are moving closer to the plant floor, and plant-level systems encompassing enterprise planning application functionality, the convergence of the two is unlikely to happen anytime soon. The supposition of real-time event management by enterprise applications or business applications views through plant systems is problematic, because they are still separated by different underlying technologies and user needs.

Building extensions to an enterprise application that can accommodate plant level needs requires extensive modifications in terms of requirements, as well as scripting, and coding in languages not commonly used in manufacturing computing, including Java, SAP ABAP/4, or Oracle's PL/SQL. Programmers with these skills are expensive, and only a few have plant floor experience, which results in lengthy and expensive implementations.

Furthermore, enterprise planning system implementations are often integrated to work with their own internal modules in a common database (typically relational). However, the planning level consists of aggregated production planning decisions that are included in most supply chain activities, such as planned or actual production and inventory quantities. As a result, the plant-level infrastructure consists of a wide assortment of disparate legacy systems and manual methods that few organizations can afford to rip-and-replace or change quickly without extreme cost and severe production disruptions.

The standard view of these systems is a general concern about corporate-wide macro issues, including financial planning and consolidation, aggregate inventory data, human resources (HR) management, and trading partner relationship management. ERP suites are broadly applied because their functionality is highly abstracted, since in reality, the core functionality of financials and HR are common across multiple industries. Moreover, planning systems are generally used to provide decision-support information or to respond to managerial issues on an exception basis. The emphasis is on system standards, consistent data presentation, and data roll-up functions such as accounting, costing, and inventory. See Enterprise Applications—The Genesis and Future, Revisited, Part Two: 1990s—Enterprise Resource Planning.

Plant floor applications are very different. Plant floor application vendors deliver somewhat generic solutions, since continuous flows, discrete piece production rates, temperatures, pressures, and other manufacturing process parameters are common across many manufacturing applications. Still, these systems have highly varied applications that may include retrieving and applying a process on a numerically controlled (NC) machine tool that makes a specific threaded hole from a stored part program; measuring and adjusting an oven temperature on a minute-by-minute basis; changing a machine load schedule because materials failed quality requirements; or turning valves on or off to deliver a liquid in a product recipe.

Detailed inventory information or specified variances of each manufacturing operation are typical too. Moreover, these systems operate in an on-line transaction processing (OLTP) world, and they focus on optimizing and accomplishing current operational requirements within minutes, seconds, or milliseconds. The execution level is far more granular, providing real-time tools and systems to manage manufacturing as it occurs, and then reporting aggregated actual results to the planning level.

Product-centric versus Process-centric

A major role of the plant execution system is to collect and pool data from real-time processes, which are sent to enterprise applications at the planning level. These may include ERP and supply chain management (SCM). However, the reality is that enterprise applications are product-centric; plant-level applications are process- and asset-centric. For example, an ERP application will deal with manufacturing pieces, such as jars of jam or pieces of widgets, whereas the process system will deal with measurements such as pounds of sugar and fruit or liters of juice. In such cases, the raw, real-time data collection is essentially ineffectual.

Conversely, MES systems use bills of material (BOMs) or recipes and route operations to map machine or equipment assets with the products that flow through them, but they typically are not capable of detailing cost and schedules, and they cannot discern assets performance and other useful information. Also, the ERP application will want information on the actual units produced and the date and time the lot or batch was completed. However, the plant execution environment knows no boundary between products. It will only recognize that a series of set points have changed and that some actions have taken place. It can also connect these with customer orders and commitments.

A level below plant execution software applications is the control level, where physical device processes are accomplished. This level typically includes the most basic process events, such as turning on motors, measuring temperatures, or making test measurements. Most of these events do not require human intervention, and are executed with software logic in the programmable logic controller (PLC). These are stored-program devices that control large numbers of discrete elements, using very fast input/output (I/O) scan times.

Early PLCs rarely performed arithmetic functions, though some of today’s PLCs do, and they also work in concert with other computers and applications that provide man-machine interfaces (MMI) at the control level, or serve as data historians for plant-floor processes. Other typical plant-level components include supervisory control and data acquisition (SCADA) systems, which measure process variables and machine states, and perform regulatory or machine control across a process area or work cell. Human-machine interfaces (HMI) control the mechanical or electronic system interfaces that are used by a human operator, such as a mobile phone or factory system.

Industrial automation technology is evolving in response to Internet-based computing, since thin clients, portal technology, and Web-enabled devices have changed plant information management in ways that were not foreseen until recently, and provide functionality for automating, monitoring, and controlling plant-floor operations. They also establish bidirectional data transmissions throughout the enterprise. These are all examples of how information technology, and specifically of production management, converge with plant automation.

However, transactional enterprise applications have traditionally been ill-suited to managing the details of dynamic manufacturing processes in plants. From the aspect of data models, ERP systems target stock items and costing information. Process routing and operations are primarily used to assign labor, materials, and overhead costs to works in process. It is difficult to model complex manufacturing processes, especially exception handling, within so many different industries. Moreover, each plant has its idiosyncrasies even within a particular vertical segment.

Some ERP vendors offer extensions that can handle broad industry categories; however, these tend to segment manufacturing as continuous and batch processes, or as discrete. While ERP applications can deal with units that are produced independently from product and financial issues, radically different data models are used to account for productivity, yields, and financial viability across these different segments (see Process Manufacturing Software: A Primer). Thus, while ERP vendors have made their products more attractive to specific vertical markets, they cannot really afford to deliver specialized functionality unless the market is large.

Also, as for the user interface (UI) aspect, the screens and controls of enterprise applications are geared toward planners, accountants, and business analysts, who use the system most of the day, with their heads “glued” to the monitor. Ensuring the availability of features, functions, and parameters for all the different ways companies may use the system creates too many fields and screens, which are not applicable to the plant staff.

No line worker or machine operator will spend minutes to enter data about an operation that took only seconds to do. As a result, many companies are forced to hire data entry or capturing clerks to achieve real-time data. Ironically this “flies in the face” of cost cutting and improved effectiveness. Additionally, since ERP systems are built around manual data entry concepts, complex programming, scripting, and interfacing are required to enable process equipment with automatic data collection (ADC) capabilities that can synchronize with process events.

Some vendors, however, have built event and action models and have enabled and automated data collections to support radio frequency identification (RFID), bar code or radio frequency (RF) devices, and electronic records management, for various regulatory compliance initiatives. Further, smarter instrumentation, object linking and embedding for process controls (OPC), standardized application programming interfaces (API), and Web services are used in these applications to further reduce problems. However, they do not have widespread application.

Analysis of MES Vendor Community

What may be a critical flaw of the MES vendor community is that it has not clearly defined the functions of MES solutions. MES itself does not have a broadly accepted meaning, especially among discrete, continuous, and batch process industries. When a provider declares itself to be a MES vendor, often all it is really saying that it is not an ERP, enterprise asset management (EAM), or an open control system (OCS) vendor. Consequently, the user is left to guess exactly what the vendor’s functional scope is.

MESs come in all shapes and sizes and may have one or more of the components outlined above, depending on the industry and user company. For instance, a company might call a single module, like a shop floor control (SPC) or a plant information management system (PIMS) package, an MES system. Others may offer a wide assortment of systems and collectively offer them as an MES, but they may have no ties among the packages. Also, while core functions will generally be well integrated, most of the support functions will not. For example, more modern applications may pay more attention to data integration issues, most current plant-level execution systems still consist of disparate components.

comments powered by Disqus