Preserving Elusive Troubleshooting Data
Looking around my office I saw piles of reports, articles half-read, and documents half-written—all covered with various shades of sticky notes—and it was making me miserable . Looking at my laptop, I realized that it too had become unnecessarily cluttered, filled with multiple drafts of documents, presentations, and spreadsheets. Working in this confusion day-in and day-out was unproductive, so it was time to clean it all up.
As I worked, I realized these paper piles and computer folders contained a mixture of good, useful information and worthless junk. The stuff I kept often contained work that I had started and then forgotten. It was frustrating whenever I recognized a presentation, diagram or strategy that I’d been forced to recreate. (I had wasted a lot of time reinventing previous work.) As I dismantled my piles and organized my folders, I also uncovered information that was either no longer relevant or completely out of date, so it wasn’t needed so long as I could get the latest version when necessary. In fact, keeping that old information around would be counter-productive if I used it by mistake, so it really needed to be discarded. Finally, I realized that all the information I kept was still an incomplete record of what I knew, and it was only my memory that was holding these snippets of information together.
Thinking about it now, I realize that my cluttered office has a strong resemblance to the way service information is managed every day to support complex equipment. The machines are constantly evolving with upgrades, modifications, and operating parameters but the service manuals, catalogs, and troubleshooting guides (TSG) are just snippets of information held together by a technician’s memory. And this is a problem
In a previous blog, we talked about how quickly troubleshooting information (in particular) becomes out-of-date after a machine has been put into production. To ensure fast, accurate fault isolation, new information generated in the field needs to be added to the TSG that came with the original equipment. Unfortunately, a lot of this information piles-up on different desks, and in email folders, and never gets added to the TSG that’s being used by the call center and field technicians. And therein lies the parallel to my office-cleaning exercise. Where do you put all this stuff, and how do you find the right stuff when you need it?
The typical approach is to leave the original TSG intact, except for small changes, and add new performance and troubleshooting information to different “silos” based on the equipment type, system type, implementation, configuration, data format, usage, etc. This appears to make it easy for the right troubleshooting information to be shared with a wide audience of service and support personnel, but it doesn’t. (For a more detailed discussion see Part 1 of this blog series.)
Unfortunately, searchable silos are doomed to fail over time, just like my desktop and laptop. Silos force customer support and field technicians to search across every location where the answer might have been stored. But even if a search engine could access all relevant data, no matter where it was stored, the real problem is this: as the amount of information grows within these silos, the list of search results gets longer, forcing technicians to read, understand, and evaluate each one, hoping to resolve the equipment problem. The other alternative is for every technician to become a trained search expert, so they can whittle down that list of search results to a manageable size. But in either case, the quality of the search results will be based on keeping the terminology consistent within every document, manual, report, video and bulletin that gets added to the silos, which is frequently a full-time job for one or more people. The apparently “obvious” choice of silos (knowledgebases) that contain all the service content appears easy and cheap at first, but becomes ineffective, expensive, and ultimately unused within a few years.
Another option is to create fast-track service bulletins, providing a steady flow of information to the help-desk and the field. However, this creates a lot of clutter as technicians struggle to keep up with the volume of information and understanding its relevance. These critical service bulletins, contain updated parts and repair procedures, but often fail to include a complete list of symptoms that identify any unique circumstances for each repair. Without those details, relevant service bulletins become invisible to the technicians investigating specific failure modes or early indicators of future problems.
Some technicians choose to rely on advice that’s posted on expert forums but much of this content is either fairly obvious or educated guesses/opinions, which wastes the technician’s time. Furthermore, suggestions related to multi-symptom equipment problems must be corroborated with other SMEs, before attempting expensive repairs. (As with so many things, when it comes to repairing complex equipment overlooking small details can cause bigger problems.) Just like information silos, if “expert” forums aren’t carefully managed they quickly lose value.
As the number of machines in operation grows, the information required to accurately troubleshoot equipment problems becomes more and more elusive—and silos, service bulletins and forums are all failing to deliver on promised benefits. In contrast to traditional approaches for sharing elusive troubleshooting data, the SpotLight Diagnostic Database (DDB) keeps all troubleshooting information in one place, in a database format, that captures all equipment problems, symptoms, causes and solutions. In addition, SpotLight employs a diagnostic reasoning engine that guarantees call center and service technicians always get the information they need.
- If the problem has occurred before, SpotLight guides them to the solution.
- If it’s a new problem, SpotLight guides them to relevant manuals, escalates the problem to the hotline or SME support, and captures detailed information for root cause analysis.
- If the equipment can download error codes, SpotLight supports automated troubleshooting.
- If equipment reliability is a concern, troubleshooting dashboards reveal new failure modes, defect trends, and emerging problems.
Most importantly, implementing a DDB is less work and provides greater value than traditional methods of retaining and sharing troubleshooting information. Since each equipment problem and solution gets documented when it first occurs, all other technicians benefit by re-using validated troubleshooting procedures. Furthermore, failure modes that have been predicted/ anticipated by engineering can be easily added to the database and then tracked and verified for reliability and predictive maintenance purposes. And finally, the service delays and mistakes that occur due to information silos, invisible service bulletins, and inconsistent expert forums can be eliminated as technicians no longer re-invent troubleshooting procedures for known problems time and time again.
Stay tuned for Part 3 of “All Content Is Not Created Equal.”