OpenBOM Implementation Best Practices – Part 1

Oleg Shilovitsky
Oleg Shilovitsky
23 September, 2022 | 4 min for reading
OpenBOM Implementation Best Practices – Part 1

The complexity of product development is skyrocketing these days. Just think about any manufacturing company developing modern products and your head will be spinning from the number of factors and data points that need to be taken into account – requirements, mechanical design, electronics, and software. For connected products, you have cloud software components. 

Modern business models are shifting companies from the development of products to services and companies need to deal with the complexity of maintenance, re-purposing or utilization of existing products, and building new products. When companies are coming to OpenBOM, one of the questions they often ask is “what are the best practices”? Are you providing a set of settings helping to start product implementation? While flexibility is the key and demanded by all customers, when a company is facing implementation questions, the demand and requests for best practices and guidelines are becoming obvious.

In this series of articles about OpenBOM implementation best practices, I will touch on multiple aspects of implementations to help you “wrap your head” around the main concepts of OpenBOM and help you to build an implementation strategy.

Domains, Processes, and Implementation Planning

OpenBOM is capable of managing information and processes for different activities in your company. All of them are connected. Therefore to understand how to plan them properly is important to form the right implementation strategy. Generally, we can divide three domains and activities that can be covered by OpenBOM (as of today).

  1. Design
  2. Engineering
  3. Production

This separation is not clear cut and the processes are intertwined. As such design activities can be connected to engineering and then to production. But from the planning standpoint, it is a good idea to separate them.

Each domain is defining data elements (data objects) and allows you to follow a specific lifecycle and activities.

Design

The design stands at the beginning of every product development process. This is a phase that includes multiple design activities and covers different aspects of the design process – CAD system, design collaboration, and data management for design data.

So, if you’re using multiple CAD systems, you might want to cover topics of how to manage CAD data, how to control versions and how to allow multiple engineers and other people to access this design information. The outcome of this process is well-organized data set with all design data – CAD files, history of versions, and related meta-data.

Engineering

Complex products require sophisticated capabilities to track an entire set of product data as defined by all engineers – product information. At the core of the engineering is engineering BOM (aka EBOM) which includes all information about all items, relationships, revisions, and dependencies. Engineering BOM (sometimes called product structure) collects information created by multiple engineering teams together into a single cohesive data set.

If you’re using multiple CAD systems, all inputs should be coming together to form an Engineering BOM and processes around – revision control and change function. The outcome of this process is a fully qualified set of information about the product before it will be passed to manufacturing. EBOM is also a source of revisions and engineering changes.

Production

In order to sell a product, you need to make it. While this sounds obvious, this stage of the information process is no less complex. Very often, companies are missing the data management between engineering and production and take too many processes simplified to the level of working with EBOM (or even worst, CAD structure) for production planning. Numerous requests to transfer design data directly to ERP are another confirmation.

To build the right process, you need to create a foundation for production data. OpenBOM provides some of them today (eg. planning BOM or Order). This structure allows you to build planning and, later, manufacturing BOM, which will become the outcome of the foundation of the production planning and procurement stage and process.

Conclusion

At the beginning of every OpenBOM implementation, you need to scope the data and processes you need to manage using OpenBOM. It will allow you to plan data objects, lifecycle, and processes needed to implement OpenBOM and set up the environment. Once you identified the scope of data and processes you can build an OpenBOM environment to support it. OpenBOM is a super flexible platform and allows you to build the data model and lifecycle needed to support your specific process.

In the next blog article, I will speak about the environment setup and configurations of the system.

REGISTER FOR FREE to start a 14-day trial and learn how OpenBOM can help you and your team today.

Best, Oleg 

Related Posts

Also on OpenBOM

4 6
10 April, 2026

Every time an engineer opens a product data management system, they face a small but real cognitive task before any...

10 April, 2026

OpenBOM will be presenting at Threaded in Miami, the startup gathering space hosted by Aras ACE 2026 at the Hilton...

9 April, 2026

I’m coming to Share PLM Summit 2026, taking place on May 19–20 in Jerez de la Frontera, Spain. It the...

8 April, 2026

For many SOLIDWORKS teams, the challenge was never the design work itself. It was everything that came after: configuring tools,...

2 April, 2026

A SolidWorks model is essential. A BOM is essential. Drawings, PDFs, STEP files, and DXFs are essential too. Many teams...

2 April, 2026

In the previous article, I wrote that engineering teams usually do not lose control because CAD design is wrong. The...

2 April, 2026

In my experience, manufacturing companies that rush a new product introduction process usually pay for it later. They see production...

1 April, 2026

How file-based workflows, disconnected BOMs, and the limits of PDM combine to create a product data problem most engineering teams...

31 March, 2026

Last week I wrote about where product lifecycle knowledge gets lost, and I also published a longer piece on Beyond...

To the top