"Our package can do that too." Anyone shopping for more grip on engineering data hears that line in every demo. The PDM vendor has a module for items, the ERP suite claims to manage documents, and somewhere a PLM consultant pulls up a chair, wanting to put everything under one umbrella. By the end of the week you have three quotes and less overview than ever.
Time to untangle this calmly. This article explains the difference between PDM, PLM and ERP: what each system does, where they touch and in which order a smaller manufacturing company actually needs them. Spoiler up front: the first step is usually none of the three, but getting your own CAD data in order, with solid agreements and, if need be, nothing more than a toolbox like Thundercad next to Inventor.
PDM: grip on files and versions
Product Data Management manages the files engineering works with: models, drawings, assemblies and everything attached to them. The core functions are check-out and check-in (no two people in the same part at once), version control (every state is kept) and searching on properties instead of folder names. A good PDM system also knows the references between files: it can tell you which assemblies use a part before you change it.
PDM talks in files and revisions, and that is both its strength and its boundary. For Inventor teams, Autodesk Vault is the best-known implementation; whether that step already pays off for your team depends on team size, project pressure and the cost of mistakes. We wrote an honest decision model about that in Do you need Vault? An honest answer for smaller teams.
PLM: the process around the product
Product Lifecycle Management looks beyond files: it follows a product from requirement to phase-out. Think change requests with review and approval, requirements management, the interplay between mechanics, electrical and software, and documentation that has nothing to do with CAD: manuals, certificates, test reports. PLM answers questions like "which changes are in the configuration this customer is running" and "who approved that change, and when".
That sounds attractive, and for companies under heavy change pressure or strict documentation demands it is. But PLM assumes the layers beneath it are solid: without reliable file management and filled-in metadata you are automating a process that does not exist yet. In smaller companies, "PLM" is often simply a well-agreed way of working with the means already in place.
ERP: items, quantities and planning
Enterprise Resource Planning sits on the business side: sales orders, purchasing, inventory, planning, costing. An ERP system does not think in files but in items: an item number with a description, a price, a lead time and a stock level. Whatever engineering designs only becomes interesting to ERP once it is an item that has to be bought, made or sold.
That makes ERP the oldest and most self-evident system of the three for most manufacturers: it was often running long before anyone modeled in 3D. So the question is rarely whether you need ERP, but how to get engineering data into it reliably.
Where the three meet, and where they clash
On paper the division of labor is clear. In practice it chafes in three places: the bill of materials, the item master data and the change process. The BOM is born in CAD, but production and purchasing work with the version in ERP. Items exist in both worlds, each with their own fields. And a change touches everything at once: file, item, stock and running orders.
| Question | The answer lives in |
|---|---|
| Which version of this model is current? | PDM |
| Who approved this change, and when? | PLM (or PDM with workflows) |
| How many pieces are in stock? | ERP |
| What is the lead time of this purchased part? | ERP |
| Which parts make up this product? | All three, each for its own purpose |
That last row is where most of the trouble starts. The design BOM in CAD, the managed BOM in PDM and the manufacturing BOM in ERP are family, but not identical. As long as people retype them by hand they drift apart, and every retyped line is a chance for an error that only shows up on the shop floor.
Wherever you stand in this story, the daily handover between Inventor and ERP does not have to wait for a big system. Thundercad exports the BOM into your own Excel template and lets you look up and place ERP items directly inside Inventor.
Try 30 days freeThe order that usually makes sense for smaller companies
Vendors reason from their own box; you are better off reasoning from your biggest risk. For most smaller manufacturing companies the healthy order looks like this:
- First, get your CAD data in order. Fixed templates, filled-in iProperties, a clear naming convention and models without leftovers. Without this foundation, every system just makes the chaos easier to find. How that foundation carries through to the shop floor is covered in Clean, reliable data into production.
- Then PDM. As soon as several people work in the same files daily, version control becomes the bottleneck. PDM solves an acute, measurable problem; that is why it comes before PLM in the queue.
- Connect ERP deliberately. ERP is usually already running. The gain is in the handover: first agree on item numbers and BOM transfer, only then add technology to automate those agreements.
- PLM only with demonstrable process pain. Heavy change pressure, traceability demands from customers, multiple disciplines waiting on each other: those are the signals. Not "the demo looked nice".
The order is not a law, but one rule always holds: every system amplifies what you feed it. Put clutter in and you get neatly organized clutter back.
Frequently asked questions
Is Autodesk Vault PDM or PLM?
Vault is PDM at its core: file management, versions and findability for your Inventor environment. More extensive editions move toward PLM territory with change workflows and lifecycles, but the center of gravity remains managing CAD files. For most Inventor teams that is exactly what is needed.
Can our ERP system not simply manage the CAD files as well?
Almost any ERP system can store documents, but CAD files are not loose documents: an assembly references dozens of parts that need each other. Without check-out, version control and knowledge of those references, that goes wrong sooner or later. Let ERP do what it is good at and give engineering its own management layer.
What can I do without buying a single new system?
More than you might think: agree on a naming convention, fill iProperties consistently and standardize the BOM handover to ERP. That work is required for any future system and pays off today. You can put the export and item tools in Thundercad to work on it, free for a month.