Most discrete manufacturers would probably agree that the engineering BOM or EBOM is created and managed in PLM. And it makes sense. CAD data is typically stored and managed in PLM, and the product structure, the origin of the EBOM, is typically defined in CAD and through a CAD integration automatically transferred to PLM, where it is used as the foundation to create the EBOM.

But what about the manufacturing BOM or MBOM? In my previous article “What is the difference between an EBOM and an MBOM? Do we need both?” I discussed the need to have both an EBOM and an MBOM or multiple MBOMs. Which system should own the MBOM(s) though, i.e. where should it be created and managed? In ERP? In PLM? Or maybe even in both?

Traditionally the MBOM was created in and owned by the manufacturing resource planning (MRP) or enterprise resource planning (ERP) system, primarily because that’s where companies defined and managed all the materials, production resources and manufacturing processes. With the MBOM basically being a result of defining the manufacturing process it made sense to create the MBOM in the ERP system.

This approach, i.e. creating and managing the EBOM in PLM and creating and managing the MBOM in ERP has several challenges though, specifically how and when does the data get from PLM to ERP?

Without an integration between the two systems someone will have to manually re-enter everything in ERP that has previously been created in PLM. And in case of changes in the PLM system someone has to manually update the ERP system accordingly. And indeed, that’s exactly what many companies still do today. In case of large BOMs with hundreds or thousands of parts this approach is typically quite labor and time intensive and error prone.

Then of course there is the possibility to create an integration between PLM and ERP that allows the automated transfer of data between the two systems. But what data should be transferred in that case?

If the EBOM is transferred from PLM to ERP someone will have to restructure it in ERP into the proper format of the MBOM. The challenge then often is to make sure that all parts that have been transferred will also be used in the MBOM.

If only the parts are being transferred from PLM to ERP, i.e. without the EBOM structure, someone will still have to create the structure in ERP and make sure all transferred parts are being added to the MBOM.

Both approaches usually require that the manufacturing engineers have access to PLM to see what the EBOM looks like and what it includes so that they can make sure they put everything that is on the EBOM also on the MBOM.

Then there is also the question when to transfer the information to ERP. When the EBOM is released? That means manufacturing engineering has to wait with creating the MBOM until the design (i.e. the EBOM) is complete, which can cause undue delays and really goes completely against concurrent engineering.

So maybe the data is transferred to ERP when individual parts are released? But what if the EBOM is modified afterwards and something that has already been transferred is removed from the EBOM again? Then we may already have put something on the MBOM and ordered it that is no longer needed. How would we know that it needs to be removed from the EBOM again? (The EBOM hasn’t been released yet, hence there won’t be a formal change order, hence there is no formal signal to ERP that the part needs to be removed).

With the expansion of PLM into the manufacturing realm in the last about 10 years, specifically the area of manufacturing process planning, there also came the option of creating and managing the MBOM in PLM, since the MBOM, as I mentioned earlier, is basically the result of defining the manufacturing process.

And there are several benefits of doing that, i.e. creating the MBOM also in PLM: First it allows true concurrent engineering. Since no release or other transfer process is needed for manufacturing engineering to see and access the engineering items and EBOM – everything is in the same system – they can start working on the manufacturing items and the MBOM, including designing and adding tools and fixtures required for the manufacturing process, at the same time product engineering is working on the design of the engineering items and the EBOM.

Secondly, it allows better design for manufacturing, since the product engineers can easily see what the manufacturing engineers are doing, and vice verse, and the two groups can easier collaborate.

Further, many PLM systems that have the functionality to create and manage MBOMs also include functionality that shows if all parts that are included on the EBOM have been used or consumed on the MBOM, hence making it easier to know if the MBOM is complete, or if there are still components on the MBOM that are no longer on the EBOM (for example if they were removed as part of the design process). This helps to reduce errors, delays and excess costs as a result of not ordering required parts or ordering them late, or ordering parts that have been removed from the BOM and hence are no longer needed.

Lastly, having both the EBOM and MBOM in PLM allows a much better impact analysis in case of an engineering change as the PLM system will make it easy to see what is affected by a planned change.

Of course the ERP system is still needed to execute and support the procurement of materials and the actual manufacturing of the product. So eventually all the manufacturing items and the MBOM(s) have to be transferred from PLM to ERP, either manually or via an automated integration of the two systems. But if the manufacturing items and the MBOM are done in PLM the data can be transferred to ERP gradually whenever manufacturing engineering is ready to do so and we do not have to wait until product engineering releases the entire EBOM.

So what system should own the MBOM? There are clear benefits to creating and managing the MBOM in PLM and then transferring it as needed and at the right time to ERP to support and execute the procurement and manufacturing activities.