In Part 1 we saw how a manufacturing company’s vital processes of business generation and wealth creation are supported by the resource management functions.
Common to all three is information and in this article, we investigate their differing information needs and how to cope with the differences.
Here is an example:
Company objective
Profitable client need satisfaction through the manufacture and sale of low-cost, quality widgets.
Strategy
* Create a sales and manufacturing facility backed by the necessary supportive infrastructure.
* Maintain profitability in excess of X%.
* Maintain a sales volume in excess of Y units per month.
The company structure shown is the result (each process can be broken down to sub-processes and to any level of granularity but this is outside the scope of these articles).
So, the company will not only need information to operate but also to measure how well it is doing vis-à-vis the stated performance requirements (we will get back to this measuring function later). That is why the information management function has been extracted from the resource management group since it is common to this as well as the business generation and wealth creation processes. But this is not the way companies start or grow.
Manufacturing enterprises evolve. They do not come out of a cardboard box with a set of instructions on how to put them together or how they should be run or managed. And because manufacturing enterprises tend to be more complex than most, each of their functional areas have evolved as separate entities trying to do their best towards achieving the common goal of profitable added value generation. The result is often one where business, marketing and manufacturing processes may just as well be operating as three separate companies. The way to fix this is through the thing they all have in common - information.
However, information, like time, is relative. It has to be available at a certain rate and in the right context and to the right level of detail and to the right people if it is to be useful to the people that need it. Enterprise resource planning systems do not need the flood of information that comes from the realtime environment of the shop floor because they work on a different time scale and have vastly different needs - but enterprise resource planning systems need some of that information in a distilled form that would best make sense to the application areas they are addressing while manufacturing execution systems need some of the enterprise resource planning information and some of the shop floor information for the same reasons.
The bottom line of all this is that each functional area of a manufacturing company must have access to the selected information they need from each of the other functional areas, irrespective of their evolutionary paths, selection of applications, data formats, etc, if all these departments are to work as one company rather than disparate departments.
The enterprise information discontinuity
Business systems deal with different types of data and address different issues than the plant floor. There is an entire level of data granularity that exists on the shop floor that is absolutely essential to managing a manufacturing process that is not required for business processes. A key subset, or an aggregation of this information is required to effectively manage the operations of an enterprise.
Each functional process group of the enterprise has a model that is intended to support a different set of capabilities. The enterprise resource planning model is designed to manage inventory levels and resources, plan production runs and calculate the cost of production. The manufacturing model is used to control the execution of production orders, ensure procedures are followed, capture consumption and quality data, etc. The rate at which information is generated on the plant floor and the response to incoming data must be much faster than for the business or business generation processes. For this reason, simply connecting the enterprise systems to plant floor devices will quickly overload the business system with useless data. A strong filter and distillation process needs to be in place to provide context to the data and aggregate the raw data into a form that has meaning to the enterprise.
For this to occur effectively, it must happen within a framework that allows for the transfer and screening of information between applications and since these applications and solutions are mostly from a variety of vendors, they need to follow a standard with respect to content and format. Examples of frameworks are SAP's NetWeaver and Wonderware's ArchestrA. The standard for the information content and format is ISA-95 (Instrumentation, Systems and Automation Society). These technologies exist today and solution vendors with their eyes on the future are developing applications within this environment.
Customers are increasingly looking to buy off-the-shelf solutions that conform to standards such as ISA-95 rather than vendor-dependent bespoke solutions that can only operate within their own proprietary environment. As we saw earlier, companies evolve and their software solutions need to evolve along with them. Customers want the freedom to choose solutions from the most qualified vendor rather than be tied to any one vendor through proprietary software or databases.
So, technology need no longer be the excuse for inadequate system integration. If this is the case, why are more companies not rushing towards enterprise unification? Because it requires a change in attitude and that has always been more difficult than beating computers into submission.
**Why ISA-95 is a good idea
The ISA-95 standard was developed with the objective of reducing the cost, risk and errors associated with implementing interfaces between enterprise and production control systems. It continues to be developed and refined by the Instrumentation, Systems and Automation Society (ISA) in collaboration with major vendors of ERP and MES solutions around the world.
**Reducing cost
ISA-95 can be used as a method to define the interface between enterprise and production control systems. Projects can be standardised and little is left to the unknown. ISA-95 also makes the integration of solutions from different suppliers less complex.
**Reducing risk and avoiding errors
ISA-95 was developed by a group of companies including Honeywell, Sequencia, Foxboro, Yokogawa, Fisher Rosemount, Chevron, Dow Chemical and SAP. These large international companies have years of experience with integration projects. They have combined their best practices into a consistent set of models and terminology that make up the ISA-95 standard. They know how to make integration a success and, more important, how to avoid failures. Anyone adopting the standard automatically inherits their best practices.
**Improving communication
Every manufacturing company uses its own terminology for describing functions, activities and departments within the enterprise. When working with external consultants, like suppliers of process control software or system integrators, communication can be difficult. There is a good chance that buyers and vendors will refer to different things when using the same terms, or the other way around. System integrators have to deal with this problem every time they start a new project or every time they talk with different clients. So, when discussing interfaces, it is a good idea to base the discussion on standard terminology.
**Courtesy TWP training and consultancy
For more information contact Justin Tweedie, Futuristix, 0861 WONDER (0861 966 337), [email protected], www.futuristix.co.za
In Part 3, we look at traditional IT and shop floor IT, their similarities and differences and see how they can work together to provide the seamless information base required by the various levels of the enterprise.
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version