At the beginning of October, CaseBank attended the Field Service Fall conference, in Atlanta. The event was a great success, with a wide variety of presentations including: remote visualization, mobile technology for field service, service/support transformation, effect of internet of things (IOT), organizational change, customer loyalty, safety, relevant service metrics, etc. The conference also included two speaking panels and twelve round-table discussions that promoted an active exchange of ideas between attendees.
CaseBank spoke on the importance of understanding equipment failure modes as a means to balance three repair performance goals that are often in conflict with one another: time (reducing mean-time-to-repair (MTTR)); quality (increasing first-time-fix (FTF) rates); and cost (reducing the number of no-fault-found (NFF) parts).
While observing a fault code and replacing a couple components may get a machine back up and running, it doesn’t provide the necessary feedback to improve those three key metrics (MTTR, FTF, NFF). To improve all three metrics at the same time, it is important to understand the specific failure mode that led to equipment downtime and/or performance degradation in the first place. However, gathering this information is difficult because traditional troubleshooting tools used in the call-center and in the field are cumbersome and inefficient, and because skilled technicians often don’t take the time to properly document their findings. And even if they did, service reports contain many inconsistencies based on differences in style, descriptions and troubleshooting techniques. As a result, the keys to improving MTTR, FTF and NFF, are hidden from the view of equipment operators and OEMs, locked away in silos of personal experience or at best “implied” in the service write-up, all of which are difficult to use for identifying root causes and failure modes.
At the conference, CaseBank presented the idea of replacing troubleshooting guides (TSG), fault isolation manuals (FIM) and equipment test procedures with a diagnostic database of all known and suspected failure modes along with the associated symptoms/observations for each defect. Software then operates on that database to provide dynamic troubleshooting guidance to technicians. The benefit of using a database to store this information, rather than pre-determined decision trees or step-by-step procedures, is that it can hold all known solutions to problems. With software handling the diagnostic reasoning, it becomes easier to create, revise, update, analyze, configure and integrate a database than to create a troubleshooting document. Traditional decision trees and documents, if they’re still required, can be generated automatically from a database, whereas the opposite is not true.
More importantly, with an advanced reasoning engine, call-center and field support personnel are guided through the diagnostic database to quickly isolate the specific failure mode and identify defective parts and repair procedures. That same diagnostic database can be integrated with preventive, predictive and reliability-centric tools including on-board sensors and telematics, allowing automated troubleshooting and fault code validation. Finally, a diagnostic database makes it easier to gather and analyze the results of measurements and observations taken during user troubleshooting sessions, which reveals a lot of the information necessary to identify defect trends and emerging failure modes. These benefits are the direct result of replacing Troubleshooting Guides and Fault Isolation Manuals with a diagnostic database, without which it is virtually impossible to optimize/balance the time, quality and cost (MTTR, FTF, NFF) of equipment repairs.
The attendees at Field Service Fall confirmed that a company’s reputation for reliability, performance, and customer satisfaction is dramatically improved by the speed and accuracy of fault isolation and the accumulation of field experience and troubleshooting knowledge. The best way to deliver these pieces of the puzzle is to deploy an interactive diagnostic database—in the call-center and in the field.