The Consequences of Poor Maintenance Troubleshooting
Repeat Service Visits
For a clear example of poor troubleshooting, consider the case of returning a car to the dealer because the original problem hasn’t been fixed. This happens over 6,000 times per day. Obviously, not all repeat visits are caused by poor troubleshooting. With so many models and options for cars about half those vehicles return to the dealer because the right parts were missing.
But of those cars making a second, third, or fourth trip to the dealer over 30% are doing so because the problem returned after the dealer “repaired” it and over 10% are returning because the dealer couldn’t duplicate the problem during the previous visit. Despite the significant increase in diagnostic data and fault codes, in the automotive industry, 40% of repeat service visits are driven by poor troubleshooting! (We find similar numbers in other industries as well.) For even the latest equipment, IOT still has trouble separating important signals from all of the noise (or if you prefer, separating the wheat from the chaff).
Higher Mean-Time-To-Repair and No-Fault-Found Rates
Looking beyond poor first-time-fix numbers (i.e., repeat service calls), inaccurate troubleshooting also drives up mean-time-to-repair and no-fault-found parts replacements. Considering that almost half of all service calls (both planned and unplanned) require some form of diagnosis, accurately identifying the root cause of problems has become a major focus for equipment manufacturers and service providers (dealers). Given that the best troubleshooting knowledge is locked away in the heads of experts, scattered across the service workforce the question becomes, “How can a manufacturer improve troubleshooting for its equipment while also collecting, analyzing and disseminating field experience?”
With that background, here’s what we’ve covered in this series.
All Content Is Not Created Equal Round-Up
Part 1: An Oversaturated Call Center
The conventional approach to capturing field experience involves gathering service reports into an online, searchable “knowledge base” or web portal, often part of a content/knowledge management system (CMS/KMS). Collecting these reports from field personnel is relatively straightforward, although incentives may be necessary, over time a web portal becomes bloated with redundant, incomplete, and sometimes conflicting or incorrect information. The failure of a CMS/KMS to quickly provide consistent access to relevant information, that actually answers technician’s questions, leaves most technicians no better off than before (and fully disillusioned with knowledge management). Time-pressured technicians need fast, accurate diagnostic guidance, not a long list of seemingly useful documents that turn into a drawn-out research project.
Instead, when technicians get stuck figuring out the cause of an equipment problem most of them simply call the hotline. In a perfect world, technical hotlines would be staffed by subject matter experts (SME) who can recognize important symptoms that expose tricky problems and then deliver a prompt diagnosis. Unfortunately, that’s not the case for most hotlines and with the growing complexity of equipment, technicians end up getting bounced around from one supposed SME to another. (Just like a customer.) So web portals and hotlines don’t provide a long-term solution to the challenge of improving troubleshooting.
Part 2: Preserving Elusive Troubleshooting Data
The reality is, there is already a wealth of information available to improve troubleshooting but it resides in multiple locations and gets lost within a lot of other “noise.” (By the way, filtering that noise was the original goal of the KMS in the first place.) However, no matter where the relevant information is stored, technicians need a better way to evaluate it so they can recognize and repair the right problem. Current approaches, including web portals, ask the technician to find a needle in a haystack of information, where success is totally dependent on their ability to use sophisticated search tools.
To capture, preserve and reuse troubleshooting data a better option is a diagnostic database (DDB) combined with a diagnostic reasoning engine. The database holds information about equipment failure modes—symptoms, causes and solutions along with various attributes, observations and diagnostic test results. The diagnostic reasoning engine then leverages the DDB to guide the troubleshooting process, within the context of each machine being repaired, and identify the failure mode and necessary procedures to resolve the equipment defect.
Part 3: Isolate Troubleshooting Procedures
Troubleshooting guidance is significantly different from parts, test and repair instructions. The point of troubleshooting is to identify the root cause of a problem. Since complex equipment is used by multiple customers in various environments, once machines get deployed to the field the knowledge about how they actually operate and fail increases rapidly. Call centers and technicians need that troubleshooting information to be captured and deployed just as rapidly—with daily updates to the diagnostic database. On the other hand, parts, test and repair instructions rarely change and can be effectively managed using a conventional CMS/KMS approach. From this perspective, separating diagnostic information into a database makes sense because a database is the right tool for information that expands constantly and changes frequently.
Utilizing a Diagnostic Solution For Optimized Results
To optimize troubleshooting, where speed, accuracy and consistent results are imperative, using a diagnostic database and reasoning engine is the most cost-effective solution. The DDB, as described above, is conceptually very straightforward but the diagnostic reasoning engine represents an important breakthrough.
How The Reasoning Engine Works With a Diagnostic Database
First, the reasoning engine continuously evaluates the entire DDB to identify all possible failure modes that match the known symptoms. The reasoning engine then pulls digital data from the machine (IOT) and records observations and test results from the technician to narrow down the list of potential defects and quickly identify the cause of the failure. (Unlike decision trees or probability approaches, the sequence of error codes, tests and observations is irrelevant to the reasoning engine, so technicians never get “trapped” in a branch of a troubleshooting tree.)
Second, once the defect has been isolated the reasoning engine automatically links to the information needed to fix the equipment (repair procedures, part numbers, service bulletins, theory of operation, etc.), which is often located in a CMS/KMS or web portal.
Third, whenever a technician discovers a new failure mode the reasoning engine sets in motion a process to capture relevant information and escalate it to engineering so the new solution can be quickly deployed for future troubleshooting activities. Fourth, DDB reports (dashboards) reveal failure trends based on “real-world” equipment operations, allowing engineers to quickly take the appropriate corrective actions.
Today, armies of technicians around the world are resolving equipment defects and identifying new ones (on a daily basis). These technicians generate a wealth of information in the form of best practices and service reports but most of it is trapped in the heads of various subject matter experts, where it’s unavailable to help other technicians. The traditional idea of throwing all that information into a searchable web portal seems reasonable but normalizing and deploying all that data in a usable format takes an enormous amount of time and money. (And by the time the data has been processed and deployed to the web portal much of the “latest” information is well on its way to being obsolete.) If the goal of a CMS/KMS or web portal is to improve troubleshooting it is bound to fall short of expectations (and this gets re-proven every day). That’s because the majority of information that gets loaded into a web portal is irrelevant to the actual diagnostic process and only becomes relevant after the root cause of the problem has been identified.
A diagnostic database and reasoning engine quickly and accurately troubleshoots equipment on the first try. Once the equipment problem has been identified, the correct parts and repair procedures can be quickly located within the CMS/KMS or web portal. To fully optimize equipment service and support—focusing on time, cost and quality—it all starts with troubleshooting.