A growing manufacturer rarely loses control of product data in one dramatic failure. More often, an engineer updates a spreadsheet, procurement uses a different part number, and manufacturing reads a BOM row without the revision or file context that explains it. The record exists, but the teams no longer share the same product definition.
Item master management is the disciplined way to keep item identity, files, BOM use, supplier information, and system ownership connected without treating them as the same thing. We use that model in OpenBOM by linking items and catalogs with BOMs, revisions, changes, vendors, purchasing, and ERP workflows in a shared product workspace. Our item management capabilities support this product-data layer alongside existing systems.
That distinction matters as a team moves from prototype to production. Before choosing fields or workflows, it helps to establish what an item master must represent, and where its boundaries begin.
What Item Master Management Means for Growing Manufacturers
Item master management is the operating discipline for keeping each product item identifiable, usable, and governed as it moves between engineering, manufacturing, procurement, suppliers, and business systems. It is less about maintaining a long list of part numbers. It is about assigning ownership to the data people use when they make, buy, approve, and change a product.
Separate the item from the file and the BOM row
A CAD file can describe geometry, but it is not the item itself. A BOM row records how an item is used in a particular structure, so its quantity belongs to that BOM use rather than to the item or file as an intrinsic property. Keeping those concepts separate prevents a drawing filename, a duplicated spreadsheet row, or a copied assembly from becoming an accidental source of truth.
That separation also makes identity more precise. An internal item identifier, a manufacturer’s identifier, a supplier’s identifier, and an ERP identifier may all refer to related data, but they are not interchangeable. A growing manufacturer needs fields and relationships that preserve those distinctions instead of forcing every team to interpret one overloaded part-number column.
Give each team a clear data boundary
Item master management becomes operational when teams know which record they maintain and which decisions they can make. Engineering can establish the product item and its applicable revision. Manufacturing can use the released structure for its work. Procurement can associate suppliers, purchasing information, and vendor identifiers without rewriting the engineering identity. An ERP can remain the system responsible for its own transactions and workflows.
Consider this illustrative workflow: Maya in engineering prepares a pump assembly and identifies the items in its released structure. Luis in manufacturing reviews the BOM and its item-specific uses, while Priya in procurement adds supplier information and prepares purchasing records. Each person works from connected product data, but none of them turns a CAD file, supplier number, or ERP record into a substitute for the item master. The result is a handoff that preserves context instead of passing a spreadsheet interpretation from one department to the next.
Scale governance without replacing the ERP
For manufacturers scaling from prototype to production, the practical goal is shared product data that can replace spreadsheet-based BOM tracking while existing ERP systems and workflows remain in place. OpenBOM describes its role as a cloud-native product data platform connecting CAD files, items, BOMs, revisions, changes, vendors, purchasing, and ERP workflows in a collaborative workspace. Its item catalogs, part-number templates, and Where Used capability support this product-data layer; they do not make OpenBOM an ERP, MRP, or production scheduler.
That boundary is central to a durable rollout. Start by agreeing on identity and field ownership, then connect the records needed by manufacturing and procurement. A structured item management capability can support that model while each connected system continues to perform the work it actually owns.
What Should a Governed Item Record Hold?
A governed item record should answer three practical questions: what the Item is, which lifecycle context applies, and who owns each decision. That structure supports consistent item master management without collapsing an Item into a CAD file or a BOM row. In our model, quantity belongs to an Item’s use in a particular BOM, not to the Item record itself or to an attached file.
Identity and identifiers
Start with a stable internal identifier and a description that people can recognize. Then distinguish the identifiers used by different parties. An internal part number, manufacturer part number, supplier identifier, and ERP identifier may all refer to related data, but they are not interchangeable. Labeling them separately prevents a supplier code from being mistaken for the company’s engineering identity or an ERP value from being treated as the universal part number.
A governed record can also include classification, units of measure, approved descriptive properties, and relationships to a catalog. OpenBOM documents item catalogs and part-number templates as capabilities, while properties and templates can be configured for a team’s process. That is different from claiming a dedicated native ERP item-master module. Teams bringing existing records into a controlled structure can also import existing item data after deciding which fields are authoritative.
Lifecycle and revision context
The record should show where the Item stands in its lifecycle and which revision is applicable to a specific product definition or release. Keep version, revision, and approval distinct. A file may have its own version history, while the Item has a revision context and an approval state. A BOM then uses that Item in a particular structure. These relationships let engineering and manufacturing discuss the same product definition without implying that every file change automatically changes every BOM use.
Where Used is useful here because it connects an Item to the structures in which it appears. It does not turn the Item into a BOM row. The relationship remains explicit: the Item is the governed object, and each BOM use supplies its own context, including quantity.
Ownership and stewardship
Finally, assign ownership by field group and decision. Engineering may own the internal identity and revision proposal. Manufacturing may review applicability to a released structure. Procurement may maintain supplier relationships and purchasing context. An ERP may remain authoritative for downstream transaction fields. OpenBOM can connect items and catalogs with BOMs, revisions, suppliers, purchasing, and ERP workflows in a shared product workspace, but it does not replace the ERP.
This division makes governance operational: each team knows what it can change, what requires review, and which system must receive or verify the result.
How Should Files, Quantities, and BOM Views Stay Separate?
They should stay separate because each object answers a different question: what was designed, what is being managed, how much is used, and which information a person needs to see. Keeping those boundaries intact gives Maya in engineering and Luis in manufacturing a shared product record without turning a CAD file, a BOM row, or a filtered screen into the same thing.
A CAD file is evidence of design, not the item itself
Consider an illustrative pump assembly. Maya updates the CAD file for a mounting bracket and associates that file with the corresponding Item in the product data workspace. The Item carries the managed identity and related properties. It can connect to revisions, changes, suppliers, purchasing records, and other BOM contexts. The file remains the design artifact. It is not automatically the complete item record, and changing its filename should not silently create a new part identity.
This distinction also protects identifiers. Maya may use an internal part number, while a manufacturer, supplier, or ERP uses its own identifier. Those values can be related, but they should remain labeled according to their ownership rather than being collapsed into one ambiguous field. OpenBOM connects items and catalogs with BOMs, revisions, suppliers, purchasing, and ERP workflows in a shared workspace, while leaving each system’s responsibility visible. See the user-defined BOM views discussion for how presentation fits into that model.
Quantity belongs to the BOM use
Luis reviews the pump’s manufacturing BOM and sees that the assembly uses four mounting brackets. The quantity belongs to that Item’s use in this particular BOM. It is not an intrinsic property of the CAD file, and it is not a permanent value on the Item that must apply everywhere. A different assembly might use one bracket, six brackets, or none at all. Treating quantity as a property of the file or as a universal Item attribute can corrupt purchasing, manufacturing review, and downstream integration logic.
For a more detailed treatment of this distinction, see BOM instance-level quantities. The practical rule is simple: identify the Item once, then record how that Item is used in each relevant structure.
A view is not automatically an MBOM
After Maya releases the engineering structure, Luis creates a filtered view showing the properties needed for his manufacturing review. That view may hide design-only fields and display manufacturing-relevant information, but filtering or selecting columns does not by itself create a manufacturing BOM. An MBOM requires an intentional structure and defined manufacturing meaning, not merely a different presentation of the same records.
The same caution applies to exports. An export is a snapshot of the information selected at that point in time. If Luis sends it to another system or team, the receiving result must be checked rather than assumed. Verify the mapped fields, identifiers, revisions, quantities, and resulting structure in the receiving system. This separation lets a product data platform support collaboration without claiming that a view replaces a manufacturing structure or that an export proves a downstream system accepted the intended data.
How Do Vendors and ERP Systems Fit Around the Item Master?
They fit around different ownership questions: the item master identifies what a product record is, while vendors, BOM uses, and ERP records describe how that item is sourced, used, and transacted. Keeping those responsibilities separate makes item master management more reliable as a manufacturer moves from prototype work toward repeatable purchasing and production.
Separate identity from use and supply
Consider an illustrative example. Maya, an engineer, creates a pump impeller as an item and links the applicable CAD file and revision. Luis uses that item in a released pump assembly. The assembly’s quantity belongs to that specific BOM use, not to the item as an intrinsic property. Priya then adds the approved supplier’s identifier and purchasing details. Those records are related, but they are not interchangeable.
| Record | Primary responsibility | Example | What it does not own |
|---|---|---|---|
| Item master | Stable identity and controlled attributes. | Internal number, description, revision context. | Every supplier or ERP transaction. |
| Vendor record | Source-specific commercial and identification data. | Supplier part number, vendor, unit of purchase. | The item’s engineering identity. |
| BOM use | Relationship and instance context. | Impeller quantity in a pump assembly. | A global quantity for the item. |
| ERP record | Downstream enterprise transactions and controls. | ERP identifier, purchasing or planning transaction. | Replacing product-definition governance. |
These distinctions also explain why identifiers need labels. An internal identifier, manufacturer part number, supplier identifier, and ERP identifier can all refer to related data without being the same value. Purchasing attributes belong to a defined operational context, not automatically to the engineering item. Keep those fields clearly labeled so a buyer can distinguish a supplier or ERP value from the item identity used by engineering.
Connect OpenBOM to ERP without collapsing the boundary
In OpenBOM, item catalogs, BOMs, revisions, suppliers, purchasing data, and ERP workflows can share a connected product workspace. ERP integration is an integrated, connected capability, not an ERP replacement. Our documented integrations should therefore be evaluated by the fields and workflow exchanged, followed by verification in the receiving system. OpenBOM can support simple inventory and quantity-on-hand fields, but that does not make it an inventory-allocation engine, MRP system, or production scheduler.
This boundary gives Priya a practical handoff: engineering controls the released product definition, procurement maintains supplier context, and the ERP remains responsible for its enterprise transactions. Teams can then extend the same discipline to supplier collaboration without asking one record to answer every downstream question.
A Practical Item Master Rollout Beyond Spreadsheets
A controlled rollout works best when engineering, manufacturing, and procurement adopt one product-data workflow in stages. Existing spreadsheets, suppliers, PLM, and ERP systems can continue to operate where they are still needed.
Start with identity and engineering context
Illustrative workflow: Maya in engineering, Luis in manufacturing, and Priya in procurement are preparing a pump assembly. Their goal is not to copy every spreadsheet cell into a new system. It is to establish which record owns each piece of information, then verify that the released product definition reaches the next team.
- Define the item identity. Maya identifies the pump housing, fasteners, and purchased motor as Items, with clear internal identifiers. Manufacturer, supplier, and ERP identifiers remain separate fields or relationships. A CAD file is evidence and design context, not the Item itself. This distinction prevents filenames and spreadsheet row numbers from becoming accidental master data.
- Import and normalize the starting data. Priya and Maya review the existing rows, remove duplicate records, and agree on descriptions, units, ownership, and identifier rules before adding more data. OpenBOM supports item catalogs and configurable properties and templates, but the team still owns the decisions about which fields are required. For the mechanics of this stage, see how to migrate spreadsheet item data.
- Connect CAD and BOM context. Maya connects the relevant design information to the item and builds the pump BOM. If the team uses OpenBOM SmartSync, it can connect local and cloud CAD project state with synchronization, locking, versions, and revision context. Luis checks the structure and confirms that each quantity belongs to the Item’s use in this BOM, rather than treating quantity as a permanent property of the file.
Release the definition, then verify the handoff
- Review and release the approved structure. Luis reviews manufacturing context while Maya resolves design questions. They use the team’s change and revision workflow for proposed changes, sign-off, release, and history. Version, revision, and approval are related but not interchangeable. The change and revision workflow should record what changed and which revision is applicable to the build.
- Map and verify the receiving record. Priya maps the released data for the ERP or supplier handoff. OpenBOM can integrate alongside an ERP, but it does not replace the ERP or decide every downstream process. The team verifies the receiving result, including identifiers, quantities, and revision context, instead of assuming that a successful export or integration call proves the handoff is correct. This staged approach lets the item master mature without requiring a disruptive replacement project or claiming a customer result that has not been measured.
Where OpenBOM Fits in Item Master Management
OpenBOM fits between engineering product definition and the downstream systems that execute purchasing, inventory, and financial processes. It provides a shared product-data workspace for items, catalogs, BOMs, revisions, suppliers, purchasing, and ERP workflows while leaving each system responsible for the records and transactions it is designed to own.
Native controls for item identity and reuse
At the product-data layer, OpenBOM natively supports item catalogs, part-number templates, and Where Used. These controls help a team establish a governed identity for an item and see where that item is used across product structures. That identity is not the same as a CAD file, a BOM row, or a supplier’s identifier. Internal, manufacturer, supplier, and ERP identifiers should remain distinct and be modeled or labeled accordingly.
This distinction matters when an engineer replaces a component or procurement evaluates an alternate. The item record can remain the stable reference point, while the file, supplier relationship, revision, and BOM use provide the context for a particular decision. Quantity belongs to the item’s use in a specific BOM, not to the item as an intrinsic property.
Configurable governance around the record
Our item master approach is not a claim that every governance policy is a dedicated native module. Teams can configure the data model, properties, views, and workflows to reflect their own naming rules, review responsibilities, and release practices. Those are configurable capabilities, not a packaged ERP item-master implementation. The boundary should stay visible so a team knows which control is enforced by the platform and which depends on its chosen model and process.
For example, in an illustrative workflow, Maya in engineering creates an item and links the relevant design file. Luis reviews the released BOM use, while Priya maintains supplier and purchasing context. They work from connected records rather than copying an item description into separate spreadsheets. The result is a traceable product definition, not a claim that OpenBOM has replaced each person’s downstream system.
Integrated with ERP, not a replacement for it
OpenBOM can connect product data to ERP workflows through integrations. That is an integrated boundary: the receiving ERP remains alongside the product-data platform, and the team must verify how mapped records arrive and are used there. OpenBOM is not an ERP, MRP, production scheduler, or inventory-allocation engine.
See the product data workflow for how these connected records fit together, and review the item management capability for the broader operating boundary. The practical goal is disciplined ownership across systems, not forcing every item-master question into one application.
Review item management capabilities and map the boundary between your item data and connected systems.
Frequently Asked Questions
What is an item master, and what information does it contain?
An item master is a governed collection of records for the items a company designs, buys, makes, or uses. A record can identify the item, describe its properties, connect relevant files, track lifecycle status and revisions, and distinguish internal, manufacturer, supplier, and ERP identifiers. The exact fields depend on the workflow and may include part-number rules, units of measure, vendor references, and approved relationships. The key is assigning ownership and keeping the record separate from any single CAD file or spreadsheet row.
How is an item master different from a BOM?
The item master describes an item as a reusable product record. A BOM describes how items are assembled for a particular product, configuration, or revision. Quantity belongs to an item’s use in that BOM, not to the item universally. One item can therefore appear in multiple BOMs with different quantities, positions, or revision contexts. Keeping these concepts separate makes reuse, Where Used analysis, and change review more reliable.
Is an item master the same as an ERP item record?
Not necessarily. An ERP may own downstream operational fields and transactions, while engineering and manufacturing teams manage product definition, revisions, BOMs, and changes in a product data workspace. OpenBOM can integrate with an ERP and publish mapped data, but it does not replace the ERP or claim ownership of every ERP function. Define the boundary for each field, then verify the receiving result after an integration publishes data.
How should a growing manufacturer start item master management?
Start with a small, representative product family and agree on ownership for identity, descriptions, identifiers, files, revisions, and approval. Import or clean the existing item data, establish part-number and catalog rules, and connect items to BOMs without treating quantities as item attributes. Then introduce review, release, and change controls with engineering, manufacturing, and procurement together. Expand gradually alongside existing spreadsheets and ERP workflows, measuring consistency through real records rather than starting with an abstract enterprise-wide redesign.
Ready to Bring Item Data Into One Workflow?
We can help your engineering, manufacturing, and procurement teams examine how item records, BOM use, revisions, and connected ERP workflows fit together. OpenBOM gives you a practical place to review those relationships while keeping system boundaries clear. If you want to explore the workflow with your own product data, get started here.
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
