The Records Disagree
An OEM issues a purchase order. The contract manufacturer acknowledges it. Somewhere between that acknowledgment and a finished shipment, the records diverge. The OEM's ERP (enterprise resource planning system) shows one inventory position. The partner's system shows another. A quality hold was logged, but the warehouse shipped anyway. Production status lives in an email thread.
The operating cost arrives before anyone names it a problem. Planners chase status by phone. Reconciliation meetings consume hours. Rework happens because a constraint wasn't visible in time to act. Delivery commitments get built on incomplete information.
This is not a technology gap in the sense that the technology is missing. According to NIST's AMDIA program, turning manufacturing data into meaningful intelligence is difficult, and a robust data infrastructure creates a vital foundation for building on advanced and emerging technologies. The gap is architectural and organizational: records are owned by different systems, different teams, and different companies, with no agreed definition of how they should align.
Why the Records Disagree
Order status may sit in an ERP. Production progress may be in an MES (manufacturing execution system). Shipment data may be in a WMS (warehouse management system) or a third-party logistics platform. Quality events may be tracked in a QMS (quality management system). Engineering changes may live in a PLM (product lifecycle management) system.
In Dynamics 365 Supply Chain Management, for example, subcontracting operations affect all stages of operations, from production definition through logistics for materials and finished goods. That scope illustrates how many system boundaries a single outsourced operation can cross. When a partner asks a question that spans two or three of those systems, someone assembles the answer manually.
Two structural patterns can drive the disagreement. First, systems were added over time, each solving a specific problem at deployment, and may not have been designed to share a consistent record across company boundaries. Second, in environments where data ownership was never formally assigned, the ERP team, operations team, and IT team may each control a separate slice of the record with no single owner responsible for the connection between them.
The contract manufacturer owns the production record but may not want to expose it. No one owns the handoff between them.
Four Approaches, Each With Tradeoffs
The assignment input identifies four distinct approaches worth comparing.
Staying with manual coordination persists in many environments by inertia rather than deliberate design. Three people spending an hour to assemble an answer that should take minutes is a recurring pattern, not a one-time event.
Extending existing systems may be the right starting point when a platform such as Dynamics 365 already models subcontracting relationships. A production order can have many operations, each allocated to a different vendor, triggering multiple purchase orders.
The GS1 EPCIS (Electronic Product Code Information Services) standard enables disparate applications to share visibility event data within and across enterprises. That event model can anchor a visibility design spanning ERP, MES, WMS, QMS, and partner-reported data without requiring a single shared system. The tradeoff is that point-to-point connections between two specific systems can become brittle when either side upgrades or changes vendors.
A portal or reporting layer can surface partner-reported data without deep integration. This approach works when the primary need is visibility rather than automated record synchronization. The limitation is that a portal reflects what partners enter. If reporting cadence, data ownership, and exception ownership are not defined before the portal goes live, the portal may surface the same incomplete information faster.
The Tradeoffs That Determine the Right Approach
No single approach fits every environment. The relevant variables include implementation effort, data quality, ownership clarity, partner adoption, permissions, and ongoing support.
Defining ownership before building the connection can avoid discovering the gap after go-live. The simpler the partner-side reporting requirement, the more likely the data arrives consistently.
A governed integration layer with defined interfaces may be more durable than point-to-point connections but could require more upfront design work.
Permissions and trust are a real constraint. Contract manufacturers may be cautious about sharing production data that could affect future negotiations. Visibility architecture that defines what each party can see, and what remains private, addresses that concern directly rather than assuming openness.
A Bounded Starting Point
Before evaluating platforms or integration patterns, define the operating problem precisely. Three distinct conditions can show up as the same surface symptom: decision latency, data that exists but isn't connected, and data that genuinely doesn't exist yet because no one is capturing it. The response to each is different.

