Quality · NCR
How NCRs should be tracked in panel manufacturing
· 5 min read
Quality issues happen on every floor. A wrong terminal torque, a busbar drilled to the old revision, a missing earth link, an IP gasket left out — none of it is unusual in a panel shop. The problem is rarely the non-conformance itself. It's what happens next.
On most floors the answer is a loose form. Someone writes it up, it goes in a tray or a shared folder, and it lives there with no link to the job, no owner and no record of how it was closed. By handover nobody can find it, and by the next build the same fault comes back because nothing was learned.
Tracked properly, an NCR is cheap and useful. It catches a defect while it costs pounds to fix rather than after test or, worse, on site. Here is what "properly" looks like.
The loose form is the problem
A non-conformance written on a standalone form is disconnected from everything that gives it meaning. It doesn't sit against the panel it came from. It doesn't tell you which build stage it was raised at. It has no owner the system will chase, and no status anyone can see without going to find the paper.
So it drifts. It gets closed verbally — "yeah, we sorted that" — with nothing recorded. Or it never gets closed at all and quietly disappears. Either way you've lost the two things an NCR is for: proof the issue was dealt with, and a record you can learn from. Under BS EN IEC 61439 you're expected to control non-conforming work; a form nobody can find is not control.
Raise it against the job and the stage
An NCR should be logged against the specific panel and the build stage it relates to — Kitting, Build, Test or QA — not on a separate quality spreadsheet. Raising it in context means it carries the job number, the revision, who was working on it and when, without anyone retyping it. It sits in the same audit trail as the rest of the build, so the story of that panel is complete in one place.
Tie it to the stage and the pattern becomes visible too. If most of your non-conformances are raised at Test, the problem is upstream in Build. If they cluster at Kitting, your BOM or your incoming inspection is letting things through. You can't see that when every NCR is a loose sheet in a tray.
What good looks like
A working NCR process is boring, which is the point. Every non-conformance has one owner, a clear open or closed status, and a resolution recorded against the job. Open items are visible across the floor — surfaced alongside at-risk jobs and pending approvals — so they get acted on rather than buried. Nothing gets closed on someone's word.
Closure captures what actually happened: what the defect was, how it was corrected, who verified it and what evidence backs that up — a photo of the reworked termination, a re-test result, a QA sign-off. That evidence does double duty. It's what you hand the client at FAT, and it's the raw material for spotting a fault that keeps recurring. When the same disposition shows up on three panels, that's a signal to fix the process, not just the panel.
A checklist for an NCR process that works on the floor
- Raised against the specific panel and build stage — never on a standalone form disconnected from the job.
- One named owner and a clear open or closed status, so responsibility is never ambiguous.
- A disposition recorded for every item: use-as-is, rework, repair, or reject — not just "sorted".
- Photo or measurement evidence attached at closure — the reworked joint, the corrected torque, the re-test result.
- Verified and signed off by someone other than the person who did the rework, keeping inspection independent.
- Open NCRs visible on a live view alongside at-risk jobs, so nothing is caught only at final QA.
- Every NCR for a job pulled automatically into the handover pack — no manual collation the week before FAT.
- Recurring faults reviewed periodically so the process gets fixed, not just the individual panel.
A worked example
Take a shop building around 30 panels a month. During Build on a distribution board, an operative notices the incoming cable gland size on the GA doesn't match the cable specified in the schedule. Rather than carry on and hope, they raise an NCR against that panel at the Build stage. It takes a minute: the job, the revision and their name are already there.
The NCR lands on the supervisor's live view straight away, flagged open. She assigns it to the design engineer, who confirms the GA is on an old revision and issues the correction. The gland is changed, the operative attaches a photo of the corrected entry, and QA verifies and closes it. The whole thing is resolved in a day and recorded against the job.
Two things follow. At handover, the client's FAT pack already contains that NCR and its evidence — no scramble to reconstruct what happened. And at the monthly review, the shop sees three similar revision mismatches that month, all traced to drawings released before sign-off. They tighten the release gate. The fault stops coming back, because for once someone could actually see it. That is the difference between a form in a tray and an NCR on the job.