Part/Product Management

[jrog]

Hi,

I'm a one man Hardware Engineering department, designing using Eagle, hand assembling prototypes and contract manufacturing the bulk of the items. I've been getting by with just using spreadsheets and managing my items all myself, but with 2 and 3 revisions of each product, and 3-4 products in various stages, I'm having a hard time wrapping my head around how I can control the BOMs, Part Numbers, etc., and make sense of it. I also want to be able to setup a system that I can add an apprentice/purchaser, so that I can say, "hey, I need you to build 25 more of part # xyz", and they just go to the system and start ordering the parts. I have been recommended the REDMINE system, and that I can custom tailer it to my needs, but this seems like a lot of behind the scenes work.

I have a "part numbering" scheme going, and I'm using the BOMex script for Eagle with success so far, but it's a manual effort to keep my part number lists up to date, and then I have to export a CSV file from that Excel spreadsheet to be able to run BOMex and pull in the part numbers.

Do you have an recommendations, or words of wisdom, on how I can improve my product development management, and set myself up, should I ever need to grow beyond just myself? Am I talking expensive software? Even if that is the case, I have no idea what would work best for my scenario.

Thank you

[lyndon]

Part numbers: start at "1" and increment from there. No need to get complicated like R-104-5C.D312, just 1,2,3,4...
Give each revision of a product its own part number

BOM is a comma separated text file. CAD, etc files: I just stick these things in version control. Subversion on a Linux server with Tortoise client on Windows.

That said, I worked for a small company in the early 90's where all of this was done on paper for dozens of products. We simply never saw the need to automate it. This is basically how we had it setup
1) Have a list of all parts: part #, description, average price, perhaps last place purchased from, bagging quantity
2) Kit list: (this part we automated with a BASIC program) make a BOM to build one unit and it calculates the number needed for e.g., 100 units. The kit list was combined with the pick list. So if you need to make 50 of something that had four 1k resistors and those resistors were stocked in bags of 100, it would tell you that you needed to pick 2 bags.
3) Assembly instructions, alternate parts, etc. saved in the product file
We probably had about 100 products and all this stuff fit in a single filing cabinet.

The setup that works for me these days is a simple Windows folder hierarchy:
PRODUCT
>> design notes, etc in text files under the main folder
>> CAD (put CAD files here)
>> FIRMWARE (obvious
>> SOFTWARE (for items that interface to a PC)
>> MANUF (manufacturing instructions, BOM, notes, etc)
>> MANUALS (user instructions)

The nice thing about this is you can stick the entire hierarchy of folders into version control and branch, etc if you need to make custom version. I try to use plain text, comma separated files where ever I can for simplicity.

[adafruit_support_mike]

I'll cordially disagree with lyndon on part numbers. Using arbitrary numbers leads to the classic military "ordered a case of toilet paper, got a tank" scenario (oh, those were 'S'es, not '5's!).

Simple labels work as long as you have less than a dozen things to remember, but electronics has lots of options. I use seven different kinds of resistors on a fairly regular basis (5% carbon in 1/8, 1/4, and 1/2 watt, 1% metal in 1/8 and 1/4 watt, 0805 and 0603). I limit my values to the E6 series wherever possible (10, 15, 22, 33, 47, 68), but with seven decades (1 ohm to 10 megohms) that gives me about 300 combinations to choose from. I don't have full sets of course (I'm not likely to use a 1/2 watt 1 meg resistor any time soon), but if you tell me you want a 1k resistor I'll ask "what kind?"

Thing is, all those options already have values. If I tell you my inventory numbers for two parts are R05-TH-METAL-125mW-683 and R01-0805-THICK-1004, you can work out what I'm talking about.

With chips, you have to be sure you're getting the right package.. I just built some boards designed for 74LVC1G14s in an SOT-753 package, but all I had on hand were SOT-353s. I made it work, but didn't enjoy the process.

Short arbitrary labels are good for circuit diagrams (R1, R2, ... R97), and the BOM is the dictionary where you connect those labels to descriptions that will give you enough information to order the parts you need. Personally, I try to roll the facts I'll need into my inventory codes so I don't have to get a second dictionary to connect the descriptions to something I can order.

Since I tend to order most of my stuff online, I keep links to the pages where I can order parts in my inventory along with the ID and the number on hand. It saves me another few steps of shuffling references when I need more toys.

[lyndon]

That's exactly why I don't bother to remember; I have computers for that. In fact, it's safe to say that I never use the part number at all except as a database index.

Simple labels work as long as you have less than a dozen things to remember, but electronics has lots of options.

[adafruit_support_mike]

Ah, I see the difference.. we're encoding the same information in different forms.

A question though: if you only use the part number as a database reference, do you include that in your BOM? From your description, it sounds like kind of a single-ended thing: "search the database to get the inventory number, but once I have the inventory number I don't really need it because I already have the rest of the record."

[lyndon]

Yes, the part number is on the BOM, but mainly for future-proofing. Once I could no longer hold BOMs in my head (gets kinda difficult on a board with 71 components), I first came up with a system that expected to use a relational database with highly normalized tables like any well behaved programmer would do

When I realized that I was getting ahead of myself, I created a system that has repetitive information, but is easier to work with manually. So the BOM lists (from memory): quantity, part description, inventory number, reference designations, price each, quantity needed for that price, vendor. There's a lot of information that's not needed to just pick parts and build a few units, but for doing everything using nothing more than a text editor, it's just fine.

If I actually get to the point of needing a stocking/kitting database, then the BOM that an assembler would see does not need the part number, price, etc. It only needs the part description: "Resistor 1kohm 1% 1206" so the "printed BOM" becomes a view into the "logical BOM" and I don't need to change any existing tables.

[johnnyc]

So not exactly the same problem, but similar:

I too am a one-dude engineering shop right now (with hopes of growing!). I've got bags of stuff from mouser: I often order a few extra of each part and then I keep the part because I might need it for a later project. Every six months or so I go through and try to consolidate things into different bags and always make an effort to re-use bags of parts before I order more of a certain part.

These bags are spread out through different cardboard boxes where I keep my projects and parts related to my projects. Often I'll have bags of one thing in a box, not remember where they are, and then have to reorder.

So this is a problem others must have. Mouser has great bags, both Mouser and Digikey have barcodes . . . there's got to be some software out there that helps manage inventory. I dont' want an SAP application, but it would be nice to be able to remember what I've got in stock.

And on a further note, it would be even more awesome if I had a way of organizing things so that the part came to me when it was needed. Or at least I had a fairly better idea of where to go looking for that part (ie barcodes for location could be matched with barcodes for item).

Any ideas? Anyone else have this problem?