Because the problem is usually not just reporting. It is semantic, procedural, and architectural.
Across multiple sites, scrap and nonconformance data are often recorded in different systems, at different points in the process, with different meanings. One plant may classify a failed part as scrap at the machine. Another may hold it in a nonconforming inventory status until MRB disposition. A third may record the event in a QMS but post the financial impact later in ERP. Those are not the same event, even if leadership wants to see them in one dashboard.
So yes, a single view is hard, and in many organizations the first version is misleading unless the underlying definitions and integrations are cleaned up.
What makes it difficult
-
Different definitions by site. Sites often use the same words for different things, or different words for the same thing. Scrap, rework, use-as-is, deviation, concession, and nonconformance are not always coded consistently.
-
Different process timing. The point at which an event is created, updated, or financially recognized varies. One site may log nonconformance at operation completion, another after inspection, another only after review.
-
Fragmented system landscape. Data may be split across MES, ERP, QMS, PLM, spreadsheets, homegrown apps, and supplier portals. In brownfield environments, each system often reflects a different stage of the truth.
-
Inconsistent master data. Part numbers, routings, work centers, defect codes, reason codes, units of measure, and site identifiers are frequently not harmonized.
-
Local workarounds. Operators and quality teams often use spreadsheets or offline logs when enterprise tools are slow, rigid, or poorly matched to actual workflows.
-
Different levels of data quality. Missing fields, free-text defect descriptions, duplicate records, delayed closures, and inconsistent genealogy all reduce comparability.
-
Financial and operational views do not align automatically. A scrap event in production data does not always match the cost posted in ERP, especially when material, labor, overhead, and disposition timing differ.
-
Validation and change-control constraints. In regulated environments, changing forms, codes, workflows, interfaces, or data models is slower than leaders expect because traceability and validation matter.
Why dashboards alone do not fix it
A BI layer can aggregate records, but it cannot resolve conflicting definitions on its own. If Site A counts reworkable defects as nonconformance but Site B only counts dispositions that reach formal review, a combined metric may look precise while hiding major inconsistency.
This is why many enterprise scrap and NCR dashboards become executive scoreboards with weak operational value. They show totals, but not a trustworthy cross-site comparison.
What is usually required to get a usable single view
-
A canonical data model. You need a common structure for event type, status, disposition, quantity, cost basis, defect category, source system, timestamps, and site context.
-
A controlled business glossary. The organization has to decide what counts as scrap, when a nonconformance starts, when it closes, and how rework, concession, and supplier-related issues are represented.
-
Cross-site code mapping. Local reason codes and defect codes usually need mapping to enterprise categories. This is ongoing governance work, not a one-time cleanup.
-
System-by-system lineage. Leadership should be able to trace each metric back to its source systems and transformation rules. Without that, disputes over numbers will persist.
-
Pragmatic integration. In many cases, the right approach is federated reporting over existing MES, ERP, and QMS platforms, with selective normalization, rather than forcing an immediate full replacement.
-
Data quality controls. Required fields, status rules, duplicate checks, and closure discipline matter as much as integration technology.
Why full replacement often fails
In regulated, long-lifecycle manufacturing, replacing every local system to force one process is often more risky than it sounds. Qualification burden, validation cost, downtime risk, local process variation, and integration complexity are real constraints. Sites may also depend on legacy equipment and custom interfaces that cannot be retired on the timeline of an enterprise transformation program.
That does not mean standardization is impossible. It means coexistence is usually the practical path: standardize definitions and governance first, then normalize data across systems, and only replace platforms selectively where the operational and validation case is strong.
What a realistic answer looks like
A true single view is possible, but only if the organization accepts that this is a governance and operating-model problem before it is a reporting problem. If definitions, workflows, and data ownership stay inconsistent, the dashboard will remain contested.
In practice, the best outcome is often a tiered view:
-
Enterprise-level normalized metrics for trend and risk visibility
-
Site-level operational detail that preserves local traceability and workflow reality
-
Drill-back to source records for auditability, investigation, and change control
That is less elegant than a perfectly unified system, but in brownfield multi-site operations it is often more accurate, more maintainable, and lower risk.