Nonconformities: how to close them so they stay closed
A method to record, contain and analyze nonconformities, define corrective actions, verify their effectiveness and measure the system with a few indicators and a worked example.
A customer returns a box because the labels carry the wrong lot number. The labels are reprinted, the order is shipped again and the log says “operator error”. Three weeks later it happens again, with a different operator. The nonconformity had been closed, but the problem was still there: the product was fixed, not the cause.
This article explains how to handle a nonconformity from start to finish, how to find the root cause, how to tell whether the action worked and which indicators to watch. All of it can be done in a spreadsheet.
Correction, corrective action and improvement are not the same
Many of the nonconformities that come back are born from mixing up these three ideas.
| Concept | What it does | Example with the labels |
|---|---|---|
| Correction (containment) | Removes the immediate effect | Relabel the boxes and check the rest of the lot |
| Corrective action | Removes the cause so it does not happen again | Change the lot changeover procedure and the label template |
| Improvement opportunity | Improves something that already complies | Print the label from the production order instead of typing it |
A nonconformity without a correction leaves the customer with the problem. One without a corrective action leaves you with it.
The method, step by step
- Record the event. What happened, where, when, how much product or service is affected, who detected it and which requirement was not met (the customer’s, an internal procedure or the standard). Attach the evidence: photos, the document, the lot.
- Rate the severity. A simple scale is enough: major (affects the customer or repeats systematically) and minor (isolated event with no customer impact). Severity sets deadlines and who must verify.
- Contain before you analyze. Segregate the suspect product, check what has already shipped and decide the disposition: rework, accept under concession, return to the supplier or scrap. Record the decision and who authorized it.
- Find the root cause. Use the 5 whys for linear problems and the Ishikawa diagram (6M: manpower, method, machine, material, measurement and environment) when several causes are possible. If the final answer is “human error”, keep asking: what allowed the error to happen without anyone catching it?
- Define actions with an owner and a date. Each action must address an identified cause. “Train the staff” only counts if the cause really was lack of knowledge.
- Verify effectiveness. After a reasonable time, check whether the problem came back. Someone other than the person who carried out the action does the check, at least for major nonconformities.
- Close only with evidence. A nonconformity is closed when there is a documented root cause, at least one action verified as effective and no pending actions.
Worked example: the labels
Let’s apply the 5 whys to the opening case:
- Why did the label carry the wrong lot? Because the operator printed with the lot from the previous order.
- Why? Because the label template keeps the last value typed.
- Why did nobody notice? Because there is no first-label check at lot changeover.
- Why not? Because the lot changeover procedure does not include it.
- Why? Because it was written when labeling was done by hand and was never updated when the printer changed.
The root cause is not the operator: it is an outdated procedure and a template that makes the error easy. There are two corrective actions: clear the lot field on every print, and add to the procedure a first-label check signed by the supervisor.
Now the cost. Assume these hypothetical figures for each time it happens:
| Item | Calculation | Amount |
|---|---|---|
| Rework (relabeling) | 300 boxes × Bs 4 | Bs 1,200 |
| Scrapped labels and damaged boxes | 50 units × Bs 12 | Bs 600 |
| Lot reinspection | 6 hours × Bs 25 | Bs 150 |
| Reshipping freight | Bs 250 | |
| Total per event | Bs 2,200 |
If the problem repeats once a month, that is Bs 26,400 a year. The corrective action costs, say, Bs 800 between fixing the template and one hour of training per shift. That number is what convinces management to spend time on the analysis and not just on the correction.
Indicators to know whether the system works
| Indicator | Formula | How to read it |
|---|---|---|
| NCs closed on time | Closed within the deadline ÷ closed in the period | Low means unrealistic deadlines or weak follow-up |
| Action effectiveness | Effective ÷ (effective + not effective), over those verified | Low means shallow root cause analysis |
| Recurrence | NCs repeating an already treated cause ÷ NCs closed | Should trend toward zero |
| Aging | Days open, grouped in bands (0–30, 31–60, 61–90, over 90) | Shows where work gets stuck |
| Cost of poor quality | Sum of rework, scrap, returns and reinspection | Tells you where to act first |
Suppose that in one quarter you closed 30 nonconformities, 24 within the deadline: 80% on time. You verified 22 actions: 18 effective and 4 not effective, that is 81.8% effectiveness. Three of the 30 repeated a cause already treated: 10% recurrence. With those three numbers you already know the problem is not speed but the depth of the analysis.
A Pareto of causes (by 6M category or by process) usually shows that a few causes explain most cases. That is where actions go first. If your nonconformities start in lots, traceability matters a lot; we cover it in FEFO vs FIFO.
Common mistakes
- Closing with “staff was trained” without showing the cause was lack of knowledge.
- Analyzing the cause before containing: while people discuss, product keeps shipping.
- Having the person who carried out the action verify its effectiveness.
- Verifying on the same day the action is implemented: the problem has had no time to come back.
- Opening a new nonconformity every time the same problem repeats, instead of reopening the analysis.
- Not recording costs, and therefore being unable to prioritize.
Checklist before closing
- The event is described with evidence and the unmet requirement is identified.
- Containment and product disposition are recorded, with who authorized them.
- The root cause is documented with 5 whys or Ishikawa, and does not end in “human error”.
- Each action has an owner and a date and is tied to a cause.
- Someone else verified effectiveness, after a reasonable time.
- The related costs are recorded.
If you want to automate it
A spreadsheet works as long as someone keeps it up to date. As volume grows, an ERP like MKA can require containment before analysis, record the 5 whys or the Ishikawa diagram, prevent, from the level you configure, the person who completed the action from verifying its effectiveness, and add up the cost of poor quality by process and by month (see management systems).