- What material lot was used in this batch?
- When did we detect this issue?
- Why was this decision made?
- Who postponed the maintenance on the equipment?
In a manufacturing enterprise, information exists in a variety of systems (ERP, MES, LIMS, QMS, WMS, SCADA and IO devices, etc.), each an island of information, that need to interface and communicate with each other as part of the intricate orchestration of process execution. Each island is a System of Record (SOR) – an information system which is the authoritative data source for a given data element or piece of information. ISA-95 states that activities of manufacturing operations management are those activities of a manufacturing facility that coordinate the personnel, equipment, material, and energy in the conversion of raw materials and/or parts into products.
As manufacturing business processes execute, data from various SORs is used and/or changed. Then, why is it so difficult to answer the questions above when all the data required exists in SORs? The reasons are not that obvious.
First off, many of the standard operating procedures (SOPs) in the manufacturing environment are manual in nature (people driven), and a majority of them are performed on an as needed basis. Since the SOPs are executed manually, understanding a detailed account of what happened, when it happened, and why it happened typically involves, at best, paper records, and at worst meetings with people discussing what they recall happing. Unfortunately, most people look at SORs as individual systems that are eventually updated through manual data entry or, in some cases, through automated data flows using variety of technics (i.e. file transfers or custom code extensions of the individual SOR). I am not going to address the problem of Band-Aid / spaghetti code integration in this blog posting; it is a topic on its own.
The second problem that prevents people from answering the questions is that they don’t have access to the transient history of process execution that occurs outside of these systems. In other words – these systems don't store the information change history needed to understand lineage of causes and effects required to understand what, when and why. This information is essential to driving continuous process improvement within the manufacturing enterprise. Applications like process historians, if used to capture information, typically only includes time context and are unable to handle complex and transactional data from SORs like ERP and MES. Likewise, ERP systems typically lack detailed execution information.
As an example, ask yourself how you would answer the following question - what production request was first to process after equipment maintenance was performed on a specific piece of equipment? In most cases the answer we get is that someone has to know how to query records related to the equipment from the Maintenance Management system, and from the time-stamp of the record try to find the production request that was processed around that time. Time, again, being the only relevant context available to link information between SORs.
What is missing is one very important element of context of information – its “lineage” or ordered history of information changes. Lineage adds the essential context that relates instances of execution with a timeline of events and activities. Lineage also provides information about the duration of process execution, be it related to equipment, material transformations, system performance, or people’s responsiveness. From a continuous improvement perspective, lineage provides in situ metrology for the performance of SOPs and for all participants in the SOP.
Our preferred solution that solves the lineage problem is to automate SOPs using Catalyst workflows – because workflow automation provides a “business process historian”. To enable high reliability and fault tolerance, the Catalyst Workflow Engine uses a transactional data store that records all of the execution data related to a workflow as well as all data that is passed in and out of a workflow to/from connected SORs (systems, equipment and people). Workflow automation provides a system that contains a complete lineage and therefore provides visibility across all SORs participating in the execution of SOPs.
Revisiting the example, consider the alternative workflow-based approach for SOPs that will capture data upon:
- Interaction within any SOR (a request to make product was entered),
- Presentation of a task to any person (an operator was told to go make product),
- Communication with any asset (the equipment in the workstation experienced a state changed to running and it is now making product).
The execution history of the workflow(s) provides the lineage required to quickly and easily answer the question posed. But perhaps more important, the complete business process history is known. Because all data related to the execution of workflows is accessible, the information required to manage SOP performance exists. This provides additional insight into questions like:
- How long did it take for the operator to actually go and make the product? (uncovering unnecessary delays which is wasted time)
- How long did it actually take to make the product? (providing true cycle time for the product within the workstation)
- How much idle equipment time was experienced in the process? (providing true equipment utilization on productive tasks)
None of this information typically exists within an individual SOR, and without workflow automation, we are often left with an incomplete and incomprehensible view of the past. So with workflow automation as a Business Process Historian, not only can we answer the question posed, but we can support continuous improvement efforts with detailed data about the performance of SOPs.
I love really this blog site because it provides me the big deal of superb information.ReplyDelete