3 OpenBOM Implementation Decisions: Part Numbers, Revisions, and BOM Types

How to define part number strategy, revision control, and BOM types early in your OpenBOM rollout

When companies start an OpenBOM implementation, they usually come with a practical goal in mind. They want to get rid of spreadsheet chaos, to manage CAD files, organize product data, improve collaboration between engineering and procurement, and create a cleaner path from design to production, to manage purchases and RFQ. Those are right goals. But in my experience, three topics always come back very quickly: part numbers, revisions, and BOM types.

These are not small setup details. They are foundational decisions that shape how your data behaves later. The recent OpenBOM articles on part numbers and revisions, multi-level BOM revision control, and BOM types all point in the same direction: if you do not make these decisions intentionally and early, the problems will show up later in duplicates, confusion, and process friction.

Here is the short version before I go deeper. Part numbers define identity. Revisions define controlled change over time. BOM types define how different teams use the same product data in different business contexts. When these three decisions are aligned, OpenBOM becomes much easier to scale. When they are not, even a flexible system starts to feel confusing. Let me explain why each one matters and what I’ve seen go wrong.

Part Number Strategy in OpenBOM: Define It Before You Import Anything

If you delay part number decisions, the problem will hunt you later. This is the one topic many teams postpone because it feels administrative. They want to move quickly, import data, and start using the system. On the surface, that seems reasonable. But part numbers are not just labels. They become the backbone of item identity, reuse, procurement, reporting, and integration.

Before I get into what to do, let me describe what happens when you don’t.

A company spends years managing BOMs in Excel. Every time an engineer creates a new revision, they copy the file and add the revision to the file name. PRT-001-A.xlsx becomes PRT-001-B.xlsx. Eventually someone moves that data into OpenBOM during implementation, either manually or through import. Now you have PRT-001-A and PRT-001-B sitting as two separate catalog items with no shared identity. Procurement doesn’t know they represent the same part at different revisions. Engineers searching the catalog find both and don’t know which one is current. A third person creating a new BOM picks the wrong one. That ambiguity, once it spreads across hundreds of parts, is not a minor inconvenience. It is a data normalization project that takes weeks to clean up, and it was entirely preventable with a one-hour conversation at the start of implementation.

This is the core problem the Bill of Materials (BOM) Management Best Practices article addresses. The Excel habit of embedding revision into the part number or file name is so deeply ingrained in manufacturing organizations that even after teams move to a structured system, they often replicate the same logic in a new form. The solution is straightforward but requires an early, conscious decision: part numbers and revisions are separate concepts and must be managed that way from day one.

There is a deeper reason for this separation that is worth understanding clearly. Revisions are, by definition, interchangeable. If two revisions of the same part are not interchangeable — if a design change broke form, fit, or function in a way that means the old revision cannot substitute for the new one — then you should not be creating a new revision. You should be creating a new part number. Combining non-interchangeable variants under the same part number and distinguishing them only by revision letter is exactly the kind of ambiguity that causes production errors downstream. When interchangeability ends, the part number should change, and the revision history should stay clean.

So the guidance is simple. Define your part number strategy before any significant data import. Keep it simple and stable. Don’t encode revision logic into the number itself. And treat the interchangeability question as a genuine decision, not an afterthought.

Revision Control in OpenBOM: Strategy, ECO Gating, and Interchangeability

Every company says it wants revision control, but not every company has really decided what a revision means in their business. That difference matters much more than it seems.

Most companies address revision strategy reactively. A quality event surfaces, or an audit reveals inconsistencies, and suddenly someone needs to untangle three years of undisciplined change history. What should have been a strategy discussion at the start of implementation becomes an archaeology project. I’ve seen it happen often enough that I now raise the revision question in the first conversation with any new customer.

The Revision Control in Multi-Level Bills of Materials article covers the two primary strategies — top-down and bottom-up mixed — along with the tradeoffs between them. Top-down is consistent but expensive in revision volume. Bottom-up is flexible but requires active management to keep it coherent. Most companies in ongoing production end up with a bottom-up or hybrid approach, but the choice should be made deliberately, not by default.

There are two things the article covers that I think deserve more attention in any implementation conversation.

The first is naming conventions. It sounds like a configuration detail, but it is actually a prerequisite for revision control to work at all. If the assembly level uses alphabetic revisions (Rev A, Rev B) and the component level uses numeric revisions (Rev 1, Rev 2), you have no shared language to confirm whether the component revision procurement ordered last quarter matches the one engineering just released. That inconsistency is invisible until an audit or a field quality event forces the question. Establishing a single, consistent revision scheme across all BOM levels before any revision work begins is not optional. It is the foundation.

The second is the ECO/ECN bridge. Revision control that is not gated by an Engineering Change Order process is just version logging. It tells you what changed, not why, not whether it was authorized, not what the business impact was. Revision numbers accumulate, but the history is meaningless because it lacks context. An ECO defines the scope of the change, identifies all affected BOM levels, documents the rationale, and captures approvals. Only once the ECO is approved should a new revision be created and released. Without that upstream gate, revision history is a log of events, not a record of decisions.

This connects directly to the most common mistake I see: up-revving everything by default. A component changes, so the parent assembly changes. Then the top-level assembly changes. Engineers do this because it feels safer, more complete. But blanket up-revving is not more controlled. It is noisier. It creates revision history that is harder to read, harder to audit, and harder to use for any meaningful impact analysis.

The right discipline is FFF: Form, Fit, and Function. If a change does not affect how a part looks, how it connects, or what it does in a way that breaks interchangeability, an automatic up-rev through the entire structure is probably not necessary. If interchangeability is broken, then a much more deliberate process is required — and as I said in the previous section, at that point you may be looking at a new part number rather than a new revision.

Define your revision philosophy before you start revising. Decide whether your approach is top-down, bottom-up, or hybrid. Establish consistent naming conventions across levels. Make sure an ECO process is gating your revisions. And don’t treat up-revving everything as the cautious choice. It is usually just the noisiest one.

BOM Types in OpenBOM: eBOM, mBOM, Service BOMs, and Maintenance BOMs

This is where many OpenBOM implementations either become significantly more powerful or stay trapped in an engineering-only mindset. One BOM is never enough for a real product lifecycle, and understanding why is one of the more important things a team can do early in implementation.

A lot of teams start with one BOM, usually the engineering BOM. That is natural. The data often comes from CAD, design spreadsheets, or initial product definition. But before going further, I want to clarify a distinction that the Practical Guide to BOM Types article makes clearly and that many customers miss.

Single-level, multi-level, and flattened BOMs are structural representations. They describe how data is organized and displayed. BOM types are something different: they are defined by their role in the product lifecycle. An eBOM and an mBOM can both be multi-level structures, but they serve completely different business functions. Confusing structure with type is one of the most common early mistakes in an implementation, and it leads to a situation where a customer builds a clean multi-level BOM and then wonders why manufacturing, procurement, and service are all still working off side spreadsheets.

The reason is straightforward. Products do not live in a single business context. Engineering needs one view. Manufacturing needs another. Service and support need another. Procurement may need another. Sales and RFQ workflows often need their own structured view too. Each of these represents a different question being asked of the same product data.

• Engineering asks: what did we design?
• Manufacturing asks: how do we build it?
• Service asks: what do we replace, repair, and support?
• Maintenance asks: what do we need to keep the system running over time?
• Procurement asks: what do we source, quote, and order?
• Sales may ask: what is the configuration or offered package?

None of these questions can be answered well by one overloaded structure pretending to be everything at once. That is why eBOM and mBOM are distinct types, and why service BOMs, maintenance BOMs, and procurement views each deserve their own intentional treatment. The BOM types article covers all of these with practical examples, including a service BOM for an industrial pump and a maintenance BOM for a CNC machine, and the differences are not trivial.

One area that comes up quickly once customers understand BOM types is product variants and configurations. If you make forty product configurations, the question of whether to create forty separate BOMs or manage one configurable structure with options and rules is a real architectural decision. The BOM types article introduces configurable BOMs, resolved BOMs, and serialized BOMs as terms customers will encounter. Once you’ve decided on your eBOM and mBOM approach, the variant question is usually the next one to surface.

The practical guidance is this: don’t think of BOM types as complexity. Think of them as the business answering its own questions with clean data rather than offline spreadsheets. For some companies, that means starting with eBOM and mBOM and expanding from there. For others, the service or maintenance context is equally urgent from day one. The point is to decide which BOM types your business actually needs early in the implementation, and to build those structures intentionally rather than discovering the need later when the data is already a mess.

How Part Numbers, Revisions, and BOM Types Form a Product Data Architecture in OpenBOM

What makes these three topics so important is that they are not separate. They form a data architecture for your product.

Part numbers define what something is. Revisions define how it changes over time in a controlled and traceable way. BOM types define how that same product data is used across different lifecycle and operational contexts.

When part numbers are weak, revisions become confusing because there is no stable identity to anchor the change history to. When revision strategy is weak, BOM structures become noisy because every level carries revision history that nobody can interpret. When BOM types are ignored, the team overloads one engineering-centric BOM and then wonders why other functions still rely on side data.

Together, these three OpenBOM articles describe a more intentional approach to product data architecture. The part numbers and revisions article focuses on identity and traceability. The multi-level revision control article focuses on how change propagates through product structure and how to govern it. The BOM types article focuses on product views across the lifecycle. They are worth reading together, not just as setup guides, but as a framework for thinking about product data management as a discipline.

Conclusion: The Foundation of a Scalable OpenBOM Implementation

OpenBOM gives customers a lot of flexibility. That flexibility is a genuine advantage, but it only works well when a few key decisions are made early and made consciously.

Define part numbers before any large data import. Treat part number and revision as separate concepts from the beginning. If two versions of a part are not interchangeable, change the part number rather than overloading the revision scheme.

Decide how you will manage revisions before you start creating them. Establish consistent naming conventions across all BOM levels. Gate revisions with an ECO process. Choose your strategy — top-down, bottom-up, or hybrid — deliberately. And do not treat up-revving everything as the safe default. It is usually just the noisiest one.

Invest in BOM types. Understand the difference between BOM structure and BOM type. Build the lifecycle views your business actually needs — engineering, manufacturing, service, maintenance, procurement — as intentional data models, not afterthoughts.

These are not software settings. They are data architecture decisions. Getting them right early is what separates an OpenBOM implementation that scales from one that creates new problems to replace the old ones.

REGISTER FOR FREE and check how OpenBOM can help. 

Best, Oleg