From Tool Data to Yield and Scrap Analytics

Clean, structured data is the prerequisite — not a nice-to-have

You cannot compute trustworthy yield on numbers you had to hand-copy. If someone is transcribing counts off a tool printout into a spreadsheet at the end of a shift, every downstream number inherits that person's typos, their guesses about ambiguous readouts, and the units they silently skipped when they got busy. A yield of "94%" built on hand-keyed data is not a measurement — it is an estimate wearing a lab coat.

So the first job is not analytics at all. It is getting the raw output of your tools into a consistent, machine-readable shape. That is the whole point of manufacturing data mapping: taking the RTF, TXT, CSV, and log files your equipment spits out and turning them into structured records that always mean the same thing. Once that pipeline exists and runs without a human retyping anything, yield and scrap analytics stop being a data-wrangling project and become simple arithmetic on top of clean records.

What yield analytics actually needs

Yield is just good units divided by total units. The difficulty is never the division — it is defining a "unit" consistently and knowing, for each one, whether it passed. That requires a per-unit record with a stable identity and a clear pass/fail result. What the unit is called depends on your process:

• On a test bench it is often a unit serial and a test name, sometimes nested inside a batch or lot, so you can roll individual test results up to a unit and units up to a batch.
• In CNC machining it is a part and the specific feature or dimension being checked against a tolerance.
• In injection molding it is a job, a shot, and a cavity — because a single mold produces multiple parts at once and one cavity can misbehave while the rest are fine.

Get those identifiers right and yield falls out naturally. You can slice the same number by lot, by shift, by tool, by part number, or by cavity without recomputing anything, because every record already carries the fields that let it join to the others. The pass/fail flag has to be unambiguous too — a measured value plus its spec limits, not a subjective "looked okay." When pass/fail is derived from real measurements and limits, your yield number is defensible, and so is every chart built on it.

Scrap tracking: attributing loss to a cause

Yield tells you how much you lost. Scrap tracking tells you why. A scrap count with no reason attached is a number you can watch go up and down but never act on. The value is in the attribution: this unit was scrapped, and here is what caused it, which tool it ran on, and — where it applies — which cavity or station produced it.

That means your structured records need a scrap reason field with a controlled, consistent vocabulary. "Chip on edge," "dimension out of tolerance," and "short shot" are useful categories; a free-text box where one operator writes "cracked" and another writes "crack" and a third writes "broke" is not. When the reason codes are consistent, you can finally answer the questions that save money: which failure mode costs you the most, whether it clusters on one machine, whether one cavity in a mold is responsible for a disproportionate share of the reject pile. Attribution is what turns scrap from an accounting line into a to-do list.

The reject log is its own signal

Most shops treat the quarantine or reject log as a compliance artifact — something you keep because you have to. It is more than that. The pattern of what gets rejected, and when, is one of the earliest signals you have of tool health and process drift.

A tool that is starting to wear does not usually fail all at once. It nudges its output toward one edge of the spec, and the reject log fills up with a specific failure mode before overall yield drops enough to alarm anyone. If you are watching reject reasons over time, a slow climb in one category on one machine is a maintenance flag weeks before it becomes a scrap problem. The same log that satisfies your auditor becomes a leading indicator — but only if it is structured and queryable, not a stack of paper tags in a bin.

SPC and Cpk on the parameters that drive quality

Pass/fail counting is backward-looking — it tells you a part already failed. Statistical process control looks forward. Instead of waiting for a part to fall outside the spec, SPC tracks the actual measured values of the parameters that drive quality and watches how their distribution behaves over time.

The everyday tools are control charts and capability indices like Cpk, which compare the spread of your process against the width of your spec window. A high Cpk means you have comfortable margin; a falling Cpk means the process is drifting toward a limit even while parts still technically pass. That early warning is the entire point. But SPC only works on real numeric measurements — a critical dimension, a temperature, a cycle time, a resistance reading — not on a pass/fail flag. This is another reason the structured-data step matters: SPC needs the underlying value preserved, not thrown away the moment a part is judged good.

You do not chart everything. You pick the handful of parameters that actually correlate with the failures you see, and you put SPC on those. A focused set of well-chosen control charts beats a wall of charts nobody reads.

Turning it into live dashboards and alerts

Once the records are clean and the definitions are settled, the dashboard is mostly presentation. Yield by line and shift, scrap broken down by reason and tool, control charts on your key parameters, and a running view of the reject log — these are queries against structured data, refreshed on a schedule.

Alerts are where dashboards earn their keep. A screen only helps the person looking at it; an alert reaches the person who needs to act. A rule as simple as "notify the process engineer when Cpk on this dimension drops below 1.33" or "flag when scrap for this reason exceeds its usual daily rate" moves you from reacting to yesterday's numbers to catching problems as they start. The threshold logic is straightforward — the reason it works at all is that it is running on data you can trust.

A realistic path from raw files to a working yield view

You do not build all of this at once, and you should not try. A sane order looks like this:

• Get one tool's raw files parsing reliably into structured records — the same fields, the same units, every time, with no hand-keying.
• Nail down your unit identity and pass/fail definition for that process, and confirm the resulting yield matches what people already believe by hand.
• Add scrap reason codes with a controlled vocabulary, so loss can be attributed to a cause and a tool.
• Stand up a simple yield-and-scrap view. Rough is fine — the goal is a number people trust enough to argue about.
• Layer SPC onto the few parameters that matter, then wire up alerts on the ones worth waking someone for.

Notice that four of those five steps are about data, not charts. That is the honest shape of this work. The analytics everyone wants are genuinely easy once the foundation is right — and permanently unreliable when it is not. Start with clean, structured tool data, prove out one yield view end to end, and expand from there. The dashboard will feel like the reward it should be, instead of a pretty layer over numbers you quietly do not believe.