Help me figure out a good organization system for work related part attributes

I work at a growing company, which has been in business 100 years or so. They know a lot of stuff, but it's mostly tribal knowledge. I seek to create an information database for the various widgets that go into a part.

We know widget type X has been built y different ways out of z different materials, and these were the results for each. If you're going to make a new one, start in this area.

I don't want this to just be an Excel spreadsheet if possible, but I do not know what's out there. We use Sharepoint for, uhh, sharing, things.

I am open to ideas, freeware desired.

Can you be more specific re: widgets that go into a part?  Are these features of a given part that can be done a-la-carte?  Attributes?  

Do you guys have an ERP? This capability might already be in there.

Keith Tanner said:

Do you guys have an ERP? This capability might already be in there.

Yes, and not a good idea here. This is for design engineers only. Sort of a brainstorming tribal knowledge database.

ProDarwin said:

Can you be more specific re: widgets that go into a part?  Are these features of a given part that can be done a-la-carte?  Attributes?  

 

Soo no. I can't. I'll pretend it's a different product.

We make brake systems. We make caliper pistons, calipers, seals, rotors, and brake hoses. We include bolts too. Each one of those parts has been made from five-ten different materials. The clearance between the caliper piston and bore has varied. The brake fluid has varied. The application has varied. We've used a few different types of rubber in the seals. etc. All of which has different levels of success in the application it was designed for.

Not the military way, that's for sure. 

"Threaded rod with hexagonal head, 13/34ths head size, hardened radon steel, fine pitch, 11.2 mm length, NPT 1/2-40 coarse thread"

tuna55 said:

ProDarwin said:

Can you be more specific re: widgets that go into a part?  Are these features of a given part that can be done a-la-carte?  Attributes?  

 

Soo no. I can't. I'll pretend it's a different product.

We make brake systems. We make caliper pistons, calipers, seals, rotors, and brake hoses. We include bolts too. Each one of those parts has been made from five-ten different materials. The clearance between the caliper piston and bore has varied. The brake fluid has varied. The application has varied. We've used a few different types of rubber in the seals. etc. All of which has different levels of success in the application it was designed for.

How big is the scale, both now and projected?  Is it just for expert/trained people to look up stuff, or is it going to feed into some kind of other programmatic system?

You said you don't want Excel, but if it's small-ish (say less than a thousand entries) and there's no requirement for automated access then the simplicity of a spreadsheet is appealing.  Databases are a lot more complex to access and update, you wind up needing to write interfaces to them, etc.  With Google docs (or presumably the cloud-based Office) you've got all of that stuff solved for you.

codrus (Forum Supporter) said:

tuna55 said:

ProDarwin said:

Can you be more specific re: widgets that go into a part?  Are these features of a given part that can be done a-la-carte?  Attributes?  

 

Soo no. I can't. I'll pretend it's a different product.

We make brake systems. We make caliper pistons, calipers, seals, rotors, and brake hoses. We include bolts too. Each one of those parts has been made from five-ten different materials. The clearance between the caliper piston and bore has varied. The brake fluid has varied. The application has varied. We've used a few different types of rubber in the seals. etc. All of which has different levels of success in the application it was designed for.

How big is the scale, both now and projected?  Is it just for expert/trained people to look up stuff, or is it going to feed into some kind of other programmatic system?

You said you don't want Excel, but if it's small-ish (say less than a thousand entries) and there's no requirement for automated access then the simplicity of a spreadsheet is appealing.  Databases are a lot more complex to access and update, you wind up needing to write interfaces to them, etc.  With Google docs (or presumably the cloud-based Office) you've got all of that stuff solved for you.

It's just for design engineers colocated, there are maybe twenty people who will use it. I'm thinking OneNote more than Excel, but I was wondering if there was something more interactive.

Javelin said:

Not the military way, that's for sure. 

"Threaded rod with hexagonal head, 13/34ths head size, hardened radon steel, fine pitch, 11.2 mm length, NPT 1/2-40 coarse thread"

At GE, it was so bad that we had a dozen different part numbers which all were on separate specifications which call eventually, after a dozen pages, called out the same valve. I had to call the supplier to find out what was what. These were massive valves, maybe $50K per. It was a big deal. Everything was this way.

QuickBase may be the droid you're looking for. It can be anything from Excel in the cloud, used to get out of Spreadsheet hell, to a full out relational database. 

excel>>>>one note for something like this.

If you want to store other information like best practices and whatnot, like a brain dump of tribal knowledge, you could do a wiki in sharepoint.  But dont be surprised if that falls on its face.

I would vote for excel with a VB front end to make it look pretty and be more interactive. 

My take is that Excel is the best quick and dirty app for this.  I'd recommend having a column just for tags so you can search within that column.

I agree it feels like excel might be right for this. Annoying if you ever need to paste in a quick drawing though. Maybe put the excel doc in a folder and make a pdf for drawing and details that aren't bucketed and categorized in excel. Then excel can link to the PDF. 

ProDarwin said:

If you want to store other information like best practices and whatnot, like a brain dump of tribal knowledge, you could do a wiki in sharepoint.  But dont be surprised if that falls on its face.

I've never seen a wiki survive unless there has been someone who either (A) has it as a pet project, and it will fall on its face as soon as they leave, or (B) there is a person for whom that sort of documentation, i.e. a process manager, is their entire job. And as soon as you lose someone else, that person will be pulled in to cover the slack the wiki will fall on its face. 

tuna55 said:

ProDarwin said:

Can you be more specific re: widgets that go into a part?  Are these features of a given part that can be done a-la-carte?  Attributes?  

 

Soo no. I can't. I'll pretend it's a different product.

We make brake systems. We make caliper pistons, calipers, seals, rotors, and brake hoses. We include bolts too. Each one of those parts has been made from five-ten different materials. The clearance between the caliper piston and bore has varied. The brake fluid has varied. The application has varied. We've used a few different types of rubber in the seals. etc. All of which has different levels of success in the application it was designed for.

I've had to do this type of report before, generally with only three related parts, though.  Parent part, child part, grandchild part.

I found the timeline made the most sense to me, so if you're doing a whole bunch of stuff, maybe like a family tree/flow chart type thing?  "In the beginning was the Widget, and the Widget was good.  The Widget begat widget Jr who had a shell of iron instead of Widget's shell of steel."  but in a chart manner.  With the flow chart you can use different colors of branches and different shapes of the boxes to denote different things.  A red line for a different material, a square box for a 2 piston caliper, but a triangular box for a 3 piston caliper, circle for a single piston, etc.

If I were doing this, I'd be working with an SQL database. Come up with what we need to know about each product, how they're related and bang it together. Then build a crude, pure HTML front end to pull out data.

But the most important thing to define first is 1) what goes in and 2) what comes out. What data do you want to store about products? (hint, "everything" is not an answer). What do you want to be able to pull out of this data? That will likely drive the answer to the first question. Know what questions you will be asking and you will know what you need for the answer.

The stuff in the middle is just details.

Let me be a little more clear, because I believe the proposals here are close, but missing by a bit.

This isn't a history lesson. More like a lessons learned.

Case 1: If I wanted to make a new brake caliper today, but for a very different application, I might say I wanted to try a different metal, or plating. Have we ever used that metal before? On what product, and for what reason? Did it work well? Did it pass the required tests? Were the warranty claims in line with the others like it? What was the cost?

Case 2: I want to look into all of the brake calipers we've made. Which ones had the best corrosion resistance? Which were the cheapest?

Case 3: We make brake rotors from thirteen different materials, and four different methods of manufacture. Which ones stand out as poor? Which ones are excellent? Should we trim some of them off the vine and integrate these other methods into those product lines?

Does that help?

1) Write down the requirements for the system. Exactly what information does it need to provide. How precise does it need to be. How fast, easy, pretty, etc.

2) Like Keith said - what are the inputs and outputs of the system. The rest are details.

3) I would start with Excel. It is quick and easy and you will throw out the first three iterations anyway as you learn what you really need. A SQL database is ideal, but that requires a good database oriented person to set it up, modify it, and keep it running. 

Depending on how many people are using this, I personally would either use Excel (fewer than 4 people using it) or QuickBase - QB because I have experience and extra licenses for more apps. I'm not sure what QB costs, my company has over 100 apps and at least 5k users, so that is not a concern for me. 

I still think One Note is a better format than Excel. I want to have pictures and summaries from lawsuits, metrology data, copies of hand written test reports, etc. I want it all tabulated. OneNote cannot do a lot of searching or cross referencing, though.

I don't believe that I can count on a database keeper, or spending money for software, but I could be persuaded on the latter.

One note is a terrible tool for this type of thing.  It will be incredibly disorganized.

Excel is the quick and dirty version.

SQL is much much much better, and likely very worth spending some $ to set it up.

General process:

1)  Use one note, determine hey, this may have some legs.

2) build proof of concept in Excel.  it works well.  

3)  Improve Excel thing to the point where it is overcomplicated/a bit cumbersome to take it any furthere.  It works really well.

4) Hand off to an internal team and tell them "This is a great proof of concept, it needs to be developed into a proper application before widespread adoption"

5) Internal team just bandaids Excel before rolling out to a ton of people

6) After a few years the tool has a lot of negative attention because it doesn't work as desired

7) New version of excel comes along and some of the Excel programming breaks.  People stop using it.

I found an ally in the organization, and we're going to work on it together. Much as prescribed, we're going to start in Excel and list the appropriate attributes first. I think we can leverage Sharepoint's clever linking tools to help a bit.

Honestly, it sounds to me like you're describing a good old fashioned technical report, perhaps turned into an engineering design guide/manual. In my experience, these are generally created and maintained in MS Word, and distribute access as a PDF.

Spreadsheets and databases are great for filtering through a large number of attributes to find out 'what'... But not so much for getting deeper into 'why' and 'how'.