MRB authority in a multi-site aerospace organization should be structured as a centrally governed, formally delegated authority model. Corporate quality and engineering should define the MRB policy, approval rules, escalation criteria, and evidence requirements. Sites should execute MRB decisions only within documented limits for their programs, products, customers, and competencies. The boundary is important: a site MRB cannot approve what the design authority, customer contract, regulatory requirement, or delegated MRB agreement does not allow.
The practical goal is not to make every decision central. That usually creates bottlenecks. The goal is to make local decisions consistent, traceable, and bounded so that a nonconformance in one plant is not dispositioned differently from the same condition in another plant without a justified reason.
Use an enterprise MRB framework with local execution
A common structure is an enterprise MRB charter supported by site-level MRB boards. The enterprise level defines the rules. The site level handles day-to-day nonconformance review within its delegated scope.
The enterprise framework should define at least the following:
- Which roles may approve each disposition type.
- Which programs, part families, commodities, or processes each MRB authority covers.
- When engineering, quality, manufacturing, supply chain, or customer representatives must be included.
- When a decision must be escalated to the design authority, customer, regulatory interface, or corporate MRB.
- How delegated authority is granted, trained, renewed, suspended, and audited.
- What records, rationale, objective evidence, and configuration references are required.
Site MRBs should then operate inside that framework. They can handle routine nonconformances faster, but they should not be free to invent local disposition practices that conflict with enterprise policy, AS9100-aligned procedures, customer flowdowns, or approved engineering data.
Separate disposition authority by risk and technical impact
Not every nonconformance needs the same approval path. The authority model should distinguish between low-risk administrative or workmanship issues and conditions that may affect fit, form, function, interchangeability, fatigue life, safety, qualification, or configuration.
In many aerospace environments, rework to bring the product back to approved requirements may be handled locally if the procedure is approved and the work remains within the original design definition. Repair or use-as-is dispositions often require stronger engineering authority and may require customer approval, depending on the contract, product criticality, and delegated MRB terms. Scrap decisions may be local, but they still need inventory control, cost capture, and traceability.
Repeated defects also need a higher bar. A condition that looks minor once may indicate a process control problem when it appears across sites, suppliers, shifts, or lots.
Make authority specific, not generic
MRB authority should be assigned to named roles or named individuals with defined scope. Broad statements such as “site quality may approve MRB dispositions” are usually too vague for aerospace-grade control.
Authority should be specific to:
- Site or manufacturing location.
- Program, customer, or contract.
- Part family, commodity, or special process area.
- Disposition type, such as rework, repair, use-as-is, return to supplier, or scrap.
- Technical domain, such as structures, electronics, propulsion, composites, machining, or assembly.
- Export control and technical data access constraints where applicable.
This prevents a qualified MRB approver in one context from being treated as qualified in another context where the product, customer, or technical risk is materially different.
Define escalation triggers clearly
Multi-site MRB structures fail when escalation depends on personal judgment alone. The procedure should identify conditions that require escalation before disposition is approved.
Common escalation triggers include nonconformances involving key characteristics, critical items, special processes, flight safety implications, qualification impact, drawing or specification ambiguity, suspected design deficiency, repeated defects, supplier systemic issues, customer-owned product, repair outside approved data, or any disposition that could affect configuration or certification evidence.
Escalation should also be required when the available evidence is incomplete. Remote MRB approval can work, but not if the approver is relying on partial photos, unclear measurements, missing serial history, or uncontrolled copies of drawings.
Align the systems, but do not confuse workflow with authority
The MRB workflow usually touches QMS, MES, ERP, PLM, inspection systems, supplier portals, and sometimes maintenance or MRO systems. The system design should make the authority model enforceable, not just documented.
In practice, this means the QMS or NCR system should preserve the nonconformance record, disposition rationale, approvals, attachments, and audit trail. MES should prevent unauthorized continuation of work or shipment when material is on hold. ERP should reflect inventory status, cost, scrap, return, or rework transactions. PLM should provide controlled access to current design definition and configuration context.
Brownfield environments rarely support this cleanly at first. Plants often have different MES versions, local databases, legacy ERP behaviors, spreadsheet-based logs, and customer-specific portals. A single global MRB tool may help, but it does not solve unclear authority, poor master data, or weak integration. Full system replacement is often unrealistic in aerospace operations because of validation cost, downtime risk, qualification burden, integration complexity, and long asset lifecycles. Standardizing the decision rules and interfaces is usually more practical than forcing all sites onto one system immediately.
Watch the common failure modes
The most common failure modes are predictable. Over-centralized MRB authority slows production and encourages informal workarounds. Over-localized authority creates inconsistent dispositions and weak customer confidence. Poor system integration lets material move before disposition closure. Weak delegation records make it difficult to prove who had authority at the time of approval. Reusing a prior disposition without confirming configuration, lot history, and customer requirements can create traceability and technical risk.
A sound multi-site MRB model should therefore include periodic governance reviews. These reviews should look at disposition patterns, repeat nonconformances, overdue actions, customer escapes, supplier trends, COPQ, and whether site decisions remain inside delegated limits. Changes to MRB authority should go through change control and should be reflected in procedures, training records, system permissions, and audit evidence.
The safest structure is not the most centralized one. It is the one where each site knows exactly what it may decide, what it must escalate, what evidence is required, and how the decision is preserved across the product record.