There is no universal “good” NCR cycle time. Reasonable targets depend on your industry, risk profile, complexity of dispositions, and how automated and integrated your systems are. That said, there are ranges that are common in regulated manufacturing and can serve as a starting point.
Typical NCR cycle time ranges
When people talk about NCR cycle time, they usually mean calendar time from NCR initiation to final disposition approval (not including completion of long-running corrective actions). In many regulated environments, you’ll see:
- Low-risk, routine NCRs (clear scrap/rework, low dollar/risk): 3 to 10 days, assuming good data capture and local disposition authority.
- Standard product NCRs with some investigation or MRB review: 10 to 30 days is a common benchmark in aerospace, medical device, and similar sectors.
- Complex, multi-site or customer-notified NCRs: 30 to 60+ days is not unusual, especially when drawing changes, supplier investigations, or customer approvals are involved.
As a practical target for a mature but realistic environment:
- Overall median NCR cycle time: 10 to 20 days.
- 90th percentile NCR cycle time: < 30 days, with known justifications for items that exceed this.
These are directional, not guarantees. Some organizations will be faster, some slower, depending on constraints, validation state, and how much they can automate handoffs.
Key factors that drive your achievable target
Reasonable cycle time targets need to reflect the reality of your systems and processes. Influencing factors include:
- Risk and regulatory class: Safety- or conformity-critical NCRs typically require more review, more signatures, and sometimes customer or regulatory notification, all of which add time.
- Product and process complexity: Complex assemblies, deep BOMs, long routing chains, and tight tolerances usually mean more stakeholders and more analysis per NCR.
- Disposition authority structure: Centralized MRB in a single site can be fast if staffed and responsive, or slow if overburdened. Distributed MRB speeds simple decisions but can introduce inconsistency if not well controlled.
- System integration and data availability: If engineers must manually pull drawings, as-built/as-planned data, supplier certs, and test records across MES, ERP, PLM, and QMS, investigations will be slower than in an integrated stack.
- Workflow automation: Email- and spreadsheet-driven NCRs are almost always slower than automated, role-based workflows in a validated QMS/MES environment.
- Plant mix and legacy systems: Brownfield sites with mixed vendors, homegrown tools, and limited downtime often need to accept longer cycle times unless they incrementally streamline the most painful handoffs.
- Staffing and role clarity: Even with good tools, unclear ownership, competing priorities, or chronic MRB backlogs will dominate your actual cycle times.
How to set a realistic target for your plant
Instead of picking a number in isolation, start from your current performance and constraints:
- Baseline with real data:
- Measure current NCR cycle time from initiation to disposition approval.
- Segment by risk category, disposition type (scrap, rework, use-as-is, concession), and origin (internal vs supplier vs customer).
- Identify structural blockers:
- Look for queues (MRB boards, engineering review) and cross-system handoffs (QMS to ERP to PLM) rather than blaming individuals.
- Note any steps constrained by validation status, such as changes that require re-validation of automated workflows or reports.
- Set tiered targets:
- Low-risk, straightforward NCRs: aim to close the majority within 5 to 10 days.
- Medium complexity: target 10 to 20 days, with clear SLAs for MRB/engineering response.
- High complexity or external approval required: set realistic expectations (e.g., 30 to 45 days) and track separately so they do not mask delays in routine items.
- Define which clocks you measure:
- Primary metric: NCR initiation to final disposition approval.
- Optionally track time to containment and time to implement corrective action separately rather than folding them into NCR cycle time.
- Align targets with change control and validation capacity:
- If you set aggressive targets that require workflow changes in QMS/MES, consider the qualification, validation, and documentation burden those changes will incur.
Tradeoffs when pushing NCR cycle time down
Shorter NCR cycle times are generally good but come with tradeoffs, especially in regulated, long-lifecycle environments:
- Depth of investigation vs speed: Forcing all NCRs to close in a very short window can drive superficial root cause analysis or overuse of scrap to avoid delay.
- Workload and bottlenecks: Aggressive targets without more capacity or better tools shift the problem into MRB backlogs, workarounds, or untracked “shadow” decisions.
- Traceability and documentation quality: Rushing can compromise documentation, which matters for audits, customer reviews, and long-term product support.
- System change burden: Re-architecting NCR workflows in a validated QMS/MES to win a few days of cycle time might not be justifiable if it triggers re-validation, retraining, and downtime.
A common pattern is to focus first on reducing queues and handoff delays (MRB scheduling, notification rules, clear ownership), then selectively automate documentation and data pulls once the process is stable.
Coexistence with existing systems
In most brownfield environments, NCR data and workflow are distributed across QMS, MES, ERP, PLM, and sometimes shared drives or email. Full replacement of these systems simply to improve NCR cycle time is rarely practical due to:
- Qualification and validation effort: Replacing core quality or manufacturing systems requires significant validation and can disrupt other validated processes that depend on them.
- Integration complexity: NCRs touch inventory, planning, engineering, and sometimes field service. Replicating all those integrations correctly is non-trivial.
- Downtime risk: Attempting a “big bang” change to NCR tooling can halt production or create gaps in traceability if it fails.
In practice, most organizations improve NCR cycle time by:
- Standardizing NCR data fields and workflows within existing systems.
- Automating high-friction handoffs (e.g., triggering holds in ERP/MES from QMS, or pulling drawings from PLM) rather than replacing those systems.
- Adding reporting layers that consolidate NCR metrics across systems for visibility and management review.
How to tell if your target is reasonable
Your NCR cycle time target is likely reasonable if:
- It is tighter than your current performance but can be met for most NCRs without routine escalation.
- It is differentiated by risk/complexity, not a single blanket number for everything.
- It does not depend on system changes that you cannot realistically validate, deploy, and sustain.
- You can explain, with data, why the target makes sense in your specific context.
If you are consistently missing even modest targets, the issue is usually less about the number you picked and more about ownership, queue management, and cross-system friction. Address those first; then you can revisit and tighten the target over time.
