@
OF you always have tha overall most well rounded answer coming from every angle. You never under think circumstances and always go for tha whole story rather than not. You're very respectable
Wow! Thank you very much. For sure that's the goal, but I can't agree with the 'you always....' part. A good goal, though. Very kind of you to notice, it's very nice to be appreciated.
That's a good piece of info to think about, but just because QA can't find the cause or reproduce the error does not prove that there was no error. In fact, I often find that defects which are hard to reproduce (in the software world) often lead us to search and find some unknown deeper problem, either with the software or more likely, a gap in the QA process/procedure.
Excellent point. Works much better for hardware than software if you asked me. "Don't worry, we'll fix that in software" has got to be right behind 'if you like your plan, you can keep your plan'........
In the case above the main product was an analog box that hooked to marine radars and output video. It was easy to verify that the 3 input signals (trigger, head mark and video in) were properly processed in both polarities and correct amplitude by test fixture. A solid go/no go test that basically never failed. It was almost always an installation/configuration/commissioning problem in the cases that returned 'just fine'. Occasionally operator error or training. Like with the software side, you have to run each to ground if you want Quality Assurance (as opposed to QC or Inspection).
Fun world, I'm a hardware guy at heart. At the mercy of software in digital systems (many's the time I got the ticket signed off by going to a prior revision of software). Give me a hard failure to tie down every time over 'I wonder how it ended up trying to execute it's date code....'. Love it.
You know how many programers it takes to change a light bulb, right? None, that's a hardware problem.
Has it been considered that the same QC going out might be the same QC for RMA's coming in?
Always an issue if you're into QA as opposed to QC. Inspectors are human, so the problems are human and need
system solutions to offset that.
In most cases I know of RMAs don't got to QA or any inspection (which is why the place discussed above is the exception). Normally returns are handled in an entirely different channel to production. Classically the department head reports to the Old Man (company president), like Sales, Production, Accounting and so on. It's considered a danger sign for Customer Service to be part of Production or Sales (where they often are found). For sure QA belongs on it's own branch of the corporate tree. The point is, normally Field Returns are separate and not subject to the same inspections going out and with that one exception never coming back in the way it was played when I was in that game.
The wisdom of that is exactly what you whimsically suggest. You want a set of fresh eyes and hands on the problem. The 'don't ask the same question over and over expecting a different answer' thing.
It's not easy to do right, for sure. Although I understand it often seems like 'how can those idiots send it out without a power cord'.
Long as I'm prattling on, one more fun idea......a single field return can kill the profit from a pile of good ones. The risks are great, companies can easily reach a tipping point and self destruct if the wrong sort of oops slips though. Recoveries like what we just saw with Ascent are not givens, it's the mark of an exceptional outfit that can respond like it seems DV has. Handled differently they might easily have ended up on the rocks.
OF
