Concur with wmarhel, be carefull using DPMO
A couple of past experiences.
I was mentoring a Black Belt on a project where they were improving a process called detail check. There, the CAD system produced a drawing and the "detail check" team looked for errors in the design implementation prior to passing over to manufacturing to wire up the circuitry.
Before I was involved, the improvement team decided that they would obtain a baseline DPMO. So they said each drawing had so many wires on it ( 1 opportunity to either be there or not) , each wire had a start point (opp) and a termination (opp) and a wire coding number (opp) and a color code (opp), so essentially they ended up with each wire on the drawing having 5 or 6 opps for error. OK, that meant each drawing had several hundred opps. They calculated a few hundred DPMO from their sample.
When the team took that result to manufacturing, they almost got thrown out of the building. "No WAY are you that good!” they said. The point is that you must define the opportunities in view of the customer. In this case the wiring guys did not give a tinkers dang if there were 10,000 opportunities for error that were done correctly. ONE error made the drawing not suitable for their use.
Another story on defect counts. I did a project looking at a packaging line. The inspection of the package had a quality plan with, as I remember 77 defects called out. e.g. ("PRINT MISSING CHARATERS", PRINT SMUDGED” and a bunch of others) were all separate defect categories. Please imagine an operator trying to inspect to that list and the daily arguments of the IT IS A DEFECT! , IT IS NOT! variety. All of this is NVA work.
When our team finished we had combined them into only a total of 17 categories e.g. all the Print ones were now "Print Unreadable", with some decent operational definitions around them. Still a lot, but much better.
The bottom line is, if you will not do something with the minute symptom codes, look for combining to simplify and get more resolution in your first order Paretto. If you are using the lower level data to drive improvements, then I applaud you, but in such cases it has been my experience that it is just recorded and no body ever looks at it again because individually they are not seen to be a problem worthy of effort.
My advice is stick with PASS/FAIL, as previous poster also indicated, to drive your initial improvement efforts.
A legitimate use of DPMO can be seen to compare two products of dissimilar complexity, like a circuit board with 100 components versus one with a 1000. This can be the first cut to say what to work on as a priority.
But to improve this type of process, I'd be very carefull of DPMO where the "O" was anything except "1", that "1" being what the customer wants. Else, you may delude yourself that you are doing better than you actually are.