A recent post by Martijn Dullaart on LinkedIn about Product Changes caught my attention. Here is the link to the post where Martijn suggests that we should stop thinking of changes as purely “engineering changes” and instead treat them as product changes—acknowledging that impact ripples far beyond the engineering department.
That idea resonated with me. Not just because “Product Change” is a better label, but because it reveals a deeper truth: many of the terms we use in PLM still carry the weight of their origins in engineering-only processes. These words subtly reinforce a limited scope, one that stops short of the full product lifecycle.
In a world where the digital thread connects requirements, engineering, manufacturing, procurement, sales, and maintenance, language should reflect that broader vision. Terminology is not just semantics—it shapes how people think about ownership, scope, and integration. If we want to truly connect data across the lifecycle, our words need to match reality.
In this article, I’ll explore five terms that deserve a fresh look, and why changing them could help manufacturing organizations think—and act—differently.
From Engineering Change → Product Change
Why does this matter?
“Engineering Change” is a term that made sense when most product data lived inside the engineering department—drawings, CAD files, specifications. In that world, an engineering change order (ECO) was primarily about fixing or improving a design before handing it off to manufacturing.
But in reality, a change to a product is rarely confined to engineering. Consider a seemingly simple design tweak to change a fastener type. It might:
- Affect procurement (new supplier lead times, cost negotiations)
- Require manufacturing process changes (tooling, work instructions)
- Alter compliance documentation (regulatory filings, certifications)
- Trigger service manual updates (maintenance instructions, spare parts lists)
- Impact sales commitments (delivery dates, customer expectations)
By calling it a Product Change, we make clear that change governance is enterprise-wide. The term itself invites early engagement from all functions, not just engineering.
In the digital thread context, a product change process in a digital thread environment can:
- Connect the change request to all impacted configurations (EBOM, MBOM, SBOM)
- Show downstream cost and supply chain impact instantly
- Synchronize approvals across systems (PLM, ERP, MES, service portals)
- Track effectivity across the installed base for recall or maintenance planning
The shift in wording encourages exactly the cross-functional thinking the digital thread depends on.
From BOM / Part List → Product Structure
Why does this matter?
A Bill of Materials (BOM) or Part List is often visualized as a static document—an engineering output that lists components and subassemblies for manufacturing. But the reality in modern manufacturing is far richer and more dynamic.
The Engineering BOM (EBOM) defines how the product is designed.
The Manufacturing BOM (MBOM) defines how it will be built.
The Service BOM (SBOM) defines how it will be maintained.
Treating them as separate documents leads to duplication, manual reconciliation, and misalignment.
Product Structure reframes this as a single connected dataset—one authoritative definition with multiple views for different stakeholders.
In the digital thread context, OpenBOM’s xBOM approach allows us to rethink the data:
- All BOM views are different projections of the same connected data.
- Changes in engineering automatically reflect in manufacturing and service views, with controlled transformation rules.
- Procurement can filter the structure by supplier, lead time, or cost without creating a new BOM.
- Service can see exactly which assemblies a specific customer has, linked to field data.
Switching the term from “BOM” to “Product Structure” communicates that this is not a one-time deliverable but a living, multi-perspective product model.
From Revision → Baseline
Why does this matter?
A “Revision” label—Rev A, Rev B, Rev C—comes from document control. It works for static artifacts like drawings, but is insufficient for managing a dynamic product in a digital environment.
A Baseline is more than a version number. It captures the following things:
- The complete product definition (across all relevant views) at a specific point in time
- Effectivity rules: which units, dates, serial numbers, or locations the configuration applies to
- The associated documentation, processes, and compliance evidence
In the digital thread context, Baselines are essential for:
- Manufacturing cut-ins (“All units after serial 5000 use this baseline”)
- Regulatory submissions (FDA, aerospace authorities)
- Field service traceability (“This customer’s system is on Baseline 3.2”)
- Root cause analysis (“Failures only occur in Baseline 2.1 units built in Plant A”)
Revisions track changes to an object. Baselines track the lifecycle state of the whole product. It’s a small but critical difference that improves traceability and decision-making across the enterprise.
From Drawing Release → Design Release
Why does this matter?
In many organizations, the “Drawing Release” process is still the official handoff point between engineering and manufacturing. But the assumption here—that a 2D drawing is the authoritative product definition—is rapidly becoming outdated.
With Model-Based Definition (MBD), the primary source of truth is often a 3D CAD model with embedded PMI (Product Manufacturing Information). These models feed CAM, CMM, QA systems, and even augmented reality service tools directly.
“Design Release” is a more inclusive term:
- It covers 2D drawings, 3D models, and hybrid deliverables
- It shifts focus from the medium (drawing) to the content (design definition)
- It aligns with a future where fewer manufacturing teams rely on paper drawings at all
In the digital thread context, a Design Release event can:
- Lock the authoritative definition in PLM while enabling controlled downstream consumption
- Push validated geometry and PMI into manufacturing and inspection systems automatically
- Link to simulation and compliance data to form a complete product definition package
This small language change signals readiness for a model-based enterprise.
From Part Number → Part Link
Why does this matter?
Traditionally, the Part Number has been the backbone of identification in PLM, ERP, and supply chain systems. But in practice, three different identifiers coexist:
- Part Number – An identifier used within a company (and sometimes across companies) to refer to a specific design or material. It’s tied to the engineering definition.
- SKU (Stock Keeping Unit) – An identifier used by retailers and internal inventory systems to manage stock, pricing, and sales channels. It may bundle multiple part numbers or represent a variant for a specific market.
- GS1 Digital Link – A web-based standard that encodes a product’s global trade item number (GTIN) into a URL, allowing anyone to access authoritative online information about the product. It supports omnichannel experiences, traceability, compliance, and richer customer engagement.
How do they differ?
- Part Numbers are engineering-centric and control the technical definition.
- SKUs are commerce-centric and control logistics, sales, and retail handling.
- GS1 Digital Link connects either to a GTIN or other identifier and resolves it to live product data on the web—bridging engineering, supply chain, customer support, and marketing.
Why “Part Link”?
“Part Link” suggests that an identifier is not just a code in a database but a connection to a living set of product information—accessible across the digital thread. It can point to:
- Engineering definition in PLM
- Inventory status in ERP
- Compliance certificates in supplier portals
- Installation and maintenance guides in service platforms
- Marketing data for customers and partners
In the digital thread context, using Part Links can help to make those changes:
- Improves traceability from raw material through manufacturing to end-of-life
- Supports sustainability reporting and circular economy tracking
- Simplifies integration between systems—each link resolves to authoritative data rather than duplicating it everywhere
- Prepares companies for regulations like the EU’s Digital Product Passport
Switching the mindset from “Part Number” to “Part Link” aligns identification with connectivity and interoperability, not just internal cataloging.
Why This Language Shift Matters for PLM and OpenBOM Users
The digital thread is about more than integrating software—it’s about creating a shared understanding of product data across disciplines, systems, and organizations. Language is one of the most powerful tools we have to shift that understanding.
If we continue to use terms born in siloed, document-centric processes, we risk building “digital” versions of the same disconnected workflows. But when we adopt terms that reflect connectivity, context, and lifecycle thinking, we make it easier for people to design processes—and choose tools—that work end-to-end.
Conclusion
Digital transformation and the digital thread require rethinking traditional definitions and scope. A product change is not just an engineering change. A product structure is more than a BOM. A baseline is more than a revision. A design release is more than a drawing. And a part link is more than a number.
Expanding data horizons with the digital thread creates a more complete data lifecycle—one that covers requirements, engineering, manufacturing, procurement, sales, and maintenance.
New terminology will encourage manufacturing companies to rethink their data strategies—from documents to data—and to build the connected product definition that the digital thread demands.
Interested to learn more about OpenBOM concepts – Digital BOM, Collaborative Workspace, xBOM, and others?
REGISTER FOR FREE to check this out.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
