Your PLM and ERP don't talk to each other (and the FDA noticed)

Here's a scenario that plays out in medical device companies every week. Engineering approves an ECO at 4 PM Tuesday. The new revision is, on paper, immediately effective. But the production floor doesn't know. The MRP run still uses the old BOM. The work instructions on the bench are still the old revision. The next unit comes off the line built to a spec that, technically, no longer exists.

Now ask the question the FDA will eventually ask: when was the change actually in effect on the floor? Tuesday at 4 PM, when it was approved? Wednesday at 7 AM, when production got the email? Friday afternoon, when someone updated the printed work instruction binder? Two weeks later, when MRP picked it up on the next regeneration?

Nobody knows. That's the problem. "We push it through quickly" is not a controlled process, and a controlled process is the only kind that survives 21 CFR Part 820 §820.40 — Document controls.

A lot of medical device companies choose a PLM first, build their design controls around it, and only later realize it does not connect well to the ERP they need for production control and compliance. PLM is selected by engineering. ERP is selected by operations. The two evaluations happen on different timelines, with different stakeholders, against different criteria. Integration shows up as an afterthought — usually after the second system is already in place.

By the time someone owns end-to-end design-to-production traceability, both systems are entrenched, both have customizations, and "integration" turns into a six-figure consulting engagement that produces a brittle nightly batch job. Approved revisions land in ERP, with a 12-hour delay, after the operator has already built two units to the previous spec.

That's the world most med-tech operators live in. It's expensive, it's fragile, and it's the root cause of more FDA observations than the systems themselves.

The time to think about this integration is before you choose your PLM, not after. The bridge between them needs to be automated data flow: approved revisions, effectivity dates, BOM changes, and routing updates flowing into production without re-keying — and without a 12-hour batch lag.

Equally important is the reverse direction. Production data must be available to design teams when they need to validate design assumptions, assess proposed changes' impact on yield or cost, or close the loop on CAPA. If the only way for an engineer to see production scrap rates is to ask the quality manager for a spreadsheet, your change control process is structurally slow.

A real integration looks like this: an ECO is approved in PLM. Within minutes, the new revision is effective in ERP, the work order routing reflects the change, the operator's tablet shows the new instruction, and the old revision is archived but still retrievable for any unit built against it.

Specific behaviors to demand from any PLM-ERP combination you're evaluating:

If you've already chosen mismatched systems, you have three realistic paths. First, build the integration properly — not a nightly batch but a real-time event-driven sync with audit trails on both sides. Expensive, but durable.

Second, simplify by consolidating. If your PLM is light and your ERP has decent change-control capabilities, you may be able to move the design history file workflows into the ERP and retire the PLM. We've seen this work well for companies under 100 SKUs.

Third, accept the gap and instrument around it. Add controls that enforce the human handoff: no work order opens without an explicit revision check, no shipment releases without a final build record review against the active PLM revision. This is the most fragile path, and it requires the most discipline.

There's no painless option once the systems are in place. That's exactly why the integration question belongs at the start of PLM evaluation, not at the end.