Seven Rules Towards Single Bill of Material

I’d like to continue discussion around the topic raised yesterday by Jim Brown and this is about “single bill of material”. I was reading Jim’s post and my thoughts was about why managing of single bill of material is questionable? I think the key answer to that is because in a real company we have multiple systems and everybody are touching bill of material. So, since I hardly believe business owners of these systems will agree how to share Bill of Material, we do have a “multiple bill of material” status-quo.

Now, I don’t believe systems like we have in manufacturing companies – all these EDM, PDM, PLM, ERP, CRM, MDM… will be magically agree on how to share bill of material in short term. But at the same time, I think, our industry is spending mega-bucks trying to synchronize all these bill of whatever we have (materials, documents, processes, requirements, configurations etc.). So, since Daily PLM Think Tank is about ideas, I decided to put key seven rules that can bring us to the new status quo of “single bill of material”. May be definition of this bill of material in the beginning will be shared between multiple systems, but even so, it will create movement toward single bill of material.

So, here are my seven rules.

1. Complete Data Representation. Data in Bill of Material starting from Part Number and ending all characteristics need to be complete to satisfy needs on all “company-customers” in every department starting from sales and ending up in manufacturing and services.

2. Unique Part Numbers. We need to establish a central system to maintain by single system. If Part is going to change from Form Fit and Function standpoint, new unique Part Number need to be created.

3. Synchronized Changes. We need to prevent changes that potential can be made on partial data representation. Example could be changes in Design System without appropriated changes in manufacturing and all other systems or data collections.

4. To use Part Numbers only.
Bill of Materials need to be made of Part Numbers only. We need to prevent usage of any alternative identification such as – drawing numbers etc.

5. Include all scheduled items. We need to include all items that need to scheduled for manufacturing and shop-flow. Everything that going to production need to be incuded into bill. There is no item that will be excluded for whatever reason (i.e. non completed assemblies and semi-finished items).

6. Less levels will be better.
The simple solution is the most complicated one. Today manufacturing is struggling to become lean. I think to manage as less as possible levels in Bill of Material will allow to simplify significantly everything we are doing (including way to synchronize or management bill of material).

7. Complete Approval before change. All requested to change need to be approved by all people that are using Bill of Material before bill is going to change. This is will allows trust between users of the bill of materials.

So, in my view, by following such rules we can get much better quality Bill of Material in organization. This is not requires religious discussions about single vs. multiple bill of materials. In the end, nobody cares in how many databases/files/servers we are going to store this (or these) bill of materials.

As usual, I’m very interesting in your feedback. Especially on such non-technological topic. Please, let me know what do you think?

Best, Oleg


Share This Post

  • AndyF

    Well as usual, I guess I come at this topic from a different angle. What we’ve evolved to in our thinking is that the number of BOM’s don’t really matter. If different people need different BOM’s for some reason then so be it. What is important is that everyone works off of the same file of parts. So we want to have a central database with all of the parts in it and all of the part attributes. Those parts can then be combined into different BOM’s as people need.

    Now if there are multiple BOM systems in production there does need to be some sort of linkage back to a central planning system so we can maintain inventory levels, coordinate buying efforts, manage defect tracking and produt returns and all of that good stuff.

    But I don’t think a single BOM system is a good idea, or even a possible idea in any larger company. It is certainly possible at Joe’s Furnace shop or something like that but once you start to run global mfg enterprises you’ll have BOM’s floating all over the place.

  • Andy, I definitely understand your view. Your underline thinking – all these departments will never agree on something reasonable. So, let’em to work out of the central database of parts and allow to combine their own BOMs. In this schema, you will be ready to pay cost of synchronization for BOM, but not for the Part. My take is to say – whatever different departments are doing, they need to create BOM in the same environment. do you see it possible? Thank you for comments! Great discussion… Best, Oleg

  • Oleg,
    A very interesting post. I have trouble getting beyond the “complete data representation” rule #1. Is it possible? Is it practicle? I was schooled to think single BOM was what we all wanted to achieve, but I am really questioning the conventional wisdom. I am still hoping to hear from somebody that is willing to stand up and say “I made it work for my company!”

    I think the link above (on “topic”) was meant to be to my post on “Single Bill of Material – Holy Grail or Pipe Dream” at
    Thanks for the dialogue.

    Always a good discussion in the “tank”

  • Luigi

    I think that also the Released Engineering BOM is to be managed in a centralized system. In this way it becames a starting point to create the P-BOM, the M-BOM etc. I think guys dealing with production have to consider the E-BOM as the reference model. All the changes to the other BOMS have to be considered in terms of impacts on the E-BOM, and only the E-BOM responsible has to accept the changes that impact also on the E-BOM before apply them.

    Best regards

  • Roberto Barale

    In general I agree with the seven BOM rules suggested by Oleg:
    • Complete data representation
    • Unique Part Numbers
    • Synchronized changes
    • To use Part Numbers only
    • Include all scheduled items
    • Less level will be better
    • Complete approval before change

    I just want propose some general remarks on BOM topic; sometime we talk about BOM having in mind different objects:
    • BOM as list of Parts Flat or hierarchical, with part and link attributes (in different type of views As Design ,As Built …)
    • BOM as Product Breakdown Structure of our assembly
    • BOM as Functional Breakdown Structure
    • BOM as image of a CAD product description
    • BOM as Virtual Mock-up configured
    • …

    The theoretical goal could be to have a central system hosting all the information concerning BOM:
    • Part description with all company attributes
    • Different type of link between parts:
    o Hierarchical
    o Technological
    o Alternative
    o Effectivity
    o Specification document of the part
    With all company attributes
    • Ownership management for part
    • Ownership management for part attributes (several owner for various attribute groups)
    • Ownership management for link
    • Ownership management for link attributes (several owner for various attribute groups)
    • Lifecycle rules

    A realistic approach must take into account some criticalities:
    • Each specific domain today is covered by different tools who are very expert and efficient into the domain itself (CAD, Documents, PDM, Configuration management, ERP, …)
    • Each tools is developed with its technology and tools
    • It is very complex and diverging from each software editor policy, thinking about a common DB and a common data model to connect all the tools
    • Having a unique common DB solution could become a strong dependence from the solution provider for high strategic company data
    • Development and deployment of such a solution requires a very long time and much more money compared to integrating commercial tools

    The possible customer cares could be:
    • Start each application implementation on BOM with a company view
    • involve all company BOM contributors to define the specific data model for each domain
    • take as much as possible the information pertain a domain and not shared with other inside the related system (like encapsulation in Object Programming)
    • identify all shared attributes and identify the owners and contributors
    • describe the whole lifecycle for Parts and BOM over the company and then split it for each specific tools into reasonable flow
    • try to simplify the push/pull operation between the various BOM applications

    These are few simple thinking coming from my day by day experience on BOM management.

  • AndyF

    I’ll weigh back in and say that there isn’t a “one size fits all” answer. I’m sure GE doesn’t use the same BOM system for jet engines and plastics. Boeing probably uses a different system on the commercial side vs. the military stuff.

    Where I work our whole BOM system and ERP system started to change dramatically when we sent all of our manufacturing off shore. These days our BOM’s don’t mean much, it is the BOM in Flextronics or Foxcon’s system that matters.

    This is another reason why I think the big PLM vendors have missed the boat. They can’t possibly provide us with the diversity of solutions that we actually require because every single customer has different requirements. Their solution is to write bloatware which costs $M’s to purchase and support and still doesn’t work correctly.

    The number of BOM’s you need is dependent on your business model. If you can do it with one BOM that is always up to date and is accessable real time by anyone around the globe then more power to you. Most people can’t figure out how to do that in their environments. Heck, I work at one of the original high-tech companies and we have to fax BOM changes to vendors sometimes because our firewall rules prohibit the necessary data connections. Why would we buy a multi-million dollar PLM system if we still have to print things out and fax them to our vendor?

  • Jim, here is the point. I don’t believe you can build a system from scratch doing well in enterprise. Enterprise is all about complex and cumbersome constraints, systems, business objectives and technological challenges. I put these rules as a guidance to improve situation and make it better. With regards to #1 – Part is the central piece in all what you have in engineering system (wide scope). Part definition spread out of multiple systems today. So, start shrink it to less numbers. Each day – one less. In the end, I believe you will have what do you need. Does it make sense? Best, Oleg

  • Luigi, Agree with your point. Make a lot of sense to have a single reference model for Bill of Material. Best, Oleg

  • Roberto, Thank you very much about your insight. I like your pragmatic view related to how describe realistic situation in organization. This is where I see the top customer’s pain today if you want to observe global enterprise (or company) level BOM. Your approach of sharing data is probably one that most realistic today in organization. However, this is an approach that sucks mega-bucks in implementation of BOM today. Synchronization between systems makes it near to impossible using technologies we have today. If you have an approach to have a single system for BOM, you need to start establishing this system step-by-step cutting dependencies and creating single BOM system. I’m not sure, this is possible, however will be very interesting to discuss what are your feeling and experience about that.
    Best, Oleg

  • Andy, Thanks! I love your example with fax of Bill of Material changes. Two things separately – 1/ you can reduce number of diverse BOM systems step by step. This is the main point of my seven rules. Don’t do it “single shot”, but step-by-step. This is the way to make engineering system less complicated. 2/ PLM vendors are trying to serve average needs of big customers. With split of 50/50 between software and services it works for big companies in my view. The main problem is $$$ and time of change. When you need your system to support something, you will be missing your targets because of changes in enterprise (not only PLM, but PLM too) system to support it. Best, Oleg

  • Hervé Menga

    I think the traditional question about the unicity of BOM is a fake problem.
    From my personal point of view, i would consider “the” BOM with the primary meaning of the bill of materials, which is the list of physical components i need to collect to construct my product. From this view, it is the BOM for procurement activities. And this BOM is already unique for a company that produces something, isn’t it ? (the form of this BOM is something different, it could be a simple list on a paper, a list of records in a database, or any list of “parts” anywhere, it does not change the purpose of this list, which is the list of things i must get from the “outside” world so i can construct my own things).
    So, why do we have to care about the EBOMs, functional BOMs, CAD BOMS, and other avatars.
    My personal view is that all these things are manipulated by engineering (product development) activities, in a place where we should only manipulate models of the product definition.
    On this place, we engineers are only constructing the product definition, which is pure raw knowledge and how-to stuffs, and the only way to manipulate knowledge is to build models and manipulate the models themselves (through pen and paper documents, computers, softwares, and so on).
    Sometime, one of these models may be viewed (by us, humans) as a list of things (a list of CAD sub-models, a list of sun-functions, a list of sub-systems, a list of sub-parts) because the internal structure of these models cannot be seen “directly” by us, poor humans, and these lists may be confusingly called “BOM”s by us.
    The thing we usually forget is that a model is constructed by a modeller, so the model contains the intentions of the modeller. So a model is never unique, each one depends on the intentions of the modeller…
    This is the reason why i could pretent that the question of the unicity of the BOM is a fake question, because the BOM is already unique.
    The real questions on which we have to work are:
    – what could be the interactions between the models of the product definition, and is it possible to simulate these interactions with current softwares?
    – what are the dependencies of the BOM with these product definition models, and is it possible to simulate these dependencies with current softwares?

  • Herve, Thanks for you comment! In my view, you can call it as you want – Product Design, Functional Model, CAD BOM whatsoever… I believe, people said “BOM” since this is something that unified in their minds. This is about abstraction level. If you can create another abstraction level – it will be just fine. Bottom line is that people in manufacturing need to get “list of components” needed for product (out of design/engineering) and you can call it whatever you want – BOM, Design Component List etc. BOM, in my view, is considered as a common denominator between all enterprise systems. At least, this is what I see in people’s mind…. Does it make sense? Oleg

  • I think Herve hits at the core of this issue. We are talking about a model of a product. The question is whether there is one, central model that meets the needs of all of the activities, processes, and people that interact with the product across its lifecycle. Clearly the model looks very different depending on your perspective.

    The big question is whether there is one model that meets everybody’s needs, or whether the different views are inherently different and should be associated and synchronized instead. Is there one uber model that encompasses all? I am still waiting to see it.

  • Jim, you can call BOM, product model and even design model and even purchasing list. It will not change number of options you have on your way to manage these pieces of data across enterprise. In my view, today, you have two strategy in your implementation (1) diverse views (2) single view. BTW, in both options, you will need to do some synchronization. I’m not convinced that there is a possibility to create a model that meets the needs of all activities. I just wonder how possible to provide a single abstraction of various bill of materials across enterprise.

  • Hello,
    As an NPI enginer that is in the field for more than 20 years, working in the R&D, managing Engineering department, Managing production floor and interacting strongly with customers (service activitie) and with supliers I will bw happy to share my thoughts.

    As we all know the BOM is “born” during the R&D activities wich is driven by the marketing or customer needs or and other entity that ignites (legaly)R&D activity (in order to bring money to the company).
    The basic methodology of NPI is to involve as early as possible those groups that are in the best interest to add fruitfull inputs to the “R&D to production ” process. I’m talking bout the marketing group, operations team (consists on purchasing, logistics and production personnel) and service personnel.
    All this “group” of people are working together on defining the product, each one from its point of view and from the aspects that are his interest. We are talking, in general, on building a BOM that at the end will be OK in terms of Marketing (configurable as derivative of the “master BOM”), R&D – modularity and easy for future changes and upgrades; service (FRU definitions), operations (purchasing – LLI; production – ease of production; outsourcing future options) and all other servisability, maintainability, manufacturability and other xxxability aspects.
    From the above there is one conclusion: there is only ONE (!!!) BOM that serves all. Any other BOM that is used by one or more teams is a derivative from this BOM and should be agreed upon by all major team leaders as well as managment.
    When I say “BOM” I meen a list of sub-systems and components that make a system and behind each record there is the needed documentation.

    If there is a need to perform a change (ECO) then all above groupe are to participate in the process in order for them to forward their inputs (as they see the change).
    “It is all a matter of synchronization,data and knowladge sharing – all for best colaberation”.

  • Hello Garber, Thank you for your deep insight! What I specially liked is how you specified that the matter of collaboration is to be able to synchronize multiple activities via ONE Bill of Material. Best, Oleg

  • Pingback: BOM: Overstructured, Understructured or Lean? « Daily PLM Think Tank Blog()

  • Pingback: BOM: Manufacturing and Engineering « Daily PLM Think Tank Blog()

  • Joop van Roon

    A BOM is a hot item in my company.
    Every department thinks that everybody is working with his BOM.
    But in the end there is only ONE BIG BOM.
    You need to have one BOM from the top to the bottom, based on unigue parts. Even vendor parts needs to be unigue parts in your own company. Even before the parts are defined on a drawing or a document, there is a need to distribute the BOM as soon as possible. Sales needs to be able to order some parts in an early stage. The BOM is now still growing at the engineering department. All our departements are using the same Parts in the BOM, but every departement is adding there own documents and attributes and also there own parts, think of tooling parts. When the BOM is ready for engineering, then the BOM is still not finished.
    – ie. Engineering put in a Flight Computer, this is for engineering one partnumber.
    But when the software of the Flihgt Computer needs to be updated, then you already have an extra mod status of the part number.
    When the Flight computer is broken, it will be de-installed and a replacement is installed. The broken Flight Computer is going to our department Component Maintenance is adding a couple of hundred parts from the Flight Computer in our system, they need to do that, so that the can repair the broken part.

    – A BOM is a living document existing of unique parts.
    – As long as your product is working, the BOM will be changed.

    So i can find myself in all above persons, because they have all the same problems.

    My company is working global, 24/7 our parts are viewed all over the world, digital through a webserver.

    I needed to go into details, to try to get to the point of the conclusion.

    i was an engineer, a senior constructor and now i am an application administrator.
    Greetings Joop

  • Joop, Thanks for sharing your view. Agree with you, the best way to describe BOM is a singe big “document/data”. However, multiple people need to work on it on-going. Unified identification and change processes (independent on department) will be key, in my view, to successfully manage it. Best, Oleg

  • Pingback: Happy 1st Birthday Daily PLM Think Tank! « Daily PLM Think Tank Blog()

  • Colleagues,
    Suppose the BOM problrm is more deep .
    You take into account ahead of all a BOM for complex products, but not for a “material type” products. My experiance in the SteelMaking industry shows some problems in using a trditional BOM for our products. The “process type product” approach is not good for using too. Suppose there must be used more flexible approach which was developed for biology as the “duality principle in a Classification Theory” – see “3. Mid-range objectives.” part of my paper – .
    Waiting for your comments .

  • Leonid, Thank you for your comment! I discussed mostly “discreet manufacturing”. Agree process industries are different. What you said about “a material type” of product sounds like more related to manufacturing/ERP space and design/engineering is less involved in my view. Does it make sense? Best, Oleg

  • Pingback: Back to basics: Should PLM Take Control of Your BOMs? « Daily PLM Think Tank Blog()

  • Oleg,Of course, you are right about different types of products from raw materials to complex devices.
    My experiance has been in metallurgy and around. But there are some common lows in some theories.
    I mentioned them in my paper “About new generations of the MIS in the XXIst Century” (it is in Russian – ). Suppose it could have some common foundations for many types of products .
    May be it will be interesting for you ?

  • Leonid. Thank you. I will take a look on your paper. Best, Oleg.

  • 🙂
    Hope there could be a helpful cooperation ?
    There is a text around in English. .
    See the “3. Mid-range objectives.” part .

    Best, Leonid

  • Pingback: Top 10 PLM Posts in 2009, Beyond PLM and more… « Daily PLM Think Tank Blog()

  • Joe Fowler

    This is really a fairly simple concept.

    1. The authorized BOM is the engineering design,
    2. However, manufacturing planning uses synthetics to separate, kit and deliver parts to assembly operations, i.e., so that the hydraulics guy on the assembly line only gets hydraulics parts and gets the parts in workable increments,
    3. The manufacturing planning BOM is a different view or representation of the engineering design BOM, i.e., the only parst that get added at this stage of the process are synthetics,
    4. The manufacturing planning BOM must be reconciliable back to the original design BOM,
    5. The as built or manufactured BOM is the representation or view of the BOM that gets delivered to your Customer. This is a physical structure and should resemble the engineering design BOM (the Customer doens care about the synthetics you used to control delivery of parts to the floor). They need a reparable parts list,
    6. And finally there is the as maintained BOM. this is the BOM representation after delivery of a product, or the sustainment view of the BOM. Many products do not capture this view since many companies are not responsible for maintaining products for 20 to 30 years like Aerospace and Defense.
    7. All BOM views can be maintained and controlled in a single PLM solution. The PLM solution should control updates to other systems that need a BOM to run their engine (like ERP).
    8. Why? Because PLM systems generally do a better job of configuration management. Most ERP solutions are late to the PLM game and traditionally are transactional based systems.

  • There are different types of Products and the PLMs types for them are different types too.
    The described approach is suitable only for the ASSEMBLY type products but not for the Metallurgy for example and for Process Type Products as well .
    There must be some more universal approach to the PLM – PLCS . Look the 3rd part of the paper –

  • Leonid, This proposal is based on the example of discrete manufacturing, in general. For metallurgical industry, which is more like “process” industry, I believe, silos can be different. However, I do believe that core of the problem- separation of Bill of Materials and need for synchronization remains the same. Thanks for your comments! Oleg

  • Joe, Thanks for sharing your view! I completely agree and understand -today’s systems are complex and everything that related to BOM is pretty much interconnected. I think, the way systemS implemented it (PLM, PDM, ERP…) is because they are trying to keep status quo of separate functional silos. The question if this is the right thing to do for the long term? Best, Oleg

  • Oleg.
    Thanks for your comments .
    Suppose the problem will be more actual soon .
    Of course the Products description must be separated from the ERP with universal using and by the producers and by customers and by salers . Do you know the eClass activity around ?

    Also there must be a “vertical” cmmon descripuion from an Invention to testing and further extended lificycle till manufacturing, implementing , reparing .

  • Leonid, thanks! I had no chance to see it, but I will take a look. Why do you think product description need to be separated from ERP (or vice versa?). Best, Oleg

  • Pingback: Do We Need Chief Excel Officer To Manage BOM? « Daily PLM Think Tank Blog()

  • Pingback: Not-Linear BOM Perspectives()

  • Pingback: Not-Linear BOM Perspectives « Daily PLM Think Tank Blog()

  • Pingback:

  • Pingback: PLM, Multiple BOMs and Cross-Functional Teams()

  • Pingback: PLM, Multiple BOMs and Cross Functional Teams « Daily PLM Think Tank Blog()

  • Pingback: 4 Reasons Why It Is Hard to Deliver MBOM in PLM? « Daily PLM Think Tank Blog()

  • Pingback: Why Companies are Not Ready for Single BOM?()

  • Pingback: Why Companies are Not Ready for Single BOM? « Daily PLM Think Tank Blog()

  • No matter if some one searches for his essential thing, so he/she desires to be available
    that in detail, so that thing is maintained over here.

  • Pingback: Will PLM manage enterprise BOM?()

  • Pingback: Will PLM manage enterprise BOM? | Daily PLM Think Tank Blog()

  • praca ciechanów

  • Pingback: Bill of Materials (BOM): process or technology challenge? | Daily PLM Think Tank Blog()

  • I really like what you guys are up too. This kind of clever
    work and reporting! Keep up the superb works guys I’ve
    included you guys to my own blogroll.

  • Pingback: Thoughts about BOM ownership()