66horns
I did some searching because it seems absurd that this doesn't exist already. Take a look at some of the info through the following link:
http://www.google.com/search?hl=en&lr=&as_qdr=all&q=checksheet+site:plex.com
This company seems to have an ERM product with numerous modules, one of which is a specification database.
What we currently use, and what I've seen for the most part, is MS Excel based inspection sheets. This is done well when the entire PPAP package is combined into one workbook of many sheets. The specifications are numbered and entered into the ISIR sheet, and the check sheets are linked to the data already entered. The sheets themselves are actually forms and are printed off. Data collection is written onto the hard copy and these check sheets are then filed into filing cabinets, where they are for all intents and purposes lost.
The place I work at currently doesn't even go this far. The inspection sheets are in Excel, each part has its own file. The file is a basic form and each time we create a new inspection check sheet, we re-enter the data.
One place I worked at had an electronic data collection system. Each machine had a computer terminal, and the setup machinist would put in the critical dimensions to be checked, a frequency, gage to use, etc. The electronic checksheet would ask for inputs based on the frequency. It was a constant development process that I'm sure grew beyond budgets, I didn't stick around to see.
These setups all have deep problems.
The major problem is the fact of filing cabinets. Once a check sheet goes into a filing cabinet, it is gone. What I mean is, you can only find that check sheet by part number. You cannot find that check sheet by gage number, by operator, by inspection result, by job number, etc. There may be ways around this if something like JobBOSS, Vista, E^2 or etc. are in use, but none of this is practical.
Another problem is the fact of poor data quality. Metric to inch conversions are incorrect, errors of data entry are prevalent, and poor inspection planning is done by operators and quality techs who are generating check sheets and ISIR paperwork by the reams.
We currently have a directory of Excel checksheets with 10,000 part numbers. This entire body of work could be lost right now and the operation would suffer absolutely no significant quality or productivity loss. It's tempting because they would certainly develop a different approach if offered a clean slate.
The idea of formatting specifications and tolerances for databasability came about because of errors in converting from metric to inch.
At the time, I was working for a company that had a complete PPAP and checksheet package together in Excel files. The format for specifications, tolerances, targets, and notes, however, was not databasable. It was entered as text, such as '1.25" +/- .020' or 'OAL 12.625 TARGET 12.680'.
Many parts were dimensioned in metric, and it was necessary for the quality manager to manually convert dimensions. The quality manager did not do this correctly in most cases so a spreadsheet for the purpose was developed. Quite simple, really. I'd get the correct data rounded to .0001" and update the check sheet.
However, there are many different types of specifications and many different types of tolerances. The conversion only worked for linear dimensions that were toleranced with a uni- or bi-lateral tolerance, range dimensions had to be handled differently.
After a little more work, it became possible to convert dimensions and their tolerances whether or not it was specified as a range. Using concatenate functions, the tolerance could be re-built. Inputting english inch specifications in a certain format (.5; "; +.03; -.00) would output a string of data in metric, and any portion of that string (12.7mm +.08 -.00) could be updated or modified individually. This concatenation would allow the data to be formatted for databasability in data entry and then automatically formatted for readability in form creation.
After a while of thinking about this, a complete breakdown of specification formats was developed for mechanical inspection.
In a little while, it should be possible to create a system that would automatically create check sheets, allow inspection results to be collected or entered electronically, allow measurement uncertainty and calibration results to be incorporated into targets for manufacturing, allow manufacturing results from one process to feed into the next one downstream, allow absolute traceability of all measurements and total positive recall to be accomplished, allow statistical analysis of inspection results, allow automatic lookup of standard dimensions and tolerances from tables, allow interface with ERM software, and interface with CMM, CNC, and CAD systems.
The main obstacle to accomplishing this is the great momentum of paper based inspection reporting. Of the 10,000 part numbers we currently carry inspection check sheets for, the average number of specifications per blueprint is approximately 22. Given the distribution, we estimate that 220,000 specifications +/- 25,000 are on hand. Given a guestimate of the time it would take to enter all these dimensions, specifications, and tolerances into a discrete data format, it seems it would take someone 12 months of steady data entry work to bring the company up to speed. In the US, based on this estimate, this would cost a manufacturer about $25,000. In the East, this could probably be accomplished for $10,000 in 2 or 3 months.
If an ERM software company provided this software, the cost would probably be very high. Each seat for data collection would cost extra. The universal upgrade would be astronomical.
I am young, and inexperienced. I have not seen a software package that can remove the filing cabinets from manufacturing. If it exists, it would be fascinating.