Manufacturing Data Collection Case Study in a Plant

At half past six in the morning, the production manager is still searching for the previous day's numbers. One shift recorded the quantity on paper, another in Excel, and the reason for scrap was only mentioned verbally during handover. This manufacturing data collection case study doesn't start with the introduction of a new system, but with this very familiar situation: the plant is operating, but management only sees what happened with delay and uncertainty.

Starting situation: data was available, information was missing

In the affected multi-shift metalworking plant, about 80 people worked. Production scheduling was done in an enterprise resource planning system, but there was no unified production data coming from the machines. Shift leaders recorded the produced quantity, downtime, and scrap on paper, and at the end of the day or the next day, an administrator entered these into a spreadsheet.

At first glance, this did not seem like a serious problem. The shift leaders knew the machines, the production plan was completed, and the monthly closing somehow always happened. The difficulty became visible when the number of orders increased, rescheduling became more frequent, and more products ran on the same production capacity.

The daily report was regularly delayed by two to three hours. If a machine stopped, the reason often only appeared as "fault" or "material shortage." The amount of scrap was visible, but it was not reliably clear at which operation, for which product, or under what circumstances it occurred. Production, maintenance, and quality management saw three partly different pictures of the same day.

Management originally requested a machine monitoring system. This was an understandable reaction, but during the analysis of the situation, it became clear that collecting machine data alone would not have solved the problem. The machine might know it was running or stopped, but it couldn't be sure which production order the operation belonged to, whether the raw material was depleted, if they were waiting for quality control, or if a tool change was being performed.

Manufacturing data collection case study: what needed clarification first?

The first step of the investigation was not selecting sensors, terminals, or integrations. It was necessary to trace how information moved in the plant from shift handover to management reporting.

It turned out that the same data was recorded by multiple people. The operator wrote down the quantity, the shift leader summarized it, the administrator entered it into Excel, and then the production planner reused it for the next day's plan. Repeated data entry not only took time. Every transfer provided a new opportunity for numbers to diverge or for essential information to arrive late.

Not all data is valuable

The second realization was that beyond the paper forms, there were too many fields that no one used for decision-making. An operator was supposed to record more than ten types of codes, so in most cases, the simplest entry was made: "other." This meant a formally completed data sheet from an administrative perspective, but little usable information from a managerial perspective.

The goal was not to log every machine movement. The goal was to be able to quickly and consistently answer a few important questions: which production order is running, how much has been completed, why did the machine stop, where did scrap occur, and which deviation requires intervention.

Downtimes have business reasons behind them

The categories of downtime received special attention. Previously, the "machine fault" category included maintenance failures, tool shortages, programming issues, material supply delays, and waiting to start the next job. This distorted the assessment of maintenance performance and obscured organizational problems that did not originate within the machine.

In the revised process, downtimes were organized into a few clearly interpretable groups. Machine faults were separated from material shortages, waiting for plans, quality waiting, and changeovers. This not only resulted in better reports. It also designated which area needed to respond to the given deviation.

The solution: process-based data collection

In the established operation, the operator selected or scanned the current production order with a barcode at the start of the shift. The basic production quantity data came from the machine, where this was technically possible. At other workstations, the operator recorded the completed quantity on a simple terminal.

Human input did not disappear, and that was not the goal. The system requested operator involvement for events where the machine could not know the necessary business context: when starting downtime, recording scrap, or changing orders. The operator should not type text on a poorly lit shop floor terminal. They were given predefined, short options to choose from, and rarer cases could be marked for later clarification.

The master data of the production order came from the existing enterprise resource planning system. Thus, the operator did not search among product names and item numbers manually, and the production data was returned to the order to which it belonged business-wise. System integration here was not a spectacular technological element but a condition for eliminating duplicate data entry.

Before implementation, a short trial run followed on two machines with different operations. One worked in mass production, the other with frequent changeovers. This was important because overly detailed rules might be acceptable in mass production but easily bypassed with frequent changeovers. Therefore, the final process was adjusted based on the shifts' experiences, not office assumptions.

What counted as a real result?

After three months of validation, the compilation of the shift report decreased from an average of two to three hours to about twenty minutes. More importantly, the production manager could see significant deviations during the shift, not just encounter them the next morning.

Some of the previous "machine fault" downtimes were transferred to material supply, preparation, and production planning categories. This initially caused uncomfortable conversations because it made it visible that not all losses were technical in origin. However, the maintenance team could finally prioritize work based on actual failures, and production planning could deal with preparation delays with concrete data.

The quality of scrap data also improved, but not overnight. In the first weeks, workers often chose the most general reason code. After feedback with shift leaders and merging some ambiguous categories, the data became more interpretable. This is an important lesson: manufacturing data collection is not a one-time IT project but an operational discipline that needs to be regularly checked and refined.

What a plant manager can take from this for their own operation

The first question should not be what kind of manufacturing data collection system is needed. Instead, it's worth examining which decision lacks reliable information today and how delayed the data reaches the person who needs to act.

It's also worth assessing how many times the same quantity, order, or scrap data is recorded. If a person regularly mediates between systems, papers, and spreadsheets, they are probably not the problem. They are sustaining an information flow that the process and systems do not adequately support.

Not every plant requires the same depth of machine data collection. In a varied, small-batch production, tracking orders, changeovers, and waiting times often provides more value. In high-volume, automated production, more detailed measurement of cycle time, performance, and machine condition may be justified. The right solution depends on where the loss occurs and who can actually make decisions based on it.

Usable production data is not valuable because there is a lot of it. It is valuable because the shift leader, maintenance, and management see the same fact about the same situation in time to make changes.