To build a scrap cost heat map that leadership can trust, you need more than a BI report. The underlying scrap data has to be modeled, reconciled, and validated across MES, ERP, quality, and supplier systems. In aerospace, this usually means a staged approach rather than a single project sprint.
1. Start from a clear question and scope
Before tooling, define what “heat map” actually means for your site:
- Time horizon: last month, rolling 12 months, or by build lot / shipset?
- Grain: by operation, by work center / cell, or by finished part?
- Cost basis: standard cost, actual cost, or blended? Include rework or only true scrap?
- Use cases: where will decisions be made (CAPA, daily tier meetings, SIOP, supplier reviews)?
Locking these choices early avoids a situation where operations, finance, and quality are all looking at different “scrap” numbers and disputing the heat map instead of acting on it.
2. Define a common scrap data model
In a brownfield environment, scrap is usually scattered across MES, ERP, QMS, and sometimes spreadsheets. A minimum common model should cover:
- Event grain: 1 record per scrap occurrence (or per nonconforming quantity) with timestamp, quantity, and unit of measure.
- Where it occurred: plant, line, cell / work center, operation, machine ID.
- What was scrapped: part number, part revision, part family, router/operation, serial/lot if applicable.
- Why: nonconformance code, defect type, root cause category, disposition (scrap, use-as-is, rework, return to supplier).
- Cost: standard or actual cost at operation, scrap value, and financial period.
- Context: program, customer, work order, build lot, supplier (for purchased parts).
Document this as a data contract between systems. Without explicit definitions, your “heat map” may be visually attractive but analytically unreliable.
3. Reconcile identifiers across systems
The biggest practical blocker is inconsistent keys. To cut across cells, part families, programs, and suppliers, you need robust mapping tables:
- Part & family mapping: link MES part numbers, ERP item masters, and any local aliases to a master part plus a part family attribute.
- Program / customer mapping: tie work orders, contract numbers, and shipsets to a normalized program list.
- Cell & work center mapping: align legacy work center codes, physical cell names, and machine IDs to a stable hierarchy (site > value stream > cell > machine).
- Supplier mapping: reconcile vendor codes used in ERP, QMS, and any supplier portals to a single supplier ID and parent group where relevant.
This reconciliation usually requires data cleansing and ongoing governance. Trying to skip it and “fix it in the dashboard” tends to fail once leadership compares numbers across systems.
4. Clarify scrap vs rework vs yield loss
Aerospace plants often conflate different loss types:
- True scrap: material permanently unusable for intended purpose.
- Rework / repair: salvaged material that consumes additional labor, machine time, and sometimes concessions.
- Administrative loss: routing errors, incorrect BOMs, mis-issues, or wrong traveler that cause “paper scrap.”
Decide what the heat map will show by layer:
- Layer 1: direct scrap cost only.
- Layer 2: direct scrap plus rework cost.
- Layer 3: broader cost of poor quality where data quality allows.
Finance and operations should jointly sign off on these rules to prevent debates about which costs “count.”
5. Establish cost logic that finance will trust
Scrap cost logic must tie back to the financial system of record:
- Cost source: decide whether to use standard cost (from ERP), actual cost, or a hybrid. In regulated environments, standard cost is common for stability and auditability.
- Cost location: define at which operation you value scrap (material only at first op, full value near final op, or route-based rollup).
- Overheads: be explicit whether you include burden and overhead allocations, or show them as a separate layer.
- Period alignment: map scrap event dates to financial periods and ensure the sum by period reconciles with financial reports within agreed tolerance.
Plan for a formal reconciliation step with finance to validate that total scrap cost in the heat map is consistent with ledger or COPQ reporting.
6. Integrate MES, ERP, and QMS data incrementally
Trying to redesign your MES/ERP stack just to get a heat map is rarely viable in aerospace given validation and downtime constraints. Instead, treat the heat map as a cross-system analytics layer:
- Stage 1: Extract scrap events from MES (or shop-floor system) and join to ERP item master and cost data. Focus on plant > cell > part number.
- Stage 2: Add QMS / nonconformance and CAPA data to enrich defect and root cause dimensions.
- Stage 3: Add supplier, program, and customer attributes by joining to purchasing and contract data.
Use a lightweight data warehouse or data lakehouse pattern where possible. Avoid invasive changes to validated systems unless you are prepared for revalidation workload and associated risk.
7. Design the heat map views to match decision-making
Once the data foundation is in place, you can build targeted heat maps rather than a single “one size fits all” view:
- By cell & part family: visualize scrap cost per cell vs part family to highlight where certain families are fragile in specific operations.
- By program & supplier: show which programs and suppliers drive the highest scrap cost, normalized by receipts or build volume.
- By defect type & operation: map dominant defect codes by operation or machine to direct engineering and process investigations.
- Trend overlays: show rolling 3–12 month trends to separate chronic issues from recent spikes.
Each view should support a clear action: launch a focused problem-solving effort, adjust routings or controls, or prioritize supplier development work.
8. Account for regulated and long-lifecycle realities
In aerospace, several additional constraints affect how you build and rely on a scrap heat map:
- Traceability: your model must preserve the link from scrap events to work orders, serials/lots, and, where relevant, specific shipsets or tail numbers.
- Change control: modifying scrap codes, routings, or data capture workflows may trigger change management and, in some cases, revalidation or customer notification.
- Long lifecycles: part numbers and programs can span decades. Expect multiple ERP or MES generations and build your data model to handle legacy codes and system transitions.
- Audit evidence: ensure the underlying data lineage is documented so that reported scrap metrics can be explained to customers or regulators if needed.
Full replacement of MES/ERP solely to fix scrap reporting typically fails or stalls due to qualification burden, integration complexity, and downtime risk. A cross-system analytical layer that respects existing validated systems is usually more realistic.
9. Put governance and validation around the numbers
To keep the heat map credible over time, define governance practices:
- Data quality checks: automated checks for negative scrap quantities, missing cost, or unclassified defect codes.
- Periodic reconciliations: monthly review of scrap cost totals vs finance and major deltas vs prior periods.
- Code discipline: controlled process for creating or retiring scrap and defect codes so they remain analyzable.
- Versioning: document major model or logic changes so trend breaks are explainable.
Without this, teams will quickly revert to arguing about whose numbers are correct instead of using the heat map to prioritize improvement work.
10. Practical implementation steps
A pragmatic sequence for most aerospace plants is:
- Align operations, quality, and finance on definitions of scrap, rework, and cost basis.
- Document a target data model and identify source fields in MES, ERP, and QMS.
- Build and validate mapping tables for parts, cells, programs, and suppliers.
- Stand up a basic data pipeline and warehouse/lakehouse schema for scrap events.
- Prototype a simple cell vs part family heat map in a BI tool and reconcile totals with finance.
- Iterate by adding supplier and program attributes, then defect and root cause dimensions.
- Formalize governance: data quality monitoring, reconciliation cadence, and owner roles.
This approach accepts brownfield complexity and focuses on building a trustworthy analytical layer step by step rather than trying to redesign core systems.
