Why Parts Don’t Have Revisions (Only Datasets Do)

September 2, 2025

Martijn Dullaart

Community Voice

When you ask a hundred people:

“Do parts have revisions?”

The room will be divided depending on the person’s role. Engineers will mostly say yes, while supply chain managers will mostly say no. 

But here’s the truth:

👉 Parts don’t have revisions. Datasets do.

This statement almost always sparks debate, confusion, or even pushback. And that’s good because challenging assumptions is how organizations evolve from a document-centric past to a truly model-based future. 

In this edition of the “How do YOU CM2?” series, we’re unpacking one of the most misunderstood—and most critical—principles in Configuration Management. If you want to streamline your Product Lifecycle Management (PLM) strategy, reduce rework, and accelerate the adoption of change, this concept is the lever that makes it happen. 

Let’s start with some definitions. What is a part or item? In this post, these are synonyms.

A Part or Item is a non-specific term used to denote any product, assembly, or component, including hardware (e.g., rim or spokes), software (e.g., control software), processed materials (e.g., glue), or service (e.g., training) that satisfies a function.
Source:
The Essential Guide to Part Re-Identification

What is a dataset

A dataset is a set of information that must be released as a whole and can be released separately from any other dataset.
Source:
The Essential Guide to Part Re-Identification

What is a unit?

A unit is a single instantiation of a part as the result of an executed application order.
Source:
The Essential Guide to Part Re-Identification

Why This Matters More Than You Think

In traditional product development environments, we often talk about a part “being at Rev A” or “going to Rev B.” But when you step back and think about it, a physical part sitting on your desk doesn’t magically change when a document revision changes.

That bolt in inventory doesn’t suddenly shift from Rev A to Rev B. The material properties don’t alter. The geometry doesn’t change overnight.

What does change?

  • The dataset that defines the part: CAD models, drawings, specifications, test data, and digital twins.
  • The rules and context for when that dataset applies. 

This distinction is more than semantics, it’s the difference between effective change control and a lot of complexity and extra effort to get things right.

When “Revisions” Go Wrong

A few years ago, I met with a manufacturer who showed me their part identification system. Every part number had a revision, tracked in their PLM and ERP systems.

So what was the problem?

  • Production planners were ordering “Rev C parts,” but only the interchangeable “Rev B” parts were in stock. At the same time, the Bill of Materials required Rev C parts.
  • In the factory, they were uncertain if they could still use the Rev B parts or whether they should wait for the Rev C parts to get in stock. 
  • Suppliers were confused. Did they need to scrap perfectly good “Rev B” inventory?
  • Engineering was frustrated. Design updates were complex due to the precise bill of materials. Parent Rev A uses Child Rev B, and Parent Rev B uses Child Rev C. Also, read Precise Bill of Materials Don’t Exist!

When you use part revisions like this, the revision becomes part of the Part number, and you have no way of managing changes efficiently, resulting in delays, rework, and finger-pointing. Millions of dollars in lost productivity, and all because of a flawed assumption that was never challenged before.

When we reframed the conversation around datasets (not parts) having revisions, the team suddenly realized:

  • The part number is constant—it represents the part or item.
  • The dataset revisions evolve—it represents our latest definition of that part or item.
  • The effectivity rules govern which dataset applies to which unit, build, or contract.

Another example is explained by Joseph Anderson, where a manufacturer of intubation tubes distinguished the adult from the child tubes using the part revision (watch from 22:29 to 23:04). 

Using part number revisions is a poor man’s solution to compensate for the inability to manage and trace parts. It causes confusion, leading to mistakes, and people, in Joe’s example, his son, get injured because of it. 

The CM2 Perspective

The CM2 standard has long taught that:

  • Part numbers identify items. They do not carry revision intelligence.
  • Datasets define items. They evolve over time and are revision-controlled.
  • Effectivity ensures accuracy. Production and Purchase Orders call out datasets by their effective revision.

This is why CM2 practitioners say:

“Parts don’t have revisions. Datasets do.”

It’s a powerful simplification. It prevents the mess that part-number proliferation brings, where organizations burn time creating new part numbers for every minor design tweak. Instead, you gain transparency and control: a single, stable part number tied to evolving datasets with clear effectivity. Setting standards and following them eliminates confusion, rework, wasted effort, and the repercussions of bad decisions.

Organizations that adopt this principle see measurable benefits:

  • Reduction in engineering change cycle time (because changes flow through dataset updates, not part renumbering).
  • Fewer procurement errors (buyers don’t mistakenly order the wrong “rev” of a part).
  • Less Inventory Bloat  (warehouses don’t have to carry multiple bins of “different” parts that are interchangeable)

In short, this one mindset shift drives down cost, improves quality, and speeds up delivery.

Why Organizations Struggle

So why is this still such a common misconception?

  1. Legacy Systems: Many were built around part-revision fields, reinforcing outdated practices.
  2. Cultural Inertia: “We’ve always done it this way” is powerful—even when it causes pain.
  3. Document-Centric Thinking: Too many organizations are still oriented around paper-based processes, where the drawing is the part.
  4. Fear of Change: Untangling revision practices feels risky.

The good news? CM2 provides that framework. It gives organizations the language, process, and data models to break free from revision confusion.

Practical Steps You Can Take

If you’re ready to move from “parts have revisions” to “datasets have revisions,” here’s how to start:

  1. Audit your current state. Where are you tracking “part revisions”? ERP? PLM? Supplier contracts?
  2. Separate part numbers from dataset revisions. Establish clarity on what identifies an item vs. what defines it.
  3. Train your teams. Engineers, buyers, and suppliers need a shared language to avoid old habits creeping back.
  4. Apply effectivity rules. Ensure you know which dataset applies where and when.
  5. Tell the story. Don’t just change the process—explain why this matters. Link it to cost savings, quality, and delivery metrics.

So, let me ask you, as part of this ongoing How do YOU CM2? conversation:

👉 Where in your organization are you still treating parts as if they have revisions?

Is it in your ERP? Your supplier agreements? Your engineering team’s vocabulary? I’d love to hear how you’ve addressed (or struggled with) this. Drop your thoughts in the comments.

Final Thought

The future of product development belongs to organizations that master clarity in their digital thread. And clarity starts here:

Parts don’t have revisions. Datasets do.

If you embrace that principle, you’ll not only eliminate waste—you’ll accelerate your path to true digital transformation. Also, read Parts don’t have revisions.

So… How do YOU CM2?

Ready to go deeper?

Use code Martijn10 for 10% off training—and don’t forget to tell them Martijn sent you 😉.

Copyrights by the Institute for Process Excellence

This article was originally published on ipxhq.com & mdux.net.

Go to the Perspectives Page

About the Author

Known by his blog moniker MDUX—Martijn is a leading voice in enterprise configuration management and product lifecycle strategy. With over two decades of experience, he blends technical depth with practical insight, championing CM2 principles to drive operational excellence across industries. Through his blog MDUX:The Future of CM, his newsletter, and contributions to platforms like IpX, Martijn has cultivated a vibrant community of professionals by demystifying complex topics like baselines, scalability, and traceability. His writing is known for its clarity, relevance, and ability to spark meaningful dialogue around the evolving role of configuration management in Industry 4.0.

ALWAYS EVOLVE WITH IPX
Follow us
on Linked