I interviewed Fred Schenkelberg who discussed Component Failure and the Five Useless Responses from Suppliers and What to do About it.

 

 

 

 

 

 

It’s great to speak with you today, freed. I’m looking forward today to discussing the topic of component failure and define useless responses from suppliers, as well as what to do about it. Before we start, can you provide a brief background of yourself?

 

Sure, and thanks for the invite, Dustin, I appreciate it. I’m a reliability-engineering and management consultant. I’ve been on my own, working in this field for about ten years. I’ve worked with all kinds of different companies. Matter of fact, last year I taught a course in the Shanghai University of Science and Technology on reliability-engineering management, which was a lot of fun. Prior to that, I was at Hewlett-Packard. I used this line earlier today: I grew up as a manufacturing engineer, where I first started in the industry, so, therefore, it’s always the designer’s fault. It’s kind of shaded my approach to a lot of things I work on.

 

So, focus on reliability and engineering as a design aspect. Selecting components is a part of that, but then how do you assemble that into a system that meets your business and your customers’ needs? That’s kind of the space I work in.

 

Can you talk more about what component failure is and what these useless responses from suppliers are?

 

I thought I got your attention when I mentioned these responses. It’s a good question: What is a component failure? We’ve come a long way since Henry Ford and his assembly line. He was pulling iron ore out of the ground and processing it into metal and then forming it into the parts he needed for his vehicle. He controlled his entire supply chain, whereas today we don’t. When I was at Hewlett-Packard, whether it was a desktop computer or printer or whatever device, we relied on a pretty extensive supply chain to provide components, everything from capacitors to the molded parts on the outside.

 

When a part fails, when a system fails and it has, whether it’s a ford label on the vehicle or an HP label on the box, the customer sees the failure, and they don’t really care whether it’s an AVX component or an intel chip that fails; they just know that it failed and they’ve got a loss of function. Many times we do some due diligence and failure analysis and say, “Okay, this component from this particular vendor seems to have caused the problem.” And that’s what I mean by component failures; we can identify the particular component that was either the instigator or sometimes the victim—or both—of something that went wrong. At that point, it’s oftentimes a discussion back with the vendor. That’s what I mean by a component failure.

 

In that process, we often make a phone call. We call our representative or technical contact or support folks at the supplier’s facility. A real story was—I don’t remember what the component was; it was probably a field-effect transistor or something like that that was having a combination of a very high-yield dropout; we had a lot of failures at assembly, and we were getting failed failures related to the same part.

 

One of the steps was bundle up a couple of components and send it back to the vendor. I FedEx’d it and expected it to be there the next day. I called them and said, “These parts are on the way, here’s what we know,” and the immediate response on the phone, before he got the parts was, “Oh, it was ESD. We had an electrostatic discharge; it happens all the time. It’s not our fault. Something went wrong and somebody damaged the part.”

 

How in the world can you know that from five hundred miles away and not having seen the parts yet? It was the second time I got an answer like that. I went and talked to my boss about it. He said, “Suppliers have five standard answers. They try one of these answers, and if you go away, their job is done, and they don’t have to deal with you anymore.” I’m like, “There’s got to be a better way.”

 

It’s ESD, which was hard to prove that it actually is ESD, especially for electronic components and CMOS technology-type stuff; it’s very hard to find that failure. It was a common scapegoat. If we can’t figure out exactly what caused it, it must be ESD. That’s one.

 

Another one is: “We’ve never seen this before. It’s unique. We’re surprised. We don’t know what to do.” Another one is: “You didn’t use the part right. You overstressed it in your design. You did something wrong.” It’s basically a veiled way of saying it’s your fault. Another is: “Oh, we know about that. No problems. We already implemented a fix. No trouble.” All’s they know is the symptom; they may not really be able to explain what the cause was.

 

One of my favorites was: “We didn’t think you’d notice. We changed our process a little bit, and it should have no change in form, fit, or function, so we didn’t need to notify you.” And I’m looking at my components that are failing left and right, going, “Well, it needed a fix. That’s why I called you.” Those are the five that I get, and I’m sure other people have additions to this list or different responses. Dustin, you work in this field. Have you seen or heard these kinds of responses?

 

Similar to those, yes. My next question is: What is a better response?

 

Well…it varies. I know in some organizations, they just don’t have the capability to answer the question. They really don’t have the facilities or capability to do the diagnostics, and their answer may be, “Let’s work together with an outside lab to figure out what really happened here. We’ll add our expertise to what we think has happened, and you add your information about the circumstances and the design.”

 

One of the best labs I worked with was a vendor, and right away they said, “Let’s preserve the evidence.” It was like a detective show or forensics exercise. They said, “Don’t take it off the board. We need to investigate if it’s a solder-drain problem, for example. Can you ship us the board and help us understand how to evaluate it? Let’s do the, I think it’s called the 8 Ds, eight disciplines of failure analysis or root-cause investigations.

 

The first step is to really preserve the evidence. It’s the equivalent of putting up the police tape around the crime scene. Asking the question if it’s just one part or affecting a batch level part or is it across batches, those kinds of things. What this particular group did was started asking those kinds of questions to get a sense of the magnitude or scope of the problem. They were very forthcoming with, “Here are the things we see that are related. Here’s an analysis of your design that pushes the margin this particular way. Together, we were able to replicate this; it was an intermittent problem. Within a week or two, we’re able to come to an agreed-upon root cause and fix.” Like most problems, it’s not just the vendor’s problem; it’s not just the designer’s problem; it was a mix or variation or combination of those two areas that you have to design it so that the product or component will work in that circumstance.

 

The response I appreciated the most was: “It’s in our best interest if your design works because you’ll buy more of our components, so let’s work together to get it right.” That was very much appreciated, but it’s exceedingly rare. That’s probably a better response, one I would look for from suppliers when I have an issue.

 

Do you have any final recommendations?

 

I think it comes down to two different recommendations. One is: Your suppliers, they’re good people, they want to do a good job, they want to provide good components. They don’t intentionally send you faulty parts—at least not the reputable dealers I work with most of the time—so treat them with respect. When you have a failure, it’s not automatically their fault. Their component may have been a victim of your bad design, created an overcurrent situation or some other phenomenon that caused their component to take the damage.

 

You’ve got to be open-minded. The recommendation is that you’ve got to work together to solve the problem. If you approach somebody as an adversary right from the start, they’re less likely to cooperate with you, just even on a subconscious level. That’s one recommendation: Work with your suppliers like they really are your partners in trying to solve this thing.

 

The second part starts long before you get a failure. As you vet your suppliers, as you go through the process of selecting your suppliers, investigate—and I’m not really clear exactly how to do this in all cases—but you’ve got to ask how they approach failure analysis. What’s the right way to bring them information that’s related to their components failing? Who should you call? What’s the response time? What kind of failure-analysis tools and techniques do they use? What’s the right way to contain or triage problems so you can clearly identify the contributing causes to failures? That’s kind of what I’m getting at.

 

That happens early on in a process, before you hit failure, so that you’re set up and already have a relationship to deal with failures when they occur. I think it starts very early in a program. It’s really those two things: treat your suppliers as partners, and understand what the process is and what their capabilities are. Don’t ask them to do things they’re not capable of doing I think is really the second piece of advice. Those are probably the two key parts.

 

Thank you, Fred, for sharing today.

 

I appreciate it. Thanks for the invite, Dustin, I appreciate it. I’m glad LinkedIn works and the keyword searching thing actually works.

 

 

 

 

About Fred Schenkelberg


 

02ebb1c.jpg

Fred Schenkelberg


Reliability Engineering & Management Consultant

 

LinkedIn Profile


Website