Another blog entry from Musing about Reliability

1. f m sre liabilit y.co m
http://www.fmsreliability.co m/educatio n/reliability-pro gram-structure/
Reliability Program Structure
A product reliability program is a process. Like any process it has inputs and outputs, generally some f orm of
an objective, and f eedback. 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 lif ecycle. In other organizations, reliability is considered as a set of tests (e.g. environmental
or saf ety compliance). In some organizations, reliability is ef f ectively a part of everyone’s role.
In each example above, the resulting product reliability may or may not meet the customer’s expectations.
T here isn’t a single process that will always work. Going back to the basic notion of a simple process, consider
the objective f or a moment. For a reliability program, one may desire a specif ic outcome of a reliable product.
T he process then should promote activities leading to the creation of that reliable product. T his brings up the
question of what is a ‘reliable product,’ anyway?
T he objective or goal provides the direction and guidance f or the reliability program. Clearly stating the
reliability goal is a key trait of very ef f ective programs. Leaving the goal unstated or vaguely understood, may
lead to one or more of the f ollowing:
High f ield f ailure rate
Product recall
Over-designed and expensive product
Design team priority conf usion

2. Another vital element of a process is f eedback. T his 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.
T he f inal result f or product reliability is the customer acceptance or rejection of the product. If the product
f unctions longer than expected, like an HP calculator, the product is considered a ‘good value’. If the product
f ails quickly or of ten, especially compared to other products providing the same solution, it is considered of
‘poor value’.
In some organizations the f eedback is non-existent, in others it is captured within a warranty claims system, in
others within service or repair programs. Customers may complain directly with returned products and demands
f or replacements, or indirectly by simply not purchasing the product in the f uture.
T he f eedback within the reliability program attempts to anticipate the customer’s f eedback prior to the delivery
of the product to the customer. Depending on the product and the organization, this f eedback may be very
f ormally determined, highly structured and very accurate. Or, the f eedback may be random, haphazard and
inaccurate. Both types of f eedback may be suitable, again depending on the product and organization.
Establishing the appropriate set of f eedback mechanisms within a reliability program is done within the context
of the product’s reliability goals and the value of the f eedback to the organization. T he process benef its f rom
f eedback that is timely and accurate enough to make decisions f rom. It is those decisions that lead to the
product’s reliability in the hands of the customers.
T heref ore, the basic structure f or any reliability program is to clearly establish and state the reliability goal.
Af ter that, its necessary to determine the appropriate set of f eedback mechanisms that provide timely
inf ormation, to permit design and production decisions. A primary role of a reliability engineering prof essional is
to create this basic structure f or a reliability program plan.