production test

You are currently browsing articles tagged production test.

Steph, our new marketing maven, likes the pithy blog post title I did a while back, “We design, we test, we break things.” She thinks maybe that should be a new mantra for our prductization services.  I like it too (after all I did think it up), but I also worry that it’s missing one key element: why this matters to our customers?

Design is the easy part: before our customers can sell a product, it has to be designed.  Ergo value.  Ergo this is why there are thousands of design firms out there ready, and for the most part, able to perform that value add service.

Test is a bit tougher to quantify the value.  We test to verify the product meets requirements (aka Engineering Verification Testing, or EVT). We test to validate that the product meets specs (aka Design Validation Testing, or DVT.  We test each individual unit to make sure it’s a good one (aka Production Test).  This adds value indirectly, in avoidance of field returns, in avoidance of damage to brand.  It’s a necessary evil, or at least a necessary cost, to selling a product. Because failing in the lab is a whole lo cheaper than failing at the customer’s site.

Breaking things, well that sounds like fun but how does it add value? Because if we do this early enough in the product development process, we can learn how products might fail.  We can learn what tests a product might not pass.  And most importantly we can feed back that information into the design process and modify the design so that our customers’ customers don’t get the same pleasure of breaking things that we do (are we greedy?).  We learn by breaking necks, by running products so hot they stop working, by testing hinges so many times they fracture, by testing electronics until the solder joints fatigue. And this, very very indirectly, makes a big,very very tangible,  difference to our customers’ long term profitability. For the better.

Still looking for a revised pithy saying: “We design, we test, we break thing so ________________”

Chuck

Tags: , , , , ,

Ever seen the movie where the wild-haired designer looks up from her or his laptop only to be greeted by a stern-faced production manager who says, “Your new design is failing at final test”?  And the designer responds, “Why are you talking to me.  It’s a test problem.” All the test engineers out there are grousing, “Seen that movie? Heck, I was the guy in the red shirt who died in that movie.”

No, of course they don’t make movies about engineers of any stripe, but the point is still the same…

It’s an all too common problem, blaming the person who finds the problem for the problem.  Since a good production test process–or validation test for that matter–is supposed to find problems and reject parts that do not function properly, it’s small wonder that such test processes detect problems.  Test engineers are supposed to design tests that identify failures.  It makes no more sense to blame the test engineer for identifying a design fault then it does to blame a doctor for identifying an illness.

Fortunately, after everyone gets “plumb tired of all that bell-fired finger-pointing” (old Zeb is looking over my shoulder and threw that there Zebulon-ism in…) there are proactive solutions.  Investing in a rigorous design validation testing (DVT) program should detect issues before they get to the production floor.  Further upstream, a Design Failure Mode and Effects Analysis (DFMEA) can help predict what might fail, the better to focus engineering and testing efforts.

And as for all those design engineers out there, myself and our design team included–best we take a test engineer out for lunch now and again. Because even with the best engineering rigor, the most through validation efforts, mistakes will still happen and we’ll be once again be glad that the test guys caught yet another problem before our customers do.

And no more undue blaming of test. Blame Murphy instead.

Chuck

Tags: , , , ,

Just wrapped up one of our best weeks ever, and in the afterglow I have been wondering: “Why?”  I think the answer is we have some really great customers.  And by great I actually don’t mean a salesperson’s view of a great customer–willing to pay too much and order too many; nor an accountants view–pays up front; nor even a customer service reps view–never complains and rates us high. No, a great customer is one who makes you work hard, who challenges your capabilities, and makes you strive for excellence.  A great customer also understands win-win, so while they are cracking the whip with one hand they are providing the information, the specs, the quick feedback to help you get the job done / product shipped or whatever.  A great customer will never tell you that you s__k when you are doing well, not will they tell you all is fine when you s___w up.  A great customer will insist that you improve your schedule, but then work with you to make it so.

Had a few great customer experiences this week.  We had a grueling three hour kickoff meeting for a production test firmware project, with a customer who is trying to roll out a  consumer electronics product for Christmas.  We signed up for a really challenging schedule (and are working the weekend on it) but our customer is supporting us in every way possible: providing all the data we need quickly; answering our myriad get-started questions, of which some may fall in the stupid category; explaining their reasoning behind the spec instead of just saying “go read it”; and the like.  We’ve gotten a running start and maybe even will be ahead of an extremely tight schedule.

Another great customer kicked our butt this week.  Their clean-tech program is behind schedule and we are the program managers.  We can argue til we’re blue in the face that it’s not our fault (and perhaps it isn’t) but our customer can, and should remind us in the most vigorous wording possible that behind schedule is a BAD thing.  And as program managers we need to accept  responsibility and more importantly, do whatever we can to fix.  We have no magic wand nor time warping technology, but we did work out a compromise solution together to speed up the next phase.

Of course, I can’t deny that I  appreciate customers who pay on time , but  I also appreciate it when they help make us a better company.

Chuck

Tags: , ,

It’s shockingly easy for guys like me to get up on our virtual soapboxes and basically say, “You gotta do the right thing.”  Let’s face it—we all want to take the high road; we all thinkthat we do take that road more times than not.  So wanna be blog-meisters like me can easily say “thou shalt test more” or “thou shalt conduct design reviews” or whatever and it sounds good, albeit a bit pompous.  But let’s face it: business is, for better or for worse, about making money.  So when we make decisions on productization—or most other topics—we gotta do the right thing  and make money.

So to the question at hand—how do we make the right decisions on investing (incurring expenses) on productization?  The answer can be summarized in two words: Risk and IRR.

Risk is easy to understand but tough to quantify.  In general productization efforts lower risk.  Examples of risks that proper productization efforts can mitigate include:

  •  Risk of delays
  • Risk of field failures
  • Risk to brand / image
  • Risk of damage to property or person
  • Liability risks
  • Inventory risks

Examples of productization efforts that fundamentally reduce risk include:

  • Design Validation Testing (see our earlier Productization blog on this topic http://www.zebulonsolutions.com/productizationblog/?p=50/ ), which can mitigate the risk of field failures, property damages, risk to life and limb, and liability risks.
  • Production test development basically mitigates the risk of test escapes that can lead to field failures, returns, and damage to brand, as well as potential risk to property, life and limb
  • DFx reviews address schedule risks, can mitigate inventory risks if proper attention is paid to Design for Supply Chain, etc

The other topic is IRR—Internal Rate of Return—is not so easy to comprehend but easy to calculate.  IRR is a form of return on investment calculation that better handles non steady state conditions than traditional ROI or ROIC calculations.  IRR calculates the return from a series of disparate cash flows—often a negative cash flow representing monthly investments in say a cost reduction redesign and then positive cash flows in the term of lowered cost in production.  Sounds complicated but fortunately spreadsheets can do this calculation easily (almost easily—it’s actually an iterative solver at least in Excel so sometimes needs help to converge, and there is the tricky issue of salvage value.  I can expand on either of these offline if anyone is interested in the details…).  IRR is thus a way to quantify the benefits received from investments in productization.  IRR can deal with time easily by using appropriate time units—months, quarter, weeks, years.

Then the really cool part (I show my age—does anyone use “cool” anymore?)  is one can combine both risk and IRR by using an expected value methodology for calculating IRR.  For example, if one can reduce the risk of field returns by say 10% by doing extensive Design Validation Testing, then one should calculate an IRR using 10% of the current cost of field returns as the payback. In fact even for mundane tasks such as cost reductions the return is never 100.0% certain (Murphy’s Law if nothing else) so one should really use expected value, in such cases as a derating factor,  in any IRR calculation.

The tricky part of course is assigning the right costs, the right risks, the right expected values and the right time frames.  But even if the calculation is not perfect, it’s far better than nothing or the omnipotent finger in the air.

Chuck

Tags: , , , , , , , , ,