Jan 292014

We received the following question about Bills of Material (BOMs) from a product development manager:

QUESTION: “How does one balance the need of a BOM to be expedient and fast for real world use, while still trying to make an investment in a universal and reusable bomb?”

That’s a great question for product development teams. Our answer is a series of steps:

STEP 1 – Admit it’s a problem

It may sound like the trite stuff of a 12-step program, but the first step to recovery is admitting you have a problem! There’s nothing wrong with having a problem, and in fact, solving problems is what we went to engineering school to do, didn’t we? Some people will tell you that you can have it all (usability and re-usability) in your BOM structure instantly and without conflict. That’s delusional, but we can make incremental progress over time.

STEP 2 – Define the problem

Going back to our school days, the first thing we would do in our statics or dynamics homework would be to list the forces that are active. There are at least two forces in play, and for the most part they are directly opposed to one another:

  1. Functional Universality / Re-usability – we would like to have a universal BOM that can be re-used and easily modified to work for each product.
  2. Expediency / Practicality – We have to ship the product out the door on a certain timeline. The BOM has to be easy enough to use that we can modify it quickly so that we can get our “day-job” done.

STEP 3 – Recognize that the equilibrium point is dynamic over time

Where we start out on our journey of practicality vs. universality in the BOM is not where those forces may end up in the future. The equilibrium point between those forces will change over time.

In Figure 1, we see that initially the force of expediency/practicality is stronger. Therefore, at first our BOM will mostly focus on the needs of today, rather than the needs of tomorrow. However, over time we can reduce some of the immediate pressure to ship product, because we have invested in the bill of material. The equilibrium point is driven to the right on Figure 1 toward a more universal BOM, which is still practical and expedient for our daily use.

Figure 1 Balancing BOM Usability vs. RE-usability

Figure 1 Balancing BOM Usability vs. RE-usability
Click to ENLARGE

STEP 4 – Knowing the equilibrium point at any point in time

How do we know how to balance the two forces at any given point in time? The recognition of a third force may actually help us simplify the problem. That force is the needs and goals of our management team in the company.

The management team is certainly interested in shipping the product for immediate revenue and profit. However, they are also responsible for stable growth of the company over time. Management needs are a downward pressure that we can use to our advantage, just like the Romans did with their brilliant discovery of the arch.

Figure 2 represents such an idealized arch. The forces of the needs for universality vs. practicality are pushing against one another. Without a third force, certainly the structure would tumble. However, with the third force of management needs, it’s much easier to balance the two forces and know where that equilibrium point is at a given point in time.

Figure 2 Balancing BOM Usability vs. RE-usability with Management Pressure CLICK to ENLARGE

Figure 2 Balancing BOM Usability vs. RE-usability with Management Pressure

Figure 2 – The down force of management decision making

STEP 5 – Make sure you have a solid keystone

What is the keystone in the arch? The keystone bears the pressure of all three forces and balances them. The keystone in our process is a thoughtful and dynamic owner of the bill of material structure. This might be a consultant, a specific person who specializes in product lifecycle management, or the product development manager. Whoever it is, this person or team should be able to view the opposing forces not as forces that will crush them, but as forces that will help them balance each other.


As with any problem in the real world, unfortunately we’re not dealing with a precise science here. However, hopefully this expansion of our framework will be a way to think about making progress, as you balance usability vs. re-usability in your bill of material structure.


This post is 3rd in a series of posts on ENGINEERING.com about Bills of Materials (BOMs). The first outlines the importance of managing the BOM: Dr. Strangepart: How I Learned to Stop Worrying and Love the BOM. Next is a framework of how to build re-usability into the BOM: Form, Fit, and Function – A Framework for your Bill of Material.

  11 Responses to “Opposing Forces in your Bill of Materials”

  1. Eric:
    I guess one question that has to be asked is “how will the BOM be employed?”
    If the BOM is to be employed for product costing, and you are not obsessed with four characters to the right of the decimal point, I recommend using what I call Capabilities (i.e. propulsion) and Functionality (i.e. electronics) modules with Like-kind products (i.e. same-as a F-150) or my acronym of CFL; I call this tool the sledge hammer approach to establish a product cost range.

    I have established a large library of CFLs which I then perform a modified Monte Carlo routine to identify key inputs that are financially material and “play around with them until the output “makes sense”…and viola, you can get to a product cost that will be within +/-15% of final costs…of course this is a highly simplified explanation of what is performed.

    It is my opinion that the CFL approach CANNOT be performed by a financial accountant; a managerial accountant would be the right person to populate the CFL and perform the Monte Carlo routine…but of course that is only my opinion

    • @Ron,

      Yes, that is a separate but interesting thought. In the article, I was focusing on the BOM in a more generic way, i.e. I was not trying to specifically focus on Product Cost Management. However, PCM is one of the goals that the Form, Fit, Function framework in the previous article to this one would support.

      So, your CFL monte carlo technique sounds like a stochastic version of a should-cost modeling technique, right?

  2. Moderator re-posting from linked-in:

    George Spiller, owner at Design for Profit Inc SAYS:

    This is wonderful information and I am not sure where my comments fit into your series. The creation of a bill material has the best saving potential if it is created first, before any effort is expended creating engineering detail. It is not possible to recover engineering design, development, prototyping, testing, tracking, etc costs on parts that are eliminated to create a product that is cost attractive in the marketplace. Waiting until it is possible to sum a list of exact quoted component prices usually is too late to achieve the needed price target. This early creation of a bill enables the establishing the cost impacts of a proposed offering while their is still time to minimize new part tooling costs, quoting costs, launch costs, service part costs, obsolesce cost etc.

  3. Moderator re-posting from linked-in:

    Michael Roman, Business Capabilities Architect – Manufacturing Practices, Inc SAYS:

    This is UTTER B.S. to the Nth degree. BOMs have financial, planning, procurement and safety considerations. To think that list should be appended to include “reuse” shows an utter misunderstanding of their planned purpose AND an even more ignorant understanding of how to properly utilize a business management system. Excuse me while I go throw up!

    • @Michael Roman

      So… I take it you have some disagreements with the article? :)

      While I agree with you that the Bills of Materials certainly are structures that should support the goals of the organization with respect to profit, planning, safety, and sourcing, exactly why is aiding in re-use of part so violently verboten?

      Furthermore, I don’t believe that it is only me that is talking about re-use in the BOM. I assume that you also have a big problem with all the ERP and PLM software companies, as well? After all, they talk about re-use all the time w.r.t. the BOM. Here is just one example with 5 seconds of searching on Google:


      Some have even claimed that part re-use is the main value proposition on which PLM was sold, at least initially.

      But, you obviously have strong feelings why this is so wrong. I just understand it. Please say more.


      • http://www.linkedin.com/groups/Opposing-Forces-in-your-Bill-3758755.S.5834709350882500608?view=&gid=3758755&type=member&item=5834709350882500608&report%2Esuccess=8MrE42jy5bkZyM05ySn-QVbW0ACEtNqFKqJGpCD3uGdEgNE4QccGFVuXyHNN2SPcKQhOfdO3TImatB2Imn9Qc8XGuO1RkBVcqwPXzfD3gydEgm4VZqZplT89Tf-atBVFbK2pzI89ukMx0WcFKczOdV8f0klxth44WQhLz4ufgdtYgNmlWwmnF2so0IUtgLZlW7-LokCKITE

        Michael Roman SAYS:

        Sorry for the delay. I have a number of organizations I do volunteer work with and this is a focus for some of that. The objections come from the fact that ERP Systems have a product configurator specifically targeted to build a “general BOM/Routing” from which sold items can be easily cloned. IN ADDITION, Engineering Change Management is based on an ITEM, which has a BOM/Routing attached, based on the Engineering Change done to the BOM or Routing. The basic assumptions that comes with proper use of an ERP System is that a Part (ITEM, SKU, etc.) has a UNIQUE form, fit, and function. That definition is sacred to the use, storage, cost, form, fit, and function of a purchased or sold item. Sorry if I came off a little strong. I work with organizations to fix, find, or implement their business management system (ERP). Examples like this are all too often at the crux of ERP System deployment problems that I regularly see.

        • Michael,

          OK, I understand your point with “basic assumptions that comes with proper use of an ERP System is that a Part (ITEM, SKU, etc.) has a UNIQUE form, fit, and function.” I guess I am not sure how an intelligent PN (IPN) would have to violate that. It may be the the part would have more than one usage (e.g. same part used on multiple products), but that would not violate that, correct?

          BTW – Being a founder of 2 enterprise software companies (aPriori.com and EndAround.org), I share the rage of all these companies insisting that they are just so “special”. They customize these systems to the point that they are hideously expensive to maintain and they lose a lot of the value of standardization and simplicity.


          • Michael Roman SAYS

            Now I understand the point you are moving toward and understand we agree on those areas – now to the crux of the matter.

            Most ERP Systems allow “internal data”, like Product Type, Product Code, Description, material type, etc., to serve as the “intelligence” for what the part number means. Part numbers serve to function as an “index” into the database. Part Numbers exist for the “life time” of the organization.

            It is my experience that companies change the “intelligence” of part number schemes throughout the life of the organization. Such acts erase any benefit for the “intelligence” because they also have to remember, “Oh it is a 1988 part” or “that is a 1999 part”. That means, “function (i.e., screw, bolt, nut, washer, etc.), then head type, then length, then outside diameter, then material, etc. and not the 1999 intelligence that means all of the above but drop the length and added two material types and without the abbreviations anymore”.

            One company for which I worked change “intelligence” schemes three times in the almost 8 years I worked with them (electronics industry). It finally took a fellow who lived more than 60 miles from our office and carried a brief case for a living to help the company understand the folly of their method (i.e., a consultant). I like simplicity and try to “remember” as little as possible, because I am lazy, probably.

            I understand the simplicity you seek. Put intelligence into the data and not the indexes into databases is where that “intelligence” belongs, in my humble opinion and my humble experience.

          • @ Michael, well, our prefix at Ford was for the model year, P221 was 2004 F-150. U137, I think was the first Excursion, which I was privileged to be on the launch for. We were not confused, but maybe this just uniquely works only in the automotive industry.

          • Michael Roman SAYS:

            As a teenager, I did some for Ford’s on weekends, adding the BOMs through an IBM card punch system. I think Part Numbers were 24 characters, but, that was in the early 1960s. My question is what if Ford created another truck called Fire 150 and kept the F-150. Would the “new part” be Fire-150 or F-150? What if they used Fire-150, what if the length exceeded standard length in number of allowable characters? Would they just do away with some of the “excess” characters? If so, how? Would that NOT mean they is more than one “standard” to create and remember the definition of a Part Number? All I am saying is that information belongs in the data and NOT in the database “key”. I would more than support, accessing (indexing) part numbers by a standard database element, like a description. With most current ERP Systems, field size is extendable but not the database key length and almost any field can be an index to retrieve data.

 Leave a Reply



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Skip to toolbar