PLM Software: Managing Product Data From First Sketch to Production

When a new client calls me about PLM software, the first question I ask isn’t about the software at all. Instead, I ask them to walk me through the last engineering change that went wrong.

Nearly every company has a story. In one plant, a drawing went to the machine shop at Revision C after engineering had already released Revision D. Elsewhere, a supplier quoted from a spreadsheet that someone saved to their desktop three months earlier. Then there was the purchasing clerk who ordered 2,000 fasteners for a design that had dropped them. Still, nobody in these stories was careless. Each of them worked from the data they had, but that data was wrong, out of date, or sitting somewhere nobody else could see.

That gap is where PLM software lives. Over most of my career, I’ve designed and rolled out product lifecycle management systems for discrete manufacturers, machine builders and industrial equipment companies. Along the way, I’ve come to think of PLM less as an application and more as a discipline that software makes enforceable. So if you’re evaluating PLM software, or you’re stuck in an implementation that isn’t delivering, this is how I explain it to the engineering managers and operations leads I work with.

What PLM Software Actually Manages

Once you strip away the vendor brochures, PLM software does three things. First, it holds the authoritative record of what your product is. Second, it controls how that record is allowed to change. Finally, it makes that record available to everyone who needs it, at the right revision, at the right time.

That record covers far more than CAD files. In fact, it includes part numbers, the bill of materials, specifications, drawings, requirements, supplier and compliance data, and the full history of every change. The research firm Lifecycle Insights draws a useful line between PDM and PLM. PDM manages CAD files and documents for engineering, whereas PLM manages all product information and the processes around it across the full lifecycle. I see plenty of companies that say they have PLM when what they really have is a CAD vault. A vault helps, of course. However, it doesn’t stop the Revision C problem, because the shop floor, purchasing and quality teams never look inside it.

Meanwhile, the market has clearly worked this out. CIMdata, the analyst firm most of us in the field rely on for market data, reported that the PLM market reached US$88.25 billion in 2025. Spending at that level tells you manufacturers no longer see product data management as an engineering luxury. Rather, they see it as operational infrastructure, in the same bracket as ERP.

Stage One: How PLM Software Handles the First Sketch

Most people picture PLM starting when the CAD model gets checked in. In my experience, though, the most valuable data appears earlier, and it’s usually the data that gets lost.

Early concept work produces requirements, customer notes, rough sketches, results from early prototypes, competitive teardowns, cost targets and decisions about what the product will not do. That last one gets overlooked. For example, when a design review settles on a cast housing instead of a machined one, the reasoning behind it matters two years later when someone proposes switching back. If that reasoning lives in an email thread, it’s gone.

For that reason, I push clients to capture three things in the PLM system during early design, even while the CAD geometry is still rough.

Requirements with owners. Every requirement should have a source and a person responsible for it. Then, when a requirement changes, the system can show which design items trace back to it.

Design decisions. A short note linked to the affected parts is enough, so it doesn’t need to be a formal document.

Preliminary part numbers. This one sparks debate. Some engineers want to wait for a “real” design. Personally, I’d rather assign numbers early and mark them as in work, because parts with no identity can’t be tracked, costed or reviewed.

None of this needs heavy process. In the concept phase, I want the PLM software to feel light, almost like a shared notebook with structure. The heavy controls come later.

The PLM Software Cost Nobody Budgets For: Part Numbers

If I could give one warning to every company buying PLM software, it would be this: your biggest cost won’t be licenses. Instead, it will be cleaning up your item master.

Over the years, I’ve opened databases with four different part numbers for the same M8 bolt. I’ve also seen numbering schemes that encode the material, the product line and the designer’s initials, which looked clever in 1998 but turned into a trap once the product line was renamed. On top of that, I’ve found ERP systems and engineering systems that used separate revision schemes for the same part, so Revision 3 in one matched Revision C in the other, but only sometimes.

This matters because everything downstream hangs off part identity. One practical explainer on the digital thread in manufacturing identifies inconsistent part numbers and revision schemes across CAD, PLM and ERP as a leading reason connected data efforts fail. I agree completely. Even if you buy the best integration middleware on the market, the same part with two identities will simply have its confusion copied faithfully from one system to the other.

Therefore, my advice is to settle numbering rules before you migrate a single record. Wherever you can, use plain sequential numbers that carry no built in meaning. Next, agree on one revision scheme and decide which system owns it. After that, give a small team real authority to merge duplicates. Admittedly, it’s dull work, but it’s also the most important work in the whole project.

Why the BOM Sits at the Heart of PLM Software

Ask five people in a manufacturing company what the product is and you’ll get five answers. Sales describes features, while engineering opens the model and finance pulls up a cost rollup. In practice, though, the closest thing to a single answer is the bill of materials.

The engineering BOM, or EBOM, captures the product as designed. It contains the assemblies, subassemblies and components that make up the design intent, usually generated from the CAD structure and then enriched with attributes in PLM. Visure Solutions and others describe the EBOM and the manufacturing BOM as serving different roles, and that distinction drives many of the architecture decisions I make.

So here is what I insist on for a healthy EBOM inside PLM software. To start, the BOM is managed as structured data, not as a spreadsheet attached to a drawing. Each line is also a real item with its own revision and lifecycle state. Similarly, quantities, units of measure and reference designators are fields, not free text. Above all, the BOM has a clear owner during each phase, so there’s never a question about who is allowed to edit it.

When the BOM lives as structured data, you can ask questions a spreadsheet can’t answer. Where else is this bearing used? Which assemblies are affected if this supplier discontinues this resin? What did this product contain when we shipped serial number 4471? Those questions come up constantly in industrial service work. As a result, companies without a structured BOM end up answering them with days of manual digging.

Engineering Change: Where PLM Software Earns Its Keep

If a client lets me automate only one process, it’s engineering change. After all, this is where PLM software either pays for itself or exposes every weakness in the implementation.

The Rhythm of a Good Change Process

A good change process has a predictable rhythm. Initially, someone raises a problem report or change request. Engineering then assesses it and estimates the impact. Next, a change order bundles the affected items, the new revisions and the disposition of existing inventory. Once the right people review it, it’s released, and everyone downstream sees the new state at the same moment.

The guidance on BOM change management from Visure describes structured approval workflows that bring engineering, manufacturing, procurement and quality into review before a change is implemented. That cross functional review is the whole point. Indeed, most of the expensive change failures I’ve investigated weren’t engineering mistakes. Typically, engineering made a sound change, but nobody told purchasing there were six months of the old part sitting in the warehouse.

Change Rules I Configure in Every PLM Software Project

Impact analysis comes before approval. The change order should show every parent assembly, every open work order and every document affected. PLM software makes this possible through where used queries, but only if your BOMs are clean.

Disposition is mandatory. Use as is, rework, scrap or return to vendor. Someone has to decide, and the decision has to be recorded.

Approvers are roles, not names. People leave, whereas roles stay. Routing a change to “Quality Lead, Plant 2” therefore survives turnover in a way that routing it to a person doesn’t.

Fast track exists, but it’s visible. Urgent changes happen. So give them a defined faster path instead of letting people go around the system, because going around the system is exactly how the Revision C story begins.

Likewise, an article from Uncountable on discrete PLM implementation makes a point I repeat often: simplify before you automate. If your current paper change process has eleven signatures, automating it simply gives you an eleven signature electronic process that’s just as slow. Redesign it first.

Handing Off to Manufacturing: PLM Software, the MBOM and ERP

This is the most debated topic in my field. It’s also where I see the most confusion among buyers.

Why the MBOM Exists

Engineering designs a product in a logical structure, while manufacturing builds it in a physical sequence. For instance, the motor and the bracket might sit in different engineering subassemblies but get fitted at the same station. Likewise, paint, adhesive and packaging might not appear in the EBOM at all, yet manufacturing can’t ship without them. That’s why the manufacturing BOM, or MBOM, exists. As the Dutch PLM consultant Jos Voskuil has explained on Virtual Dutchman, the same engineering definition can lead to different MBOMs, and a company can optimize its production structure without touching the engineering definition.

The old pattern was simple. Engineering released the EBOM, and then someone in manufacturing engineering keyed a version of it into ERP by hand. Surprisingly, I still find this in companies with decent revenue and modern machines. It works until the first change arrives. After that, every change has to be keyed in twice by people working from different screens.

Should PLM Software or ERP Own the MBOM?

The real question is which system owns the MBOM. My position, and that of many architects I respect, is that PLM owns the definition while ERP owns the execution. A consultant at PLM Advisors put it plainly in a widely shared discussion on MBOM ownership: the best approach isn’t picking PLM or ERP, but using each for what it does best. Years ago, Voskuil also argued in Where Is the MBOM? that the MBOM should be built in PLM, mainly because it makes impact analysis far easier when engineering makes a change. In addition, PLM Technology Guide points out a practical benefit: when manufacturing items are defined in PLM, they can move to ERP gradually as manufacturing engineering is ready, without waiting for the entire EBOM to be released.

How I Design the Handoff

In practice, I design the handoff like this. Engineering releases the EBOM in PLM. Afterward, manufacturing engineering builds or adjusts the MBOM in PLM, linked back to the EBOM so every manufacturing item traces to its design source. An integration then publishes released items and MBOMs to ERP, where routings, costing, inventory and purchasing take over. Crucially, ERP never edits the product definition. Whenever it needs to change, the change comes back through PLM.

To be fair, Oleg Shilovitsky’s writing on MBOM in PLM and ERP integration is honest about the fact that there’s no single standard way to implement this. Smaller shops with simple products can often run a single BOM with manufacturing attributes added. By contrast, complex configured equipment almost always needs separate structures. Either way, what matters is that the decision is deliberate and written down.

PLM Software and the Digital Thread, Without the Marketing Gloss

You can’t evaluate PLM software in 2026 without hearing about the digital thread. Unfortunately, the term gets stretched so far that buyers sometimes assume it’s a module they can purchase.

It isn’t. Simply put, the digital thread is the idea that one connected, traceable flow of data follows a product from concept through design, manufacturing and service, so a change in one place is understood everywhere else. It’s also what feeds a digital twin with product data you can trust. PTC has described PLM as the foundation for the digital thread, and I think that framing is fair. PLM holds the product definition the thread hangs on. Meanwhile, MES contributes what actually happened on the line, ERP contributes cost, schedule and inventory, and service systems contribute field failures and repairs, increasingly fed by industrial IoT data from equipment in the field.

Here’s what the digital thread looks like when it works in an industrial setting. Suppose a field technician logs a recurring seal failure on a pump model. Quality then opens a corrective action linked to the seal part in PLM. Because of that link, engineering sees every pump configuration that uses the seal, raises a change and swaps the material. Manufacturing subsequently receives the updated MBOM and work instructions, and service gets the new spare part number. Throughout the process, every step traces back to the original field report.

Automation World notes that fragmented data across enterprise systems often keeps companies from getting the benefits they expected from PLM. That matches what I see. Generally, the thread doesn’t break inside PLM. Instead, it breaks at the edges, where data passes from one system to another without a shared identity or a clear owner. It’s the same problem plants run into with IT/OT convergence.

Cloud PLM Software or On Premises?

Ten years ago, almost every serious PLM deployment I worked on ran on servers the client owned. Today, however, most of my new projects with small and midsize manufacturers start in the cloud.

The Economics of SaaS PLM Software

The economics are a big part of that shift. ABI Research found that on premises PLM is, on average, 31 percent more expensive than its SaaS equivalent, and that SME manufacturers increasingly see on premises PLM as something nice to have rather than a necessity. The same research also points to the major vendors moving toward SaaS, with Siemens Teamcenter X, Dassault Systèmes 3DEXPERIENCE ENOVIA and PTC Windchill+ leading the way. Similarly, Siemens makes the case in its own comparison of on premises and SaaS PLM that smaller businesses can cut costs and get running faster with SaaS.

The Real Decision Points

Even so, cost isn’t the only factor. In my experience, these are the real decision points.

Customization appetite. On premises systems tolerate deep customization, whereas SaaS platforms push you toward configuration and standard processes. I count that as an advantage for most clients, since heavy customization is the main reason upgrades become painful.

Regulatory and export control constraints. Defense suppliers and some aerospace work come with data residency rules that limit your hosting options. Consequently, check them before you shortlist vendors.

Internal IT capacity. If your IT team is two people who also manage the phones, running a PLM server stack on top of everything else is a bad bet.

Integration architecture. Cloud PLM connects to ERP and MES through APIs and integration platforms. Make sure, then, that your ERP can work with that model.

How I Run a PLM Software Implementation

Every engagement is different. Nevertheless, the shape of a successful rollout is remarkably consistent, and this is the sequence I follow.

Phases One to Three: Groundwork

Phase one: discovery and pain mapping. My first step is interviewing engineering, manufacturing, purchasing, quality and service. Along the way, the change failure stories come out. From there, the team and I map where product data lives today, including the spreadsheets nobody admits to. Often, this phase reveals that the stated problem, “we need a better CAD vault,” is really something else, such as “purchasing never knows when a design changes.”

Phase two: data model and rules. This covers part numbering, revision schemes, lifecycle states, item types, attributes and BOM ownership. Importantly, I make these decisions with the client before anyone configures anything.

Phase three: data cleansing and migration planning. Duplicate parts get merged, and obsolete items get marked as such. The guide from Pattern on PLM implementation stresses cleaning, standardizing and validating data before migration, and I can’t say it strongly enough. Otherwise, migrating dirty data into clean software just gives you dirty data that looks more official.

Phases Four to Six: Building Out the PLM Software

Phase four: a narrow first release. Usually, I start with item management, EBOM and engineering change for one product line. That’s enough to prove value without overwhelming anyone. Later, requirements management, supplier collaboration and quality integration follow.

Phase five: ERP integration. Released items and BOMs flow to ERP. At first, I keep the integration one directional and simple, and then I add complexity once both sides trust it.

Phase six: expansion. More product lines, more processes and more users come next. By this point, the internal team should be driving while I advise.

Overall, the typical timeline for a midsize manufacturer on cloud PLM is four to nine months to a solid first release. Large multisite programs on heavily integrated platforms run longer, sometimes years. So anyone who promises a full enterprise rollout in six weeks is selling you something else.

The PLM Software Mistakes I Keep Seeing

Some failure patterns show up so often that I could almost write the project review before kickoff.

Buying for features instead of process. A demo that shows impressive 3D visualization says nothing about whether the change workflow fits how your plant actually runs.

Treating it as an IT project. PLM changes how engineering, manufacturing and purchasing work together. Thus, if the project sponsor is the IT manager alone, adoption suffers. Ideally, the sponsor should be someone who owns product outcomes.

Recreating the old system. When users ask for every report and screen they had before, the result is a modern system shaped like a legacy one. For this reason, challenge each request.

Ignoring the shop floor. If operators and supervisors can’t easily see the released drawing at the correct revision, they’ll keep printed copies taped to the machine. And printed copies are where Revision C lives forever.

No data owner after go live. Data quality decays without someone accountable for it. Therefore, name a product data administrator and give them real time to do the job.

How to Tell If Your PLM Software Is Working

I always agree on measures with clients before implementation starts, because “it feels better” isn’t a business case. Specifically, the metrics I track most often are change order cycle time from request to release, scrap and rework traced to wrong revision, time spent searching for product data, the duplicate part creation rate, and the time from design release to the first production order in ERP.

When these numbers move in the right direction, PLM software stops being a cost center in people’s minds. Instead, it becomes part of how the company builds products. Ultimately, that’s the real goal. It isn’t a new login screen, but a plant where the person holding the drawing can trust it.

Frequently Asked Questions About PLM Software

What is PLM software in simple terms?

PLM software is a system that holds the official record of a product, including parts, BOMs, drawings, specifications and change history. In addition, it controls how that record changes from concept through retirement. The Lifecycle Insights PLM guide offers a thorough overview of its core capabilities.

What is the difference between PLM software and PDM?

PDM focuses on managing CAD files and engineering documents. PLM, by contrast, covers all product information and the business processes around it across the entire lifecycle, including change management, BOMs and supplier data. Lifecycle Insights compares the two in its complete PLM guide.

Should the MBOM live in PLM or ERP?

Many PLM architects recommend defining the MBOM in PLM, where it links to the engineering definition and supports impact analysis, and then publishing it to ERP for execution. PLM Technology Guide walks through the trade offs in detail.

Is cloud PLM suitable for small manufacturers?

Yes, and for many it’s now the default choice. According to ABI Research, SaaS PLM has brought adoption within reach of SME manufacturers, while on premises deployments cost considerably more on average.

How long does a PLM software implementation take?

A focused first release for a midsize manufacturer often takes four to nine months, depending on data quality and integration scope. Larger multisite programs, however, take longer. The Uncountable guide to discrete PLM implementation covers the factors that drive timelines.

What is the digital thread and how does it relate to PLM?

The digital thread is a connected flow of product data across design, manufacturing and service systems. PLM, in turn, provides the product definition that thread depends on. PTC’s discussion of the digital thread explains PLM’s role as its foundation.

How big is the PLM market?

According to CIMdata, the global PLM market reached US$88.25 billion in 2025. Before that, an earlier CIMdata market release reported growth to over US$80 billion in 2024.

References

1. CIMdata. PLM Market Results and Geographic Analysis, 2025 Calendar Year
2. CIMdata. CIMdata Publishes PLM Market and Solution Provider Market Report
3. Lifecycle Insights. What Is PLM Software? The Complete Guide to Product Lifecycle Management
4. ABI Research. PLM Is Now on Par with Traditional Manufacturing Software
5. Siemens Digital Industries Software. On Premises PLM vs. SaaS PLM: Operational Savings with SaaS
6. PTC. How the Digital Thread Can Transform Your Design and Manufacturing Processes
7. Automation World. How Digital Threads Take PLM to a New Level
8. Oleg Shilovitsky, Beyond PLM. The Role of MBOM in PLM and ERP Integration
9. Jos Voskuil, Virtual Dutchman. Where Is the MBOM?
10. Jos Voskuil, Virtual Dutchman. PLM and ERP
11. PLM Technology Guide. What System Should Own the MBOM? PLM or ERP? Or Both?
12. Visure Solutions. EBOM vs MBOM: How to Simplify BOM Management
13. Visure Solutions. BOM Change Management
14. Uncountable. Discrete PLM: Why Implementation Fails, and How Manufacturers Can Get It Right
15. Pattern. Guide to PLM Change Management and User Adoption
16. Leo AI. The Digital Thread in Manufacturing: A Practical Explainer
17. LinkedIn, PLM Advisors. What System Should Own the MBOM? PLM or ERP?