ERP already manages the bill of materials — so why build a separate system to manage product revisions? The answer is architectural. PLM and ERP are built for fundamentally different jobs and attempts to use one as a substitute for the other consistently fail for structural reasons.
Transaction System vs. Revision Control System
ERP is, at its core, a transaction system. It takes an approved product record and executes transactions against it: purchasing, production orders, inventory movements, shipping. For that to work reliably, ERP needs clean, stable, approved data. It needs to know: what are we producing right now?
PLM is a revision control system. Its job is managing the evolution of the product record: all the work-in-process between the last producible revision of a product and the next one. Incomplete designs, change proposals under review, documentation awaiting approval — all of it lives in PLM, deliberately separated from production systems.
This separation is intentional. A partially approved design change or a superseded revision has no place near a production floor that might act on it. The silo between PLM and ERP isn’t a failure of integration — it’s a feature.
Why ERP Can’t Just Add Revision Control
ERP vendors have tried to patch in revision control functionality over the years. It doesn’t work well structurally. The transactional architecture of an ERP isn’t designed to:
- Maintain full revision history across product generations
- Support work-in-process states for incomplete or unapproved designs
- Manage structured change approval workflows with routing, review, and controlled release
In a properly implemented PLM system, any prior revision of a product is accessible, differences between revisions are comparable, and every change is traceable through the approval record that authorized it. That history supports compliance audits, root cause analysis, and design reuse decisions.
ERP’s design priority is access to what’s current and producible. PLM’s design priority is the complete history of how the product became what it is today.
The Handoff: When Does PLM Release to ERP?
The PLM-to-ERP integration is a defined transfer event, not a continuous sync. It happens when a material change to the product completes the PLM approval workflow and becomes effective.
Not every change triggers a transfer. PLM recognizes multiple change categories:
- Non-material changes don’t affect the product definition. A documentation correction, a note update, a minor administrative revision — ERP doesn’t need to know. The product being built today hasn’t changed.
- Material changes affect the product definition in ways that matter to production. These go through formal review and approval routing in PLM. Once approved and effective, the new revision transfers to ERP as the next producible revision.
Along with the new revision, PLM communicates dispositions: guidance on what to do with existing inventory, open purchase orders, and in-process work orders affected by the change. PLM defines what needs to happen. ERP executes it.
Related reading: Engineering Change Control: What Happens Between PLM and the Shop Floor
The Effective Date vs. Cut-In Date Gap
One of the most practically important things to understand about the PLM-ERP boundary is the timing gap between when a change is approved and when production actually switches over.
| PLM | ERP | |
| Date type | Effective date | Cut-in date |
| Meaning | Change reviewed, approved, and authorized | Production switches to new revision |
| Set by | PLM approval workflow completion | Production planning (inventory, lead times, WIP) |
| Timing | Day of approval | Days to weeks later |
Engineering might approve a design change on the first of the month, but the production line won’t switch over until existing inventory of the affected component is consumed. Open work orders and in-process builds may continue against the old revision throughout that window.
This gap is managed through implementation tasks — tracked activities in the PLM change workflow that assign specific people to specific downstream actions. PLM tracks those tasks to a “complete” status, separate from “effective,” to confirm all downstream work is done — not just that the design was approved.
Practical Implications for PLM-ERP Integration
For engineering and IT teams designing the PLM-ERP integration, a few principles follow directly from this architecture:
Trigger on release events, not polling. Integration events should fire when PLM releases a change — not via continuous sync or scheduled polling. Continuous sync risks pushing work-in-process data into ERP.
Codify change categories. The integration layer needs to know which changes require an ERP update and which don’t. Transferring every minor PLM revision to ERP creates noise and production risk.
Dispositions must travel with the change. The integration isn’t just “here’s the new BOM” — it carries the instructions for managing the transition from old to new in the production environment.
Never assume effective date = cut-in date. Build that gap explicitly into the integration design and the change management workflow.
Summary
PLM and ERP are complementary, not redundant. PLM manages the revision-controlled evolution of the product record through design and change processes. ERP executes against the approved, released result. The integration between them is a controlled handoff at a defined point in the change process. Treating it that way produces cleaner data, fewer production errors, and a defensible audit trail.
Running Arena PLM? CADTALK automates the data handoff from Arena to ERP — carrying dispositions, BOM updates, and revision changes without manual re-entry. Learn more at cadtalk.com.
