Jim Connett, on December 13, 2021, 01:25 AM
Presenting Your Data to Tell A Story
I’ve had the wonderful and humbling privilege to work on many software projects. One that stands out in my memory was a data visualization project. Generally speaking, the requirements given to our three-member team involved creating a web-based UI that would present the aggregation of data from the MES to show the calculated results of any user-defined parameter(s) across a user-defined date and time range. I was responsible for the UI and dynamic query elements, while my colleagues were responsible for the statistical analysis and data acquisition requirements. A description of the victories, the struggles, and the lessons learned on this project could fill a book. Through it all, our greatest joy was when we heard that a certain process problem was being addressed based on data collected through this web-based application. The MES data showed a picture of both nominal and outlier conditions which were eventually traced back to a specific supplier of a part installed in the target equipment. The information was there (in the MES), and the visualization project presented that information in an easy-to-understand format. The evidence was clearly understood and accepted by all, and the picture led to corrective action items to resolve the situation.
Your MES is collecting hundreds of thousands of data points every hour. In table form, the data is difficult to understand as a collection of fields, rows, and columns – it doesn’t make a lot of sense to the average (or even advanced) user. Add to that the YEARS of data likely available (dependent on how long you’ve been running an MES) and the many subsystems responsible for collecting data, and one can quickly become buried in a bazillion seemingly dissimilar or unrelated records with no meaningful context, clarity, or connection. It does no good to present reams of paper to your manager with printed results from a database as proof of the need to buy a specific tool or invest in a software upgrade. Rather, the more data in the data set, the more important it is to present this data in a way that shows a meaningful picture. In other words, your data in picture form should speak those proverbial thousand words.
The importance of investing in an MES with reporting capabilities – or incorporating an external application that converts datasets from connected systems to something visually meaningful – cannot be overstated. Modern-day MES applications will often provide modules with visual reporting capabilities. External applications may also be used on any MES to interrogate databases or event-stacks and produce visual results. Some database management applications provide rudimentary data visualization. Regardless of the tool, data visualization should receive an investment of both human resources and dollars.
With this investment, here’s what you can expect in return:
The power of Pareto charts
Nothing is more unsettling than having a “feeling” that you’ve faced a similar problem in the past or are pursuing a solution that has been tried in the past, and nothing is more frustrating than fixing the same problem repeatedly. Pareto charts are often elixir for this déjà vu. For example, a Pareto chart showing the reason for the downtime of a given piece of equipment over an extended period can point to several problems or problem domains. Maybe the problem is a lack of training that can be addressed internally. Maybe the problem originates with a supplier whose quality has degraded. In Pareto form, the problems worth resolving are clearly shown, and addressing these top items results in drastically improved KPIs, savings in repair costs, and reduced downtime.
A data point measured on a specific material being produced is important, and that data point can be boxed in by upper and lower limit tolerances – thereby giving the datapoint some contextual boundaries. However, in isolation, the resulting data point (or set) is often quite limited. Today, you have a failing data point, so you turn a few screws with a wrench and all is good. Tomorrow, you have another failing data point, so you turn a few screws again with a wrench and all is good. The same happens the day after, and the day after that. Presenting these data points visually in a time series on a line graph may point to the fact that one is turning the wrong screws, or that the screws that need to be turned are actually on upstream equipment. Upstream adjustments as a result of downstream trending data are very common in run-to-run scenarios. Without this trending data available in aggregate (and graphical) form, it’s difficult to see the entire problem and address the issues with targeted solutions.
Equipment availability in manufacturing environments directly influences KPIs such as OEE, cycle times, and (ultimately) profitability. The Toyota Corporation has long advocated a Kanban system whereby every equipment resource is productive while work-in-progress (WIP) is minimally (if ever) queued behind a resource. In other words, the Kanban system strives to prevent a buffer that builds behind equipment. If one material comes off of an equipment, there is exactly one waiting to be loaded. Of course, this system shows benefits in certain manufacturing environments, but in others, the Kanban system is impractical, if not impossible. In high-volume manufacturing, equipment bottlenecks are inevitable. Data presented from an E10 system (specifically the standby and productive components of the E10 model) combined with dispatching data that shows the list of materials queued behind a resource at any given time can highlight bottlenecks in your manufacturing line and point to effective and worthwhile capital expenditures to resolve the bottleneck processes. With visualized data, capacity planning can go from subjective feelings based on perceived outputs to objective and concrete conclusions based on actual (or even real-time) data.
It’s not good enough to just know that something was measured at a certain temperature or the quantity processed was X number of widgets in the past 12 hours. It’s also important to know WHY that data is the value displayed on the charts or graphs. The WHY is most often answered when systems are integrated and communicate data with each other. If output decreases from normal or expected trends at a certain point in your processing line, then it’s important to know what may have caused the drop. Integrating certification databases may show that the employee working that day was certified on only a few of the required processes at that station. Integrating the attendance database can suggest that output dropped due to a lack of employees. Integrating the E10 data collection system may show that a monthly preventive maintenance procedure may have taken longer than necessary and (along with the attendance or certification data) may suggest a personnel issue for that maintenance activity. The maintenance inventory data may show that the maintenance activity was delayed due to an insufficient number of replacement parts. The day’s barometric pressure measured by a weather monitoring system may explain why the atmospheric deposition tool was more DOWN than UP over 24 hours. The point is made – data from all systems need to be brought together when visualizing reports and KPIs.
We could go on about the importance of data visualization. The point here is that meaningful data exists TODAY in both your MES and in support systems. That data, properly aggregated and presented, can tell a story and lead you to adjustment and modifications, resulting in greater efficiencies and optimizations, purpose-driven capital expenditures, and increased profitability to the company and its shareholders.
Be the first to comment.