Nonconformance report (NCR) data usually spans quality, production, and supply chain domains, so some of it should be shared with ERP and MES. What to share depends on how those systems are used in your plant, how integrations are validated, and how responsibilities are split between QMS, ERP, and MES. In most regulated, brownfield environments you share a subset of NCR data that affects planning, execution, traceability, and cost, not the entire record.
Core principle: share impact, not the entire NCR file
ERP and MES typically do not need the full NCR form, attachments, or detailed investigation notes. They need:
- Enough information to plan, schedule, and execute work correctly.
- Enough information to preserve traceability and cost accuracy.
- Stable identifiers that let users link back to the authoritative NCR in the QMS.
The QMS or quality module remains the record of truth for the NCR itself. ERP and MES consume selected fields.
NCR data typically shared with ERP
ERP is concerned with inventory, cost, planning, and supplier/commercial impact. NCR data shared with ERP usually includes:
- NCR linkage and status
- NCR ID or reference number (for traceability back to QMS).
- High level status: open, under review, dispositioned, closed.
- Criticality or severity class when it affects holds or approvals.
- Item and lot/serial details
- Part number and revision that failed.
- Lot, batch, or serial numbers (as used in ERP item/lot control).
- Quantity affected and unit of measure.
- Warehouse/storage location or plant if relevant to inventory holds.
- Inventory and disposition impact
- Nonconforming quantity put on quality hold or quarantine.
- Approved disposition: use as is, rework, repair, scrap, return to vendor, concession, etc.
- Approved rework or deviation order references if ERP manages them.
- Adjustments to available-to-promise or safety stock if used.
- Cost and financial impact
- Scrap quantity and cost (direct material and, when appropriate, labor and overhead).
- Rework labor and material booking references (to cost centers or work orders).
- Flags for cost of poor quality (COPQ) reporting if done in ERP.
- Supplier-facing data (for purchased material NCRs)
- Supplier/vendor ID and related purchase order lines.
- Return to vendor disposition and quantities.
- Debit/credit memo references if you charge back the supplier.
- Basic defect category or code when needed for supplier scorecards.
- Customer/order impact (for customer-specific work)
- Sales order, delivery, or project references affected by the NCR.
- Shipment holds or concessions that change delivery or invoicing.
Detailed root cause analysis, 5-whys, and corrective action plans generally stay in the QMS or CAPA system, with only summarized effects or status flags pushed to ERP when they influence release, approvals, or customer communications.
NCR data typically shared with MES
MES needs information that directly affects execution, work instructions, process control, and electronic batch/lot records. Typically you share:
- NCR linkage within the route or operation
- NCR ID and related operation/step, work order, and equipment.
- Timestamp of detection and responsible station or workcenter.
- Simple status flags: under review, rework required, blocked, released.
- Defect and process context
- Structured defect codes (e.g., dimensional out-of-tolerance, foreign object, documentation error).
- Severity or classification when it influences stop rules or escalation.
- Inspection or test step where the nonconformance occurred.
- Basic data needed for SPC or defect trend reporting (e.g., characteristics failed).
- Material segregation and routing impact
- Which units, lots, or serials must be held, reworked, or scrapped.
- Rework or repair routes, operations, and work instructions if MES controls them.
- Flags to prevent continuation of processing without quality signoff.
- Equipment and process constraints
- Impacted equipment, fixtures, or tools if they must be taken out of service.
- Temporary process controls or additional inspections driven by the NCR.
- Special approvals required to run (e.g., deviation, waiver references).
- Traceability and batch record content
- Link from each affected unit/lot/serial in the MES genealogy to the NCR ID.
- Disposition outcome (e.g., reworked and accepted, scrapped, regraded).
- Quality signoff records related to closing the NCR on the shop floor.
Again, detailed investigation documents (e.g., photos, long narrative problem descriptions) usually stay in the QMS, with MES holding a pointer and relevant structured codes and statuses.
Data that is usually not shared verbatim
To avoid duplication and validation burden, many plants intentionally do not replicate the full NCR record into ERP and MES. Data that typically stays in the QMS or dedicated CAPA system includes:
- Detailed problem descriptions and long text narratives.
- 5-whys, fishbone diagrams, and other root cause analysis artifacts.
- Internal emails, meeting notes, and unstructured discussion.
- Full corrective and preventive action plans and effectiveness reviews.
- Rich media attachments (photos, scans), unless your MES stores them as part of batch records by design.
ERP and MES need to be able to navigate to this information via a stable NCR ID or URL, not necessarily store it themselves. This reduces synchronization issues and change control overhead.
Key dependencies and tradeoffs
The exact NCR data you share must be tailored to your environment. Critical dependencies include:
- System roles and boundaries: If your ERP also functions as your primary QMS for NCRs, you may not need to “share” data, just expose it to other modules. In other cases, an independent QMS or PLM owns NCRs, and ERP/MES receive a limited feed.
- Master data ownership: Part numbers, revisions, suppliers, and work centers should come from the system of record. Replicating these as free text in multiple systems leads to mismatches and reconciliation issues.
- Integration and validation maturity: In regulated environments, every field synchronized across systems increases integration complexity, testing, and revalidation load. Sharing fewer, well-defined fields is usually more robust than mirroring the entire NCR form.
- Change control and lifecycle: Equipment and core systems often run for decades. Designing a minimal, stable NCR interface surface reduces rework when systems are upgraded or replaced.
- Reporting requirements: If cross-system KPIs (e.g., cost of poor quality mapped to scrap and rework orders) are critical, you may justify pushing more structured NCR data into ERP. If analytics run on a data warehouse, you may push richer NCR detail there instead of expanding ERP/MES schemas.
Brownfield coexistence: avoiding full replacement strategies
Attempting to make ERP or MES the full replacement NCR system often fails in aerospace-grade and similar environments because:
- Existing QMS workflows are heavily embedded in audits, procedures, and training.
- Migrating all NCR history and CAPA records requires high validation effort and downtime risk.
- MES and ERP are not typically optimized for complex investigations and regulatory evidence packages.
- Any major process change may trigger requalification, updated work instructions, and retraining.
A more practical pattern is keeping NCR creation and investigation in the QMS, synchronizing the specific ERP and MES fields needed for material control, execution, and reporting, and linking systems via stable identifiers and controlled interfaces.
Practical starting point
A disciplined way to decide which NCR data to share is:
- List the decisions ERP must make that depend on nonconforming material (inventory, cost, supplier action, customer commitment).
- List the decisions MES must make (can this unit move, what rework is required, what additional checks are needed).
- Map each decision to the minimum NCR fields required.
- Confirm which system owns each master data element and avoid duplicating ownership.
- Design and validate interfaces that share only those fields, with clear change control and traceability back to the master NCR record.
This keeps ERP and MES aligned with quality reality while keeping integration manageable and auditable over long system lifecycles.
