FVI experts' breakfast

15th FVI Expert Breakfast

Systematic Troubleshooting and Sustainable Problem Solving in Maintenance

Friday, January 24, 2025

Key Takeaways

Topic: "Doctor Maintenance" – Systematic Troubleshooting and Sustainable Problem Solving.

In this session, moderated by Bernhard Heindel (representing Jens Reisenweber) and Marcel Hahn, everything revolved around the question: Why do we repair the same fault five times instead of solving it once? Guest was Peter Vogtmann, the expert in methodical troubleshooting.

  • Symptom vs. Cause: Peter Vogtmann explained the difference between "repair" (symptom gone) and "problem solving" (cause gone). Many maintenance workers are proud when the machine runs again, but they have only put on a "band-aid". True excellence is when the fault never returns. Methods like Ishikawa or 5-Why are needed for this.
  • The Information Gap: The critical moment is the shift change. The operator sees the disturbance ("It rumbled"), presses a few buttons, and leaves. The maintenance worker comes later and finds a "black box". Without a clear fault description ("What exactly did you hear?") an expensive guessing game begins.
  • Time Pressure as the Enemy of Sustainability: Jörg (abrasive manufacturer) brought in the reality: When production screams "We have to deliver!", you just put on the band-aid. But the maintenance worker must have the backbone to say: "Okay, we'll do a quick fix now, but I need a time slot for the real repair next week, otherwise it will really blow up."
  • Data Quality is Everything: Klaus (Siemens) and Christian (Bayer) confirmed: The reporting quality from production is often "abysmal" ("Machine broken"). If we don't get better data, we can't analyze.
  • Digitization of Reporting: Christian (Bayer) demanded: "I don't want to type texts anymore. I want to take a photo and send a voice message, and AI should enter it into SAP." This lowers the hurdle for the operator to make a report at all.

Classification: Methodological competence meets technology

This episode provides the methodological basis for what ADAM implements technically:

  • ADAM as "Translator": The problem "poor reporting quality" is solved by ADAM through AI. The operator says: "Something is rattling here." ADAM asks back: "Where exactly? Can you take a photo?" and then categorizes the problem neatly in the system. Thus, "machine broken" becomes a usable data set.
  • Sustainability through History: To conduct root cause analysis, I need to know: "Have we had this before?" ADAM's "Asset Intelligence" searches the entire history and manuals and tells the technician: "This fault occurred 3 months ago, back then it was bearing X." This prevents the eternal "band-aid sticking".
  • Methodology "on demand": Not every technician masters Ishikawa diagrams offhand. ADAM can guide the technician: "Let's do 5-Why. Why is the motor hot? -> Because cooling is off. -> Why is cooling off? -> Because the filter is clogged." This democratizes methodological competence.

Conclusion: Systematic troubleshooting is not rocket science, but often fails due to lack of time and poor communication. ADAM alleviates the time pressure by automating research and simplifying communication.