.png)
Bill of Materials (BOMs) are a necessary piece of the hardware development lifecycle. Containing as little as or much more information than users need, BOMs help teams with:
BOM management is as much an art as it is a science, with a variety of factors that can increase complexity in managing this data. As engineers, we can overcomplicate anything and BOMs are no exception. In this article, we’ll explore the basics like common types of BOMs and how they’re structured/used.
Engineering teams can typically generate the foundations of EBOMs (engineering BOMs) from most CAD and PDM systems. These reflect the product as-designed including the part/assembly structures of CAD files. In most cases, teams use EBOMs to capture the level/hierarchy, part number and name, description, quantity, and whether it is off-the-shelf or custom. EBOMs can also contain additional information around the actual specifications of the parts/assemblies themselves - such as color, material, and surface treatments. Ultimately, the EBOM captures all the custom designed and off-the-shelf common components necessary to build the product.
The complexities that arise in BOM management are from the different revisions and versions of parts that are being checked out/checked in or released, or if metadata used for product manufacturing information is updated (e.g. color, material, surface treatments). If using spreadsheets, users need to ensure the critical information is captured and updated - often in multiple places. This manual, duplicative data entry introduces risk in that the BOMs aren’t updated as frequently as they should, and even if they are - not updated correctly. In many cases, teams use configurations of assemblies or part files, with different metadata or information to track for each configuration. These configurations might also reference a different list of children components that needs to be reflected in the BOMs (or more likely - different BOMs that are created to track the combination of configurations).
MBOMs (manufacturing BOMs) build on top of EBOMs. While the EBOM may contain the line item for an injection molded part file as the top enclosure of an assembly, the MBOM will contain the line items for any labeling, adhesives, or other consumables that get applied to the enclosure as well. MBOMs include information around how parts will get manufactured, assembled, and shipped - such as manufacturing process steps/routing, assembly steps/quality procedures, and packaging instructions. In these examples - the MBOMs contain both additional line items to reflect what it takes to manufacture and assemble, as well as additional fields and values of information not tracked on the EBOM such as the lifecycle state. In this case - managing the BOM involves two inputs - the metadata from CAD files as well as manual edits on the BOM itself.
Throughout the hardware development process, different versions of EBOMs and MBOMs will be created to serve as timestamps or snapshots in time of specific builds. These versions also help teams trace the changes to overall builds over time and serve as blueprints for what is to be built. Many teams use BOMs to facilitate BOM release processes - where either EBOMs or MBOMs go through approval and release processes to indicate exactly what is going to get built. For example, many teams follow different stages in their hardware development lifecycle like Proto2, Proto 1, EVT, DVT, PVT, etc. Each of these stages would require corresponding BOM approvals and releases for what is to be built - separate from the approvals and releases on a discrete part or assembly level like with ECOs (engineering change orders). These approvals at various stages of the hardware development lifecycle could involve various stakeholders from other teams, further establishing the BOM as the central source of truth for the build.
Both EBOMs and MBOMs can be structured differently to best communicate and collaborate on information. Common examples include indented, direct, or parts only formats.
BOM structures are especially relevant when considering cases where there need to be multiple top level assemblies that do not have a further common parent assembly. In these cases, MCAD can generate discrete EBOMs for the individual top level assemblies, but not for all of these individual assemblies combined without that higher-level parent assembly.
As the acronyms EBOM and MBOM suggest, these are typically owned by the engineering and manufacturing teams respectively. However, there are a variety of stakeholders for both types of BOMs from different teams such as sales or service, who may also be contributors to the data themselves. While some teams may also use SBOMs (either sales BOMs or service BOMs) to track replacement parts or end-item management for SKUs, these are typically derived from MBOMs like how MBOMs typically derive from EBOMs. In those cases, BOMs also need to track costs on a line item and rollup level for subassemblies and assemblies. To effectively track cost rollups (especially with external parties like suppliers), teams need to ensure a tight link between the EBOM and MBOM - as any discrepancies can lead to costly reworks and schedule delays. This tight link between the EBOM and MBOM also extends to the actual production files themselves - whether CAD, drawing files, PCB/Gerber files, or Adobe Illustrator files for pamphlets/instruction manuals that ship with the product.
For example, teams commonly share BOMs and production files with suppliers to track RFQs (request for quote or bid packages) and production statuses. Suppliers could quote for the incorrect revision of a part, leading to delays in the turnaround time for quotes or potential upcharges. If discrepancies are caught in production - at best, production may pause or schedules will be frozen till the issue is resolved. At worst, this delays the assembly of the entire build. This could be a preventable issue with DFM feedback if the supplier had access to the correct revision/version of the file and references on the BOM. In other cases, teams may want to simply hide specific components (line items) or fields of information (columns) from supplier BOMs if those suppliers will not be manufacturing those parts and assemblies. In this case, teams may be maintaining both external and internal facing BOMs with primarily the same information, further compounding the duplicate data entry users have to perform.
It’s difficult enough for teams to manage BOMs manually, but ensuring suppliers have the correct revisions/versions of all files necessary can be even harder. As teams generally don’t share native files with suppliers - MCAD and PDM systems can generate STEP file exports for CAD and PDF for drawings and EDA systems can do the same for electrical files. However, the file metadata used to populate BOMs may come from either CAD or PDM systems for the EBOM use cases, with additional files and metadata coming from PLM and for the MBOM use cases. Although the data may be coming from different siloes, the BOMs must be the central source of truth as they relate to the upcoming build. With stakeholders across a variety of internal and external teams, BOM management can be a highly complex process that is a necessary requirement for the hardware development lifecycle. In our next blog post, we’ll discuss the benefits of moving away from spreadsheet based to database driven methodologies for generating and managing BOMs to help simplify hardware development.
Want to take a deeper look into how Bild can help with your team's BOM management? Schedule a demo today!