Bills of Material (BOM) for DMSMS
The Bill of Materials (BOM) will provide information that can be used to establish the production status of parts used in a system. The BOM will also provide Diminishing Manufacturing Sources and Material Shortages (DMSMS) management essential information that enables the identification, forecasting, mitigation, and management of Hardware and Software obsolescence as a part of the Department of Defense (DoD) Program Manager's Total System Life Cycle Management responsibilities. The data will be used in DMSMS forecasting tools to allow for standard and efficient sharing of information on common items.
A bill of materials (BOM), sometimes referred to as a product structure, is a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and quantities of each needed to manufacture an end item. BOMs inform production orders as teams assemble and/or requisition the materials needed to execute a production plan. While a BOM is an enabling tool for production and manufacturing teams to assemble materials and build products, it also provides a foundation for teams that maintain and sustain those products. A BOM is a critical source of data for many functional areas within DoD. Engineering may utilize the BOM as configuration data from an “as designed” perspective, Financial Management personnel may harness it for cost information, and Life Cycle Logisticians will leverage the BOM to support Supply Chain Management and Sustainment, specifically Diminishing Manufacturing Sources and Material Shortages (DMSMS) management. BOMs are crucial for DMSMS efforts because you must first have a complete list of all the individual piece parts that make up your end item (ship, aircraft, satellite ground station) if you’re going to successfully maintain access to a supply of all those piece parts (or their replacements). A BOM constitutes that complete list, and the life cycle logistician can leverage it as the foundation of a robust, proactive DMSMS management program.
DMSMS management is characterized by two approaches, reactive or proactive:
- Reactive: There is little to no effort to identify DMSMS issues in advance. Any DMSMS problem is addressed when it arises, usually when an order for an item cannot be filled by suppliers. Unfillable demands impact weapon system readiness. The proverbial train wreck occurs, and the team responds by cleaning up the mess and wondering how it occurred.
- Proactive: Practitioners implement a monitoring program to identify obsolete or nearly obsolete items along with at-risk suppliers, prior to a failed attempt to purchase the item or materials. They receive discontinuance notices or other DMSMS-related alerts such as counterfeit notices from Original Equipment Manufacturers (OEM), prime contractors, or from predictive tools. They extend the time available to deal with issues, facilitating more effective and structured resolution options. They also initiate mitigation actions as soon as practical to minimize DMSMS-related impacts on their program. Potential train wrecks are identified and averted before impact.
DoD weapon systems are both expensive and expected to be in service for extended periods. Contrast that with the industrial technological market, which assumes more inexpensive product replacement every 2-3 years. This may make the concept of “proactive” DMSMS management counterintuitive for industry, but not for DoD, which sustains weapon systems for much longer. Effective DMSMS practitioners advocate for and practice proactive issue management.
There are three common types of BOMs:
- Engineering Bill of Materials (EBOM) —defines assemblies and parts designed by the engineering department. Shows the component structure from a functional perspective and consists of a mechanical or technical drawing of a product. Typically created by engineers using computer-aided design or electronic design automation tools. It is common to have more than one EBOM for products as designs evolve. Sometimes referred to as the “as designed” BOM. For the DMSMS practitioner, EBOMs provide the most information regarding substitutions and alternate parts.
- Manufacturing Bill of Materials (MBOM) —includes a comprehensive list of all the items and subassemblies required to make a shippable finished product. Includes information about the parts that require processing prior to assembly and explains how various components in a product relate to one another. MBOM information is shared with functions involved in ordering and building products.
- Sales Bill of Materials (SBOM) —defines the details of the product prior to assembly in the sales stage. In an SBOM, the list of finished products and the components required to develop it appear separately in sales order documents. The finished product is managed as a sales item rather than an inventory item.
In addition to these main three, you may also encounter the following:
- Production Bill of Materials (PBOM) — another name for the first half of the MBOM. A structured list of all components and subassemblies used in production of an item’s next higher assembly. For the DMSMS practitioner, PBOMs provide the most accurate information regarding what is installed in the system.
- Assembly Bill of Materials (ABOM) — identifies what's included in the second half of the MBOM. Lists the next higher assembly as a sales item rather than an inventory item.
- Configurable Bill of Materials (CBOM) — used in industries with highly configurable products. Designed to meet unique customer specifications and identify the building/construction materials, labeling and packaging materials. Examples of configurable products are cars, cranes, commercial furniture, even clothing items. Common denominator with these products is that customers choose different configurations based on their unique requirements.
- Template Bill of Materials (TBOM) — provides a standardized list of components for items that are regularly serviced. Components represent the subcomponents of the object being serviced. This type of BOM can be used to track which subcomponents have been serviced or replaced.
- Software Bill of Materials (SBOM) — effectively a nested inventory, or list of ingredients that make up software components. An SBOM identifies and lists software components, information about those components, and supply chain relationships between them. An SBOM increases software transparency and can help increase cybersecurity responsiveness as well as aid software license management.
Regardless of title, each type of BOM will vary in structure and level of detail. For example, an EBOM may list parts related to a specific function of the product, such as chips for a circuit board. An MBOM lists every material that goes into manufacturing a product. To complicate things further, you may also encounter EBOMs referred as either “Engineering” or “Electronic.” You may encounter a Sales BOM, or a Software BOM, both labelled as SBOMs. Software BOMs list components of a piece of software, which could consist of a mix of commercial and open-source products, enabling developers to integrate disparate software components. Be sure to clarify the type of BOM you’re obtaining or working with. For additional information regarding Software BOMs, refer to this Framing Software Component Transparency: Establishing a Common Software Bill of Material (SBOM) article and SBOM FAQ.
BOMs are also typically structured in one of two ways, flat or indentured:
- Flat BOMs are a simple list of items in which everything is given the same priority and there is no easily identifiable relationship between components, sub-assemblies, assemblies, or the next higher assembly.
- Indentured BOMs show the relationship of components to sub-assemblies, sub-assemblies to assemblies, and assemblies to the entire system (parent/child relationships). The indentured format is preferred for DMSMS management because it provides a broader picture for identifying, assessing the impact of, and weighing resolution options for issues.
As an example, when analyzing item availability, a flat BOM would only enable the identification of the number of obsolete items within a system—a program office couldn’t drill down to specific components within assemblies. An indentured BOM, in its hierarchical format, would enable a program office to visualize the relationships of identified obsolescence issues more readily between components within the entire system, and to use this information to inform the identification and determination of potential resolution options.
BOMs (and associated data rights) are usually obtained contractually early in a system’s life cycle. The ideal situation is one in which the government has an established contractual requirement for BOMs (and for notional BOMs or parts lists during design). Contractual language between the program office and prime contractor(s), including data rights determinations, should be agreed to as early as possible. Prime contractors often must negotiate with OEMs for access to their BOMs, so it is not safe to assume that a prime contractor will automatically be able to make these available to a program office. Data Item Descriptions you may see used for BOMs include DI-MGMT-82274, DMSMS Life Cycle Management Data, as well as DI-PSSS-81656B, BOM for Logistics and Supply Chain Risk Management. Consult the SD-26 DMSMS and Parts Management Contracting Guide for additional information.
There are situations in which a contractual requirement for a BOM may have been overlooked or omitted. While not ideal, it is possible to construct a BOM organically. The SD-22 Diminishing Manufacturing Sources & Material Shortages (DMSMS) Guidebook, specifically Appendix I, contains information for program offices that need to acquire or develop BOMs.
Generally speaking, once a DMSMS practitioner has a BOM (and applicable data rights) in hand, they will load it into predictive tool(s), monitor items, forecast DMSMS issues, provide recommendations for resourcing/action, and share resolutions with the broader DMSMS community. In some cases, the prime contractor or a third party will manage the process, providing analysis and recommendations to the program office for decisions and resourcing. In all cases, it’s essential that BOMs are evaluated frequently to identify and proactively address emerging DMSMS issues. BOMs may also require updating due to weapon system modifications, technical insertions, technical refreshes, and even from DMSMS resolutions themselves. There are various predictive tools available within government and industry, some of which require subscription fees. Predictive tools are particularly useful for analyzing electronic items within BOMs to forecast DMSMS issues. Having the results of more than one predictive tool may be effective because different predictive tools cover different items. A single predictive tool, while providing some insights, may not recognize all items within a system's BOM, limiting a program office’s awareness of impending issues.
It's important to understand that different functionals utilize BOM data differently. This article focuses on BOM use for DMSMS management, so a DMSMS practitioner will selectively reference BOM details. A BOM is not just a materials list but a detailed record of a component’s specifications, including part numbers, assembly processes, and units of measure. For example, engineers, DMSMS practitioners, and contracting officers use BOMs for different purposes, such as design, sustainment, or price analysis. DI-MGMT-81994, Priced Bill of Materials (PBOM), enables price comparison of supplier parts before and after contract award. The two DIDs mentioned earlier in the context of DMSMS management, DI-MGMT-82274 and DI-PSSS-81656, do not include price data. When working within your Integrated Process Teams (IPTs), remember you can only “tailor out” DID data on a CDRL, not add new data beyond the scope of the DID. If a DID doesn’t specify the data you require, consider finding another DID.