Your PLM Is a System of Record, Not a System of Work

The PLM vendors did the hard part first. Revision control. Check-in/check-out. Approval workflows with named signatories. Traceability chains that survive an audit. Teamcenter, Windchill, and Arena are genuinely good at this — it is what they were built for, and the regulated industries that depend on them have good reasons.

But there's a distinction nobody puts on a datasheet: a system of record is not a system of work. Your PLM knows, with perfect confidence, that revision C of a bracket was released on Tuesday. It does not know — and was never designed to know — that the engineer waiting on that bracket has been chasing the firmware team in Slack for three days because the mounting-hole pattern changed and nobody flagged the harness routing downstream.

That gap is where engineering teams bleed.

What PLM is good at

Let's be fair, because the credibility of this argument depends on it.

PLM systems are the best tool ever built for vaulting product records. CAD files with full revision history. Part numbers that resolve to exactly one released artifact. ECO workflows that route a change through the right approvers and leave a defensible paper trail. Multi-level BOMs that can be structured, configured, and released. ERP integrations that push approved structures downstream.

A peer-review comparison of the two biggest platforms found users rating Windchill higher on ease of use and Teamcenter higher on raw capability — both score well above 8/10 on meeting requirements, BOM management, and workflow capability. These are not broken products. For what they were architected to do — be the authoritative record — they are the standard for a reason.

This is exactly why we don't position ProductFlo as a PLM replacement. Ripping out a working system of record to replace it with something else would be expensive, slow, and — most importantly — pointless. The record isn't the problem.

Where the work actually happens

The record is static. Work is not.

A hardware program is a coordination problem across five to ten tools that were never designed to talk to each other: ECAD, MCAD, firmware repos, requirements docs, test plans, supplier portals, ERP. The PLM sits at the center and knows the state of every released artifact — and yet, ask yourself where the actual work of an engineering change happens:

• The mechanical engineer modifies a mounting pattern in CAD.
• The electrical engineer needs to know because the keep-out zone just moved.
• The firmware engineer needs to know because the connector pinout is affected.
• The manufacturing engineer needs to know because the E-BOM no longer matches what was designed.

None of that coordination happens inside the PLM. It happens in Slack threads, email, standups, and tribal knowledge. The PLM records the outcome — the released revision — but the work of getting there, the cross-discipline negotiation, the detection of downstream impacts, happens between the systems.

Dave Shuey of Siemens' own PLM division once put the canonical version of this problem plainly: "Manufacturers have always struggled with keeping the manufacturing BOM in synch with the engineering BOM. This is a non-trivial issue. People don't always appreciate the delays that changes in the engineering bills-of-material can cause in the production process." Note the framing: even the vendor acknowledges this is a coordination problem between disciplines, not a vaulting problem.

The eBOM/mBOM boundary is just the most visible instance. Every boundary between two tools — ECAD to MCAD, firmware to hardware, design to procurement — is a place where intent gets lost in translation and someone has to do manual reconciliation work.

The bypass problem

Here's the uncomfortable evidence: when the official system can't keep up with the work, engineers route around it.

The most common shadow system in hardware engineering is a spreadsheet. Product-data vendors who talk to hundreds of small and mid-sized teams report a consistent pattern: one or two PLM licenses hold the official data while everyone else pulls it into Excel to do actual work. Engineers describe being afraid of complex, unintuitive systems; of getting locked into rigid data models; of spending time on imports and setup when they have other priorities. On TrustRadius, a Windchill reviewer notes they have to convert part lists to Excel "every time" because the extract workflow doesn't land where people actually work.

Smaller companies often reject the category outright. One engineer, describing his team's search for structure, put it this way: "We looked at traditional PLM systems, but they feel like overkill. These tools were built for aerospace companies with big teams and very structured BOM processes. We don't need a PLM rocketship. We need something that just works."

And the economics explain the rejection. A long-running thread on the engineering forum Eng-Tips puts a full Windchill or Teamcenter implementation at roughly $750,000, give or take 20%, with 4–6 months to implement — and notes plainly that for a small shop, "these systems are overkill." One company described in the same thread replaced Arena with SharePoint for revision control and a lighter PDM for CAD users — a deliberate downsizing, not a failure of adoption.

This isn't user error. When engineers bypass the system of record to get work done, the system isn't failing at vaulting — it's failing at being where the work happens.

System of record vs. system of work

The distinction matters because it dictates what you should build next.

A system of record answers: what is the authoritative state? Which revision is released? Who approved it? When? It is slow, careful, governed, and correct — by design.

A system of work answers: what changed, who needs to know, and what breaks downstream? It is fast, cross-cutting, and connected to everything — by design.

PLM was architected for the first job. The second job — noticing that a schematic change invalidates a test plan, that a CAD revision strands a firmware build, that the business team ordered parts against last week's BOM — is nobody's job. So it falls on individuals: the engineer who manually diffs, the program manager who maintains a tracker, the team that discovers the discrepancy at the prototype review.

Rockwell Automation's PLM team made a point worth quoting here: "PLM doesn't need to be the home for everything, but connecting your planning, dynamic process control (DPC), PLM and collaboration tools reduces errors and manual data synchronization." The record stays in the PLM. The work gets a layer that connects.

The layer above, not the replacement

This is the argument: hardware teams don't need a new system of record. They need a governed layer above the tools they already use — one that watches what changes in ECAD, MCAD, firmware, and requirements, understands the dependencies between them, and surfaces the impact before it becomes rework.

"No migration. No rip-and-replace." That's not a marketing line; it's the whole point. The PLM stays. Arena, Windchill, Teamcenter keep doing what they're good at. The orchestration layer reads from them, writes nothing back without approval, and coordinates the work that currently lives in spreadsheets, Slack, and memory.

What that layer has to earn is trust: every suggested action traceable to the underlying record, every cross-system link anchored in a released revision. The system of record remains the authority. The layer above just makes sure the work actually reaches it.