• Jesse

Introducing the Hardware Document Toolkit - Bill of Materials

If you just want to jump in, here’s the link. See the “How to use“ tab to get started. Please send any questions, feedback, or suggestions to ryan@vpd.io and jesse@bommer.io. If you have contributions, please see below on how to contribute.

Hardware is hard enough without having to worry about whether your documentation is at the right level to capture your plans, your intent, and your product. Bommer has worked hard to publish tools that make it easy to capture and export a bill of materials, straight from your CAD environment, to free up valuable engineering time and resources. We often get asked, though, what makes a good bill of materials? It’s a great question, and one to which we should have an answer. We're proud to share that Bommer has teamed up with Vinyard Product Development (VPD) to launch the Hardware Document Toolkit with its inaugural tool: Bill of Materials.

BOM (Bill of materials) is a great inaugural tool for this toolkit, as the consequences of getting your BOM wrong can range from a minor purchasing inconvenience to your product catches on fire. Our goal with this tool is not to provide the “end all” BOM that’s going to work for everyone; rather, we tried hard to explain what goes into a well-designed bill of materials, why the columns, properties, subtotals, and the like are so important and useful, and then we laid out examples of a basic ME BOM, EE BOM, and ASSY BOM to show these concepts in practice. Our goal for the user of this tool is to save them time and heartache, but also give them the necessary knowledge and power to make their BOM documents work for them.

Example assembly BOM with added costs
Example assembly BOM with added costs

Is this another BOM template?

No, this isn’t just another BOM template. We see many awesome, useful standard BOM templates out there in the hardware community (like the excellent Dragon Standard BOM) and we are not trying to just add one more to the pile. We do see some room to improve the collective understanding around bills of materials, though, because the problems with templates is a) they present one “world view” on what a bill of materials should be (of which there are many) and b) they often present “what” to include in a BOM without “why” it is important. This is why we ultimately decided to build this toolkit; it starts with a glossary of key terms and common BOM properties, explains when and why they may be useful, and illustrates their usage through a series of “bare minimum” example BOMs. We hope that you, the reader, can use this to dial in your bill of materials and your manufacturing processes, with an understanding of why what you’re doing is important.

Snippet of the bill of materials glossary
Snippet of the bill of materials glossary

How do I use it?

Easy! To get started, click this link to open up the Google Sheet document that contains the tool. We’ve put together a comprehensive starting checklist in the “How to use” tab in the document. Follow the instructions there and you should be good to go.

Thoughts we’d like to share

As we were building this tool, there was a lot of discussion about BOM best practices and pitfalls. As it turns out, there are a lot of unobvious “gotchas” when working with documentation! Here’s a list of some of the most important thoughts we had during this process. If you see something missing or want to weigh in, please get in touch (see “How to contribute” below).

Note: we assume some knowledge of design or manufacturing and use acronyms and terms that are familiar to people in the space. If you find something you don't understand, that isn't in our glossary, please get in touch. We'd love to help.

CAD is not enough on its own

It’s tempting to assume that since your CAD model contains your design data, it’s all you need to send to your integrators, manufacturers, or clients. Unfortunately, that’s frequently not the case. CAD without a BOM is like a recipe for a cake without the list of ingredients at the top; sure, you could probably figure out how many cups of flour go in by reading the steps, but it would be a lot easier to ensure you get what the right cake by listing flour quantity and any specific properties about that flour upfront. The same is true with your design files and your BOM (and other documentation you will need along the way).

Include all necessary information

Your BOM is a communications tool, first and foremost. It will be used to communicate your design intent (through part selection, material and tolerance properties), supply chain plan (through vendor/distributor information, manufacturer information), product costs, and lead times; all of which are critical to ensuring that your product is brought to market, at the quality standards you’ve established, at the cost you’ve expected, so that you can sell product and make money. If your BOM doesn’t contain all of the necessary information, you risk decisions being made outside of your control. That information needs to come from somewhere, whether it be you or the manufacturing engineer trying to map their stock to your product; it can also manifest as delays with lots of back-and-forth between you and your manufacturer as they try to fill the necessary blanks.

Include only necessary information

Somewhat surprisingly, it’s not only possible but fairly common to over-specify your BOM. The potential for risk isn’t as high as under specification but it is still tangible: your engineers and purchasers now have to fill out a lot of information (though tools like Bommer can greatly help with this), and you remove potentially beneficial flexibility from the system. As an example, maybe it doesn’t matter what coating is applied to your fasteners; giving your manufacturer the latitude to pick what’s easiest in this specific case can reduce cost, time to produce, or supply chain risk. Within your BOM, you can do this by omitting a column, or if you need row-by-row flexibility, designating a value for “do not care” or “any”.

Remove ambiguity wherever possible

Even if you have all the necessary information, and only the necessary information, you can still create situations where your BOM is not a clear communication of your product design intent. In these situations, you may need to add more (possibly redundant) info, to make crystal clear what you’re trying to communicate. We show a couple of examples in our BOMs where this can be useful.

On lines 1.2.7 and 1.2.8 of the EE BOM example, we have two lines for Adjustable Output Low Dropout Voltage Regulator. These items have the same description but refer to two different manufacturer part numbers. Technically, if you look at the whole BOM, all of the information is there; the part numbers are accurate for each line item, so someone reading this BOM would hopefully know those are separate parts. Someone just skimming the descriptions, however, may incorrectly think these are the same parts; we may advocate enhancing the description to include one or more differentiating characteristics so that there is nothing left to chance. This is, unfortunately, a common problem when BOMs generated from a part library or database (especially one built up over time, without clear standards for that whole time); the right way to fix this (we think) is in the source data, not in the BOM so that future users of these components don’t run into the same issue.

A similar situation exists on item 1.2.12 on our EE BOM, Ferrite Beads, EMI suppression, SMD, but this one has a fix applied. We added SMD to the description; despite the fact that almost every other component on this board is SMD, ferrite beads are not normally included this way. As a result, it’s beneficial to add something to the description to remove the potential for mistakes here.

Capture your second (and third, etc) sources (or alternates)

This is really a supply chain tip, but here’s how we think you should represent that stuff in your BOM. Building in redundancy by designating alternate parts, manufacturers, and/or distributors will help ensure that if your primary source for a part runs out of stock your manufacturing line will not be interrupted. As an example, see the OP AMP (item 1.2.26) in the EE BOM example. We happen to know that the LM358D has several “sister components” such as the LM258 in the same line, and on the same sheet, each with slightly different electrical or physical characteristics. If the engineer with the most relevant knowledge can capture these alternates at design time, it makes it easy to react to shortages or other interruptions without interrupting your manufacturing.

Capture all of your costs and risks

It’s important to have the final costs output from your BOM be meaningful and capture as many of the cost adders and supply chain risks as possible. Costs like MVA (manufacturer value add), logistics, and the like can add up, and you can run into trouble if you don’t properly account for them. In our example assembly BOM, when looking at COGS (cost of goods sold), you can see how the component costs increase by almost 80% once the additional costs are factored in. This is the number you want to focus on because this is the actual cost to produce your product.

Your BOM can also be a place to capture risk in your supply chain by assuming higher placeholder costs until you have quotes, sometimes even using a blanket $1,000 cost for unknown components to force your team to recognize these and pursue quotes and cost-downs.

It’s ok to bend the toolkit (a little)

Your BOM is a communication tool, to borrow a line from above; as a result, it would be impossible for us to capture all of the nuances of a communication tool in one toolkit. We’ve tried to lay out a simple roadmap but as you look at your own BOM practices, you may feel the need to deviate; that’s ok! It’s ok for your quantity to include “spares” if it lets your operations team properly capture total cost to build. It’s ok for your mechanical engineering BOM to only capture vendor (but not cost) information, or a single vendor, or no vendor information at all if that gets handled downstream from the engineer's desk. What’s most important is understanding what should not be bent (e.g. unique part numbers) and getting everyone on your team to agree on the structure and semantics that you have decided on.

Automation is key

As you can see, your BOM is a lot to think about, both in designing the document for your team to use and when detailing it out for a specific product. Automation software like Bommer can greatly reduce the amount of time you have to think about your BOM. The goal with any automation should be simple repeatability once you have it set up; too frequently, setting up an automated system will take so long as to nullify any time savings from the tool. Bommer strikes this balance by providing immediate value and simple customizability. You can install the software and immediately start editing or exporting BOMs like our examples, complete with auto-generated thumbnails (if you want them). You can then progressively tailor your BOM using in-app configuration tools to capture what you need when you need it.

How to contribute

This tool is an MVP and can be made better with your contributions. So please use this, share it, and add to it and make it your own. This document is released openly under "Creative Commons Attribution-ShareAlike 4.0 International". All contributions will adopt the same license. Really, all we ask is that you attribute the original creators and let us know your thoughts too as we want to grow this project!

To contribute, please reach out to ryan@vpd.io or jesse@bommer.io.

About the creators

Ryan Vinyard (ryan@vpd.io) is the founder of VPD and a consultant supporting hardware development through PM work, documentation, and process facilitation. He has a background in energy, transportation, and consumer products, and experience ranging from early development to manufacturing. Ryan typically engages as a part-time Director of Hardware to help a team accelerate hardware development with a focus on documentation such as Gantt charts, PRDs, BOMs, and comparison matrices. Read more from Ryan and VPD by clicking here.

Jesse Rosalia (jesse@bommer.io) is the co-founder and CEO of Bommer and the creator of the Bommer suite of bill of materials automation software. Bommer plugins live in your CAD application and automate the most tedious aspects of building, capturing, and exporting your bill of materials. Companies of all sizes use Bommer to simplify their workflow, freeing up valuable engineering time while avoiding common pitfalls and errors. Jesse has over 20 years of experience in software development and architecture, including 2 years as the CTO of a small robotics startup where he also dabbled in mechanical and electrical engineering.

This work is licensed under a Creative Commons Attribution 4.0 International License.

201 views0 comments

Recent Posts

See All