A Bill of Material (BOM) at its core is a very simple concept: a list of components needed to manufacture a finished product. So if one was making a pair of spectacles, the BOM may look as follows:
|Item 1||Right Lens||1|
|Item 2||Left Lens||1|
It must be said that understanding how a BOM functions is fundamental to understanding how PLM systems work. This simple list is really at the core of the PLM system. However, simple concepts have a tendency to escalate into very complex subjects. And so it is with a BOM.
One of the complexities associated with a BOM is that an organization usually has a requirement for different types of a BOM in order to define a single product. Most manufacturing companies have at least three types:
- EBOM (Engineering BOM) is the list of parts that engineers are responsible for and comprises all the components that require some sort of design input.
- MBOM (Manufacturing BOM) is the list of parts that are required to actually make the product. This is typically different from EBOM by components that engineering do not specifically design (glue strips, liquid fills etc.). It may also be plant specific.
- XBOM (Service BOM) is an as built list of parts used in a product that actually made it off the factory floor. This may be different from what was originally specified by the MBOM because of crisis during manufacture. It is important from a customer service perspective.
So the question is: how are your three BOMs authored, edited, maintained, and released? Whatever the answer to this question, the outcome is always the same:
- No BOM – No product
- Wrong BOM – Factory rework or customer dissatisfaction.
An informal survey of small to medium size companies yields surprising results: Excel is the predominant BOM management tool in an engineering environment. Manufacturing BOMs are normally handled by some sort of ERP system and service BOMs are poorly tracked, if at all. This situation is fraught with potential for disaster because of all the manual processes that have to occur before an actual product gets made.
Hence the analogy in the title. BOM management may be a hidden problem that is set to explode in an organization, especially as the products being made become more complex. PLM systems can offer a single organized BOM that represents all the different types in a consistent, controlled manner. Given the potential consequences of the bomb exploding, BOM in PLM should be a priority.
Do you have a BOM management disaster of your own to share? How about a BOM management triumph?