# Manufacturing Data Analytics for Root Cause: Linking Machine, Batch and Shift Data

> How manufacturing data analytics finds root causes: link machine, batch, shift and quality data, then prove the source of defects in six practical steps.

Source: https://digitalbridge.com.tr/en/blog/manufacturing-data-analytics-root-cause.html
Publisher: Digital Bridge Teknoloji (https://digitalbridge.com.tr)
Topic: Data & Analytics
Published: 2026-10-22 · Updated: 2026-10-22

Manufacturing data analytics for root cause means linking machine, batch, shift, raw material and quality records on a shared timeline and work order, to prove where a defect or stoppage comes from. The goal is not a better guess but a statement like "this defect only appears when these conditions coincide". That starts with data that can be joined.

## How root cause hunting usually goes on the shop floor

A familiar scene: scrap on one product family has been high for a fortnight. Quality keeps defect records in a spreadsheet, maintenance logs breakdowns in its own book, machine parameters stay inside the PLC, and the raw material batch only appears on the delivery note. In the review meeting everyone looks at their own data, and four different explanations emerge.

The problem is not a lack of data but data that is **disconnected**. If you can't see, on one row, which machine, tool, material batch and shift produced a given reject, root cause analysis turns into a debate. The loudest hypothesis becomes the corrective action, and the defect returns a few weeks later.

This article doesn't replace methods such as [8D problem solving](https://digitalbridge.com.tr/en/blog/8d-problem-solving.html) or [SPC and Cpk](https://digitalbridge.com.tr/en/blog/spc-cp-cpk-explained.html). It covers the data side that feeds their root cause step (D4 in 8D): not the method itself, but how to produce the evidence the method needs.

## The cost of not finding root causes with data

A wrong root cause is paid for twice: once in an ineffective corrective action, and again when the defect comes back. On the downtime side, one large study puts the scale plainly:

> Siemens estimates that the world's 500 largest companies lose almost $1.4 trillion a year to unplanned downtime, equivalent to 11% of their revenues. ([Siemens — The True Cost of Downtime 2024](https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf))

The same report found that large plants average 25 downtime incidents a month per facility, and that an average large plant still loses 27 hours a month to unplanned downtime. A stoppage that keeps recurring for the same reason is often a sign of a root cause that was never closed; [calculating OEE](https://digitalbridge.com.tr/en/blog/how-to-calculate-oee.html) shows how much of that loss sits on your own line.

Trust in the data is a separate problem. In the [2025 Outlook: Data Integrity Trends and Insights](https://www.lebow.drexel.edu/sites/default/files/2024-09/drexel-lebow-precisel-data-integrity-trends-insights-2025-outlook.pdf) survey of 565 data professionals by Drexel LeBow and Precisely, 67% said they don't fully trust the data their organisation uses. Data quality expert Thomas C. Redman estimates the cost of bad data at 15% to 25% of revenue for most companies ([MIT Sloan Management Review, 2017](https://sloanreview.mit.edu/article/seizing-opportunity-in-data-quality/)). On a production line, that translates into maintenance on the wrong machine, complaints to the wrong supplier and retraining for the wrong operator.

## Which data does manufacturing data analytics need to join?

Root cause analysis draws on five families of data. Each has limited meaning on its own; the value comes from the links between them.

| Data family | Typical source | What it adds to root cause | Join key |
|---|---|---|---|
| Machine state and stoppages | PLC, SCADA, counters, andon | Which machine, and when the problem started | Machine code + timestamp |
| Process parameters | PLC, sensors, recipes | Drift in temperature, pressure, speed and similar | Machine + time window |
| Work orders and batches | MES, ERP | Which product was made with which material lot | Work order no. + batch/lot no. |
| Quality and scrap | Inspection, gauges | Defect type, location and quantity | Batch no. + inspection time |
| People and set-up | Shift rota, tool/die records | Effect of shift, operator and tool changes | Shift + machine + time |

The last column is the critical one. If quality records carry no batch number, or machine clocks drift apart, the data simply can't be joined. So the first job is to capture the keys needed for [production traceability](https://digitalbridge.com.tr/en/blog/production-traceability-guide.html) on the shop floor. Where older machines don't expose this, [retrofitting legacy machines](https://digitalbridge.com.tr/en/blog/retrofitting-legacy-machines.html) with current clamps, counters or PLC reads closes the gap.

For the "people and set-up" row in the table, the shift plan alone may not be enough, because what was planned and what happened on the floor can differ. In plants using [SmartPass](https://digitalbridge.com.tr/en/smartpass.html), card reads are turned into timesheets according to the shift plan, and entry and timesheet reports can be exported as Excel, PDF or CSV and joined to machine and quality data on shift and time keys.

## Root cause analysis with data: a six-step framework

The flow below is a practical way to run classic quality tools on joined-up data. Each step's output is the next step's input.

1. **Define the problem in measurable terms.** Not "scrap is up" but "burr defects on product family A have risen markedly over the last 14 days", with a clear defect code, product and period. The [steps for setting KPIs](https://digitalbridge.com.tr/en/blog/how-to-set-kpis.html) help here.
2. **Join the data into one table.** Match the five data families on work order, batch and time. Align sources whose clocks differ, and clean duplicate and missing records using [data quality rules](https://digitalbridge.com.tr/en/blog/data-quality-duplicates.html).
3. **Focus with a Pareto chart.** Rank defects by type, machine and product. A handful of categories usually carries most of the loss, so narrow the analysis to them.
4. **Stratify.** Break the same defect down by shift, machine, tool, material batch and operator in turn. If it clusters in a single stratum, you have a strong lead.
5. **Test the hypothesis on the timeline.** Overlay the suspect parameter (mould temperature, say) on the hours when defects appeared. Use a control chart for variation and drift; correlation alone isn't proof, the timing has to line up too.
6. **Verify the fix with data.** Apply the countermeasure and track the same indicator across the same strata. If the defect rate drops in the relevant stratum, you've found the root cause; if not, go back to step 4.

### Three common traps

First, **mistaking correlation for cause**: two variables rising together doesn't mean one drives the other; a third factor may drive both. Second, **settling for averages**: daily mean temperature can look normal while defects occur during short spikes, so you need the raw time series. Third, **closing the case as "human error"**: the data usually points not at the operator but at the instruction, tool or setting that led them into the mistake.

## Which analysis technique answers which question?

Not every question needs a heavy AI model. Many root causes become visible in properly joined data using simple techniques.

| Question | Suitable technique | When it falls short |
|---|---|---|
| Where is most of the loss? | Pareto analysis | Defect codes entered inconsistently |
| Does the defect cluster under certain conditions? | Stratification, cross-tabulation | Key fields (batch, tool) missing |
| Is the process stable, and when did it shift? | Control chart, time series | Sampling too sparse to catch the event |
| Which parameter moves with the defect? | Correlation, regression | Many interacting variables |
| Can we see abnormal behaviour in advance? | Anomaly detection, machine learning | Little labelled history |

The last row moves the analysis from looking back to warning ahead. To catch sensor drift before a defect occurs, [anomaly detection methods](https://digitalbridge.com.tr/en/blog/anomaly-detection-guide.html) come into play, and for machine-driven problems they pair naturally with [predictive maintenance](https://digitalbridge.com.tr/en/blog/predictive-maintenance-guide.html).

## The infrastructure that keeps data analysis-ready

Rebuilding root cause analysis in a spreadsheet every time isn't sustainable. A lasting setup has three layers.

The **collection layer** pulls machine and sensor data from the floor. Across dispersed sites, a [remote monitoring IoT platform](https://digitalbridge.com.tr/en/blog/remote-monitoring-iot-platform.html) can do this job; on the line, [MES and production management](https://digitalbridge.com.tr/en/industry-40/mes-production-management.html) generates work order, batch and stoppage records. For stoppage reasons to be recorded properly at source, an [andon system](https://digitalbridge.com.tr/en/blog/andon-system-explained.html) is a good starting point.

The **integration layer** matches these sources with ERP and quality records on shared keys. A [data warehouse and ETL platform](https://digitalbridge.com.tr/en/data-analytics/data-warehouse.html) holds the history here; we cover the architecture in our [data warehouse and ETL guide](https://digitalbridge.com.tr/en/blog/data-warehouse-etl-guide.html). Second-by-second sensor history goes not into the warehouse but into a [time-series database for sensor data](https://digitalbridge.com.tr/en/blog/time-series-database-iot-data.html), and is matched in the analysis on a shared time key.

The **visualisation layer** shows Pareto, strata and time series on one screen. The aim isn't decorative charts but the ability to drill from a defect to its machine, batch and parameter in two clicks. [BI dashboards and management reporting](https://digitalbridge.com.tr/en/data-analytics/bi-dashboard.html) provide this; for design principles see our [guide to building a BI dashboard](https://digitalbridge.com.tr/en/blog/bi-dashboard-kpis.html).

## How we do this at Digital Bridge

We don't install an off-the-shelf package; we start from your problem. The work usually runs in four stages.

**Discovery and needs analysis.** We pick one recurring defect or stoppage and map where each piece of data lives today. We then list, concretely, which join keys are missing between machine, batch, quality and shift data. For Industry 4.0 projects the site assessment is free of charge.

**Data capture and integration.** We capture the missing keys on the floor: where needed, we set up the batch link with [barcode-based production traceability](https://digitalbridge.com.tr/en/industry-40/production-traceability-barcode.html) and the parameter stream via PLC and sensor reads. Our MES integrates with Logo, SAP, Mikro and bespoke ERP systems (Logo and Mikro are widely used Turkish ERP packages), and we tie quality records into the same data model through a [quality management system](https://digitalbridge.com.tr/en/industry-40/quality-management-system.html).

**Pilot.** We start with one line or product family. We build the Pareto, strata and time-series views for the chosen problem, then run the first data-driven root cause session together with your team. For machine-driven issues, our [anomaly detection service](https://digitalbridge.com.tr/en/technology-hardware/anomaly-detection.html) adds early warnings on the sensor stream.

**Roll-out.** The data model and screens that worked in the pilot are extended to other lines. Because software and hardware come from the same team, there's no gap in responsibility between the sensor, the data collection unit and the dashboard. You'll find our other guides in this area on the [Data & Analytics topic page](https://digitalbridge.com.tr/en/blog/topic/veri.html).

## Next step

Finding root causes doesn't need a new method so much as connected data. If you have a recurring scrap or downtime problem, let's work through it together and show you exactly which data is missing. [Get in touch via our contact page](https://digitalbridge.com.tr/en/contact.html) for a short discovery call; we'll review your current data sources and propose a written scope for a pilot.

## Frequently Asked Questions

### What is the difference between manufacturing data analytics and root cause analysis?

Root cause analysis is the method for finding the true source of a problem, run with tools such as 5 Whys, fishbone diagrams or 8D. Manufacturing data analytics supplies the evidence for that method. Once machine, batch, shift and quality data are joined, the team relies on facts rather than opinion, and can use the same data to check whether the corrective action actually worked.

### What data is essential for root cause analysis in production?

At minimum you need four things: the defect type and quantity, the work order or batch number of the defective part, and the machine and timestamp where it was made. Adding process parameters, shift, tooling and raw material batch deepens the analysis. If the key fields are missing, the data can't be joined, so recording discipline has to come first.

### Can you find root causes with data without using AI?

Yes. Many production problems become visible in well-joined data through Pareto analysis, stratification and control charts. Machine learning adds value when many parameters interact, or when you want to catch drift before a defect occurs. A sensible order is basic analysis first, then advanced methods only where the simpler ones run out of road.

### Can older machines provide data for root cause analysis?

In most cases, yes. Machines without a controller can be fitted with current clamps, counters or external temperature and vibration sensors to capture running state and basic parameters. Machines with a PLC can be read directly. What matters is that this data is aligned with work order and batch information on the same timeline.

### What drives the cost of a manufacturing data analytics project?

The main cost factors are the number of machines and lines to connect, whether those machines have a PLC or need extra sensors, which ERP and quality systems must be integrated, how long historical data is kept and how many dashboards you need. Starting with a single-line pilot pins down the scope. The price is set in a written proposal covering scope and phases after a needs analysis.

### Where should we start with data-driven root cause analysis?

Start with a single recurring problem whose cost is known. List the data that could explain it, capture the missing join fields on the floor, and run your first Pareto and stratification analysis on a few weeks of data. A small but measurable pilot delivers results faster than trying to digitise the whole plant at once.