Most of us will be well aware of just how important product reliability is to business success and customer satisfaction. Of course, it is more than that: we need to deliver well-targeted reliability, cost-effectively and on-time. And it isn’t easy.
But who said that reliability engineering is easy?
Or that reliability engineering requires a fixed set of tools that we can learn in College?
My experience over 30+ years in the reliability field is that we need to continually refresh, improve and expand our skills, to address new technologies, new challenges, and take note of new learning.
Reliability engineers MUST follow a path of Professional Development
I have recently posted an article on www.accendoreliability.com in which I review some of the opportunities we have to access additional learning and certification. There are several.
I personally offer Reliability Green Belt®, Reliability Black Belt® and Reliability Master Black Belt® training programs, and also provide an ASQ CRE Preparatory Course. (Training Programs) These provide a wealth of current knowledge for the aspiring and experienced reliability engineer alike.
In addition, however, I believe we also need to network and learn from others.
Conferences are a great opportunity to do this. My favourite is RAMS, but you may have a focus in a particular industry or a particular field. The better conferences will be the ones where the papers only accepted after successful independent review (refereed), and where a full written paper is provided – not just copies of the presentation slides.
You will quickly find out that it is pretty well impossible to get a full understanding of topics from the time-limited presentations, but contact with the author and with fellow attendees, will allow you to review the papers afterwards and follow up. I believe that such active networking is a crucial part of professional development.
I will be at RAMS 2018 in Reno, NV at the Reliability Engineering Academy booth. I urge you to come visit. In the meantime, please contact me.
A client came to us with concern about poor right-first-time product test results from their contract manufacturer. They had reason to be concerned: 10% yield is not good! Clearly, the manufacturer was having trouble. Our task was to identify the root causes and recommend how to fix the problems.
The design company initially asserted that the SMT process was not good enough. However, we were to disprove this.
The process flow to the first test rig was SMT, firmware load and then test on a pogo-pin test rig. All components were standard, off the shelf, and from reputable suppliers. Quality controls were well implemented covering purchasing, receipt, handling and storage. In addition, our initial assessment of the SMT process indicated that the SMT process was also well under control.
However, firmware load files, whilst being correctly “pulled” from the design company, did not have record of having been validated. Therefore, we prompted investigation of the firmware itself.
Specialists identified that the FPGA manufacturer support centre held knowledge of issues and work-arounds with regard to timing and other issues involved in firmware load, and these strongly influenced loading success.
Accordingly, the firmware was improved and, after further validation of firmware, a much-improved manufacturing yield was obtained.
This issue was clearly one of poor design team processes.
We also found poor or omitted design transfer to the manufacturer, and of poor or non-existent validation of test fixtures, including of the pogo-pin tester noted above. Gauge R&R was therefore initiated.
At a higher level, it became apparent that the design company did not understand or have in place procedures to ensure comprehensive and validated transfer of knowledge to its contract manufacturer. Without clear guidance, consistent manufacture cannot be expected.
And without consistent manufacture, reliability is lost. Not surprisingly, I always include consideration of manufacturing capability when working with clients.
I have provided training to a wide range of clients, in several industries, over many years, across the world and to disparate audiences. I believe my students have benefited from my teaching, but in addition, I can declare that I have learned also from the experience.
One thing I have learned is that our pre-existing assumptions and prejudices can hinder root cause analysis.
One industrial-client sponsored session on root cause analysis required participants to propose and consider issues that had arisen in their workplace. We had 2 nationalities in the room. Let’s call them A and B. Nationality A firmly asserted that if they issued a procedure or directive, it would not be possible for those to be omitted or disobeyed. Nationality B were equally firm that omissions or failures would be a possibility. What was interesting was that the breakdown was 100% on nationality; Not on seniority; Not on education; But, rather, through some pre-existing assumption or prejudice.
Over my career, I have facilitated and undertaken root cause analyses on subjects from aircraft crashes to electronic component test failures. The best results have always come from those that follow a clear procedure (there are several published) that allows for a wide capture of possible causes to a well-defined problem, and then requires justified evidence to support refinement and final conclusions. If a possibility is ignored or discounted through prejudice, the root cause of a problem will not be found. And if the root cause is not found, a complete fix will not be identified and reliability will suffer.
This applies to hardware, software, simple systems, complex systems. Root cause analysis should be a core skill for all engineers and project managers.