Until about the early 1990s everything was pretty easy. The engineering BOM or EBOM existed in one place, in a pre-defined field on the face of every engineering drawing that was filled out by hand or maybe typed with the help of a 2D CAD system. From there someone took the information and manually typed it into an MRP system to create a manufacturing BOM (MBOM) for manufacturing and to purchase the required raw materials and parts.
Unfortunately from there it only seemed to become more complicated. With the ascent of 3D CAD the models all of a sudden included part attributes and assembly structures. That gave rise to the CAD BOM, which could be leveraged to more or less automatically create the EBOM on the face of the drawing, but of course only if the CAD assembly was correctly structured with all the parts and all attributes were provided.
The CAD vendors and users quickly realized that managing the assembly and file relationships of all the different parts and drawings and their revisions was challenging. This led to the introduction of the first CAD data and product data management (PDM) systems. Many of these systems were integrated with the CAD system of the same vendor, and even though this integration allowed an often fairly seamless transfer of the CAD BOM into the PDM system, there were now two engineering centric BOMs: One in the CAD system (the CAD BOM), and one in the PDM system (the EBOM). And the MRP or ERP system still managed the MBOM.
Soon companies realized that it would be more efficient to transfer the BOM from the PDM system to the MRP or ERP system. But which BOM? The PDM system only had the EBOM, but the ERP system needed an MBOM.
That when the battle for the BOM started, which is still being fought to this day. Both the CAD/PDM vendors and the ERP vendors of course made the case that it was better to manage the BOMs in their system. Their case was that whoever owns the BOM owns the enterprise. And they weren’t wrong.
The question became where should the EBOM and MBOM be created and managed? In the early 2000s the CAD/PDM vendors expanded the functionality of their systems downstream and started to call them product lifecycle management (PLM) systems to indicate that they could do more than just manage engineering data. And the ERP vendors expanded their systems upstream and included product data management capabilities so that they could do more than just manage manufacturing data.
Today the PLM vendors argue that it is better to create the MBOM in their system because they already manage the EBOM, and then transfer the MBOM to the ERP system for manufacturing and procurement use. The ERP vendors argue it is better to create the EBOM in their system because they already manage the MBOM.
So who is right? Who wins the battle for the BOM? The answer is, it depends largely on the complexity of the products a company designs and manufactures.
In companies with less complex products that have a fairly simple EBOM with little variation, which often can be found in make-to-stock (MTS) environments, it may be easier to enter the few lines an EBOM consist of directly and manually into the ERP system. In this instance it is often sufficient to only create and manage an MBOM in the ERP system. Even if the company uses a PDM or PLM system to manage CAD models, drawings and other engineering documents, there is little value of having an integration between the PLM and ERP systems to automatically transfer either an EBOM or an MBOM.
In companies with more complex products that have large EBOMs with hundreds or even thousands of parts and components and a high variation, as it can usually be found in configure-to-order (CTO) and engineer-to-order (ETO) environments, there is a huge benefit of using the PLM system to manage all the different BOMs in an integrated environment.
Even very complex order or customer specific EBOMs can often be created in minutes using preconfigured platforms, modules, variants, options and configuration rules. The CAD assembly and drawings can largely automatically be created based on the configured EBOM, and the MBOM can also quickly be created from the EBOM and then transferred to the ERP system for manufacturing and procurement. Any changes can be propagated quickly through all BOMs, which ensures fewer manufacturing and quality problems on the shop floor.
Even without using the product configuration management capabilities of today’s PLM systems and starting from the bottom up, the CAD BOM can seamlessly be propagated to the PLM system through an available CAD-PLM integration and in many PLM systems be used to nearly automatically create an EBOM that remains synchronized with the CAD BOM. This means if changes are made on either the CAD BOM or the EBOM, they are automatically reflected on the other BOM. The EBOM can then be used in the PLM system to relatively easily create an MBOM. Many PLM systems have functionality to ensure that all components on the EBOM are used on the MBOM.
In the latter two scenarios it has huge benefits to create and manage the EBOM and MBOM in PLM, and transfer the finished MBOM to the ERP system for use in manufacturing and procurement.
So who wins the battle for the BOM? In most companies both PLM and ERP have an important role to play (see also PLM Insight “Do We Need Both ERP and PLM? Why?”). And thanks to the competition between PLM and ERP vendors to create the better solution to create and manage BOMs, ultimately you, the customer wins. The key is to carefully determine what the best solution is for your company.
Andreas Lindenthal, the author, is the founder and managing partner of PLMadvisors. He is a passionate thought leader and recognized industry expert with over 25 years international, hands-on experience in innovation, new product development (NPD), and product lifecycle management (PLM). He has served a large number of leading global companies across various industries to sustainably improve their business results by helping them to drive innovation, increase productivity, shorten time-to-market, reduce costs, ensure compliance and improve product quality through the definition, evaluation, implementation and operation of best-in-class innovation, NPD and PLM strategies, practices, processes and technologies.
