September 23, 2022
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).
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.
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.
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.
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.
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.