|
IMPORTANT NOTE
In 2005, the term General Maintenance was replaced with Corrective Maintenance, which better describes the purpose of the maintenance. These terms are synonomous, so you can use either term, but courseware updated in 2005 and later uses the term Corrective Maintenance. |
Quality Control
The quality of the solution depends on the quality put into the steps.
Getting a complete and accurate symptom description, and reproducing
the
symptom, assures that you fix the symptom the customer wanted you to
fix.
A good damage control plan ensures that you won't make anything worse.
Correct general maintenance shows the customer you care about quality,
and often greatly reduces costs. A correct narrowing process will
reduce
costs, prevent further damage, and ensure that the root cause, rather
than
a peripheral symptom, is fixed. Proper repair or replacement of the
defective
component prevents further damage.
Testing is like inspection in the factory. The few defects that escape the quality controls of the earlier steps are caught here, by showing that the symptom description you recorded and reproduced has been eliminated, and that no further problems have been created. Taking pride is a periodic maintenance item that ensures the quality of you as a troubleshooter and a human being. Preventing further occurrence is the utmost in customer service. The quality of the solution depends on the quality of the steps.
Bottleneck analysis
Use this when the symptom can be described as "it's too (slow, fast,
etc.)". Bottleneck is a special kind of Divide and Conquer (see step
6). One cool and easy bottleneck analysis test is to slow down
a section of the system. If that section is the bottleneck, the system
as a whole will slow down significantly. If not, it won't. The entire March
1998 Troubleshooting Professional Magazine is devoted to bottleneck
analysis.
Don't skip steps
The Divide and Conquer process can be thought of as continually forcing
the problem into ever smaller boxes, until it's trapped. Some of the
worst
troubleshooting debacles I've seen involved the problem escaping the
box.
In other words, the troubleshooter thought he had proved it was in one
area, when it was really in another. When that happens, tests become
inconclusive
and the troubleshooter starts to doubt himself. Whole days can be
wasted.
Take every precaution to avoid this -- don't skip steps.
[ Training | Troubleshooters.Com | About Steve Litt | Email Steve Litt ]