SAP QM

QM plans and records quality inspections (of incoming goods, in-process production, and outgoing products), manages defects via quality notifications, handles quality certificates, and controls whether materials can be used based on inspection results. It embeds quality into the logistics processes.

• Inspection Planning & Lots: what and how to inspect.
• Results Recording & Usage Decision: pass/fail and disposition.
• Quality Notifications: handling defects/complaints.
• Quality Certificates.
• Quality in procurement/production/sales.

QM is unusual in that it mostly runs inside other people's processes. It is switched on per material through the QM view on the material master, where inspection types decide which events trigger an inspection.

Master data comes first. QS21 maintains a master inspection characteristic, the thing being measured, such as a diameter with its tolerance. QP01 creates an inspection plan, which pairs characteristics with operations, much as a routing does for production. QDV1 maintains sampling procedures, deciding how many units to check.

Execution: QA32 is the inspection lot worklist, the screen QM people live in. QE51N records results against characteristics. QA11 makes the usage decision, which is the moment stock moves from inspection to unrestricted or to blocked. QM01 raises a quality notification for a defect or a complaint.

The tables are QALS for inspection lots, QAMV for the characteristics on a lot and QAVE for usage decisions.

Half an hour, and it shows why QM is described as a control rather than a module.

1. Set up a material with the QM view and an inspection type for goods receipt, with an inspection plan behind it.
2. Post a goods receipt against a purchase order with MIGO. The stock arrives in quality inspection stock, not unrestricted, and an inspection lot is created automatically.
3. Try to issue that stock. It refuses, because inspection stock is not available.
4. Open QA32, find the lot, and record results with QE51N against the characteristics from the plan.
5. Make the usage decision with QA11. Accept, and the stock posts to unrestricted. Reject, and it posts to blocked or is returned.

Step three is the point of the whole module. QM does not inspect things; it stops them being used until somebody decides.

QM integrates with MM (inspect incoming goods, block stock until approved), PP (in-process inspections), and SD (outgoing quality, certificates). It ensures quality gates are enforced within the standard logistics flows rather than bolted on afterwards.

The integration to know is that QM inserts itself into existing flows rather than running its own. A goods receipt in MM creates an inspection lot. A production confirmation creates one. A delivery in SD can require a certificate before it ships. Each of those is the other module's process with a QM gate in it, which is why QM configuration is nearly always a conversation with the module it is constraining.

• Which inspection types to activate. Every one is a gate that stops stock. Turning on goods receipt inspection for everything creates a queue nobody can clear.
• How much sampling. One hundred per cent inspection is thorough and expensive. Sampling procedures trade certainty for throughput, and the level should follow risk.
• Whether quality blocks or warns. A hard block is a real control and it stops the business when quality is understaffed.
• Certificates and batches. Regulated industries need the batch record and the certificate, and that decision cascades into projects and warehousing.

• Where quality sits organisationally. A quality team that reports to production is under pressure to release; one that reports independently can hold a batch. The system enforces whichever the business decides, and it cannot substitute for the decision.

Inspection is the planned half of QM. Notifications are the unplanned half, and they are where the module earns its keep in a business with real quality problems.

A quality notification records that something went wrong: a customer complaint, a supplier defect, an internal problem. It carries the defect, the affected material and quantity, and then a structured investigation.

The structure is worth knowing because it is what turns complaints into improvement. Items record what was wrong. Causes record why. Tasks record what will be done, with owners and dates. Activities record what was done. Each is coded from catalogues, which is what makes the data analysable: without codes you have a pile of text nobody can summarise.

Notifications connect outward. A supplier complaint can trigger a return delivery and a debit memo. A customer complaint can trigger a return, a credit memo and a replacement.

The reporting that follows is the argument for doing any of this: defects by supplier, by material, by cause, over time. That analysis is what changes a supplier relationship or a production process, and it is only possible if the coding was done consistently, which is a training question more than a configuration one.

In regulated industries QM is not an efficiency measure, it is the licence to operate, and the mechanism is batch management.

A batch is a quantity of material produced or received together, carrying its own characteristics: manufacturing date, expiry, potency, whatever the industry requires. Stock is tracked per batch, and batch determination decides which one is picked, typically oldest first or by shelf life remaining.

QM attaches to batches at every step. Inspection results are recorded against the batch. The usage decision releases that batch and not the material generally. A certificate of analysis can be generated from those results and sent with the delivery, which is often a contractual requirement.

Traceability is what it all enables: given a batch, which raw material batches went into it, and where did it go. That is the question asked during a recall, and the answer has to come in hours rather than days.

The implication for a project is that batch management is decided at the start, per material, and retrofitting it onto a material that already has stock is genuinely difficult.

• Learning screens, not the end-to-end process.
• Ignoring the finance integration that every logistics module has.
• Skipping master-data setup that the process depends on.

• Activating inspection without staffing it. Stock arrives, sits in inspection, and production stops for a reason that looks like a supply problem.
• Usage decisions made in bulk to clear a backlog. That is the control being switched off by habit rather than by decision.
• Inspection plans that never change. They age with the product. See supplier management for the vendor side of quality.

• Recording results without the sampling procedure behind them. Inspecting some units and treating the result as certain about all of them is a statistical claim, and the procedure is what makes it a defensible one.

• Catalogues left as delivered. Defect and cause codes are what make notification data analysable, and generic codes produce reports that say nothing anyone can act on.

Recording a result is the easy half, and designing inspection types, plans and sampling so quality is controlled without stopping the business is the part you do in the course.

The instinct worth taking from this page is that QM problems are usually other modules' problems with a quality gate in front of them. Before changing anything in QM, check whether the inspection is doing exactly what it was configured to do and the real question is whether it should have been configured at all.