Best practice for "Test Operation" (or process code) system?
Hi,
Would anyone be willing to share (by link to blog or posting here) thoughts on best in class approaches to planning the list and number system for "Test Operations" in WATS?
We have come some way into our pilot phase but before we get too far and committed, I would like to try and get some learnings from the community on this subject.
My thoughts so far is that you want "as few process codes" as possible, aiming for broader "groupings" than super-specific. E.g. "Insulation Testing" used for all products that need to log a (single) insulation test, rather than "<product name> Insulation Test". Still, there could be cases where one would need multiple related process codes. For example, some products may need several unique insulation tests done at different times in the production cycle, or perhaps a very specific type of insulation testing is done to meet a special product certification category where it would be beneficial to "tag" those in a separate process for grouping and reporting.
At that point in my thinking, having only 10 numbers between categories seems like it could be too restrictive "in the future"?
Also, for our production, we have and will continue to have many "manual inspection" touch-points during production. Since a SN# can only have one (active) pass-fail result per process code, and since the inspections by nature cannot be completed "all at once", this category in particular seems like it could be difficult to manage. . My idea on that so far is to try to identify more exactly the unique "position in the production flows" where these inspections occur and try to group them that way and then end up with e.g. "Manual inspection - pre-stack", "Manual inspection - pre casting", "Manual inspection - post casting" etc.
So maybe similar to WATS shipping concept, but multiplied out by 10 or 100 to allow more sub-categories within? pro-con to that approach? "1000 - Incomming Inspection", "2000 - First of Line Test", .... "10000 - End of Line Test" ...?
I am very curious to hear if anyone would be willing to share any ideas, wisdom, or experiences on this topic in general!
-
Just found this and it's old but I'll post anyway.
I've had the same issue with the two different WATS installs. I found that one process won't work across every product unless you're working with very similar products.
As such, I found using grouped processes for each particular product group or different production line.
Using 1XXX for production line 1 (1000 insulation test, 1100 board test, 1200 system test, 1300 burn-in, 1400 final test)
Using 2XXX for production line 2 (2000 insulation test, 2100 pre-conformal coat test, 2200 conformal coat, 2300 post-conformal coat, 2400 system test, 2500 burn-in, 2600 ESS/HASS, 2700 final test)
-
Thanks!
We ended up for various reasons going in a slightly different direction. We ended up with a documentet standard for numbering "tasks" more broadly. We always had operation numbers in production flow charts, now it is anchored and consistent from rnd/development and APQP system through production and testing and beyond. This groups/numbers specific types of test, e.g. temperature cycling, or calibration as a 15xxx number, but the specifics of a test for an actual product still depends on the actual product line. (Each product has its own set of drawings and production flow charts, and procedures that cover the specifics for that product (and revision of it).)
So for example, all calibration operations are always "1503" no matter what product family it is, but product A may very well have a totally different way of calibrating vs B. Of course typically this will mean that when we want to analyze test data, we would need to filter on more than just the operation code, we would want to add one or more Part# as well (probably).
How well this will work in the long run is too early to tell, like life, it has pro's and con's... but I do like that the numbering is consistent across departments. (10xxx, 11xxx, etc. are for other types of activities, like receiving or incoming inspections, or packing etc. so it goes well beyond what WATS needs to be bothered with. Ties in with ERP and quality plans there too.)
-
Hi, it's hard to give a definite best practice for this, as different customers has different needs, often related to the size of the product mix and volumes.
The general idea is to use as few and generic processes as possible, and name them after their purpose. This way you can compare for example the "Final Function Test" across all products.
It is not good practice to use specific ones for each products, as this will make your process list extremely long and will make heatmaps and other tools more difficult to read.
Br
Ola Lund Reppe
Please sign in to leave a comment.
Comments
4 comments