Suppliers can share throughput data in a way that is useful for OEMs and primes while still protecting proprietary processes and commercial details, but only if the data model, access controls, and governance are designed deliberately. The goal is to share performance signals, not internal recipes or cost structures.
Focus on signals, not secrets
Start by defining what the customer actually needs to see for planning and risk management:
- Current capacity and committed load at a coarse level (e.g. weekly slots by value stream or cell, not by individual machine)
- Throughput trends (parts/week, hours/week, lead time distributions) by part family or program, not by detailed routing
- Constraint indicators (e.g. which process family is gating throughput) without exposing specific equipment models, settings, or tooling strategies
- Queue and WIP levels by stage category (e.g. machining, special process, assembly) rather than full internal process maps
Intentionally exclude fields that reveal margins, internal costing, unique process parameters, or exact cycle-time by operation unless there is a contractual and cybersecurity basis to share them.
Use aggregation and normalization
To avoid leaking proprietary detail, suppliers can:
- Aggregate data: Report at daily or weekly granularity and by part family, program, or generic process category instead of part-by-part, shift-by-shift internal views.
- Bucket capacity: Express capacity as ranges or slot counts (e.g. “10–15 units/week” or “3 FTE-equivalent slots”), not machine-by-machine utilization.
- Normalize cycle times: Share cycle times in normalized form (e.g. low/medium/high effort bands, or relative to a nominal baseline) instead of exact minutes on specific equipment.
- Mask identifiers: Use customer part numbers, program IDs, or agreed family codes as keys, and avoid exposing internal routing IDs, cost centers, or machine names.
The exact aggregation level needs to be negotiated. Too much aggregation and the customer cannot plan; too little and you expose internal economics and process IP.
Separate operational metrics from commercial data
Design the data interface so that operational signals are technically and logically separated from sensitive commercial attributes:
- Include metrics such as queue length, WIP age, throughput, on-time completion, and projected lead time.
- Exclude hourly rates, labor categories, detailed overtime patterns, and material pricing.
- Keep quote, PO, and contract value data in separate systems or interfaces, even if they are linked internally on the supplier side.
In brownfield environments, this usually means building a specific reporting or collaboration layer between the supplier’s ERP/MES and the external portal, so the external party never sees raw tables or unrestricted reports.
Define a clear data-sharing contract
Before building interfaces, agree on a written “data contract” between customer and supplier that specifies:
- Which fields and metrics will be shared, at what granularity, and for which part families or programs
- Update cadence (e.g. daily snapshot, weekly roll-up) and retention period
- Which systems are authoritative (e.g. MES for WIP counts, ERP for confirmed ship dates)
- Anonymization and aggregation rules when multiple customers’ work shares common resources
- How the data can and cannot be used (e.g. not for unilateral re-pricing, not for benchmarking against anonymous competitors)
This is partly contractual and partly technical: without a clear contract, IT and OT teams on both sides will over-share or under-share out of caution.
Leverage role-based access and views
Even within the customer, not everyone needs the same visibility. Structure access as:
- Planning view: Capacity bands, lead-time forecasts, WIP by program or part family.
- Execution / expediting view: Per-order status, aging, in-queue vs in-process, expected completion window.
- Management view: Performance trends (OTD, average queue time, throughput variability) by program or supplier site.
On the supplier side, export or API endpoints should be built to generate only these views, not raw MES/ERP tables. In many aerospace and defense contexts, this means a separate “supplier collaboration” or “portal” overlay that reads from existing systems but exposes only filtered objects.
Use an intermediary or overlay instead of replacing core systems
Full replacement of a supplier’s ERP or MES just to share throughput data is rarely practical in regulated, long-lifecycle environments. The qualification burden, integration risk, and downtime required to replatform core systems usually outweigh the benefit of more elegant data flows.
A more realistic pattern is:
- Extract a limited, validated dataset from existing MES/ERP on a schedule or event basis.
- Transform and aggregate the data in an intermediate service or data mart according to the agreed data contract.
- Expose only the curated, de-identified metrics to the customer’s collaboration portal or API.
This allows suppliers to maintain their current validated systems while giving customers enough visibility for planning, without opening internal schemas or operational details to external users.
Apply cybersecurity and export-control filters
In aerospace and defense supply chains, throughput data can still intersect with export-controlled or sensitive technical data. Suppliers should:
- Ensure that external views avoid controlled technical data fields (e.g. drawings, specs, process parameters) and only expose references the customer already controls.
- Use role-based access, network segmentation, and encryption aligned with frameworks such as NIST 800-171 or IEC 62443 where applicable.
- Validate that any cloud or portal used for data sharing meets contractual cybersecurity and export-control requirements before enabling automated feeds.
These constraints can limit how real-time or granular the shared throughput data can be without additional investment in controls and validation.
Build validation and change control around shared metrics
Because shared throughput data may be used in planning, capacity decisions, and in some cases audit narratives, it should be treated with the same seriousness as other regulated operational data:
- Document data sources, transformations, and aggregation logic.
- Put the data extraction and reporting jobs under change control so that metric definitions do not drift silently.
- Periodically reconcile shared data with internal records to detect integration or mapping errors.
Without this discipline, both supplier and customer can make planning decisions based on inconsistent or misunderstood metrics.
Practical metric examples that protect IP
Examples of throughput-related metrics that are usually safe to share when aggregated and governed correctly:
- Average and 90th-percentile lead time by part family and customer program
- Available capacity band by week for each process family (e.g. rough machining, special process, final assembly)
- WIP counts and age brackets per stage category for a given customer’s orders only
- Rolling 4-week throughput and backlog trends for the customer’s portfolio
These provide actionable visibility for the customer while avoiding disclosure of the supplier’s exact routings, takt times by operation, or plant-wide portfolio mix.
