Your Reliability Engineering Professional Development Site
Have you ever wondered what are the key ingredients for successful FMEA application in a company? Why are some FMEAs successsful, and others are not? What are the most important factors for uniformly achieving great results? Based on supervising or performing over two thousand FMEAs, six FMEA success factors have been identified, and they are covered in this article.
Nothing succeeds like success.
Alexandre Dumas
Your planner is putting together a scheduler to 8:00pm on a Friday night for Saturday morning. Your storeroom doesn’t have the parts you need and you maintenance supervisor is running back and forth. On top of this, you are unable to meet your maintenance goals, preventing the orgainzation from achieving its goals.
Depending on your organization, you may walk into this type of chaos every morning, and those that don’t, chances are you did at some point.
So what seperates the organizations that have this choas and those that don’t? Clear Roles & Responsibilities is what seperates these two types of orgainzations. This is the first of a series of 6 posts on the topic of Roles & Responsibilities. [Read more…]
Do they design reliable products? Or Do they guide the development of reliable products?
It’s some mix of course. It depends on the process for the organization they operate in. I will point out that neither extreme works. I am often surprised with how many organizations I see that still have the 1950’s model of ” Design it and then give it to the reliability team to make it reliable.” I still don’t believe there is a single person in any engineering role in any engineering organization that believes that works.
That is what one of my old mentors used to call a “window dressing program”. No one believes it actually helps the product but you get to take your customers around your facility and show them all the great testing you are doing (SILENT END OF SENTENCE ” on out of rev parts and in a program phase where results can’t be implemented.”). [Read more…]
Risk assessment is a critical element of ISO 31000 risk management framework. Risk assessment provides the requisite evidence based data and information for Risk Based Thinking, specifically risk based problem solving and risk based decision making. Using the appropriate risk assessment for the organization can determine how to treat and manage specific risks. [Read more…]
A work order full of code numbers confuses people. When work order type (breakdown, corrective, modification, etc) is described as Work Order Type ‘04’ you can guarantee that no one knows what ‘04’ is without looking it up on a list.
If a Trade Type is a ‘02’ and it means a fitter, you can be sure that a lot of work order requests from operators will be wrong and they will take the planner’s time to correct. Even more confusing is when the Work Order Type and the Trade Type are both an ‘04’! [Read more…]
Making or supporting decisions involving product or system reliability is fraught with uncertainty. Is it reliable enough? Will failures occur prematurely? Are failures dangerous?
Uncertainty is risk.
In recent years more organizations and international standard bodies have focused on risk management. Identifying, analyzing, and mitigating uncertainty in a systematic manner.
There is not a set way for every organization to organize a risk management process. The ISO 31000 standard does describe a framework for the implementation of risk management within your organization. [Read more…]
When I introduced you to the Stuck at Fault Model I stated that the size of VLSI devices necessitated the usage of Electronic Design Automation (EDA) tools to support testing.
My first full-time job at IBM exposed me to the world of test and to their EDA tools.
In the mid-1980’s, testing of logic devices relied upon the S@ fault model. Three common software tools included fault simulation, automatic test pattern generation, and fault diagnosis.
This article will provide an introduction to fault simulation as one can view the other two tools as applications built upon a fault simulator. [Read more…]
Automobile companies pay dealers to perform vehicle prep and make warranty repairs on customer vehicles. A lot of data is collected thus warranty is considered big data.
Generally, vehicle warranty covers 3 years or 36,000 miles. When a vehicle is serviced, the customer, vehicle, repair, and text data are collected. Claims are entered into a transaction database, may be rejected for a number of reasons, and then resubmitted until resolved. The transaction database covers many model years, millions of vehicles, and a number of warranty claims for each vehicle. As a rough estimate, assuming 10 years, 2 million vehicles/year, and 2 claims for each vehicle, yields 40 million records. The actual number is higher due to the submission, rejections, and resubmission cycle.
Understanding the reliability stakeholders in an organization is an interesting exercise.
Who are they?
It’s easy to look at each of those and say “They all could easily get by and appear successful even if a product has moderate to poor reliability”. You could also state that ” Reliability is a key factor to success in their role” [Read more…]
RCM Implementations don’t fail, believe me if you understand what your getting into upfront, use a proven process to select your asset for analysis AND you commit the resources, your implementation will be a huge success.
Looking back 20 years I can clearly remember performing my first RCM analysis and the ordeal that followed as we struggled to:
a) See the value in the analysis we had just completed (Someone told us that RCM should be performed on every piece of equipment at our plant so we selected one of our most common assets.
b) Free up the resources necessary to implement the tasks that came out of the analysis. [Read more…]
There is much talk about data based decision making, but I think that misses the point. We make decisions based on knowledge. Data needs to be translated into that knowledge, and yet not all knowledge can be measured. This has been my training philosophy for a number of years now and has been quite effective. [Read more…]
What did American inventor and businessman Charles Kettering mean when he said, “A problem well stated is a problem half-solved”? Framing the problem and pondering solutions can be enlightening, and a great way to learn. This article will pose three problems and offer solutions, as a way to learn by doing.
“I hear and I forget. I see and I remember. I do and I understand.”
Confucius
Nothing can undermine FMEA results more than approaching the subject from the wrong philosophy. In this article readers will learn how use key focus areas to achieve effective FMEAs in all applications.
“In matters of style, swim with the current; in matters of principle, stand like a rock.”
Thomas Jefferson
Should an FMEA result in design or manufacturing improvements? Should it ensure that tests discover the right problems? What are the objectives of FMEAs? Whether you are new to FMEA or an experienced practitioner, there is always something to learn. This is the first in a series of articles on FMEA that should expand the knowledge of every reader.
“Successful engineering is all about understanding how things break or fail.” ~ Henry Petroski
Do you consider yourself new to FMEA, or are you an FMEA expert?
Or somewhere in between?
I’m a great believer that knowledge of any tool such as FMEA, is a lifelong journey. In the new series of articles called Inside FMEA, my intention is to bring to life the subject of FMEA, and provide value to readers from all levels of experience.
Each week I will publish a new article on Accendo. The topics will span the full range of FMEA applications, and offer guidance to real-world challenges that FMEA teams face each and every day. [Read more…]
