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, contributions or suggestions to ryan@vpd.io and jesse@bommer.io.
Documentation is a perpetual challenge I see companies working on hardware struggle with, from the earliest hardware startup to larger companies. A lot of my work at Vinyard Product Development (VPD) supporting hardware development has revolved around the kind of “meta-documentation” that often falls through the cracks since it doesn’t export directly out of design programs — the product requirements document (PRD), bill of materials (BOM), quality plan, and master services agreement (MSA) to name a few. They are important because they are some of the fundamental documents that define a product and your company’s approach to producing that product.
It’s for that reason that I’ve been talking with people for the last year about a project I’ve wanted to launch around “open sourcing” templates for hardware development that cover the basics of these kinds of documents. As I started working on this project and collaborating with Bommer on making a BOM, we looked more into the existing templates and examples out there and realized that a lot of the value we could bring to the hardware community was not in the document template itself as much as defining more of the terminology, jargon, and real world usage of the terms and implications of the document in a glossary. We also made some example BOMs to make those all clearer. We are here today to launch The Hardware Document Toolkit with the first installment — Bill of Materials.
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.
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 non-obvious “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 the right cake by listing flour quantity and any specific properties you need from 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 communication 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 always implemented 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 guide 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 workflow. 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 real 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! We’d also love to know any other hardware documents you’d like to learn more about next.
To contribute, please reach out to ryan@vpd.io or jesse@bommer.io.
About the creators
Ryan Vinyard (Vinyard Product Development, ryan@vpd.io) is 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. Ryan has previously posted on Medium about Leaving the Valley for a Walk in the Woods and 1 Year Back in Hardware.
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. Please share, contribute, and help us make it better!