RSC Topic: Lean in High-Mix Low-Volume (HMLV)

Aerospace-specific process improvement methods.

  • value stream mapping

    Value stream mapping is a lean process analysis method used to visualize how materials and information move through a product or service workflow from request to delivery. It commonly shows process steps, handoffs, queues, decision points, cycle times, wait times, inventory or work-in-process, and the information signals that trigger work.

    In manufacturing, value stream mapping is used to describe the end-to-end flow across operations such as planning, receiving, production, inspection, rework, packaging, and shipment. It is broader than a single workstation study because it looks at the full stream of activities and delays, including both physical flow and system or communication flow.

    A value stream map is not the same as a detailed work instruction, routing, or process flowchart. It is a higher-level view intended to make lead time, non-value-added activity, bottlenecks, rework loops, and coordination gaps visible. Depending on the organization, it may be created for a current state and a proposed future state.

    What it typically includes

    • Major process steps across the value stream

    • Material movement between steps, cells, suppliers, or storage points

    • Information flow such as ERP, MES, scheduling signals, release approvals, or manual communication

    • Timing data such as cycle time, changeover time, uptime, queue time, and total lead time

    • Inventory, WIP, backlogs, or other waiting points

    • Quality loops such as inspection, rework, or nonconformance handling where relevant

    Operational meaning in manufacturing systems

    Operationally, value stream mapping helps teams connect process reality across departments and systems. In regulated or traceability-heavy environments, the map may include approvals, documentation steps, inspection gates, genealogy capture, or handoffs between ERP, MES, QMS, and shop floor activities. The purpose is still process understanding, not system design by itself.

    For example, a manufacturer might map the path from order release through kitting, production, inspection, and shipment to see where work waits for material, traveler updates, quality review, or data entry into connected systems.

    Common confusion

    Value stream mapping is often confused with process mapping, spaghetti diagrams, and standard work documentation.

    • Process mapping usually focuses on step sequence and decision logic within a process. Value stream mapping adds timing, flow, and system-level delay across the broader stream.

    • Spaghetti diagrams show physical movement paths. Value stream mapping covers overall material and information flow, not just motion.

    • Standard work or work instructions define how a task is performed. Value stream mapping does not replace task-level instructions.

    Boundary of the term

    The term commonly refers to the mapping method and the resulting visual map. It does not by itself mean a digital twin, a simulation model, or a compliance record, although those may use related process data.

  • What are the 4 types of supply chain?

    There is no single, universally accepted list of exactly “4 types of supply chain.” Different frameworks use different labels (for example: lean vs agile; make-to-stock vs engineer-to-order). In industrial and regulated environments, one common way to group supply chains into four types is based on how they handle demand patterns and risk:

    1. Efficient (cost-focused) supply chains

    These are designed to minimize unit cost and maximize utilization when demand is relatively stable and predictable.

    • Characteristics: Long, optimized production runs; high asset utilization; tight cost control; heavy use of forecasts and MRP.
    • Where it fits: High-volume, low-variability components (fasteners, standard machined parts, common consumables).
    • Constraints in regulated environments: Cost optimization is limited by qualification, validation, and approved supplier lists. Aggressive supplier switching to cut cost often triggers requalification, documentation updates, and potential audit scrutiny.

    2. Risk-hedging (resilience-focused) supply chains

    These prioritize continuity of supply for critical items where disruption risk is high and impact of a stockout is severe.

    • Characteristics: Multiple qualified suppliers, strategic buffers, sometimes regional diversification, and formal risk registers and mitigation plans.
    • Where it fits: Single-source or long-lead materials, custom alloys, specialized electronics, regulated components with complex approvals.
    • Constraints in regulated environments: Adding or changing suppliers can require design updates, PPAP or equivalent, validation, and change control. As a result, “hedging” often relies more on buffer inventory and long-term agreements than on easy supplier changes.

    3. Responsive (service-level-focused) supply chains

    These focus on speed and flexibility to meet variable customer demand, often with tighter delivery commitments and configuration variability.

    • Characteristics: Short planning horizons, higher safety stocks on finished goods or key subassemblies, cross-trained labor, and late-stage customization.
    • Where it fits: Aftermarket and spares, configured products with frequent change orders, and customers expecting short lead times.
    • Constraints in regulated environments: Responsiveness is bounded by change control, documentation updates, and validation. For example, rushing alternate materials or unapproved routings can create compliance exposure and traceability gaps.

    4. Agile (flexibility and innovation-focused) supply chains

    These are designed to handle high uncertainty in both demand and product definition, often in R&D-heavy or project-driven businesses.

    • Characteristics: Modular designs, configurable BOMs, flexible manufacturing cells, and close engineering-supplier collaboration. Often used in project- or program-based delivery.
    • Where it fits: New product introduction, prototypes, low-volume high-mix programs, and complex capital equipment.
    • Constraints in regulated environments: True agility is constrained by documentation, approvals, and validation. You can move faster inside a controlled framework (for example, pre-approved design envelopes, qualified alternates, managed deviations) but you cannot bypass formal change control.

    How these types coexist in brownfield industrial environments

    Most regulated manufacturers do not have a single type of supply chain. Instead, they segment by product family, customer, or program:

    • Commodity parts may follow an efficient model.
    • Safety-critical or ITAR/Export Controlled items may use a risk-hedging model.
    • Aftermarket and repair services often require a responsive model.
    • NPI programs and prototypes often operate in a more agile model.

    This segmentation must work on top of existing ERP, MRP, PLM, and QMS systems. In brownfield environments, you usually tune policies (planning parameters, safety stocks, sourcing rules, routing choices) rather than replace core systems, because full replacement tends to be blocked by integration complexity, validation effort, and downtime risk.

    Implications for planning and risk management

    Instead of focusing on naming the “4 types,” it is more practical to:

    • Classify product families by demand pattern, risk profile, and regulatory load.
    • Align planning and sourcing policies (for example, efficient for stable commodities, risk-hedging for critical single-source items).
    • Ensure traceability, change control, and supplier qualification processes can support the desired level of responsiveness or agility without creating compliance gaps.

    The specific labels you use internally matter less than having a clear, documented strategy for each segment, traceable into your planning parameters, supplier strategies, and operational procedures.

  • value stream pilot

    A value stream pilot is a limited-scope implementation used to test and refine changes across a defined value stream before applying them more broadly. In manufacturing, it commonly refers to selecting one product family, process flow, cell, line, or plant segment and trialing improvements to how material, information, and work move from one step to the next.

    The term includes more than a single isolated process experiment. A value stream pilot usually looks at end-to-end flow across multiple steps, functions, or systems, such as planning, production, quality, material staging, and reporting. It does not usually mean a full enterprise rollout, and it is not the same as a generic software pilot with no process scope.

    How it is used in operations

    Organizations commonly use a value stream pilot to validate future-state changes in a controlled area. The pilot may involve process redesign, standard work updates, layout changes, digital work instructions, MES or ERP data changes, revised quality checks, or new performance measures.

    In practice, the pilot area is chosen because it is representative enough to test the approach, but limited enough to monitor closely. For example, a manufacturer might pilot a new value stream design on one assembly family to evaluate queue time, handoffs, rework visibility, and information flow between ERP, MES, and quality records.

    What it includes and excludes

    • Includes: trial implementation across a defined workflow or product flow, observation of operational results, and learning before scale-up.
    • Excludes: a purely theoretical value stream map, a one-time kaizen event with no follow-through, or a full production standard applied everywhere from the start.

    Common confusion

    Value stream pilot is often confused with value stream mapping. Value stream mapping is an analysis and visualization method. A value stream pilot is the real-world trial of proposed changes.

    It may also be confused with a software pilot. A software pilot focuses on evaluating a tool or application. A value stream pilot focuses on the operating flow itself, even when software changes are part of the test.

    Why the term matters

    The term is commonly used in lean and transformation work to distinguish between designing improvements and proving them under actual operating conditions. In regulated and traceability-focused environments, a value stream pilot may also be used to confirm that process changes, system changes, and documentation changes work together without narrowing the effort to only one department.

  • What real-time data should an aerospace MES surface to supervisors?

    An aerospace MES should surface the real-time conditions a supervisor can actually act on during the shift: work waiting, work blocked, quality holds, labor and equipment status, material shortages, and exceptions that threaten schedule or traceability. Not every available signal belongs on the screen. In regulated environments, more data is not automatically better. If the MES shows stale, unvalidated, or poorly integrated data, supervisors will work around it and the board becomes decoration.

    What supervisors usually need first

    For most aerospace plants, the core real-time view should answer a short set of questions:

    • What work orders or operations are due now, late now, or at immediate risk?
    • Where is work physically and logically stuck?
    • Which jobs are blocked by material, tooling, inspection, approval, or machine availability?
    • Which operators, cells, or lines are idle, overloaded, or running off plan?
    • What quality events require containment or escalation right now?
    • What happened in the last hour that changed the shift plan?

    If the MES cannot answer those questions reliably, adding more KPIs usually makes the problem worse.

    Recommended real-time data categories

    The most useful aerospace MES supervisor view typically includes these categories.

    1. Dispatch and execution status

    • Current operation status by work order, serial number, batch, or assembly
    • Queue, in-process, complete, hold, waiting inspection, waiting material, waiting approval
    • Planned versus actual start and finish at operation level
    • Jobs approaching contractual, internal, or downstream handoff deadlines
    • Route step adherence and skipped or attempted out-of-sequence steps

    This is usually the center of the screen because it shows where intervention is needed first.

    2. Constraint and blockage visibility

    • Material shortages and missing kit components
    • Tooling or gage unavailability
    • Machine downtime or loss of critical capacity
    • Pending electronic signoffs or approvals
    • Missing documents, unreleased revisions, or obsolete instruction access attempts
    • Awaiting first article, in-process inspection, source inspection, or customer hold release

    In practice, supervisors often need blockage codes that are specific enough to act on. A generic red status is not enough.

    3. Quality and traceability exceptions

    • Open nonconformances affecting active work
    • MRB or deviation dispositions that are pending and blocking flow
    • Inspection failures by operation, part family, or work center
    • SPC or process capability signals only where the process is mature enough to trust them
    • Missing genealogy, missing lot linkage, missing as-built data, or incomplete signoffs
    • Rework loops and repeated failure at the same step

    For aerospace, this matters as much as throughput. A supervisor does not just need to know that work is moving. They need to know whether it is moving with complete, defensible records.

    4. Labor and skills coverage

    • Who is clocked in, where they are assigned, and what they are currently executing
    • Certification or authorization constraints for the operation being performed
    • Unstaffed bottleneck operations
    • Labor utilization by cell or area, with care not to overinterpret noisy labor data
    • Requests for support, training, or supervisor override

    This becomes important when the plant depends on scarce certifications, tribal knowledge, or dual signoff steps.

    5. Equipment and asset status

    • Machine up/down/starved/blocked states where machine connectivity exists
    • Maintenance status for constrained assets
    • Calibration status for critical gages and tools
    • Environmental or process parameter alarms only if they are integrated and governed

    Many plants want this, but not all have the OT integration discipline to make it reliable. If connectivity is partial, state that clearly rather than implying complete real-time visibility.

    6. Short-interval performance versus plan

    • Shift attainment against plan at the area, cell, or program level
    • Throughput by constrained resource
    • Queue aging and WIP accumulation
    • First-pass yield and rework count for the current shift or day
    • Top active reasons for delay or non-productive time

    These are useful when tied to action. They are less useful when presented as a generic OEE layer in high-mix, low-volume aerospace environments where context matters more than one rolled-up number.

    What should not be the primary supervisor view

    Supervisors usually do not need a dashboard dominated by executive metrics, finance summaries, or broad monthly trends. They also do not need raw event streams with no prioritization.

    Avoid making the main MES screen a mix of:

    • ERP-style backlog reports with delayed refresh
    • PLM document libraries without operational relevance
    • QMS metrics that are important but not shift-actionable
    • Dozens of alarms with no severity logic or ownership
    • Plantwide OEE as the main control signal in a complex, high-mix environment

    Those views may belong elsewhere, but they should not crowd out immediate execution control.

    Brownfield reality: the answer depends on integration quality

    In many aerospace sites, the MES is only as real-time as the surrounding systems allow. Material status may still come from ERP transactions entered late. Revision status may depend on PLM release timing. NCR or deviation status may live in QMS. Machine state may come from separate historians, SCADA, or not at all.

    That means the right supervisor view is often a federated exception view, not a promise that the MES itself is the single source of truth for every signal. If system timestamps are inconsistent, if operators back-enter transactions, or if dispatch logic is manually overridden without traceability, the dashboard will mislead people.

    Full replacement of MES, ERP, PLM, and QMS stacks to solve this is usually unrealistic in regulated aerospace environments. Qualification burden, validation cost, downtime risk, and integration debt are usually too high. Most plants get farther by improving event quality, integration timing, and exception handling around the existing stack.

    Practical design rules

    • Show only signals with a defined owner and expected response.
    • Separate informational metrics from action-required exceptions.
    • Display data freshness and source when latency varies by system.
    • Use role-based views. A cell supervisor and a quality supervisor do not need the same screen.
    • Preserve drill-down to traveler, serial, operation, revision, hold reason, and approval status.
    • Keep audit trail access close to the operational event when traceability matters.

    If a metric cannot trigger a decision, escalation, or documented action, it probably does not belong in the primary real-time view.

    Common failure modes

    • Supervisors see too many statuses but not the actual blocker.
    • Data refresh is delayed, so teams rely on whiteboards and calls instead.
    • Quality holds are visible, but the reason, owner, or next step is not.
    • Labor assignment looks current, but certification or training status is not tied to the operation.
    • Material appears available in ERP, but not actually staged at point of use.
    • Out-of-sequence work is possible in practice, but the MES flags it too late.
    • Machine connectivity exists for some assets but is presented as if it covers the whole area.

    These failures are common because plants often implement display logic before fixing data ownership and transaction discipline.

    A practical minimum set

    If you need a short answer, start with this minimum set:

    • Late and due-now operations
    • WIP by status and queue age
    • Blocked jobs with reason codes
    • Material and tooling shortages
    • Quality holds, failed inspections, and active nonconformances
    • Labor and constrained machine status
    • Shift attainment versus plan
    • Missing traceability or signoff exceptions

    That is usually enough to run the shift without pretending the MES can solve every planning, quality, and engineering problem in real time.

  • What is the difference between process drift detection and traditional SPC in aerospace?

    Traditional SPC and process drift detection are not the same thing.

    Traditional SPC is a structured statistical method used to monitor process stability against expected variation, typically with control charts, sampling plans, and defined response rules. It is usually centered on a specific characteristic, feature, or process parameter and asks a fairly narrow question: is this process behaving as expected, or has it gone out of statistical control?

    Process drift detection is broader. It looks for gradual shifts over time that may not trigger a classic SPC rule early enough, especially when changes are small, slow, multivariable, or spread across different data sources. In aerospace, that can include subtle movement tied to tool wear, machine condition, operator sequence, environmental conditions, upstream material changes, software revisions, or routing differences.

    Practical difference

    • SPC is usually chart-based, characteristic-specific, and grounded in established statistical process control practice.

    • Drift detection is usually pattern-based, often cross-variable, and may rely on analytics beyond classic control charts.

    • SPC is often easier to explain, standardize, and defend in quality routines.

    • Drift detection can surface earlier warning signals, but it is more dependent on data engineering, contextual data, and model tuning.

    Why this matters in aerospace

    Aerospace processes often run in high-mix, low-volume conditions with long product lifecycles, special processes, strict configuration control, and nontrivial measurement uncertainty. That creates two realities.

    • First, traditional SPC may be hard to apply cleanly when lot sizes are small, setups change often, and product families are not statistically identical.

    • Second, drift can still be real even when no single control chart looks alarming, because the signal may sit across multiple systems or emerge slowly over months.

    For example, a bore dimension may remain inside specification and even inside control limits, while cycle time, spindle load, rework frequency, and tool offsets all shift together. Classic SPC on one measured feature might not flag that early. Drift detection might.

    What process drift detection can add

    When implemented well, drift detection can help identify weak signals before they become scrap, escapes, or recurring NCRs. It can be useful for:

    • slow degradation in equipment performance

    • changes after maintenance, software updates, or recipe edits

    • supplier material shifts that alter downstream behavior

    • differences between nominally equivalent lines, cells, or programs

    • process changes hidden by broad tolerances or sparse inspection

    That said, this is not automatic. In many plants, drift detection produces noise if timestamps are unreliable, machine states are not normalized, genealogy is incomplete, or measurement systems are not capable enough to separate real movement from metrology variation.

    Tradeoffs and limits

    Traditional SPC has the advantage of being mature, interpretable, and easier to anchor in documented quality procedures. It is usually simpler to validate operationally because the logic is explicit.

    Process drift detection has the advantage of scope and sensitivity, but it introduces more dependencies:

    • good contextual data, not just final inspection results

    • stable identifiers for part, lot, machine, tool, operator, and revision

    • measurement system capability and calibration discipline

    • clear response workflows so alerts do not become background noise

    • change control when analytics logic, thresholds, or source mappings are modified

    In regulated aerospace environments, that last point matters. If drift detection influences product disposition, inspection strategy, or release decisions, the surrounding workflow, evidence trail, and system behavior may need formal review and validation appropriate to the use case. It should not be treated as a black box that replaces engineering judgment.

    Does drift detection replace SPC?

    No. In most aerospace operations, it should complement SPC, not replace it.

    SPC remains useful where the process, measurement method, and sampling discipline are stable enough for control charting to be meaningful. Drift detection is more useful as an overlay that watches for slower or more complex patterns that SPC may miss.

    A practical approach in brownfield environments is usually coexistence:

    • keep existing SPC where it is already embedded in quality plans and operator routines

    • add drift monitoring on critical assets, routes, or failure modes where multivariate change is a known risk

    • connect results back to MES, QMS, historian, CMMS, or ERP records where possible for traceability and investigation

    Full replacement of legacy quality monitoring rarely works cleanly in aerospace. Qualification burden, validation cost, downtime risk, integration complexity, and long equipment lifecycles usually make rip-and-replace strategies harder than expected.

    Bottom line

    Traditional SPC asks whether a defined process characteristic is statistically in control. Process drift detection asks whether the broader process is gradually changing in ways that may matter operationally or qualitatively, even before a classic SPC alarm appears.

    In aerospace, the better question is usually not which one is superior. It is whether your data, measurement systems, and response process are mature enough to use both without creating false confidence or alert fatigue.

  • How can aerospace manufacturers measure throughput in low-volume, high-mix environments?

    Throughput in aerospace high-mix, low-volume (HMLV) environments cannot be reduced to a simple parts-per-hour number. You typically need a layered approach that looks at throughput by work order, by routing step, and at the constraint resource, rather than only at finished units.

    1. Choose the right unit of measure for HMLV

    In HMLV aerospace, parts are complex, routings are long, and mix shifts daily. A single “widgets/hour” number is usually meaningless. Common, more practical throughput measures include:

    In practice, this connects to operational visibility when teams need to turn the answer into repeatable execution habits.

    • Work orders completed per period (per week or month) by product family or program.
    • Routing steps completed per period on key resources (e.g., 5-axis machining, CMM, NDI, bonding, paint).
    • Throughput hours: sum of standard or planned hours completed on released work orders in a time window.
    • Constraint-step throughput: completed operations at the known bottleneck machine, cell, or department.

    Each of these requires reasonably accurate routings and labor standards. If those are weak or outdated, the first step is often to stabilize them before trusting derived throughput metrics.

    2. Measure throughput at the work-order level

    Because individual part numbers move slowly, the work order is usually the most reliable lens:

    • Count work orders released vs. completed over a defined period, segmented by program, family, or process type (e.g., structural machining vs. sheet metal vs. assemblies).
    • Track work-order cycle time (release to completion) and lead-time adherence. Rising cycle time at constant release volume usually signals a throughput or WIP problem.
    • Use hours-based throughput: completed standard hours or earned hours per week is often more stable than units in HMLV.

    In a brownfield environment, this data often lives partly in ERP (work orders, standards) and partly in MES or manual travelers (actual progress). Without at least basic interoperability, you will only see a partial picture.

    3. Focus on constraint-step throughput

    For most aerospace shops, true throughput is limited by a few resources such as specialized machines, inspection, NDI, or a specific skilled labor pool. Measuring throughput at these constraint steps is usually more actionable than measuring finished assemblies:

    • Identify the constraint with loading studies or simple observation (persistent queues, high overtime, chronically late operations).
    • Measure completed operations at the constraint per day or per shift, ideally normalized by planned hours.
    • Track queue time before the constraint as an early indicator of collapsing throughput.
    • Segment by mix (family, complexity, customer) so you can see when the mix has effectively reduced the constraint’s output.

    This approach fits both legacy and modern MES: even if you only have paper travelers, you can sample how many operations exit a key machine or cell per day. Digital systems make it easier but do not replace the need to reason about the real constraint.

    4. Use routing-step completion as an intermediate metric

    For complex, long-cycle assemblies, you will not see many finished units in any given week. Routing-step throughput gives a more continuous signal:

    • Count completed operations per resource or area (e.g., ops 20/30/40 in major machining cells) and trend them.
    • Track first-pass completion vs. rework operations to separate true throughput from churn.
    • Measure operation-level cycle time: start-to-complete at each critical step.

    Operation-level data often comes from MES, digital travelers, or time collection systems. If your plant still relies heavily on manual sign-off, the first step may be to digitize routing progress (even with light-weight scanners or tablets) before attempting fine-grained throughput measurement.

    5. Combine throughput with WIP and lead time

    Throughput alone is easy to misread in HMLV without context on WIP and lead time:

    • WIP vs. throughput: if WIP keeps growing while throughput is flat, you are loading the system faster than it can execute.
    • Lead time vs. throughput: if lead times are rising while reported throughput is stable, your throughput metric may be missing rework, queueing, or partial completions.
    • Program-level view: measure throughput and WIP by program or customer to detect where mix is silently consuming capacity.

    These views usually require at least basic alignment between ERP (order/WIP quantities), MES (operation status), and scheduling tools. In many aerospace plants, spreadsheets bridge the gaps; this is workable if the interfaces and data definitions are tightly controlled and periodically reconciled.

    6. Attribute non-productive time and variability

    HMLV throughput is often constrained by unplanned variability rather than by nominal cycle times. To understand true throughput, you need to distinguish productive from non-productive time:

    • Log major causes of delay at constraint resources: waiting on NC programs, tooling, FAI approval, MRB decisions, material, or engineering changes.
    • Quantify rework and scrap at each step, not just at final inspection. High rework consumes capacity and inflates apparent throughput if you only count operations completed.
    • Measure schedule adherence at the operation level: how often do operations start and finish within their planned window?

    Without reasonably consistent reason codes and operator reporting, any throughput number will hide as much as it reveals. Digital work instructions and digital travelers can help standardize cause coding, but only if governance and training are in place.

    7. Deal explicitly with FAI, one-offs, and engineering churn

    In aerospace, throughput is frequently distorted by FAIs, prototype lots, and engineering change-driven disruption:

    • Separate FAI and NPI lots from steady-state production when calculating throughput trends. FAIs often take longer and require more stops for inspection and approvals.
    • Tag one-offs and repairs so they are not mixed into baseline throughput metrics for recurring part numbers or assemblies.
    • Measure engineering-change impact explicitly (e.g., hours lost or days of delay due to ECO holds), rather than attributing all variability to the shop floor.

    In brownfield stacks, this usually requires clear coding in ERP and consistent use of routing or order attributes that MES can read. Without that discipline, data from FAIs and one-offs will contaminate “normal” throughput measures.

    8. Practical data strategies in brownfield environments

    In many aerospace plants, you will not be able to deploy a clean-sheet MES or scheduling system quickly due to validation, qualification, and downtime constraints. Throughput measurement must work with existing systems:

    • Start with what you have: use ERP work-order completions and simple time stamps to build an initial throughput view, even if some steps are manual.
    • Add light-weight data capture at constraints: barcode scans or basic digital travelers focused on the bottleneck resources often deliver more value than a plant-wide big-bang rollout.
    • Align master data before deep analytics: inconsistent routings, units, and part families across ERP and MES will undermine any throughput KPI, regardless of tooling.
    • Use incremental validation: for regulated environments, treat new throughput calculations as software features subject to change control and documented verification, especially if they feed planning or customer commitments.

    Full system replacement purely to improve throughput visibility is rarely justifiable in aerospace. The validation burden, integration complexity, and risk of disrupting qualified processes often outweigh potential gains. Layered, interoperable solutions and targeted digitization around constraints are usually safer and faster paths.

    9. Governance and interpretation

    Finally, throughput metrics in HMLV aerospace must be governed and interpreted carefully:

    • Define each metric precisely (what is counted, which orders, which hours) and lock that definition under document control.
    • Review metrics with operations, quality, and engineering together so that changes in throughput are not misattributed to a single function.
    • Periodically reconcile metrics to reality (shop-floor walks, sample job histories) to catch data quality or integration issues before they drive bad decisions.

    Used this way, throughput metrics in low-volume, high-mix aerospace environments become a tool for targeted improvement around real constraints, rather than a superficial scoreboard.