Generically Specific: An Oxymoron?

I recently went to the movie Extremely Loud & Incredibly Close, starring an incredible new young actor named Thomas Horn, along with Tom Hanks and Sandra Bullock. Have you heard of it? Anyway, there is a scene in the movie when Oskar (Horn) and his Dad (Hanks) are having an Oxymoron War, saying things like deafening silence and clearly confused and seriously funny and -- one of my favorites -- jumbo shrimp.

This scene actually reminded me of an oxymoron I've heard used in our ProFicient SPC Fundamentals Training Class: generically specific. Students used it in reference to naming conventions within the software.

Here is the situation: I am creating a new data entry configuration (DEC) for collecting dimensional data. The parts I'm currently working with require inside diameter (ID) and outside diameter (OD). So I should call this DEC Diameters, right? What if I had other parts that required ID, OD, and Overall Length (OAL), and I used the same equipment to measure those parts? In that case, I wouldn't want to name the DEC Diameters, since it's a little too generic.

This seems like such a simple thing, doesn't it? In reality, it can sometimes delay the rest of the configuration. In the example above, I might want to ask a few questions:

  1. What kind of parts am I measuring?
  2. Where are they made?
  3. What instrument am I using to measure the parts?

For this example, these are plastic parts produced from an injection mold and measured using an OGP visual comparator. Now I have options. I could call the DEC OGP Measurements or Injection Mold Variables. Now, the naming convention is more specific (OGP, Injection Mold), but still generic (Measurements, Variables), thus the term Generically Specific.

The same might be true when building the database structure for your company. How do you group your parts, processes, and tests?

Parts are tricky. Do your operators know what a 43756B is or would they rather select Black Widget - 0.25 inch? There are a few ways to address this issue, but how do you group these parts? You might group them as Widgets, but what if your company makes 100 different widgets of 10 different sizes and 10 different colors? To be generically specific, you might use Black Widgets, Brown Widgets, Red Widgets, and so on, instead of just Widgets.

Note: Part names can only be 31 characters long!

Processes are a little easier because your machines have names or numbers associated (Machine 1, Line A, Press 1A, etc.), but how would you group them? You might say you have Machines, Lines, or Presses, but that wouldn't be specific. Using the parts example above, you might have Widget Machines.

When collecting attribute (inspection) data for a certain group of parts, what do you use for the test group? Better yet, what do you use for test names? Using the widget example above, the test group might be called Visual Inspection, but you might also choose to be more generically specific and call it Widget Attributes. The test name might be as simple as Color, but what if Color was considered a major defect in your quality plan? Then you might have Critical Defects, Major Defects, and Minor Defects, where Color is one of the defect codes.

Caution: Part, Process, and Test names can only be entered once in the database.

Example 1: The Test Inside Diameter might be a variable test for Black Widget, but all the other widgets require Inside Diameter as well. Therefore, it might be better to be more generic and group it under Part Variables or Diameters.

Example 2: Part 43756B is a Black Widget, so it might live in the Black Widget part group. You can move it to the Widgets part group, but it can't live in both groups at the same time.

In the end, it's what you want and what makes the most sense to the operators. Just remember to be generically specific, or maybe it's specifically generic. Either way, it is an oxymoron that works. Good luck!

Jude Holmes
By Jude Holmes
Application Engineer
See Full Bio
Take the Next Steps