Defect Recording
Quality Managementbeginner

Defect Recording: Catalogs, Defect Classes and Traceability

Key takeaway

πŸ“Œ KEY POINTS βœ… A defect describes what failed, where, its severity, quantity, and inspection context β€” more than a simple characteristic result. ⚠️ Don't record every failed measurement as a generic defect without purpose β€” that erodes trend analysis. πŸ’‘ Free-text-only defects make trend analysis unreliable; consistent coding enables real Pareto analysis. ━━━━━━━━━━━━━━━━━━━━ β–Ά 1.

Explanation

πŸ“Œ KEY POINTS
βœ… A defect describes what failed, where, its severity, quantity, and inspection context β€” more than a simple characteristic result.

⚠️ Don't record every failed measurement as a generic defect without purpose β€” that erodes trend analysis.

πŸ’‘ Free-text-only defects make trend analysis unreliable; consistent coding enables real Pareto analysis.

━━━━━━━━━━━━━━━━━━━━
β–Ά 1. WHAT A DEFECT CAPTURES

  • What failed, where it occurred, severity/class, quantity, inspection context
  • Traceable to inspection lot, operation, characteristic, material, batch, or notification

━━━━━━━━━━━━━━━━━━━━
β–Ά 2. STANDARDIZATION

  • Catalogs and code groups standardize defect type and object-part descriptions
  • Defect classes support severity or follow-on behavior per configuration

━━━━━━━━━━━━━━━━━━━━
⚠️ 3. THE DISCIPLINE

  • Quantitative out-of-spec results may already give measurement evidence β€” defect recording should ADD classification, location, or follow-on action, not just duplicate the number
  • Consistent coding enables Pareto analysis by defect family, supplier, work center, or product
  • Govern who can close or change defects after disposition, especially where regulatory auditability matters

━━━━━━━━━━━━━━━━━━━━
β–Ά 4. ACROSS RELEASES

  • Defect data feeds quality notifications and CAPA
  • Also exposed through embedded, CDS-based defect/Pareto analytics β€” not just classic list transactions

βœ… CHECKPOINT: explain why recording every out-of-spec measurement as a generic defect adds noise, not value.

Real project scenario

A plant recorded all defects as code 'OTHER'. Quality reports showed high defect volume but no actionable pattern. Introducing a governed defect taxonomy exposed that most issues came from one packaging operation.

Common mistakes

  • Using one generic defect code.
  • Duplicating measurement results as meaningless defects.
  • Omitting batch/operation references.
  • Changing codes after closure without governance.
  • Using free text as the only classification.

Best practices

  • Use specific defect codes.
  • Link defects to the inspection context.
  • Keep severity rules consistent.
  • Analyze Pareto trends.
  • Govern post-closure changes.

Interview angle

Explain the difference between a rejected characteristic result and a defect record, and why catalogs matter.

Practice this lesson

Quick check

1. In the lesson "Defect Recording: Catalogs, Defect Classes and Traceability", consider this project situation: A plant recorded all defects as code 'OTHER'. Which statement is correct?

2. When recording a defect against an inspection characteristic, which code typically identifies where on or in the inspected object the defect physically occurred?

3. During defect recording, what is the function of a cause code assigned to a defect item?

Interview questions

1. Using this SAP project situation β€” A plant recorded all defects as code 'OTHER' β€” explain Defect Recording: Catalogs, Defect Classes and Traceability. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

2. In incoming inspection (lot origin 01), what is a QM defect record, and how does it relate to catalogs, defect types/codes, and the results recording of inspection characteristics?

Answer it in your own words first, then compare.

Practice more with Interview AI β†’

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics