1
\$\begingroup\$

I'm looking for a good way to manage BOMs for electronics assemblies in a production management system. I would really like to hear about how others manage BOMs in a professional setup.

I'll start by describing our current situation an why it doesn't work very well.

We are using the OrCAD Capture CIS/PCB Editor for schematic capture and PCB Layout. The BOM generated by Capture is imported into Microsoft Dynamics NAV, which we use for production management/planning, economics and stuff.

The BOM is stored in NAV as a summed list. I think it is called as instances in OrCAD terms. Each part instance is stored with a part number, what quantity is needed, an the RefDes of the occurences in one or several text fields.

NAV has a certain amount of space in each field. If the list of of RefDes' is too long, it is broken into several fields. The list can be broken in the middle of a RefDes, so the first characters is at the end of one field and the rest in the beginning of the next.

That way is really good for procurement, since they know how many of each part they have to purchase.

The problem is when we generate a BOM for the external EMS. They need a BOM with part numbers and RefDes, so they can map the correct parts to the pick'n'place file for the assembly. The BOM exported from NAV is a procurement BOM in a weird excel sheet where the RefDes is listed in several cells like described above.

Problem is that the EMS has to manually combine the cells, to get a complete list of RefDes. This is tedious and prone to errors since it is a manual process.

There must be a better way to do this.

It could be a problem our NAV configuration/setup, but my current conclussion is that NAV is pretty useless for electronics production.

I have seen systems where each occurrence of a component has its own line with partnumber and RefDes in the BOM. This would be a manufacturing/assembly BOM.

It satisfies the need of the EMS, and i bet the "system" can sum the the occurrences of each part so procurement is satisfied as well.

What are your experiences with managing BOMs for production and procurement?

Which systems do you use?

How are the the data stored (by instance or occurrence)? And why?

Is one way preferred over the other?

Any thoughts are appreciated.

\$\endgroup\$
  • \$\begingroup\$ Sounds like the tool needs to tolerate variable-length strings. \$\endgroup\$ – analogsystemsrf Apr 4 '19 at 8:55
  • 1
    \$\begingroup\$ Are you using a product data management or life cycle management tool? \$\endgroup\$ – Peter Smith Apr 4 '19 at 9:05
  • \$\begingroup\$ @PeterSmith I would guess that Microsoft Dynamics NAV is an ERP system. It is primarily made for economics. I'm not sure how well suited it is for managing an electronics production. \$\endgroup\$ – Peter Karlsen Apr 4 '19 at 9:16
  • 1
    \$\begingroup\$ We put our BoMs in erp , which plays nice with the production planning and purchasing systems, but requires semi-manual entry from PLM. I find in this space it is a matter of compromise between different types of pain. Single source solution (expensive) specifically for electronics and small mechatronic assembly is provided by some companies, notably altium which has PLM built in to the PCB EDA \$\endgroup\$ – crasic Apr 4 '19 at 15:58
2
\$\begingroup\$

In a production environment (and particularly electronics) you really need both ERP and PLM systems. Good discussion here (A bit of self advertising involved, but the core discussion is ok).

This answer is a bit more than just the BoM as that is one (albeit very important) part of the puzzle.

There are version control systems available for some CAD systems but that only controls the output of the tool itself; if you have numerous products at different revisions or perhaps variants, a PLM tool is essential as it is if you are using (as is likely) multiple tools for a complete product.

Most (all?) PLM tools permit you to freeze a complete product datapack in (usually) arbitrary formats (include CSV files and such).

A typical flow:

CAD: implement required changes / updates / release data.

At release, Datapack(s) from CAD tools(s) -> PLM tool. For good reasons, this is known as a single source of truth.

The PLM tool can have all the data necessary for EMS vendors (who are quite happy with CSV data, incidentally, which supports arbitrarily large text fields) as well as supporting the data for your ERP system.

In such a data flow, the PLM becomes the master repository for released data.

If you do not yet have a PLM system, be warned that implementation can take many months and requires both a lot of planning as well as explaining to people why their ways will change and the benefits of doing so.

Having noted that is not an easy task to implement a PLM system, once it is in place it can be worth it's weight in gold for many reasons; product level version control is a major item here, but if a big customer wants to audit your processes it becomes the star of the show.

I have used a number of systems, from the very expensive and heavyweight TeamCenter to a lighter weight tool known as DDM.

The typical data storage that has kept my suppliers happy over the years for electronic PCB assemblies is something like this:

Part description: footprint: Quantity: Ref Des list (in a single cell): Manufacturer: mfr part number.

There can be more, but in my experience that is a fairly common practice.

The complete electronics manufacturing pack contains a great deal more, of course.

My packs consist of:

Fabrication data for PCB - gerbers, ODB++ data (preferred by many higher end suppliers), drill data and a PCB fabrication master which contains information that is not listed in other formats: a snapshot of part of one such is below:

Typical fabrication master

An assembly pack:

Pick and place data (not required if your assembler uses ODB++ data)

Bill of materials in CSV format (as above).

Assembly master (typical output below)

Test requirements (I usually call that out on the assembly master).

Typical assembly master

Note that I specifically list the Bill of materials (with revision) to be used.

For the BoM, CSV data is fine for assemblers; I am showing what a properly implemented PLM system can contain to support both the assemblers and ERP.

\$\endgroup\$
  • \$\begingroup\$ Thank you for your answer. Unfortunately we don't have an PLM system. I think it is needed to run a professional electronics production. We do encounter problems with version and revision control. This is a cause of many headaches and misunderstandings. \$\endgroup\$ – Peter Karlsen Apr 4 '19 at 11:08
  • \$\begingroup\$ Added a note on the major benefits of PLM systems. \$\endgroup\$ – Peter Smith Apr 4 '19 at 11:27
  • \$\begingroup\$ Stariting in 2018 I have had global EMS company tell me they prefer to see a single odb++ , your entire production package can be embedded in single ODB++ including BoM. With assembly and Fab notes as layers or optionally as separate PDF. I have also been under impression And using odb++ as a Gerber alternate, but it is designed to replace your entire release package. It's viable to be a single single source of truth . Great answer! \$\endgroup\$ – crasic Apr 4 '19 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.