Which software should manage your BOMs? The 5 families of tools, and the one that fits you

The question to ask before comparing anything

"Which software should manage our BOMs?" is nearly always the second question. The first one, the one that determines the answer, is: which BOM do you want to manage?

The one coming out of design, or the one used to build? They don't live in the same place, aren't produced by the same people and don't share the same structure — I detailed why in eBOM vs mBOM. Many companies buy a tool that's perfect for one while believing it solves the other's problem.

The 5 families of tools, without indulgence

The useful reading of this table isn't "which is best" but where your pain point actually sits today. If your engineering BOMs are wrong, an ERP won't help. If purchasing receives the right list but too late, that's not a PDM problem.

Is Excel still enough? The 6 signs it isn't

Let's be blunt: the spreadsheet remains an excellent BOM tool for a small outfit, a stable product and one person in charge. It isn't professional malpractice, and I regularly advise clients not to leave it too early. Six signs, however, indicate it has become the problem:

• 1. Two people give you two different versions of the same BOM, and each is certain theirs is right.
• 2. A part modified in design takes more than a day to reach purchasing — or never gets there.
• 3. Nobody can say which BOM version was used to build the machine delivered last year.
• 4. The same part number is described three different ways depending on the line, and the ERP creates three separate items.
• 5. A BOM error has already caused a pointless purchase or a production stop — and it wasn't the first time.
• 6. The file can only be open by one person at a time, and that person is on holiday.

Three signs out of six and the subject is open. Five, and it already costs more than the solution — you just need to quantify it, which the method in the article on project cost makes possible.

The 7 criteria that actually decide

Here's the grid I use with clients. It beats a feature comparison, because it starts from your situation rather than from the market.

• 1. The link to CAD. The engineering BOM must be extracted from the assembly, never retyped. If the tool can't read your design files, someone will key it in — and get it wrong.
• 2. Change management. Can you see what a change implies before approving it, and who approved it? The most discriminating criterion, and the one most often missing from requirement lists.
• 3. Levels and multiple occurrences. A part appearing in three sub-assemblies must remain one reference, counted three times — not three items. Many simple tools fail here.
• 4. Units beyond the piece. Grams of glue, metres of profile, litres of paint: if the tool only handles integers, your mBOM is wrong from the first consumable.
• 5. ERP integration. Which way does data flow, who is authoritative, and what happens when both sides edit the same line? Ask to see the conflict case, not the happy-path demo.
• 6. Rights and traceability. Who can change what, and does history outlive the people? That's what turns a list into evidence that holds up in an audit.
• 7. Data exit. In what format and at what cost do you get everything back if you change tools in seven years? Test the export during evaluation, not after signing.

What I recommend, by profile

The 4 implementation traps

• Importing data without cleaning it. Duplicates, approximate descriptions, reused part numbers: the tool will faithfully carry them over and produce wrong results faster. Numbering comes first.
• Choosing on a demo. Every demo works. Ask to load your BOMs, with your awkward cases — the multi-body part, the variant, the item purchased under two references.
• Forgetting who does the data entry. A tool that shifts the entry burden onto an already overloaded person will be bypassed within three weeks, however good it is.
• Neglecting the change case. Every tool handles a brand-new BOM well. Ask to see what happens when a part used in twelve products changes revision: that's where the differences show.

FAQ

What's the best BOM management software?

There isn't one in absolute terms: it depends which BOM you want to manage. For the eBOM, a PDM linked to your CAD; for the mBOM, your ERP; for both linked with change management, a PLM. Start by identifying which one hurts today.

Can you manage BOMs in Excel?

Yes, and it's even sensible for a stable product handled by one or two people. It stops being sensible as soon as several people edit it, changes are frequent, or you must prove what was built last year.

Isn't the ERP enough to manage BOMs?

For the manufacturing BOM, often yes. The problem is upstream: the ERP doesn't read your CAD files, so the engineering BOM enters through manual entry or a flat import. That's the link to secure, not the ERP itself.

What does a BOM management tool cost?

From zero, if a vault is already included in your CAD licenses, up to a company-wide project for a full PLM. In every case, licenses weigh less than configuration, data migration and training.

How do I migrate my existing BOMs?

In batches, after cleaning, and never unchecked: systematically compare a few BOMs before and after import. The full method is in the migration guide.