Regulated Industries, Separate Troubleshooting Procedures to Ensure Safety
In recent blogs I’ve described a problem faced by every manufacturer and operator of complex equipment, namely the challenge of understanding all the different ways that machines can fail (failure modes). Whether a machine stops functioning entirely or whether its’ performance falls below expectations, for the owner/operator that machine is now defective. Since most modern equipment depends on multiple electronic and software components, the complex interactions between these systems makes it impossible for manufacturers to predict, prepare and document everything that might go wrong in the field. Therefore, every time a new type of machine goes into operation, new information about failure modes arrives rapidly and relentlessly. As field experience grows, OEMs spend a lot of time generating service bulletins and updating diagnostic procedures trying to keep up with the flow of new information. But these manuals are perpetually out-of-date. Much of the time and cost of these revisions is driven by a desire to modify existing procedures (to identify new failure modes) without making the original guidance more complicated.
As a result, I have consistently recommended separating the diagnostic information from the conventional service documents, using a diagnostic database (DDB) to organize it and interactive software to deliver it.
Implementing a DDB for troubleshooting guidance (not maintenance instructions) raises some interesting questions when viewed in the context of regulated industries, where public safety is a significant factor (e.g., aviation, transit, rail, etc.). Regulated environments often require maintenance procedures to be approved by a designated authority prior to being released to the field technicians. Since diagnostic steps change frequently, the process of approving every change to troubleshooting guidance could delay their availability to the point that it reduces safety and increases operating costs and downtime. On the other hand, repair and replacement instructions do not change frequently, so the longer approval process does not really affect service manuals. With a DDB the longer approval cycle for troubleshooting guidance can be eliminated, allowing technicians to quickly respond to emerging safety and performance concerns. Any procedures required to disconnect, remove or replace components already appear within the approved service and repair manuals.
This is the essential point: troubleshooting guidance is not the same as maintenance and repair. Troubleshooting is the act of gathering relevant information, combined with decision-making (or reasoning), to determine the cause of an equipment problem. Maintenance and repair is the act of modifying the equipment in some way—for evaluation, adjustment, or replacement of parts.
If diagnostic guidance was required to follow the same regulatory approval cycle as service manuals, then critical field experience would arrive late to the field and technicians would find it nearly impossible to recognize and respond to new failure modes. Such an approach would be counterproductive to the safety goals of the regulations.
When diagnostic guidance is managed by a DDB the maintenance manuals are still effective, despite their long revision cycles, but the DDB can quickly implement best practices from the field to identify emerging problems and new failure modes. (The DDB is still quality-controlled, but can be updated much faster and cost-effectively.)
There is an argument to be made that troubleshooting procedures can affect safety because they often require components to be disabled, removed or replaced in order to complete inspections or run diagnostic tests. These steps are considered maintenance activities and should be performed according to the approved maintenance instructions. Troubleshooting guidance simply requests information to identify the source of a problem, whereas maintenance is the act of altering the equipment to run a test or restore proper performance. These two aspects of product support can, and should, be separated. By having the DDB refer to removal and repair procedures within the authorized service manuals, rather than duplicating those procedures, equipment safety actually increases because service instructions remain consistent (i.e., manuals never get “out-of-sync”).
The key to the DDB approach is to recognize that troubleshooting guidance essentially boils down to identifying symptoms and asking questions. If troubleshooting procedures must be “approved” then whenever they fail to ask the right questions, meaning they lack the latest information and can’t identify the problem, then the technician would be forced to request special permission to try a different approach to isolate the defect. Meanwhile, the aircraft, railcar or locomotive would remain out of service, which is a ridiculous and untenable situation for any operator.
Separating diagnostic procedures from maintenance manuals and putting it into a diagnostic database (DDB) makes sense across all industries, and offers particular benefits for regulated industries. In regulated environments,
- A technician must follow authorized instructions, or their accepted equivalent, when performing maintenance and repairs.
- As part of the service process, troubleshooting procedures guide technicians to look for specific symptoms and ask relevant questions, which is different from repairing and replacing components.
- Consequently, technicians try to use whatever steps are necessary to determine the underlying cause of a problem.
- If components need to be disconnected or replaced to isolate a defect, technicians must follow approved service instructions.
- Pure troubleshooting guidance does not include any service procedures and therefore do not require the approval of regulatory authorities.
- As a result, diagnostic procedures should be managed within a DDB where they can be documented, revised, validated and maintained more efficiently.