One of the most frequent debates in the BOM management discipline is around the so-called single-BOM vs multi-BOM approach. My recent article about Single BOM? brought many questions, comments, and discussions around the single vs multi BOM approach, which led me to think about the next article where I want to talk about the difference and commonality of both approaches as well as the decision process related to the selection of tools and technologies.
What is the root cause of the conflict between multiple approaches? The reality of product development including engineering, production, maintenance, and support is to have multiple representations of the data. Design is different from manufacturing planning. A specific production BOM can be different between customers and changes can be introduced in the middle of production that will change some of the models. The level of conflicts is different and depends on the industry, level of complexity, and product development organization. Company organization including contractors and suppliers is another dimension of differences.
Organizations want to have control of the data. Having multiple BOMs (eg. Design, Engineering, Manufacturing) can be a solution to solve this problem, but at the same time the complexity of the process and potential mistakes on data synchronization forces companies to rethink the approach that is used for each specific organization.
The approach with multiple BOM is the simplest option that exists, which basically means that every organization of the product development stage creates its own BOM. The names can be different, but essentially means the segmentation of phases (As-Design, As-Planned, As-Built, etc.) or organizational ownership (Engineering, Manufacturing, etc.). In some situations, the segments are caused by the companies, contractors, and suppliers’ boundaries.
Each BOM (product structure) is managed as a separate entity. The coordination and change process includes many synchronization and updates to keep consistency between multiple BOMs. It completely solves the problem of ownership and introduces huge complexity of reconciliation, traceability, and validations.
This is an opposite approach to Multiple BOMs. In this approach, there is a single BOM that is used by all organizations. The roots of this approach are coming from the time when MRP was the only system that managed the BOM in the company. This means (mostly for the engineering phase) reconciling the information from design (drawings) to the single BOM. Most of the conflict in this approach is coming from the needs of engineering to maintain a different structure for a variety of reasons and processes – engineering change, planning, cost, etc.
There is a single BOM managed in a system that provides the best tool for the job. All changes and data are reconciled in this structure and the BOM is considered as a single version of the truth. The reconciliation processes can be complex and depend on the tool’s ability to bring data from multiple transactional and design systems. The best system to manage the BOM is usually declared as a single source of truth.
Single BOM, Multi-Views
A modified version of a single BOM approach, which mainly focuses on how to segment a specific organizational or process representation from a single BOM. This option is considered a viable alternative to the first option (Multi- BOM) that creates too many difficulties for reconciliation, changes, and synchronizations.
Conceptually, this model is the best because it can reduce the data redundancy and eliminate the data synchronization points. However, this option put a heavy load on the need for the organizations to agree about single data representation and the ways to extract a segmented data representation (View).
BOM Management Technologies
The fundamental technology to manage all options of BOMs is technically the same and includes data management technology to manage relationships between objects. While core principles are the same the technology implementation can be significantly different and dependent on many technical aspects – data management systems, database types, access control, and user experience.
The logical aspects of the BOM management model include item/instance data and structure management. The latest is one of the key elements to support a variety of options to organize data segments. Effectivity is a term that is used to describe segment conditions. While it might sound complex, the effectivity is a complex name for a filter that is used to describe these conditions. The filter system can be pretty complex.
Most mainstream legacy PLM and ERP solutions are using SQL-based Relational Databases Systems to store and manage data. These systems are stable and provide reliable and robust ways to manage data, but when it comes to the management of product structures with multiple requirements of data filtering and segmentation, these systems are the weakest element of the technological stack to scale the system to the level of complexity needed.
The last decades of database development introduced new technologies to manage data more efficiently. A big group of NoSQL databases combines different types (document, key-value, graph, search, etc.) to improve the way data can be managed. Legacy PLMs are traditionally focused on the single database that will be approved by the IT department and installed on-premise. SaaS and Cloud solutions unlock the option to adopt polyglot persistence and multi-database solutions to provide a better way to manage data and to scale BOM management systems vertically and horizontally.
Single Tenant vs Multi-Tenant
Organizational structure is another aspect that impacts the BOM management solution architecture. When BOM needs to be managed by multiple organizations, the ability of the system When it comes to BOM management, the tenancy is the technology that can manage the way multiple organizations can have access to the data. Single-tenant solutions (the majority of PLM systems belong here) require a single system database per organization. This architecture although it is the most mature one, is very limited in the modern manufacturing landscape involving multiple organizations to work together. Multi-tenant technology is the future of BOM management allowing seamless data access and collaboration between multiple organizations.
BOM management is a complex discipline that requires sophisticated data management technologies combined with the process organization to help manufacturing companies manage data and processes, perform design, production, support, coordinate changes, and support the decision process. Modern manufacturing is demanding scalable robust data management systems capable of supporting multiple organizations working together in a connected way. Eliminating data redundancy, streamlining the process, and improving user experience – are the top 3 requirements that are demanded by all manufacturing organizations these days. The future is a BOM management solution capable of supporting multiple organizations and bringing the right data to the right people at the right time. Sounds simple, but it is very hard to do. Old legacy systems were developed in the days when the focus was on a single company. As we are moving to the era of networks, the new technologies will eventually outperform old legacy systems. While technology will be the key to achieve robustness, it can also be a foundation to bring an agreement between multiple groups of people fighting for control over single BOM management by the old systems. Just my thoughts…
Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital network-based platform that manages product data and connects manufacturers and their supply chain networks. My opinion can be unintentionally biased.