Quality Managementbeginner

QM Master Data: MICs, Inspection Methods, Catalogs and Selected Sets

Key takeaway

📌 KEY POINTS ✅ Reusing MICs across plans makes results comparable across materials, plants, and suppliers. ⚠️ Inconsistent coding (one plant says "scratch," another says "surface mark") makes enterprise defect trends unreliable. 💡 Old inspection results must remain interpretable under the historical requirement that applied when the lot was created. ━━━━━━━━━━━━━━━━━━━━ ▶ 1.

Explanation

📌 KEY POINTS
✅ Reusing MICs across plans makes results comparable across materials, plants, and suppliers.
⚠️ Inconsistent coding (one plant says "scratch," another says "surface mark") makes enterprise defect trends unreliable.
💡 Old inspection results must remain interpretable under the historical requirement that applied when the lot was created.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE MASTER-DATA OBJECTS

MICs: quantitative (unit, target, tolerance) or qualitative (catalog code groups/selected sets)
Inspection methods: document how a characteristic is tested, linked to MICs or plan characteristics
Catalogs: organize standardized codes for defects, causes, activities, usage decisions
Code groups: governance within catalogs
Selected sets: restrict valid codes for a particular business context

━━━━━━━━━━━━━━━━━━━━
⚠️ 2. THE CONSISTENCY PROBLEM

Inconsistent coding across plants breaks enterprise defect trend analysis
Duplicate MICs with different units prevent meaningful process comparison

━━━━━━━━━━━━━━━━━━━━
▶ 3. VERSION DISCIPLINE

A characteristic may change specification over time
Old inspection results must remain interpretable under the historical requirement that applied at lot creation

━━━━━━━━━━━━━━━━━━━━
▶ 4. ACROSS RELEASES

Master-data divergence across plants is a common, quiet governance gap in multi-plant/central-finance template rollouts

✅ CHECKPOINT: explain why inconsistent defect coding across plants breaks enterprise reporting even when every individual inspection is correct.

Real project scenario

Three plants used different defect code groups for the same surface defect. Corporate quality reporting showed them as unrelated issues. Harmonizing catalog governance made the defect trend visible across plants.

Common mistakes

Creating duplicate MICs for the same characteristic.
Using free text instead of governed codes.
Ignoring units and decimal precision.
Changing codes without historical/reporting impact review.
Leaving obsolete selected-set codes available.

Best practices

Reuse common characteristics.
Govern codes centrally where possible.
Standardize units.
Preserve historical semantics.
Retire obsolete codes deliberately.

Interview angle

Explain MIC, inspection method, catalog, code group and selected set with one example of each.

Practice this lesson

Quick check

1. In the lesson "QM Master Data: MICs, Inspection Methods, Catalogs and Selected Sets", consider this project situation: Three plants used different defect code groups for the same surface defect. Which statement is correct?

2. What is the correct hierarchical structure of QM catalog master data used to record codes such as defects, causes, and usage decision reasons?

3. What is the purpose of maintaining an inspection method as master data in QM?

Interview questions

1. Using this SAP project situation — Three plants used different defect code groups for the same surface defect — explain QM Master Data: MICs, Inspection Methods, Catalogs and Selected Sets. 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. What interface options exist for integrating QM master data (inspection types, catalogs, characteristics) with MM material master records in S/4HANA, and when would you use IDocs versus APIs?

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.