The death of EBOM vs. MBOM divide?

The death of EBOM vs. MBOM divide?


In a traditional engineering, “over the wall” approach is a reflection of sequential operations – marketing, design, manufacturing, testing and production. Each stage of development process is carried out separately. As you done with one stage, you can move the the next one.

Pieter Hamans‘s article Creating a Manufacturing Bill of Materials made me think about sequential bill of material management process again. Although Peter mentioned that ideal BOM management system can support all objectives simultaneously, the following passage explains the reality EBOM vs MBOM separation:

A frequently made distinction is that between Engineering BOMs and Manufacturing BOMs. An EBOM is typically created in the engineering department and may originate from a Computer Aided Design or CAD software. It reflects the component structure from a functional perspective, and often also per technical discipline: there may be a mechanical design and an electrical design for example. To support collaborative engineering Product Life Cycle management (PLM) of Product Data Management (PDM) systems have been introduced. On the other hand we have the MBOM to support the manufacture of the product. The MBOM is typically maintained by logistics professionals and is used in an Enterprise Resource Planning (ERP) system. The MBOM drives material planning and product costing. Often there is some work to be done to convert an EBOM into an MBOM.

The article provides a good summary of situations you typically can find in discreet manufacturing when managing part ordering, production and manufacturing logistic. Flattening of BOM, consumable and by-product items are good examples of things that usually not coming into EBOM.

At the same time, EBOM vs MBOM divide introduces one of the highest level of complexity in engineering and manufacturing systems. I captured below the picture from the article.


I think, the appearance of two clouds can highlight the problem even more. The data is flowing between two systems and creating inefficiency in change management. Two data structures EBOM and MBOM are managed by two separate systems. Things can fall between the cracks. To bring design or engineering change to manufacturing takes time and can introduce potential mistakes. Low visibility on manufacturing plan and components availability and cost leads to sub-optimal design and engineering decision.

EBOM vs MBOM divide was introduced by historical sequential engineering. It was good back 20 years ago, but it is completely inefficient in the new era of connected engineering and manufacturing processes. New business processes are demanding higher visibility in engineering, manufacturing and supply chain. The split between EBOM and BOM cannot stand against the demand to optimize engineering and manufacturing.

The connection between EBOM and MBOM is highly demanded. It will come in many ways. One of them is better integration between existing systems. Integrated change management system with search capabilities can be a solution deployed on top of existing PDM/PLM and ERP repositories to manage all transactions and changes.

Cloud technologies has a potential to connect information. Instead of replication of existing PDM/PLM and ERP repositories to the cloud, the new system organization can come into place. Cloud services is one of the key technologies that can stop the divide between EBOM and MBOM.

What is my conclusion? Historical divide between EBOM and MBOM leads to inefficiency in engineering and manufacturing. Future development of PLM and ERP systems will eliminate the divide by introducing new integration technologies and unbundling services helping to manage information in a more efficient and connected ways. Just my thoughts…

Best, Oleg


Share This Post

  • Dhirendra Kulkarni

    Your concluding remarks are correct, so instead of building integrations why not ocnsidering doing MBOM in PLM itself? this eliminates need for synchronization. This is th every reasons why PLMs have started managing MBOM….

  • beyondplm

    Dhirendra, thanks for this comment! Yes, one of the options is to manage MBOM in PLM system.

  • Loic Mouchard

    Hi Oleg,
    Are you supposing that there is 1 EBOM matching 1 MBOM? Let’s suppose you sell a product that is manufactured in different factories, or by different suppliers. From an EBOM, you then certainly define more than one MBOMs (one per factory for example). Continuing with the same idea, imagine the the design (EBOM) is Freezed, there is still multiple reason to change the MBOM (new means of production, price on the material, bankrupt supplyer, change in the legal rules).

    You are right,Integration of PDM and ERP systems is challenging. Would a bigger system managing both be more efficient or just more complex?

  • beyondplm

    Loic, you’re right. MBOM and EBOM are not identical and I’m pretending to say it is the same. My point is that a “disconnect” between EBOM and MBOM leads to inefficiency and problems. A better integration or a system to manage both – these are options to improve the situation. Thanks for your comment and sharing your insight. Best, Oleg

  • Gurney

    Funny thing is, I don’t know a single PLM vendor (I mean, serious ones) who hasn’t been offering that for, like, a decade or 2.

    MBOM are the result of engineering decisions. They naturally belong to PLM.

  • beyondplm

    Gurney, Thanks for your comment! I think some ERP vendors might disagree in the part of management of procurement and orders. You comment is valid if applies to manufacturing planning solutions like Tecnomatix and Delmia.

  • Francois

    We have been working on a solution called xBOM (Developed for SOLIDWORKS PDM) so that you can merge the EBOM with the MBOM. The main idea behind xBOM is to merge non engineering data into your engineering BOM. If you are interested you can check our webinar

  • beyondplm

    Francois, thanks for sharing the video. I’ve seen xBOM before. It is an interesting solution to work around EBOM/MBOM problem

  • Pingback: Work Smarter, not Harder with SAP PLM! – SAP® PLM()