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

Posted by olegshilovitsky
For many years, enterprise was considered as a boring space. It was so much fun to talk about web, gadgets, Google and many other "cool" things. Why to get worried about enterprise application? Most of the people might think 

Data. Conversion. Interoperability. Translation. The discussion about these topics is endless in CAD/PLM world. Customers are looking for interoperability between different product versions, competitive products, data models, data formats, databases and geometrical kernels. Customers were always first impacted by problems of interoperability. The lifecycle of engineering and manufacturing work is longer than typical lifecycle of product version or even engineering IT solution. Technically, data interoperability is a complex problem. It is not easy to solve, even if you are want to do so. Evan Yares recently posted an interesting article about interoperability – 

Many years ago, one of my mentors told me that "the worst pencil is better than the best memory". I liked it. Since than, I have no trust in remembering things. I started to take notes. I switched to be completely paperless 4-5 years ago. The biggest problem on my way to become completely paperless was the ability to capture information at the time you need it coming from multiple sources. Finally, iPhone and combination of apps allowed me to create an environment where I can keep track of my activities and get access to this at any time.
One of the biggest tech events for me last week was 
BOM is fascinating. After posting
PLM vendors are continuing to adopt cloud. I can clearly see a difference between people attitude for cloud solutions now and 4 years ago. Here is my simplistic definition of changes that happened for the last 4 years. The following sequence represents a typical reaction on "cloud PLM" for the last 4 years. 2009: What is cloud? 2010: Why I need cloud? 2011: Why not to use cloud? 2012: How to use cloud?
I suggest you an experiment. Invite two engineers and ask them to provide a definition for some of PDM/PLM related terms. I’d not be surprised if you will get more than two definitions. It is not unusual to spend lots of time during PLM software implementation meetings to define terms, language and meaning of things. Regardless on terminology, I found BOM to be a central element in every product development organization and business. It contains a recipe of your product, process and, at the end of the day, becomes a lifeblood of your product development processes. Thinking about BOM management solution, I can see four major things that need to be defined, discussed and clarified.
