A product reliability program is a process. Like any process, it has inputs and outputs, generally some form of an objective, and feedback. Furthermore, the process may or may not be controlled or even exist as a formalized part of the organization. Reliability may just happen—for good or bad. Results may or may not be known or understood.
In some organizations, the reliability program may be highly structured with required activities at each stage along the product lifecycle. In other organizations, reliability is considered as a set of tests (e.g., environmental or safety compliance). In some organizations, reliability effectively constitutes a part of everyone’s role.
In each example above, the resulting product reliability may or may not meet the customer’s expectations. There isn’t a single process that will always work. Going back to the basic notion of a simple process, one can consider the objective for a moment. For a reliability program, one may desire a specific outcome of a reliable product. The process then should promote activities leading to the creation of that reliable product. This brings up the fundamental question “What is a reliable product, anyway?”
The objective or goal provides the direction and guidance for the reliability program. Clearly stating the reliability goal is a key trait of very effective programs. Leaving the goal unstated or vaguely understood may lead to one or more of the following:
- a high field failure rate,
- product recall,
- an overdesigned and expensive product, and/or
- design team priority confusion.
Another vital element of a process is feedback. This occurs within the process as part of the creation of the output, and it most certainly exists externally based on the output or process results.
The final result for product reliability comprises the customer acceptance or rejection of the product. If the product functions longer than expected, the product is considered a “good value.” If the product fails quickly or often, especially compared to other products providing the same solution, it is considered a “poor value.”
In some organizations the feedback is nonexistent, in others it is captured within a warranty claims system, and in others it resides within service or repair programs. Customers may complain directly with returned products and demands for replacements or indirectly by simply not purchasing the product in the future. Using the feedback within the reliability program enables one to anticipate the customer’s feedback prior to the delivery of the product to the customer. Depending on the product and the organization, this feedback may be very formally determined, highly structured, and very accurate or random, haphazard, and inaccurate. Both types of feedback may be suitable, again depending on the product and organization.
Establishing the appropriate set of feedback mechanisms within a reliability program is done within the context of the product’s reliability goals and the value of the feedback to the organization. The process benefits from feedback that is timely and accurate enough to enable decisions to be made. It is those decisions that lead to the product’s reliability in the hands of the customers.
Bio:
Fred Schenkelberg is an experienced reliability engineering and management consultant with his firm FMS Reliability. His passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs. If you enjoyed this articles consider subscribing to the ongoing series Musings on Reliability and Maintenance Topics.