Your Reliability Engineering Professional Development Site
Find all articles across all article series listed in reverse chronological order.
I recently held a lunch and learn about infographics. The recorded session is below. In our work as engineers, we often spend a great deal of time extracting amazing information from complex data sets only to find no clear way to get our message to those who need it which can include leadership, peers, or even the customer.
Changing how we present information can be the difference between driving change and simply being a slide in a weekly status meeting that solicits the response “next.”
What if you knew all the possible outcomes for your product’s reliability performance due to component variations, for example? What if you knew the future with enough certainty to make a difference?
Building on brainstorming, what-if analysis involved using models or prototypes that allow you to change something and see how it alters the output or performance. What if we change this support bracket from iron to aluminum? What if we swap out this 100 ohm resistor for a 200 ohm one?
As a curious engineer you could spend many, many hours conducting what-if based experiments, so there is a bit more to this idea then just a random walk of changes. [Read more…]
There is a big difference between Preventive Maintenance Optimization (PMO) and Reliability Centered Maintenance (RCM). Daffodils are a perfect way to explain the difference. [Read more…]
Reliability engineering has an image problem. It is seen as an imbugerance that destroys budget, schedule and fun. People sometimes think reliability engineering is simply statistics, data analysis and other mind-numbing stuff. Reliability purgatory. Which brings us to the first reason you need to do reliability engineering.
#1 – Reliability engineering is not reliability purgatory. Reliability purgatory is all effort and no outcomes. Reliability happens at the point of decision. Design decisions. Manufacturing decisions. Maintenance decisions. True reliability engineering helps you make better decisions – which often comes down to organized judgment and not statistics.
As I headed to work this morning in my Chevy Silverado Truck, this message appeared on my dash console.
As if there aren’t enough distractions these days built into our vehicles (i.e. – GPS, telephones, use of our various electronic devices, iTunes, Email, Text, etc.), do we really need a warning message to read while driving, that is telling us to focus on the road? [Read more…]
Multi-stage horizontal wells have been drilled and completed in shale formations in North America for two decades, and now account for nearly 90% of new wells drilled in the U.S. The Plug and Perf process (PnP) is used for completing most of these wells. [Read more…]
Over the past week, I received a couple of interesting questions. One concerned assuming a Weibull beta value for an accelerated life test plan. The second involved assuming expected life models for elements within a reliability block diagram.
In both cases, we faced incomplete data and uncertainties, yet felt the need to assume some values in order for the math to work out. We do make assumptions in order to solve problems. We also can make mistakes that lead to unwanted consequences. [Read more…]
Based on our understanding of the six failure patterns, we can see that there is a large probability of failure when the equipment is first installed and started up. One of the Englisch causes of this increase in probability is the fact that the equipment was not installed or maintained correctly. This may be due to the installer or maintainer not using or following procedures. Having procedures is the first step to reducing these failures, but the procedures must be written in a clear, easy to follow manner. When writing procedures, it is critical to ensure that there are no interpretations in the written instructions. How can this be accomplished?
The universal language for aviation is english, which is considered very safe and reliable. How has this industry been able to overcome the fact that many of the people involved in aviation are not native English speakers? How does a large company such as Boeing supply aircraft all over the world and the customers perform the maintenance in a consistent manner? The aviation and defense industries use a controlled language by the name of Simplified Technical English.
Simplified Technical English is a controlled version of English, that is designed to help the users of English-language maintenance documentation understand what they read. Technical writing can be complex and difficult to understand even for native English speakers. Complex writing can be misunderstood, which may lead to accidents or premature failures. Simplified Technical English makes procedures easy to understand and follow, eliminating language issues and reducing premature and maintenance induced failures.
Simplified Technical English provides a set of Writing Rules and a Dictionary of controlled vocabulary. The Writing Rules cover grammar and style. The Dictionary specifies the words that can be used and those that can’t be used. For the words selected, there is only one word for one meaning and one part of speech for one word. Some of the benefits of Simplified Technical English may include;
The Simplified Technical English specification is not easy to learn, but there are training and software available (if you are interested in this standard, please visit the ASD Simplified Technical English website). The detailed contents of the Simplified Technical English specification will not be covered, but instead, the rest of the post will cover what you can immediately do to make your procedures more readable and drive reliability.
So without becoming an expert in Simplified Technical English, how can you begin to write better procedures? You can begin with some basic writing practices and by reviewing the procedures before it issued. Some of the basic practices to use when writing procedures include;
Once the procedure is written, be sure to review and delete any information which is not relevant (i.e. Instead of synthetic lubricating oil, use only). well-written should help in eliminating any interpretation and driving clarity.
Here is an example of how the wording of a procedural step could be open to interpretation. The task “Replace the filter” could mean either of the following:
Now you can see how one person may perform a task and how another would perform it differently. Once the task is clear, a technical specification should be added to ensure the task is performed to a standard such as;
The end result of ensuring the task is clear, and a specification is present is “Install a new filter and tighten to 15 ft-lbs” This task is simple, clear and easy to understand.
When following these basic steps a well written procedure will be developed to ensure clarity and repeatability, thereby reducing maintenance induced failures. Do you use a Simplified Technical English or a form of it in your procedures or job plans? If not, how are you actively working to reduce maintenance induced and start-up related failures?
Remember, to find success, you must first solve the problem, then achieve the implementation of the solution, and finally sustain winning results.
I’m James Kovacevic
Eruditio, LLC
Where Education Meets Application
Follow @EruditioLLC
References;
As a risk manager, you will often be asked to explain the RoI (return on investment) of you, your team, even the whole risk management program.
Effective risk management can help an organization grasp an opportunity and realizing an upside risk should generate a positive RoI.
However, when you are focussed on shoring up a weak system, plugging gaps and minimizing risks, showing an RoI can be hard. Even so, an inability to show a positive RoI in a cost-conscious environment can threaten investment in your team. It can even make people question the value of the program as a whole. [Read more…]
Reliability Centered Maintenance (RCM) is without doubt the most effective method to determine your failure management policies, yet it is sometimes seen as an expensive and time consuming endeavor used to produce what some (mistakenly) believe they can get from manufacturer recommendations and other sources. The naysayers see it as a “gold plated” approach to a relatively simple challenge – produce a decent maintenance program.
They couldn’t be more wrong! And that error, could get them into a lot of trouble if circumstances align against them. [Read more…]
“Time is money” – Benjamin Franklin
One of the most common complaints about FMEAs is that they can take a long time to do. This article presents solutions to this challenge.
When I caught my husband cheating, I learned the two criteria for scheduling a maintenance task. Satisfy these two criteria to create an optimized maintenance plan. [Read more…]
There are many scenarios that can arise throughout product development programs. There is one in particular that I have seen unfold more than once: I call it the “Plus one program.” Don’t let the name fool you; it’s horrible to watch unfold.
A startup or established player introduces an impressive jump in industry-standard technology, or sometimes an established player introduces an innovation to their industry. Since the technology is so innovative, there is great value in getting it to market quickly even if it isn’t a mature design. In this case, it is actually a smart move to go to market with a device that doesn’t have “ideal reliability.” In other words, the value of getting it out there quickly is worth the field issues. Those issues will be tolerated by the customer as well, if the technology is that good.
The majority of times that a Root Cause Analysis (RCA) is ‘required’ is often due to some type of threshold of pain being met. Someone is hurt, we’ve had an environmental excursion, we lost a lot of money in throughput or equipment damage, we violated some regulation, etc. Essentially, when the ‘suits’ show up, something bad has happened and we will do an RCA whether we like it or not. This is the basis of ‘reactive RCA’, where we respond to an incident that has already met certain defined requirements, often called ‘triggers’. [Read more…]
A recent student of mine was an engineer for a rail corporation. Let’s call her Liz. Liz kept asking me ‘what do I need to put in a contract’ to make sure my suppliers take reliability seriously? She kept asking this over, and over, until I got the penny to drop. Liz eventually realized that she was the one who had to take it seriously. [Read more…]
