Ask any manufacturers where they maintain their “bills of materials (BOMs)” and the first question you will get is “which BOM”? For all but the simplest of products, there can be many different BOMs. As manufacturers continue to digitally transform their operations, the lines of demarcation between design and production are becoming increasingly blurred, prompting the need for further discussion on the topic of eBOM vs. mBOM – what data belongs where?
What is an eBOM or an mBOM?
An engineering BOM (eBOM) originates with product design engineers and is created and stored within a Product Lifecycle Management (PLM) system. It is generally specific to the point of detailing component specifications but often doesn’t identify where the parts came from or if they were manufactured internally.
A manufacturing BOM (mBOM) is usually created by procurement planners, manufacturing engineers, production specialists, or similar positions. There can also be “as-built BOMs,” “as-shipped BOMs,” and “as-maintained BOMs,” among others. Each of these BOMs provides further details and may or may not vary significantly from the original eBOM.
Today’s digital transformation has amplified the perennial debate as to where an eBOM and mBOM should be created, utilized, and maintained? Should it be in a single application or spread among multiple systems? And which application(s) should it originate from? Design engineers live in the PLM world, production planners and procurement specialists live in the ERP world, and plant floor production relies on their MES/MOM solutions. Each group prefers its environment, which is what has fueled the debate.
The eBOM
The simplest definition of an engineering bill of materials is that it is the “as-designed” list of assemblies, subassemblies, parts, and components of a product. It is created by the engineering function and is generally created using a variety of computer-aided design tools such as CAD or EDA software. As such, there can be multiple eBOMs for a complex electro-mechanical device, mechanical, electrical/electronic, printed circuit design, etc. To further define the designed item, design engineers also provide engineering specifications that define the product from a material, process, or quality aspect. This engineering data is typically referred to as MetaData.
What differentiates an eBOM from downstream BOMs is that it reflects intent, not the outcome. The eBOM is generally rigorously controlled with an engineering change order (ECO) required to modify the original design. The eBOM tends to be kept either in the PLM or CAD/CAM software used by engineering and probably doesn’t have the level of detail about some of the parts that downstream BOMs are likely to have.
The mBOM
The manufacturing BOM is considered “downstream” from the eBOM in that it is created after the eBOM. Like the eBOM, there can be multiple versions of mBOMs reflecting the various manufacturing processes used to create a product. Although the mBOM can be a direct copy of the eBOM, the mBOM may also restructure the eBOM into manageable segments of work. In addition to the part content of the eBOM, the mBOM will include all the items required by manufacturing to manufacture/assemble the product established by the engineering MetaData.
Since the mBOM reflects the product as it is ready to be shipped to the customer, it is also likely to reflect any packaging materials used to ready it for shipment. The mBOM drives the manufacturing process so it is the driving force in any Manufacturing Execution System (MES) application. It is the MES solution that guides the execution provided by the mBOM and captures the actual results, which then go into documenting the “as-manufactured” or “as-built” BOM.
This article may be of interest, The Digital Enterprise: Manufacturing at the Tipping Point.
The “One Source” Myth
One of the challenges in operating efficiently within complex, discrete manufacturing is ensuring everyone is “singing from the same sheet music.” If different parts of the organization are working from potentially conflicting data, then chaos will soon follow. Future production or quality issues become highly likely, leading to unhappy customers as products fail to deliver their promised value.
This potential challenge has led many businesses to consider pursuing a strategy of a single unified BOM structure that will serve as their “one source of the truth.” The first impulse is trying to establish a single-source model is to consolidate everything into a single application. Often this manifests itself as having all the BOMs kept in either the PLM system or the ERP system, as these tend to be corporate-wide solutions that have centralized IT support. The challenge is that each system has different users, license agreements, operational time frames, and response times. Picking one system to be the single repository results in massive integration and synchronization challenges. The ability to have a single centralized record is rarely achievable.
Synchronization is the Answer
A more rational approach to maintaining “the truth” is to recognize that each BOM is best executed and maintained in the system closest to the activity that is most intimate with the BOM. For the mBOM, it is the MES application. Of course, this means your MES must be capable of tight integration with both your PLM/Engineering tools and your ERP/production planning and procurement tools.
The key to having a single source of the truth is for your eBOM, mBOM, and other BOMs to be tightly synchronized – regardless of where they are kept and executed. For your mBOMs, this means changes made in the eBOM reflecting engineering changes need to immediately flow into the mBOM seamlessly and transparently. If your MES, PLM, ERP, and Field Service solutions are knitted together, you can have the best of both worlds. All your BOMs will be optimized for each primary constituency, yet every employee will still have current visibility on what is “the truth.”
