Case Story: Rejections That Kept Coming Back, and the Data That Ended the Arguments

The problem

A plant we work with makes parts that pass through several tests before dispatch. Rejections were not new to it. What troubled the owner was that the same kinds of rejection kept coming back.

When we sat with the team, we found three reasons.

First, the data could not be trusted. Many rejection entries had no reason. Sometimes the wrong item was picked from a list, so a rejection showed against the wrong customer. When numbers were doubted, a meeting of ten people spent its hour arguing about the figures, not about the problem.

Second, checks were uneven. The first piece was checked with care only for new items. In some places, final inspection had become a signature on the tag. Nobody was clearly named for each inspection stage.

Third, some rejections came after the last check. Parts passed final inspection and still reached the customer damaged.

What we built

1. Accuracy before analysis. From the first day of a month, no rejection is entered without its reason and its machine number. If the reason is not clear, the supervisors discuss the likely reason and enter it before the next day. Starting on the first gives a full month that can be compared.
2. A report shaped like the real flow. The rejection report has one column for each test, in the order the tests happen, with a list to pick the test and the reason. The quantity that goes to the next test is the passed quantity of the one before. Beside it runs a ladder of OK quantity at each stage (made, finished, tested, packed, dispatched), so the owner sees where the quantity falls away.
3. No wrong items. The item now fills in on its own from the work order number. Nobody types or picks it, so the same product sold to two customers stays separate.
4. One reading rhythm. Rejection is read every day as a percentage, even when rough, and reviewed every week on a fixed day: this week against last week, then the month. On the dashboard, one click on a day splits the rejection by customer, item, stage and machine. In review, we pick one wrong figure and walk it back to the entry that made it.
5. One name per stage. Incoming, first piece, in-process, testing and final inspection each have one named person and one backup.
6. Checks where the trouble starts. The first piece is checked after every set-up, and there is an in-process check before and after lunch.
7. Looking past the last check. For parts that passed inspection and still came back damaged, the team looked at packing, stacking and the journey. A visual check of each part as it goes into the box was added at packing, and separators between layers were discussed.
8. No shortcuts in process time. One urgent order had once been made with a shorter process time, and test failures followed later. The principle agreed: a process time is never cut to meet a date without a trial. The planner plans backwards from the dispatch date and keeps the full time.

A customer complaint is also booked in two places: in sales for the immediate action, and in quality for the root cause and the preventive action.

When people doubt the numbers, the meeting argues about the numbers. When they trust them, it works on the problem.

What changed

• Every rejection now carries a reason, a stage and a machine, so the review starts from the cause, not from a total.
• Each inspection stage has a named person and a backup.
• Damage after final inspection is treated as a packing and handling problem, with its own check.

What other plants can take from this

• Make the data accurate before you analyse it. Start on the first of a month.
• Shape the rejection report like the real sequence of stages and tests.
• Let the item fill from the work order, so it cannot be picked wrongly.
• Name one person and one backup for every inspection stage.
• When parts pass the last check and still fail, look at packing and transport.
• Never shorten a process time to meet a date without a trial.