The quest to reduce variations in products made on different shifts has existed as long as the chemical industry has. Yet, success has continued to elude us. However, with the arrival of more connected devices (the so-called Internet of Things or IoT), we are starting to have the opportunity to address product variability and other process problems — and the industry is responding (see: "Chemical Makers Embrace Digitalization.”).
Most process companies long have had the capability to gather operational data. However, with the lack of general connectivity, gathering these data was time consuming and expensive. Moreover, only a select few people looked at and analyzed the data. In some cases, data analysts were in different departments and arrived at different conclusions due to different data sources, methods of calculation and timeliness.
With the technology available today, we can address some of these product variability issues. Sensors are becoming cheaper, new equipment arrives with sensors and connection capabilities already installed, and operational data increasingly are viewed as valuable and worth the effort of analyzing.
[callToAction ]
Are You Collecting The “Right” Data?
Ask most process companies and they will tell you they are collecting operational data. Unfortunately, most companies stop there. According to a study by IDC, less than 1% of data collected are analyzed. This begs the question: What are we collecting the data for? The answer isn’t always obvious. Back in the day, before we even thought of connecting sensors to everything, I was doing some analysis and followed the data trail around a company. In this case, the data trail was a paper document. The document, which was created daily in production and operations, listed the products and quantities made along with the associated work in progress. Copies were filed in the production office and in accounting. Nothing was done with the data. This had been going on for years, using an expensive preprinted form. Apparently, many years ago, a study that required the data was initiated; when the study was completed, no one halted the data collection.
This underscores that some data are needed only for a limited time; so, it’s good practice to periodically review if the data are still useful. I believe the problem (gathering non-useful data) will grow as it becomes easier and easier to automatically collect data and automate the analysis. When the analysis stops being useful, do you remove it from your reports and dashboards or just ignore it?
Another issue in collecting data to address your problems is determining what are the “right” data. Most companies seem to have many definitions of each data element, usually unique to each department. These differences lead to many discussions about whose number is right. Can you agree across your organization on what the actual calculations for your key performance indicators (KPIs) are? Even if you agree on the definitions, do you agree on the data source — and also on the interpretation of data?
With all this decided, you must consider one more thing: Can you access the data? Depending upon the data source, company policy may prohibit you from accessing the data directly, and could require you to go through a demilitarized zone and firewall to get the information. This usually occurs when you’re trying to get to data that can impact the operation and safety of the facility (e.g., safety instrumented systems, safety instrumented functions and other control systems). Most companies are very leery about opening these systems to any possibility of Internet access out of concern about an intrusion or virus affecting them. Because most management systems are open to the Internet in some form (e.g., online sales portal, purchasing networks, mobile device access, etc.), companies severely restrict access to control systems from other networks and, in some cases, air gap (don’t physically connect) them.
These cases mandate setting up additional steps. The data from control and safety systems must be pushed into a safe area where the analytical and transaction systems can retrieve (pull) the data. This creates an additional layer of complexity, requiring coordination and timing among the various systems.
Are You Asking The Correct Questions?
Let me start by quoting from “Knots” by R. D. Laing:
If I don’t know I don’t know
I think I know
If I don’t know I know
I think I don’t know
KPIs imply you already know the question you want to ask, e.g., what are my inventory turns, my percent budget completion, etc. By knowing the question you want to ask, you already know the data elements needed for the answer. You might have trouble getting to a data element or might have to deal with multiple sources of the data element but essentially you understand what’s desired.
When you don’t have a firm understanding of the question you’re asking, e.g., what caused the problem, things are different. It’s all about discovery. Being able to keep adding information to your data pool is essential for resolving problems. However, some assumptions demand care. For instance, staff at one plant initially couldn’t fix an observed quality problem because they assumed outside temperature had no influence on quality in the temperature-controlled production environment. They eventually realized the increased power consumption needed to hold the temperature when the outside temperature was extreme could be causing voltage drops, which could create problems on the line and, consequently, quality issues.
This begs the question: Would I have known to add outside temperature to my data set? In the past, I probably neither would have had the data nor the capabilities to look for relationships. Today however, individual companies can take advantage of advanced data-modeling capabilities once available only at research institutes and government bodies. This type of software allows you to identify relationships between data elements that you wouldn’t have suspected. Of course, that presumes you know all the relevant data. And because we do not know what we need, we are back to square one. This, I believe, means we must take a slightly different approach.
Connectivity and data are getting cheaper and more pervasive. So why don’t we grab everything and let the modeling software do the relationship building for us? And as the relationships are identified, we can continue down the analysis path as normal, further refining the model, which then can become part of predictive analytical processes.
However, that returns us to the “right” data issue. If we don’t know whether the data element is needed, then how do we justify instrumenting and collecting the data that might be useful for our analysis? I put this to you: Installing additional sensors will cost significantly less than letting the identified problem persist. After all, if the problem wasn’t important (that is, costly), you probably wouldn’t be trying to address it.
Thus to resolve a problem, you most likely will have to ask many questions, drilling down into multiple data sources, adding more data sources, and refining the question as you go. To do this type of iterative questioning, you need software that answers your questions quickly, not as in the past, so slowly that by the time you had the answer you had forgotten the question.
Bridging Shift Changes
Data that are generated via sensors, gathered, analyzed and reported will go a long way to understanding some of the factors that can cause variability in production. Unfortunately, some information, if not quite a lot, isn’t available to automated systems in a timely fashion. The data only might be available on a periodic basis, not immediately. In addition, plenty of older equipment have analog gauges and aren’t connected. So there are gaps.
Adding data collection to operators’ rounds and transferring the values recorded to the analytical software can address some of these gaps. However, some of the missing data aren’t easily collected and processed.
One common example of such missing data is operators’ observations that appear in the “shift log” or “shift book.” Most shift logs are paper based, giving the operator a great deal of flexibility in reporting impressions and problems. All well and good, but these logs contain information that, if correctly analyzed, can help reduce variability. The question is how to get something that is mostly text into something that can be more easily analyzed. The solution is relatively simple: implementing an electronic (digital) version of the shift log. (For details on one successful switch, see “Refinery Benefits From Electronic Logs.”) Doing this can improve the quality of information. At a minimum, you can implement edits (pull-down menus) that can access your corporate systems, ensuring the equipment, products, materials and identifications have no writing errors. You will need to do some work to codify problems. This type of information should be available from a variety of sources, e.g., failure modes and effects analyses, object parts lists, quality codes, operating parameters, etc. Having the common problems associated with a code enables easier analysis. You should allow for some text to be entered for times when a code doesn’t fit. I’ll make one recommendation about the code list: Try not to have too many entries. If it’s too much work to select the problem area, people often will pick “other” or just the first entry in the list.
Once you have the shift book in electronic form, you now have the capability of looking at the information around shift change to see if there was an impact on product output and quality. But there always are other factors — again, do you have enough data collected to get to the right answer?
Including Other Business Data
While most companies concentrate on analyzing operational data when looking to resolve a production problem, other pieces of information can help. The corporate systems have a wealth of information about things that could influence the solution. Could it be a production mix problem? I have worked in a facility where we couldn’t run two specific products down parallel lines at the same time. No one knew why this caused a problem but it did. We had to analyze a lot of production schedules to realize this. Does the maintenance have an impact? How long ago was the last maintenance on the line? Which crew did the maintenance? When did the operators last undergo refresher training? How many new operators are on the shift? Have you changed vendors? Operational systems don’t have the information to answer all these — and other — questions but management systems do. You may need to include such information in your data set for analysis.
One type of information that always seems to be forgotten when looking at operational data is the financial data. While there doesn’t seem to be a link between product variability and financial data, including financial data does help in the analysis in quite a few ways. Excessive maintenance expenses on the line could indicate a problem. The high cost of obtaining parts for older equipment could spur thinking about decommissioning the equipment. Seeing a change in the product cost structure could signal that excessive rework is being performed; material cost might not increase but labor cost would. Changes in the cost of a material might point to a new vendor and potential quality problems.
Also, it is very helpful when talking to management to put a cost on the problem. Executives might not understand technical details but they always understand costs.
Widening Your Data Search
When doing root cause analysis, you don’t have to limit yourself to operational data. A lot depends upon the problem you’re trying to solve. If you think humidity and temperature might have an influence, then you might have to include environmental data from an external source. If a customer is having problems with your product, then you might need to bring in data about how it is using your product or how its equipment runs with your product. Could a supply chain problem relate to too much temperature variation or vibration during transportation? Could the route chosen make a difference?
As those examples highlight, you often will need outside information to resolve a problem. Using external data sources does pose issues. Access to customers’ data probably will call for confidentiality and non-disclosure agreements; getting data from some government and private sources may require paying for subscriptions. In addition, because the data are external, you must follow all the normal security processes.
As equipment and data sources are added to the IoT, the information available is growing exponentially. We must ensure that we take advantage of these data and increase the percentage we use.
Looking Ahead
We can and should do more with the data we are collecting than just solve problems. While problem solving is important, it’s backward looking; the problem already has occurred. Problem prevention is one possible next step. Being able to predict an event via a model based on all the information (data) we have collected would go a long way in preventing problems. After all, with enough notification we can correct the process or equipment before it becomes a true problem. Going even further, once we can predict an event, perhaps we use the same model to adjust our operations to mitigate it.
We truly are entering the age where we have the data to resolve problems. Remember, though: “There ain’t no such thing as a free lunch.” Companies need to make investments in connecting equipment and other sensors. And we have to start mining and using analytics tools to extract value from the data. Above all, we must keep looking for additional opportunities to use this investment in the IoT and the ocean of data that comes with it.
JOHN HARRISON is King City, Ont.-based senior solution specialist, industry business unit chemicals, for SAP. E-mail him at [email protected].
