Bill of Materials (BOM)

A bill of materials (BOM) is a list of the raw materials or parts and the quantities of each needed to manufacture, assemble or repair an end product. A BOM is intended as a compact inventory-oriented representation of the requirements associated with an end product. As such, it is commonly found in many enterprise software products such as ERPs or MRPs, and used to automate repetitive operations such as replenishment orders. In practice, BOMs are an umbrella term that come with varying intents depending on the vertical.

Overview of the BOM

The bill of materials is a widely used supply chain informational artefact, much like SKUs (Stock-Keeping Unit) or MOQs (Minimum Order Quantities). In its simplest form, also referred to as the simple BOM, the BOM is a list of materials and associated quantities. In its most advanced form, typically obtained from a CAD (computer-aided design) software, the BOM includes technical drawings of the product and the placement of the parts. The intent associated with a BOM varies depending on the vertical being considered:

• In manufacturing, BOMs usually reflect a process where parts, or components, are assembled. Consumables, such as tape, paint, oil or ink, are frequently not reflected in manufacturing BOMs. The BOMs are primarily used to maintain flow consistency between the relative proportions of the raw materials, work in progress and end products.
• In retail, BOMs are usually referred to as bundles, kits or packs. They reflect a pricing mechanism intended to increase the client’s basket size, giving them a discount if they buy more goods from the retailer. Sometimes, the bundle is only a matter of convenience, e.g. selling the toy together with its batteries. In these situations, BOMs might remain a purely abstract perspective.
• In remanufacturing and maintenance, BOMs represent materials that might be needed to perform repairs. In such situations, the quantities given by the BOM are merely upper bounds on the materials that may ultimately be needed. Depending on the state of the repairable component, repairs usually only require a fraction of the BOM to be completed, although the exact quantities aren’t typically known until the repair is completed.

The management of BOMs belongs to the realm of master data management, and thus, asset management systems like ERPs or MRPs do typically feature BOMs in one way or another. Many mundane routine tasks, such as inventory replenishments, depend on maintaining accurate and up-to-date BOMs.

Multi-level BOM

A multi-level BOM is like a BOM, but where items in the list may themselves have BOMs of their own. The multi-level BOM is basically the recursive perspective of a BOM. While the multi-level BOM might appear as somehow more advanced, it is usually not the case, as a software that supports BOMs usually ends up supporting multi-level BOMs, even if this support is “accidental”. Indeed, once BOMs are supported, software-wise, there is usually nothing that prevents supply chain practitioners from creating “virtual” parts in the system that have BOMs of their own. Those virtual parts may exist for the sole purpose of representing a multi-level BOM if the system does not offer a more canonical way of dealing with multi-level BOMs.

Most features of interest around multi-level BOM involve:

• data entry sanitization, e.g. to prevent circular dependencies - where a part appears as one of its inner requirements - from being entered in the first place.
• ease of use, such as unrolling all the inner BOMs of a given end product, to facilitate the management of complex BOMs where many levels are involved.
• data enrichment, for example by associating manufacturing lead times to the BOM structure, in order to provide a more fine grained perspective on the underlying process modeled through the BOM.

BOMs and service levels

Ensuring a quality of service - frequently measured in terms of service levels - for end products whenever BOMs are involved is usually a somewhat difficult statistical problem. Most companies dealing with BOMs are serving many end products where multiple inner parts are shared - e.g. the same part is contributing to multiple end products and consequently appears in multiple BOMs. In those situations, even if the service levels of the inner parts are known, either empirically measured or purposefully steered, there is no closed form to compute the resulting service level for the end products.

If the company only has a single end product, then this end product’s service level can frequently be reasonably approximated as the lowest service levels of any of its parts. All other things being equal, in this situation, the stockouts of inner parts are expected to be highly correlated, as safety stocks can be expected to be kept synchronized, as the sole end product is the only source of consumption for parts. This approximation may not hold if suppliers have varying lead times, or if there are other sources of uncertainties beyond the future demand for the end products.

If the company has a large number of end products, and if no product really dominates the others volume-wise, then the service level of any end product can be reasonably approximated as the product of the service levels of all of its parts. In this situation, the availability of the inner parts is assumed to be independent, and the availability of inner parts is a condition to assemble the end product. This approximation may not hold if the consumption of inner parts is dominated by few end products.

The two situations above, respectively referred to as sole end products and uniform end products represent respectively the upper and lower bounds that can be expected from the service level of an end product in respect to the service level of its parts. At best, the end product has a service level that is not smaller than the service level of its weakest part. At worst, the end product has a service level that is not greater than the product of the service level of all its parts.

Remanufacturing BOM

In remanufacturing, usually called MRO (Maintenance Repair Overhaul) in aviation, end products (e.g. rotables in aviation) can be repaired, and the BOM represents the full list of materials that might be involved in a repair. However, once the end product is disassembled and inspected, it usually appears that only a small fraction of the original BOM list is actually needed to perform the repair. However, the exact inner parts and quantities needed to complete the repair operation cannot be known in advance.

The remanufacturing BOM differs from the (regular) BOM because it fundamentally belongs to a different realm, the historization of the operations realm, whereas the BOM belongs to the master data realm. The amount of data entries involved is substantially higher, as every repair operation can be traced down to its consumed parts, and the uncertainty is usually irreducible.

Ensuring quality of service - typically measured through TAT (turn-around time) - in the presence of remanufacturing BOMs, is even more complicated than dealing with regular BOMs, as not only the future demand of repairs is uncertain, but the requirements associated with every repair is also uncertain. Modeling and optimizing quality of service in the case of remanufacturing is typically done through probabilistic forecasting and modeling.

Configurable BOM

Many industries, most notably automotive and electronics, offer a high degree of configurability to the customer in order to define what the end product will be. When the number of options exceed what can be reasonably managed through distinct SKUs - assigning one SKU for every possible configuration - then, companies usually resort to the notion of configurable bill of materials, which defines the set of acceptable configurations.

Configurable BOMs present a series of challenges:

• Defining a comprehension that is not only expressive enough to include all the possible configurations, but also expressive enough to exclude all the infeasible ones. For example, when considering a workstation (personal computer), the suitability of a given power adapter depends on the list of components installed in the workstation. In computer science, the goal of comprehensions is to provide an intermediate level of expressiveness, higher than Boolean expressions (low expressiveness), but lower than generic programs (maximal expressiveness). The comprehension used for configurable BOMs is frequently tailored to the company’s specific needs, as even competitors may not have the same requirements.
• Providing a good user experience for the clients, or the sales staff, who have to walk through the configurator. The configurator is the piece of software that supports a bespoke order to be made for a configuration of the product, which may never be observed again. In particular, dealing with inner affinities or incompatibilities between parts or subsystems can overburden the customer with choices that are beyond his/her judgement capacity. A good configurator supports its end-user in this regard.
• Every unit sold is fundamentally unique. Much like the remanufacturing situation, the BOM has to be assessed from a probabilistic perspective that assign a probability to every single configuration. However, unlike the remanufacturing situation, configurable BOMs are typically much more constrained, every constraint being a piece of information that can be leveraged within a supply chain optimization process. For example, back to the workstation, no matter what components are selected, there is always at least one power adapter.

Supply chains where configurable BOMs are involved nearly always require bespoke numerical models, as time-series and most models, which could be referred to as “classic” supply chain optimizations, are typically not applicable.

Lokad’s take on BOM

On the surface, BOMs are simple. Yet, this simplicity is deceptive. While managing BOMs is usually straightforward - except in the case of configurable BOMs that are invariably complicated - optimizing anything (stock levels, service levels, lead times) when BOMs are involved becomes considerably harder. Most software vendors claim to support BOMs, but most of the time, vendors only support the management of BOMs, which amounts to a trivial feature, while delivering nothing at the optimization level.

From a modeling perspective, BOMs are graphs and require graph-oriented capabilities / functions / modules in order to be efficiently processed. Lokad has extensively developed its own capabilities geared toward such types of supply chain situations. Also, from our perspective, optimizing a supply chain in the presence of BOMs is the first logical step toward optimizing a multi-echelon network.