Most teams don’t notice their PLM system is failing them. They notice the symptoms: a launch that slips, an audit that turns into a fire drill, an engineer who keeps a “real” bill of materials in a spreadsheet. Then they treat each one as a separate problem. In 2025, 64% of manufacturers reported struggling with siloed product data. That number is rarely a software defect. More often, it’s a sign the system, the process, and the people around it have drifted out of alignment. Here are eight red flags worth taking seriously, and how to tell a healthy system from a failing one in each case.
Key Takeaways
- In 2025, 64% of manufacturers cited siloed data as a top product-development challenge: a process and adoption problem, not a software bug.
- 73% of manufacturing plants fail at least one audit finding a year, mostly from missing documentation and broken traceability.
- Three or more of these red flags usually means the issue is structural: your strategy and rollout, not your software.
The uncomfortable reality: a system can be configured exactly to spec and still fail. When a PLM platform stops delivering a return, the cause is almost never the technology alone. It’s how the platform was scoped, how change was managed, and whether anyone tied the rollout back to a business outcome. That distinction runs through all eight signs below.
1. Engineers spend more time hunting for data than designing
If your best engineers are searching instead of designing, the system has inverted its own purpose. Employees lose roughly 12 hours a week navigating disconnected systems to find the information they need, nearly a third of the workweek spent on overhead. In a PLM context, that’s senior engineering talent reduced to data archaeology.
Look past the one frustrated engineer to the pattern: people asking colleagues for “the latest” file, version confusion on released parts, design work waiting on someone to confirm which document is current. In 2025, 62% of manufacturers reported that lost or outdated product files had directly delayed a launch.
In a healthy system, the current, released version is the path of least resistance: finding the right data is faster than asking a coworker. When it isn’t, the system has quietly become a place data goes to get lost.
According to the 2025 Aras survey of more than 600 manufacturing executives, siloed data (64%) sits alongside IP security (69%) and the AI skills gap (65%) as a defining challenge. When your PLM can’t break those silos, it isn’t solving the problem it was bought to solve.
2. Every engineering change takes weeks, not days
A routine engineering change should move in days. When it crawls through email threads and approval queues instead, the bottleneck is the process, not your engineers. As of 2025, digital-first automakers compressed concept-to-launch to about 24 months, roughly half the 40–50 months still typical at legacy manufacturers. Slow change cycles compound across every program you run.
Familiar symptoms: a change that should take days waits on manual BOM reconciliation across sites, an approval stuck in someone’s inbox, or a downstream team that never heard the change happened. Multiply that by every ECO in flight and you have a structural drag on time-to-market.
Manufacturers who get this right don’t just move changes faster; they make change visible. Their processes route, notify, and record without anyone having to remember to. So the question worth asking is simple: when a change happens, does the next team find out by design, or by chance?
3. Spreadsheets and shadow processes have crept back in
When the “real” bill of materials lives in someone’s spreadsheet, your PLM system has already lost. Tracking BOMs in spreadsheets routinely causes overlooked or misused components, cost overruns, and quality escapes. Shadow processes are the clearest adoption-failure signal there is. People only build workarounds when the official system gets in their way.
Look for the side channels. A shared drive of “working” files. A side spreadsheet that tracks the change everyone actually trusts. A senior engineer who’s become the human index for where things really are. None of that is a discipline problem. It’s the team rejecting a system that’s harder to use than the workaround.
Good is simple to describe: the system of record and the system people actually use are the same system, and nobody maintains a parallel truth. If your team has quietly rebuilt core PLM functions in Excel, the platform isn’t serving them, and the data you’re governing isn’t the data your engineers trust.
4. Audits become a fire drill instead of a report
If preparing for an audit means weeks of scrambling to assemble documentation, the PLM isn’t enforcing compliance so much as postponing it to audit week. In 2025, an estimated 73% of manufacturing plants failed at least one audit finding annually, with most failures tracing back to missing documentation, incomplete audit trails, or outdated records. The gap is rarely between being compliant and being non-compliant; it’s between being compliant and being able to prove it.
That distinction matters more than it sounds: when your system can’t produce a clean, time-stamped chain of changes on demand, audit risk and remediation cost climb together. A PLM that’s doing its job turns an audit into a query, not a quarter-long project.
5. Multi-CAD and multi-site collaboration constantly breaks
Two sites, one design, and a week of manual rework every time they drift apart. At that point the platform has become a barrier between your teams rather than the link it was bought to be. In 2025, 33% of manufacturers identified disconnected supply chains as a barrier to building a usable digital thread. For multi-CAD, multi-site manufacturers, that broken data flow is a daily tax.
Each failure here is specific. A part that’s “released” at one site but unknown at another. CAD files that lose their associativity across tools. Teams emailing exports because the system can’t broker the handoff. Every one of those moments is a place where errors enter and time leaks out.
In practice, collaboration that holds up rests on a single source of truth that every site and every CAD tool reads the same way. If your engineers in two locations are reconciling BOMs by hand, the platform isn’t doing the integration work it was bought for. One engineering VP described that manual reconciliation as costing “weeks” per change.
6. Every upgrade breaks your customizations
Routine, boring upgrades are a sign of health. When a team starts avoiding upgrades altogether, the platform has usually been customized into a corner. Heavy customization is one of the most common reasons PLM platforms become brittle. In 2025, 35% of manufacturers cited extensive configurations as an obstacle to improving their digital thread. Every bespoke tweak becomes something the next upgrade can break. Each upgrade turns into a re-implementation.
It plays out the same way every time. An upgrade is overdue because the last one broke three custom workflows. The administrator spends more time firefighting regressions than improving anything, and the platform falls further behind as the gap between what you have and what’s current keeps widening.
The over-customization trap: Most brittle PLM systems weren’t badly built. They were over-built. Every “we’ll just customize that” decision in year one becomes an upgrade tax in year three. The fix is usually configuration discipline, not more code.
Teams that upgrade painlessly tend to favor configuration over heavy customization. It isn’t an absolute, but it’s a consistent enough pattern to be worth examining. If your team can’t remember its last clean upgrade, that fragility usually points straight back at the original implementation strategy.
7. Nobody can give a straight answer on ROI
Plenty of PLM programs can’t put a number on what they return. Without one, the investment is impossible to defend, and usually isn’t delivering much. Across industries, up to 80% of IT budgets go toward maintaining legacy software, leaving only 20% for innovation. A platform that drains maintenance dollars without producing measurable outcomes is a cost masquerading as an asset.
These signs are organizational, not technical. Leadership can’t say whether change-cycle time improved. No one agreed on a baseline. The platform gets justified by “we need it,” not by a number. When the board asks what the last PLM investment delivered, the room goes quiet.
A system worth keeping answers that question without drama: it has metrics attached (change-cycle time, first-pass quality, time-to-market) and someone who owns them. A platform no one can measure is a platform no one can manage.
8. It’s a system of record, not a system of engagement
The deepest red flag is also the quietest: your team treats the PLM as a filing cabinet they’re forced to update, not a tool that helps them work. This is the adoption failure underneath most others. A platform can be technically complete and still never become part of how people actually do their jobs. When that happens, every other red flag on this list tends to follow.
Engaged systems feel different from systems of record. In an engaged system, people reach for the PLM because it’s the fastest way to get an answer; in a system of record, they update it grudgingly, after the fact, because someone makes them. The first drives the business. The second just documents it, usually inaccurately.
This is why PLM failures are rarely technology failures. They’re strategy and adoption failures. If your team has emotionally checked out of the platform, no amount of reconfiguration fixes it until you address why they left.
What these red flags add up to
One red flag is a problem to fix. Three or more is a pattern, and the pattern points at strategy, not software. When data silos, slow change cycles, shadow spreadsheets, and audit fire drills all show up together, the root cause is usually a rollout that optimized for technical completeness instead of business outcomes and user adoption. The good news: that’s fixable, and it rarely requires throwing out the platform you’ve already paid for.
Is it time for a PLM assessment?
If three or more of these signs sound like your team, the next step usually isn’t another round of reconfiguration; it’s an honest diagnosis. ArcherGrey runs strategy-first PLM assessments that start with your business outcomes. Request a PLM assessment →
Frequently Asked Questions
Should we replace our PLM system or fix the rollout?
Usually fix the rollout first. Most PLM failures are strategy and adoption failures, not technology defects. A platform can be configured exactly to spec and still go unused. In 2025, 64% of manufacturers cited siloed data as a top challenge, a problem better solved with strategy and change management than a rip-and-replace.
How do I know if it’s the software or the implementation?
Look at adoption. If people route around the system with spreadsheets and shadow drives, the implementation, not the software, is the problem. With 62% of manufacturers reporting launch delays from lost or outdated files, the question is whether your team trusts the system as the single source of truth. If they don’t, fix the rollout.
How do I build the ROI case for fixing our PLM?
Anchor it to measurable outcomes: change-cycle time, first-pass quality, and time-to-market. Up to 80% of IT budgets go to maintaining legacy systems, so framing the fix as freeing innovation capacity resonates with leadership. Establish a baseline first; you can’t prove improvement without one.
When should we bring in outside help?
When you’ve seen three or more of these red flags and internal fixes haven’t stuck. Recurring audit fire drills, broken upgrades, and entrenched shadow processes signal structural issues that benefit from an outside diagnosis. A focused assessment is the typical low-risk entry point before any larger engagement.
The bottom line
So the real question isn’t whether the platform is good or bad; it’s whether you’re looking at a rescue or a replacement. A clear-eyed diagnosis usually tells you which, and more often than not, the answer is a rescue. In the rarer case where the platform genuinely is the wrong fit, that same diagnosis becomes the foundation for the business case to replace it.
Ready to find out which red flags apply to your team? Talk to ArcherGrey about a PLM assessment →