My understanding of a BoM is that it's essentially a list of the various components required for an electronic product or module. Does this mean it could be as simple as a spreadsheet?
Are there any formal standards/templates for BoM's citing required/mandatory fields/data that it must contain? Any good samples/templates that can be referenced?
Yup, BOM is a spreadsheet.
At minimum it should contain refdes and internal part number for each component.
If you don't maintain an internal parts database, it should contain refdes and manufacturer / full part number for each component.
If this is for a small build, I put the Digi-Key or Mouser part numbers on there too, so you can order off the BOM.
I like to coalesce identical part numbers so instead of a row for C1 and a row for C2 and a row for C3, I have a row for C1,C2,C3. This also necessitates a "quantity" column. It also makes it harder to look up a given refdes since they are not in order.
The BOM will be used by the guy ordering parts and the guy running the pick and place machine, so add any annotations you want those folks to see.
Oh, and the BOM is useful for costing if you add component prices on there. Again, this is for small runs. Big runs will use more sophisticated accounting.
Yes, a useful and common way to express a BOM is a spreadsheet. No, there is no standard format. Individual companies may have internal specs and forms for BOMs, but there is no independent standard, at least that enough people follow to make is useful.
I use the following columns in my BOM spreadsheets:
A: Total quantity of this part required for the complete build. The A1 cell contains the number of units to be built. The remaining A cells are derived from A1 and the quantity per unit (column B).
B: "Qty". Number of parts required per unit.
C: "Designators". Component designators, like R1, C5, etc. The cell for each line lists all of the designators for the instances of that particular part within the unit.
D: "Desc". Basic description string, like "Capacitor, unpolarized", "Resistor, fixed", etc.
E: "Value". More detailed value beyond the basic description. This might be "12 Ohms, 2 W, 1%" for a particular resistor.
F: "Package". The name of the package for that part variant, like "SMD-0805", but sometimes proprietary package designations if it's not something standard. This defaults to the name of the package in the Eagle libary if I don't explicitly set it.
G: "Subst". Yes or no to indicate whether substitutions are allowed. For example, you probably want to let purchasing buy whatever 1 kΩ 0805 5% resistor they can get that week, but the microcontroller had better be exactly the one you specify.
H: "Manuf". Manufacturer name, usually blank for generic parts.
I: "Manuf part #". Manufacturer's part number.
J: "Supplier". Example supplier name, like "Mouser".
K: "Supp part #". Part or stock number of the supplier listed in column J.
L: "$Part". Cost per part.
M: "$Board". Cost of all of these parts on a whole board or unit. This is automatically derived from B and L.
N: "$All". Cost of all of these parts for a whole production run. This is automatically derived from A and L.
I also have a few lines at bottom. These are for the bare board itself, kitting, manufacturing, testing, and delivery to stock. The purpose of these additional lines mostly to allow summing up the complete cost of a production run.
I would attach a example, but there doesn't seem to be a way to do that. Here is a screen shot of one such BOM spreadsheet for something internal, so I'm not giving out any customer information. To be able to read it, you probably have to save the image to disk, then view it externally. This site resizes images to some maximum width for display in a message.
In this case I never filled in the per-part costs, so this doesn't show overall costing.
Typically with integrated layout environments when you create the schematic you choose components from the library, and/or add your own. You can also indicate preferred suppliers and costs. One of the tools is the export of BoMs, and its automatic updating with schematic changes, in various formats including Excel.
Here is an example:
That is from this site (if you want to see the whole thing): Arduino Uno at SOLDERPad.
