Plant-level Systems: Facing and Dealing with Obstacles
Written By: Predrag Jakovljevic
Published On: November 22 2005
Obstacles to Overcome
Unfortunately, there still seem to be walls, not to mention the ivory towers of management, that stand between the plant and the rest of the business. One wall obscures supply chain visibility, preventing people in the plant from getting relevant visibility into the upstream and downstream supply chains. Even large, well-equipped companies with modern supply chain management (SCM) systems suffer from information gaps. For example, SAP relates the experience of a manager of a well-equipped plant at a large, very modern chemical company: "50 percent of the demand that is getting to him is completely invisible until it occurs". Given the company's big setup times and setup costs, this is a high wall that must be overcome.
Part two of The Importance of Plant-level Systems.
Another wall keeps information in the shop floor. Given the lack of integration and visibility, reactions to unpredicted events are mainly driven by e-mails and frantic phone calls to the shop floor. As a result, a lot of information is lost. Reports about yesterday's events come too late or lack the detail necessary to support daily business decisions. Yet, in the "sense and respond" environment of ideally run modern businesses, data generated by events as they occur offers the best basis for management decisions and actions, and more importantly, time is not lost. Thus, if one could bi-directionally link what is happening on the shop floor with the business side, and then put events in a business context, decision-making will become much faster and enterprises might be able to fulfill customer demand, even if problems were not pinpointed earlier.
Moreover, within a multi-plant company or within a complex supply chain, a few local applications can grow to hundreds of disparate data generators and information sources. The value of these applications is typically based on each system and they are treated as a standalone answer to a particular set of operation conditions. The aggregate value of the system is not considered because these applications are built with a data-centric view that is narrow and focuses only on the requirements needed for a specific process.
Disparate systems create islands of information and groups will use their own, narrow views of data to make decisions that affect their department in one way, and may impact the entire company in another. For example, an application system designed to support the quality assurance (QA) department would contain important quality management issues, including statistical process control (SPC), nonconformance measurement and statistics, corrective action support, in-process test, etc., but equally important issues, such as work-in-progress (WIP) tracking, cost variance, and scheduling would not be included. Likewise, traditional material requirements planning (MRP) systems are closed loop systems that focus on internal mechanisms, and use logic untainted by and oblivious to outside forces and realities. See Demand-driven Versus Traditional Materials Requirement Planning.
When production systems on the shop floor are not synchronized and integrated, a disconnect in the overall business process results, and production personnel compromise their productivity and performance by wasting time to hunt for critical information. On the other hand, production managers typically get a rearview image of what happened in the past week or, in the best case scenario, the past shift. If there is an anomaly, s/he will require more information to understand why the problem has occurred, and chain reaction begins. To get the associated data, operators must go through a large numbers of systems to pull together all the information they need and more time is spent tracking down information. Production supervisors and plant managers are therefore constantly "firefighting" because they do not have automated exception-based management, and latency, delays, and increased cost result. Moreover, production personnel cannot accurately measure, monitor, or control their key performance indicators (KPI). For example, one of the largest chemical companies in the US remunerates its operations personnel based on their performance and whether they achieve the first class quality and specification conformance. Thus to compensate fairly, the enterprise needs a manufacturing intelligence dashboard to create a view of how its employees are doing.
This is Part Two of a three-part note. Part One discussed the plant-level situation. Part Three will analyze the market impact and make user recommendations.
Although widespread since the mid 1980s, the need for compliance, efficiency, and efficacy within the supply chain has generated renewed interest in plant-level applications. Both manual and computerized versions of these systems and their components generate and maintain a large amount of data that could be useful to other people within the enterprise, as well as to external trading partners on the demand and the supply side.
Historically, this information has been difficult to retrieve within those user communities outside of the plant floor. However, that the availability of this information is improving as vendors recognize and enhance their plant-level applications with a broader functionality scope, and place a particular emphasis on QA, product lifecycle management (PLM), and product data information across the entire supply chain. Web access and other tools that collect and aggregate data from disparate systems are also being developed.
The hard part of making production data available is its retrieval and arrangement in a context that supports smooth business processes and proper decision-making processes. Most information technology (IT) departments are not closely (if at all) connected to plant operations and have little awareness of what data is available at what level or how to retrieve or aggregate it.
Another issue is that dozens of plant-level applications that are typically used in medium companies were built using specifications that have long since been abandoned and forgotten. Moreover, they use technology that is no longer in vogue, and their documentation rules are rudimentary or nonexistent. Furthermore, when the IT group locates and identifies the desired information, the cost and time to integrate the data sources on the plant floor are great and often prohibitive.
To get around these problems, one idea that has been gaining in popularity lately. It involves the inclusion of a value-adding process layer that can fairly easily link scattered data sources, retrieve specific data, perform process logic, and deliver meaningful output. Companies are applying manufacturing (plant) intelligence systems to bring appropriate information from plant-focused data sources and aggregate them into a meaningful context for presentation and analysis. These systems are a combination of an integration/middleware platform and business intelligence (BI) applications. Portals can aggregate and process manufacturing data for specific user communities, and then they can be used to share scheduling information across collaborative value chains (see Portals: Necessary But Not Self-sufficient). On the other hand, manufacturing intelligence systems can collect specific data from plant-focused devices and systems, and analyze and then present information in dashboards and other KPI tracking systems.
Radio-frequency identification (RFID) technology can also be leveraged in some scenarios. For example, an RFID-enabled business plan can indicate what type of paint is moving quickly on the floor. Using this information, one could likely answer the question, "what now?" at the manufacturing level. For example, the sales department might want to rapidly capitalize on this opportunity and the production plan can then be re-aligned in real time, based on the capability to deliver or the capability to promise (CTP). Finally a notification of the material available for shipping can occur automatically and immediately.
This concludes Part Two of a three-part note. Part One discussed the plant-level situation. part three will analyze the market impact and make user recommendations.