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 a conscious part of the organization. Reliability may just happen, 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 is effectively 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, 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 question of 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:
- High field failure rate
- Product recall
- Over-designed and expensive product
- 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 is the customer acceptance or rejection of the product. If the product functions longer than expected, like an HP calculator, 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 of ‘poor value.’
In some organizations the feedback is non-existent, in others it is captured within a warranty claims system, in others within service or repair programs. Customers may complain directly about returned products and demands for replacements, or indirectly by simply not purchasing the product in the future.
The feedback within the reliability program attempts to anticipate the customer’s feedback before 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, the feedback may be 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 make decisions from. It is those decisions that lead to the product’s reliability in the hands of the customers.
Therefore, the basic structure for any reliability program is to clearly establish and state the reliability goal. After that, it’s necessary to determine the appropriate set of feedback mechanisms that provide timely information, to permit design and production decisions. A primary role of a reliability engineering professional is to create this basic structure for a reliability program plan.
Leave a Reply