Engineering change and EBOM to MBOM synchronization complexity

Engineering change and EBOM to MBOM synchronization complexity

eco-mco-ebom-mbom

MBOM (Manufacturing BOM) is a tough problem. Initially, you might think about it as an easy problem. Especially, since companies are managing MBOMs in MRP/ERP systems for a while. However, I think, the time when MBOM was simply originated in MRP system to fulfill demand planning and production orders are gone. And it brings lot of questions and, raise attention from software vendors and implementers. PLM vendors are in the first line of companies demanding the change in the way MBOM is handled.

MBOM is really hard if you want to keep it in sync with rest of product data in engineering and manufacturing. It starts from the moment of time, you understand that your engineering BOM and manufacturing BOM are not the same thing. I touched it earlier in my post – 4 reasons why is hard to deliver MBOM in PLM. The initial creation of MBOM can be technically straightforward. It mostly end up by adding date effectivity element into BOM structure. Within time it gets complicated. And one of the main reasons is synchronization of data. It goes mostly around management of engineering change.

MBOM is a central place to capture the impact of engineering changes and to insure changes are managed correctly and reflected into manufacturing process with relevant dates and references to engineering data (EBOM). The priority of changes are not equal. Organization must handle these priorities and it can result in significant cost differences. Fundamentally you can think about mandatory changes and optional changes. The first one is the change organization will be implementing at any cost. It usually result of failures and regulatory changes. The second one is more interesting. This is where all new development, innovation, design improvements, cost reduction and other things are coming. This is a place where play with effectivity date can be tricky and complex. The sequence of steps are as following:

1- Engineering release or ECO transmit the data about changes in EBOM, which serve as a source of change and provides all required engineering information

2- Manufacturing should introduce these changes into planning process. Timing is important and this process is formal. Some of companies connect it to so called MCO process.

3- All dependencies must be discovered and reflected in changes of MBOM and manufacturing planning.

The last step brings a significant complexity. Engineering information (as it comes from EBOM) often comes incomplete and doesn’t contain all data that must be reflected in a change. There are multiple reasons to that, but in general, engineering view of a product is different from manufacturing one. One of the most typical examples is related to part interchangeability. But, I can see many others too. To synchronize changes between EBOM and MBOM is very complex. However, this complexity and challenges can turn MBOM into next cool thing in PLM.

What is my conclusion? EBOM to MBOM synchronization is a complex process that requires significant data manipulation, data discovery and careful operation. It cannot be automated and it requires a lot of consideration from engineering and manufacturing people. The complexity of modern product and manufacturing processes are introducing the new level of challenges in the way to manage EBOM and MBOM. This sync is critical and companies are demanding tools that can help them to handle it in the right way. Just my thoughts…

Best, Oleg

Share

Share This Post

  • Pingback: Integration is still the major challenge in PLM adoption()

  • Pingback: Integration is still the major challenge in PLM adoption | Daily PLM Think Tank Blog()

  • Pingback: SAP has a magic technology to improve enterprise integration()

  • Johan E

    You mention that “EBOM to MBOM synchronization cannot be automated” but what is your opinion about the quickly maturing CPQ and Design Automation solutions that typically automates the generation of the SBOM (for sales/CRM), MBOM (for manufacturing/ERP) and EBOM (for engineering/CAD)?

  • beyondplm

    Hi Johan, thank you for the question! Can you please give me few examples of “quickly maturing CPQ and Design Automation solutions”. Thank you, Oleg

  • Johan E

    Sure thing! Here are a couple of companies that provide integrated CPQ and DA solutions: Configure One, Tacton Systems, Infor and DriveWorks.

  • beyondplm

    Johan, thanks for these examples. AFAIK these products are focusing on generation of sales BOM (SBOM) and then integrating with other products PLM, ERP that actually managing engineering and manufacturing. The underlining complexity I mentioned in my article is belonging to the lifecycle and changes between EBOM and MBOM, which in most of the cases shouldn’t even covered by SBOM to PLM/ERP integration. But let me know if you think I’m missing something in your comment. Best, oleg