BOM 101: How Many Levels Do You Need in BOM?

by Oleg on January 30, 2013 · 6 comments

I’m continue my BOM 101 series of posts. When working on bill of materials, you can often hear about the ability of BOM management software to support so-called “multi-level” BOM. You can search for the definition of multi-level BOM using Google and find many results. I found the following definition of multi-level BOM on Arena website quite balanced. Here is the passage from the Mult-level BOM article:

A multi-level BOM, also referred to as an indented BOM, depicts parent-child relationships and shows the hierarchical structure of assemblies and their related parts and components. A multi-level BOM is essentially a nested list whose parts or items are listed in two or more levels of detail to illustrate multiple assemblies within a product’s BOM. In contrast, a single-level BOM depicts one level of children in an assembly and only the components needed to make that assembly are listed.

In the past, when BOM was managed using paper and spreadsheets, to create multi-level BOM wasn’t a simple task. Computer systems create an opportunity to manage and manipulate easily with multiple levels of BOM. However, the question people are asking usually – how many levels of BOM do we need? This simple question is actually leads to many interesting discussions. From my practice it related to many factors. The most typical are – type of BOM (engineering, manufacturing, support), type of the product, maturity of product development and many others.

I found an interesting writeup about BOM levels in the Frank Watts’ book – Configuration Management Metrics. Navigate to the following link – I was able to access this book fragment using Google Books. Here is an interesting passage:

The tendencies of the companies to create multi-level assembly structures seems to be overwhelming. This analyst has witnessed 11 levels at a couple of companies and had a seminar attendee tell about 16 levels. Many departments wish to add structure for their apparent need and many needs are not in best interest of the company as a whole. Because agreement cannot be reached on one structure, often an “Engineering BOM” and a “Manufacturing BOM” are created. Often a material folks create “Planning BOM”. Many times various department can reach agreement only by adding additional layers to the BOM. 

The following diagram shows the number of levels in BOM correlated to maturity of product development. The analyst believes a better communication can be achieved by creating a BOM with minimum levels of structure.

What is my conclusion? The fact you can create multiple levels of BOM doesn’t mean you need to utilize it at full capacity. Multi-level BOMs are complicated and adding an additional work in the process of changes. How to maintain the right number of BOM levels? I’m interested to learn more about your experience. How many BOM levels do you have in your company ERP/MRP/PDM/PLM system? Speak your mind.

Best, Oleg

Share
  • MattB

    I agree with your comments especially how departments wish to introduce their own levels of BOM (&complexity) to support their discrete requirements. I think its difficult to quantify the number of BOM levels that should be perceived to be optimum as the number of BOM levels in my experience is largely driven by other factors, such as:-
    - Is the BOM structure aligned to the ERP structure?
    - What functions does the BOM perform, design validation, configured component, BOP, MBOM etc?
    - Does the BOM support multiple model years, configurations, pre and post launch component changes?
    - Who consumes the BOM.
    - Integration with downstream functions and software.
    Also lets not forget a BOM structure that has 6,7,8 levels of hierarchy is not necessarily a poor design, there may be valid reasons for this and as long as the structure is aligned to the business processes and the software that manages the BOM has functionality to interrogate the BOM is an efficient manner then this type of structure should be perceived to be an efficient BOM.
    When designing a BOM I would start by looking at what processes the BOM should perform and work backwards from that. If your PD process / components are complex then the BOM Levels are likely to be greater than if you are manufacturing simple product, with low complexity, across simple manufacturing processes.

  • http://twitter.com/FredSmithPTC Fred Smith

    There seems to be an underlying premise here that “more levels are bad”. I choose to believe that departments don’t insist on more levels arbitrarily. In fact, levels usually come about to reduce complexity. Hierarchical structures are a mechanism to break down complexity. A large structure only indicates that there are many decompositions. So what? How complex is an airplane, or a cell phone, or an ink pen? And what’s wrong with decomposing them fully?
    Another reason that BOMs may become overloaded is that a downstream process wants to leverage the product description that was developed upstream, but use it for a different purpose. First, re-use is generally considered a good practice, and second, there is nothing wrong with multiple BOMs for a single product that are specialized to their purpose. They are often most efficient at conveying the most relevant information.
    But, what this discussion does point to is the need for sophisticated systems to manage and navigate the product structures that are the true source of the BOMs. PLM systems are becoming critical capabilities for all but the simplest products.

  • beyondplm

    Matt, thanks for your comment and examples sharing. I don’t think, the question is what is the optimum number of level. The right question is how to optimize department functions accessing the same Bill of Materials. Best, Oleg

  • beyondplm

    Fred, thanks for commenting! Agree, decomposition is one way to simplify stuff. Engineering software did it for the last 20 years. Actually, OS (like Windows) did it for while with File Explorer. However, we came to the level where complexity is outgrowing the potential capacity of hierarchy. This is where different organization of data is coming to help. Search / Tagging/ Filtering can be used to make BOM browsing simpler without starting to go with levels. Just my opinion. YMMV. Best, Oleg

  • http://twitter.com/FredSmithPTC Fred Smith

    I understand what you are saying. Folders are an excellent analogy of how hierarchies can go horribly wrong. Imagine trying to share your desktop with dozens or hundreds of colleagues. I personally have thousands of folders and files, and have a hard time locating files that I stuffed into this organizational structure/mess. No one else could find anything by navigating my desktop. Product structures have only slightly more rigourous organizational principals than folders. So, you definitely need to be careful how you architect a complex product. And, tagging, filtering, and searching are indispensible tools too. Hierarchies like product structures are not a tool for locating data, only for organizing it.

  • beyondplm

    Fred, I’m on the same page with you. Hierarchy (more precisely graph) can represent semantics of data. However, accessing methods need to flat (search,tag, etc). Thanks for providing your insight! Great discussion! Oleg

Previous post:

Next post: