I promised to write some more down-to-earth post this year related to current PLM practices. If you are eager for my ideas for the PLM future, come to PI PLMx in London on Feb 4th and 5th. Or later when reading the upcoming summary: The Weekend after PI PLMx London 2019.
ECO/ECR for Dummies was the most active post over the past five years. BOM-related posts, mainly related to the MBOM are second: Where is the MBOM? (2007) or The Importance of a PLM data model: EBOM – MBOM (2015) are the most popular posts.
In this post, an update related to current BOM practices. For most companies, their current focus while moving from CAD-centric to Item-centric.
Definitions
The EBOM (Engineering BOM) is a structure that reflects the engineering definition of a product, constructed using assemblies (functional groups of information) and parts (mechanical/electrical or software builds – specified by various specifications: 3D CAD, 2D CAD / Schematics or specifications). The EBOM reflects the full definition from a product how it should appear in the real-world and is used inside an organization to align information coming from different disciplines.
Note: This differs from the past, where initially the EBOM often was considered as a structure derived from the Mechanical Part definition.
The MBOM (Manufacturing BOM) is a structure that reflects the way the product is manufactured. The levels in the MBOM reflect the processing steps needed to build the product. Here based on the same EBOM different MBOMs can exist, as a company might decide that in one of their manufacturing plants they only assemble the product, wherein another plant they have tools to manufacture some of the parts themselves, therefore the MBOM will be different. See the example below:
In case your company delivers products to their customers, either in a B2B or B2C model, the communication towards the customer is based on a product ID, which could be the customer part number (in case of B2B) or a catalog part number. The EBOM/MBOM for this product might evolve over time as long as the product specifications remain the same and are met.
Does every company need an EBOM and MBOM?
Historically most companies have worked with a single BOM definition, due to the following reasons:
- In an Engineering-To-Order process or Build-to-Print process the company the target is to manufacture a product at a single site – Most of the time one product for ETO or one definition to many products in BTP. This means the BOM definition is already done with manufacturing resources and suppliers in mind.
- The PLM (or PDM) system only contained the engineering definition. Manufacturing engineers build the manufacturing definition manually in the local ERP-system by typing part numbers again and structuring the BOM according to the manufacturing process for that plant.
Where the first point makes sense, there might be still situations where a separate EBOM and MBOM is beneficial. Most of the time when the Build To Print activity is long-lasting and allows the company to optimize the manufacturing process without affecting the engineering definition.
The second point is describing a situation you will find at many companies as historically the ERP-system was the only enterprise IT-systems and here part numbers were registered.
Creating a PLM-ERP connection is usually the last activity a company does. First, optimize the silos and then think about how to connect them (unfortunate). The different structures on the left and right lead to a lot of complex programming by services-eager PLM implementers.
Meanwhile, PLM-systems have evolved in the past 15 years, and a full BOM-centric approach from EBOM to MBOM is supported although every PLM vendor will have its own way of solving digital connectivity between BOM-items.
You should consider an EBOM / MBOM approach in the following situations:
- In case you have a modular product the definition of the EBOM and MBOM can be managed at the module As modules might be manufactured at different locations, only the MBOM of the module may vary per plant. Therefore, fewer dependencies on the EBOM or the total EBOM of a product.
- In case a company has multiple manufacturing plants or is aiming to outsource manufacturing, the PLM-system is the only central place where all product knowledge can reside and pushed to the local ERPs when needed for potential localization. Localization means for me, using parts that are sourced in the region, still based on the part specification coming from the EBOM.
Are EBOM and MBOM parts different?
There is no real academic answer to this question. Let’s see some of the options, and you can decide yourself.
An EBOM part is specified by documents – this can be a document, a 3D model combined with 2D drawings or a 3D annotated model. In case this EBOM part is a standard part, the specification may come from a part manufacturer through their catalog.
As this part manufacturer will not be the only one manufacturing the standard part, you will see that this EBOM-part has potentially several MBOM-parts to be resolved when manufacturing is planned. The terms Approved Manufacturing List (AML) – defined by Engineering and Approved Vendor List (AVL) – based on the AML but controlled by purchasing apply here.
Now the case that the EBOM-part is not a standard part. In that case, there are two options:
- The EBOM-part holds only the specifications and the EBOM-part will be linked to one or more MBOM-parts (depending on manufacturing locations). In case the part is outsourced, your company might not even be interested in the MBOM-part as it is up to the supplier to manufacture it according to specifications
- The EBOM-part describes a specification but does not exist as such individuals. For example, 1.2-meter hydraulic tube, or the part should be painted (not specified in the EBOM with quantity) or cut out of steel with a certain thickness. In the MBOM you would find the materials in detailed sizes and related operations.
Do we need an EBOM and MBOM structure?
In the traditional PLM implementations, we often see the evolution of BOM-like structures along the enterprise: Concept-BOM, Engineering BOM, Manufacturing BOM, Service BOM, and others. Each structure could consist of individual objects in the PLM-system. This is an easy to understand approach, where the challenge is to keep these structures up-to-date and synced with the right information.
See below an old image from Dassault Systemes ENOVIA in 2014:
Another more granular approach is to have connected data sets that all have their unique properties and by combining some of them you have the EBOM, and by combining other elements, you have the MBOM. This approach is used in data platforms where the target is to have a “single version of the truth” for each piece of information and you create through apps an EBOM or MBOM-view with related functionality. My blog-buddy Oleg Shilovitsky from OpenBOM is promoting this approach already for several years – have a look here.
So the answer do you need multiple BOM structures is:
Probably YES currently but not anymore in the future once you are data-driven.
Ultimately we want to be data-driven to allow extreme efficient data handling and speed of operations (no more conversions / no more syncing to be controlled by human resources – highly automated and intelligent is the target)
Conclusion
Even this post is just showing the tip of the iceberg for a full EBOM-MBOM discussion. It is clear that this discussion now is more mature and understood by most PLM-consultants as compared to 5 – 10 years ago.
It is a necessary step to understand the future, which I hope to explain during the upcoming PI PLMx event in London or whenever we meet.
Jos Voskuil's Weblog 
4 comments
Comments feed for this article
January 23, 2019 at 10:35 pm
Guido Banning
I guess you mean ultimately you want for each manufactured product in the field a Digital Twin that represents a complete product definition (eBOM, mBoM, As-Built BoM, As-Maintained BoM, etc.) exactly specifying how the product has been designed, manufactured, maintained, etc. + behavioral information telling the manufacturer when certain components need to be replaced before these would actually break as well as looping data back to engineering allowing them to optimize their designs (simulations) as well as better define their next generation products based (fielded data teaches the manufacturer how the products in the field are actually being used).
All this and much more can already be done with PTC’s Smart Connected PLM :-).
Thanks Guido – to be honest I am not dreaming about a digital twin for every manufactured product. It has to make sense business wise. For example if you are in mass production, it depends on your business model if the digital twin adds value to your business. Creating digital continuity is a big effort for organisations – I believe there is a lot of technology (as my blog buddy Oleg will confirm) – however I believe organisational change is the challenge for people – give up your comfort zone, explore the future and meanwhile be still profitable
LikeLike
January 23, 2019 at 10:37 pm
hGuido Banning
But must admit excellent blog about the importance of eBoM and mBoM in the PLM enterprise.
Thanks Guido – indeed creating an EBOM / MBOM connection inside PLM is already a challenge for companies
LikeLike
January 25, 2019 at 6:11 pm
Simon Kooij
Hi Jos,
The last days I have read a few blogs from you, what was still standing in my email backlog..
I have enjoyed the model based X blogs a recognized a lot where we have discussed about along the way last year to understand and get grip on it to translate it in an approach for the company.
It’s still a topic and journey what will go on !
The first picture in your blog is what I like and laughed about.
Quite similar as the text what is on the wall in my office:
Said is not Heard
Hears is not Understood
Understood is not Agreed
Agreed is not Execution
No comment about your EBOM>MBOM explanation.
It’s clear and concise.
Beside the fact that for a lot of companies it is a huge step to go from EBOM=MBOM to a full BOM-centric approach from EBOM to (multiple)MBOM(s) to feed ERP(on differten sites) fast and correctly.
Especially when the EBOM transfer to MBOM is not only panthomising of the sub-assemblies, but also to split assemblies in the MBOM (without Engineering change at the assembly in the EBOM side) or to add extra (manufacturing) parts, or replace selected parts by equivalent parts (like AML / AVL)
And when is stated: multiple BOM structures are not necessary anymore in the future once we are are data-driven,
The remark is “Nice”, but “How” to create the right BOM for the manufacturing sites from a (Generic-Variant) Design (and still be efficient (profitable)).
Time will tell, We are open to learn…
It’s a pity that I am not able to visit the upcoming PI PLMx event in London, but certainly we speak and meet again…
Have fun in London !
Best regards,
Simon Kooij
Thanks Simon for your nice/wise words from the real world – I am looking forward to keep on learning the best compromises together.
Best regards, Jos
LikeLike
April 6, 2023 at 1:05 am
Alice
Thanks a lot for your blog and videos; they give me a new point of view and inspire me a lot. Actually, I’m working on the “life cycle of a product BOM,” which should be working in your company. It makes sense that E-BOM and M-BOM are not exactly the same data.
I have 3 questions for you :
1. could an E-BOM depend on the production plant? if I understood well, 2 prod plants shipping the same product may have the same E-BOM, isn’t it?
2. Does an E-BOM have a validity period? If yes, is it a period of production? If yes, is it the Work Order begin date, shipping date or delivery date.
3. About M-BOM: in our company, we subcontract all the manufacturing of the product, but we procure the main components. Can we say that the BOM used by our MRP that has only components that we buy and own is an M-BOM? To me is more of a “Procurement BOM,” but maybe is OK to call it M-BOM.
This message is like a bottle in the sea.. I don’t know if you are going to read it but I try my luck .. I have just being nominated as Data Owner of E-BOM and I try to measure how far we currently are from a manufacturing standard.
Last question.. in your opinion, do you think E-BOM exactitude/certainty should be measured in order to improve trust on data? If yes , do you have any advice on best pratices ?
Thanks for your questions Alice – I combined the into one comment:
1. If you work with the EBOM-MBOM principle, the EBOM is in theory not depending on the manufacturing plant. The EBOM specifies which components (make or buy) are needed and for each component there is a functional specification (model/drawing/spec sheet). For the manufacturing process for different plants, each plant will source its part (to be approved by engineering) and define the production process based on their local resources (as long as they meet the engineering specifications). So one EBOM (potentially stable over time) connected with multiple MBOMs (per plant / can change faster because of supplier part availabilities)
2.The EBOM is released by engineering and a new released version can come later when changes (fixes/improvements) are made. The release date of the EBOM is not connected to production. It is up to the Change Process when a new MBOM (based on the new EBOM) becomes actual – it can depend on the urgency, the old parts still in stock.The MBOM connected to the ERP will impact shipping data & delivery date, not the EBOM.
3. In case you only assemble your end product, the MBOM can be a flat list of supplier parts and might look like a procurement BOM. However if your manufacturing process is based on assembly steps and/or half-fabricates (also used in other products) then the MBOM can have several levels and reflect the Bill of Process.
Related to your final question about quality. It is crucial to have a release process and change process in place where at least a list of checks is done by independent people. For example: A person who designs a product cannot approve the product. Or a designer cannot introduce a change – only after approval of impacted disciplines.
LikeLike