Search the Elsmar Cove!
**Search ALL of** with DuckDuckGo including content not in the forum - Search results with No ads.

Defect codes and process codes need to be controlled

We have a Boeing contract for Air Force product. We recently had a Air Force audit and the QAS generated a finding stating, "NCR defect codes and process codes are not controlled." He advised us because we manufacturer/assemble critical safety items and have serialization requirements, the codes must be controlled, at a minimum, "start date, reason code was generated, control changes to the code(s), end-of-life for the codes to include reason." During the audit, we provided him a procedure with the codes listed. When he asked specifics of when the code(s) were implemented, we could not provide him this information and this included end-of-life (EOL) for the codes. He said this was necessary as we have elected to use the code as the means to address nonconforming product and therefore, these codes must be controlled.

I disagree as the codes are specific to the NCR incident report and we have the means to know what happen at that point in time and can trend for systemic issues. He disagrees and says we must have traceability back to the codes and the NCR report shall support the closed-loop process of planning a correction and evaluating its effectiveness. Because the codes are not controlled, the defect codes could be in error or not traceable to a previous incident. I am at my wits with this auditor about this finding!

He did say he is not looking for revision control of the codes, but a "type" of record of the defect and process code with the minimums I described above.

I reached out to our 3rd party certification body auditor and she stated she would have to investigate further, with a cost.

We are a AS9100D certified company and machine and assemble military and commercial components.

Thank you for the information. What the Air Force auditor is looking for is when the codes were released, if any changes to the code definitions and EOL for the code. I think how this all came about, we had a defect code for bending. We decided we needed to clarify by adding two additional codes for bending errors based on human or machine. He stated because we basically took the one code and made two codes, there should have been a record of this change to include terminating the previous code on bending. He said when he trended our data, he saw the previous code gone and then two other codes in its place. This caused his data analysis reporting to be inaccurate as he does not have the ability trace back to a time and or a reason for the change with the code changes. He stated if we had a record, he could have incorporated the record into the audit report. Because of this, he wrote us up for not having controlled conditions for the defect and process codes. He stressed, defect codes are replacing the reason for the nonconformance. Defect codes and process codes does not relieve your organization from "the organization is expected to develop processes with the objective of ensuring that all discovered nonconformity(s) are identified, analyzed, managed, and controlled."

Controlled being one aspect for the defect codes and process codes.

I think I get it.

-NCR Report from 2000: Code 01 means one thing on this report (operator error)
-NCR Report from 2019: Code 01 means something else on that report (calibration not conducted)

At one point in time, organization decided operator error was no longer a valid defect code. When? What would Code 01 mean in 2010, Calibration or Operator?

If you had a list of codes, with revisions, and a change history table describing 'Rev. 02 Code 01 changed from Operator to Calibration May 2, 2009', you would be able to determine the cause code meaning at the time of the report.

Is that the answer?

Top Bottom