By Bianca Scholten
Have you ever seen the painting by René Magritte called La Trahison des Images [The Treason of Images]? The picture is of a pipe with the text below it reading, Çeci nest pas une pipe. [This is not a pipe.] Magritte is right, of course, because indeed it is not a pipe. It is just an image of a pipe.
In recent decades, industrial companies have invested much time and money in ERP systems and in automation of the process control layer. In between these two layers of automation, theres a nobodys land usually called the MES (Manufacturing Execution System) layer. MES concerns the activities that take place within a production department; for example, preparative tasks, such as detailed production scheduling and recipe management, but also data collection, tracking and performance analysis.
When you take a close look at such functions within plants, in general, you will encounter a primitive situation. Island automation is everywhere. Most of the factories use MS Excel for detailed scheduling and reporting, and they use MS Word for management of recipes and SOPs. Sometimes plants use more advanced applications, but in that case, these are built by different suppliers and they are not integrated. (See Figure 1.)
Islands of Automation
Typical European and American plants are islands of automation where a Babel of languages are spoken, impeding data and information exchange.
The lack of insight also becomes painfully obvious if you take a close look at planning issues. The ERP system does provide a production plan, but this usually is not adjusted to the finite capacity of the production lines, nor has it taken into account efficiency. Thats why, in almost every factory, you will encounter planners who work in Excel. They are people who have a huge amount of knowledge. They cannot ever be ill or on vacation. The factory is completely depending on them, so they feel highly appreciated. In the meantime the general manager has a hard time getting the information he needs and is left wondering who really is the boss .
Another disadvantage of the current situation is that the operators cannot concentrate on their core task: controlling the process. Instead, they have to spend a lot of time transcribing data from one system to the other, an error-prone process that leads to data being known in other departments and systems only hours or even days after an event occurs, at which time it may be too late for corrective action.
Plants that use systems that are not integrated also have significant master data management issues. When production is using raw materials from new vendors or when new recipes are introduced, then adjustments to the master data in all the systems are needed. This process takes time and may lead to data inaccuracy. Sometimes it leads to the procurement of the wrong materials or the production of final products that do not comply to specifications.
In order to avoid that, operators have to spend a lot of time doing administrative tasks. In many enterprises, it is common to report an average amount of raw materials back to the ERP system and the average production result instead of actual kilos or liters. In that case, depending on the industry, daily, weekly or monthly inventory stock levels have to be counted or measured, and the administrative stock level has to be corrected in the ERP system. Meanwhile, the administrative inventory is not reflecting the physical stock, conceivably leading to production stops, because the right raw materials are not availableand no one catches the discrepancy until production stops, and the costs start adding up by the minute. Or, more likely, hundreds of thousands of dollars in unneeded inventory are kept on hand, just in case.
This unwanted situation is a thorn in the side of many plant managers. They do understand that improvement of automation and communication between systems may help solve such issues. But who can they turn to? Factory automation traditionally is the domain of engineers, who program in ladder diagrams, function blocks and SFCs. But the network on which those ubiquitious reporting tools, MS Word and MS Excel, are based is the responsibility of the IT department. And these two departments might as well be in different countries, with different languages and cultures.
Collaboration seems like the logical answer, but in the Nobody Land of MES, thats not so simple.
MES: IT or Engineering?
For decades, factory automation has been the domain of engineers. They have programmed and maintained the PLCs that control the production lines. Later, SCADA systems were added for process visualization. SCADA suppliers started to offer more and more functionality, such as historians, that can store huge amounts of data. They also developed functionality for recipe management. Over time, more and more IT-like systems were provided by these traditional control suppliers. And these systems require different, IT-like knowledge from the engineering department.
A Common Language
By using ISA-95 standard terminology, a common language makes data exchange fluid and efficient, breaking down the islands of automation.
Are you also hearing alarm bells now? Isnt it true that the physical inventory is always correct?! It is risky if someone hasnt heeded the lesson of Magrittes pipe and considers the virtual, administrative world to be realityespecially when you let such a person work within a production environment where people do not work with data, but with dangerous machines, expensive materials, explosive environments, etc.
True, the IT department often is not very close to production. However, its equally true that many engineers are miles away from the IT world.
MES projects are essentially different from PLC-SCADA projects. They have many more stakeholders; therefore, communication is an extremely important point of concern for these projects. In ERP projects, it is quite common to implement extensive change management strategies, with kick-off sessions, newsletters, team-building days, train-the-trainer courses, etc. Within PLC-SCADA projects there is hardlyif anyattention paid to such activities, and therefore no budget for them either.
Whenever MES projects fail, it is almost always due to lack of communication. Therefore the lessons learned and best practices of ERP projects (especially the communication and change management part) can be valuable input for the success of future MES projects.
In short: IT departments can learn a lot from engineers, and engineers can learn a lot from their IT colleagues. Especially in case of MES, close collaboration is essential.
A Confusion of Tongues
OK, so we agree that the plant needs an integrated automation system for management of recipes, for finite capacity scheduling and for generating reportsin short, an MES system. Now it is time to decide what the detailed requirements for such a system are, and only after that, a solution can be chosen.
The input from many different people within the organization is required when specifying the user requirements. Production has a big say in this, but the maintenance department and QA/QC also have needs. And, of course, the IT department and engineering play an important role.
Another area of tension involves which functionality belongs in which system (ERP or MES?). These discussions are especially relevant for enterprises that have an SAP-only policy. Many SAP adepts are convinced that SAP is capable of anything. The one who has the loudest voice will win the discussion, and before you know it, the whole factory is using SAP, with all related disadvantages.
How are all these people going to communicate? Everybody views the process from their own perspectives. Each department uses completely different terms to describe the same thing. Moreover, people from production, maintenance and QA/QC are not automation specialists, and IT and engineering are not production specialists. Inevitably, this mix of needs, concerns, technical languages and cultures will result in a Babelic confusion of tongues.
In short, MES projects clearly have a strong need for guidelines and standard terminology. How should a specific word be interpreted? Where should we put responsibilities? Which functionality belongs in which system? Are there any best practices and lessons learned from other manufacturing companies that can be modeled?
In the 1990s, some software suppliers, consultants and industrial enterprises acknowledged this problem. They established the SP95 committee within ISA, with a goal to develop a standard for enterprise-control system integration. Several parts of this standard have already been published, and companies all over the world are applying it. ISA-95 is based on the best practices of pioneers.
ISA-95 is not an automation system, but a method, a way of working, thinking and communicating. The method is described in several documents, each around a hundred pages. These contain models (figures) and terminology you can use to analyze an individual manufacturing company. Each of the models focuses on specific integration aspects; they each illuminate the issue from a different perspective.
Communicating about a system can be difficult because different people in the same conversation often assign different meanings to general terms. ISA-95 defines words that relate to integrating enterprise and control systems. ISA-95 places this terminology within models, which make clear the relationships among the various terms.
Compare this principle with drawing a blueprint for a house. A blueprint depicts what the house will look like, with symbols for windows, doors, walls and roofs. The words window, door, wall and roof are familiar to all of us, and we use them to talk to each other about the house. Every house is different, and still we can depict and describe every house with the same symbols and words for doors, roofs, walls and windows. The same applies to ISA-95. No two manufacturing companies are alike, and yet you can use the ISA-95 models and terminology to talk with others about the companys functions, activities, responsibilities, information flows and so on.
Moreover, ISA-95 standardizes the information to be exchanged, which has led to ERP and MES software vendors now offering an ISA-95 interface definition instead of the traditional vendor-specific interface definition. As a result, it has become easier, not only on the level of human communication, but also on the technical level, to integrate systems from different vendors.
The objective of the ISA-95 standard is to reduce the cost, risk and errors associated with implementing interfaces between enterprise and control systems. The standard can also be used for definition of user requirements for MES systems. Moreover it simplifies the implementation of new MES systems so that the company in the end has enterprise and control systems that are well-integrated.
Market research by MESA, has made clear that many industrial companies intend to purchase an MES system in the short term. Lets hope that will change the situation and that there will be more and more plants in which the production managers know what is going on; in which operators are controlling the process instead of doing administration; plants that have no stock issues leading to production stops; in which IT and engineering work closely together; plants where people have made a sensible decision in dividing functionality over ERP and MES systems, andlast but not leastwhere the managing director, not the planner, is the boss!
Bianca Scholten is a fellow at Netherlands-based consultancy, Ordina, and author of The Road to Integration: A Guide to Applying the ISA-95 Standard in Manufacturing, ISA, 2007. She can be reached at [email protected]