Rejection Analysis: Turning Scrap into an Improvement Plan

Every manufacturer rejects material. Few learn anything from it.

The pattern is familiar: a lot fails, it gets set aside, someone notes it in a register, and the business moves on. Three months later the same problem occurs, and nobody connects the two — because nothing was recorded in a form that could be compared.

Rejections are already paid for. Analysis is how you get something back.

Why free-text notes fail

Ask five inspectors to describe the same defect and you get five phrasings: "dimension off", "size issue", "out of tolerance", "not per drawing", "measurement wrong".

Every one is accurate. Collectively they are useless, because no report can group them. The information exists and cannot be aggregated — which is functionally the same as not having it.

Standardised reasons change everything

A maintained list of rejection reasons — chosen at inspection rather than typed — makes rejections countable. Suddenly you can ask questions that were previously unanswerable:

• Which reason accounts for the most rejections this quarter?
• Which vendor produces which failure mode?
• Which process step generates the most scrap?
• Is the problem we fixed last month actually staying fixed?

FlexgrewERP maintains rejection reasons as a master list used across all quality checkpoints — incoming, in-process, job work and returns — so the data is consistent regardless of where the rejection happened.

Building a list that gets used

Two failure modes here, opposite in direction:

Too few reasons ("Quality issue", "Other") tell you nothing. If "Other" is your most-used reason, the list is not doing its job.

Too many reasons — fifty options in a dropdown — means inspectors pick whichever is nearest the top, and the data becomes noise wearing the appearance of precision.

Aim for fifteen to twenty-five reasons that are genuinely distinguishable and matched to how your product actually fails. Review the list annually; retire what nobody uses, split anything that has become a catch-all.

Analysing what you collect

Once the data is consistent, three cuts do most of the work:

By reason

Rank rejection reasons by quantity or value. Almost always a small number account for the majority — that is your improvement backlog, ranked by the business itself.

By vendor

For incoming rejections, this is your supplier quality picture and the basis for evidence-based conversations. See vendor management.

By process

For in-process rejections, this points at the machine, step or setup that needs attention — rather than a general instruction to be more careful.

The QC summary report consolidates outcomes across checkpoints and exports to Excel and PDF, which matters because these numbers belong in a review meeting.

Value, not just count

One refinement worth making early: rank by value, not only by quantity.

Two hundred rejected fasteners and three rejected castings may look very different in a count and identical in rupees. Counting alone points improvement effort at the cheapest problems, because they are the most numerous.

Closing the loop

Analysis without action is a report nobody reads twice. A workable cycle:

1. Monthly: pull the QC summary; identify the top two or three reasons by value
2. Assign an owner to each — a person, not a department
3. Agree one concrete change — a vendor conversation, a process adjustment, a specification clarification
4. Check next month whether the reason's share actually fell

That last step is the one usually skipped, and the one that distinguishes improvement from activity. If the number did not move, the diagnosis was wrong — which is useful to know.

The realistic expectation

You will not eliminate rejections. What you can do is stop paying repeatedly for the same one, which is where most of the recoverable money sits.

See rejection reasons, QC records and summary reporting working together — book a FlexgrewERP demo.