Technical Memory: Erfahrung aus jedem Serviceeinsatz wieder nutzbar machen

Warum Servicewissen heute verloren geht

In größeren Service-Organisationen passiert eine typische Sequenz: Ein Techniker diagnostiziert eine Störung an einer Anlage, erstellt einen Servicebericht, löst das Problem. Der Bericht wird archiviert. Wenn dieselbe Störung sechs Monate später bei einer anderen Anlage auftritt, beginnt die Diagnose wieder bei null. Das erlebte Wissen sitzt in den Köpfen einzelner Mitarbeiter. Scheiden diese aus, geht das Wissen verloren oder wird schlecht wieder zugänglich.

Die klassische Maschinenhistorie dokumentiert zwar jeden Serviceeinsatz chronologisch – aber sie erklärt nicht, warum eine Störung auftrat und welche Maßnahme tatsächlich geholfen hat. Ursache, Diagnose und Maßnahme sind oft über mehrere Berichte, E-Mails und Gespräche verteilt. Gleichzeitig wiederholen sich ähnliche Fehler, weil das Erkannte nicht strukturiert und verlässlich verfügbar ist.

Der Kreislauf: von der Störung zur bestätigten Erkenntnis

Das Technical Memory von Eternitree durchläuft einen neunstufigen Prozess:

1. Anlage erfasst Verfügbar

   Equipmentstamm mit Stammdaten, Betriebsstunden, Dokumenten und Historie sind als Kontext verfügbar.

2. Störung gemeldet Verfügbar

   Ticket wird erstellt mit Problembeschreibung, Fehlercode, erste Hinweise vom Kunden.

3. Serviceeinsatz durchgeführt Verfügbar

   Techniker vor Ort, Messwerte, Diagnose, Maßnahme, Ersatzteile, Betriebsstunden beim Einsatz.

4. Bericht und Daten erfasst VerfügbarGeplant

   Servicebericht mit Dokumentation, importierte Arbeitsberichte, Spracheinträge (später), Telemetrie- und Messdaten als Zeitreihen (geplant).

5. Strukturierte Erkenntnis gebildet In Entwicklung

   OCR und KI-Assistenz extrahieren aus dem Bericht: Fehlerbild, vermutete Ursache, Maßnahme, betroffene Teile, Betriebsstunden beim Auftreten. Rückverweis zum Original bleibt erhalten.

6. Fachliche Bestätigung VerfügbarIn Entwicklung

   Berechtigte Fachperson prüft die Erkenntnis, bestätigt Kausalität und Gültigkeitsbereich, schreibt Freigabe. Die Erkenntnis wird Teil der verifizierten Wissensdatenbank.

7. Technical Memory verfügbar Geplant

   Das bestätigte Ursache-Maßnahme-Wissen mit Beleg, Prüfer und Gültigkeitsbereich ist im Memory indexiert und bereit für die nächste ähnliche Situation.

8. Ähnliche Fälle erkennen VerfügbarGeplant

   Im nächsten Ticket zeigt Eternitree heute schon ähnliche Tickets, passende Wissenseinträge und Checklisten; der Vergleich technisch ähnlicher Anlagen ist geplant. Wiederholungserkennung warnt, falls ein Fehler erst kürzlich schon vorkam.

9. Bessere Entscheidung beim nächsten Einsatz

   Der Techniker erhält beim ähnlichen Fall sofort Kontext: „Diese Störung gab es bei Anlage XYZ, Ursache war Ventilspiel, Maßnahme war Prüfung und Justage." Erspart Fehlersuche und Rückfragen.

Der Kreislauf schließt sich: Jeder neue Serviceeinsatz fügt potentiell neue Erkenntnisse hinzu, die dann wieder bei ähnlichen Fällen helfen. Das Wissen wächst strukturiert und bleibt erhalten.

Originalbericht und Erkenntnis bleiben getrennt

Ein Grundprinzip: Der Originaleintrag (Dokument, Seite, Text, Importzeit, Quelle) ist unveränderlich. Niemand kann aus Versehen oder Absicht einen Bericht rückwirkend editieren. Die strukturierte Erkenntnis entsteht separat und verweist zurück auf den Beleg.

Eine aus einem Bericht extrahierte Erkenntnis trägt zunächst den Status „vorgeschlagen". Sie wird nicht still überschrieben, wenn jemand meint, eine andere Begründung sei besser. Stattdessen wird die Änderung sichtbar dokumentiert, und die neue Fassung braucht erneut fachliche Freigabe. So entsteht Nachvollziehbarkeit und Vertrauen in die Wissensdatenbank.

Warum fachliche Bestätigung wichtig ist

Ein warnendes Beispiel: Betrachten Sie ein Bauteil, das an einem Motortyp zwölfmal in sechs Monaten ausfällt. Das klingt nach einem defekten Bauteil oder Designfehler. Aber ohne weitere Information ist das nur eine Beobachtung, keine Ursache. Folgende Fragen sind entscheidend:

• Wie viele Motoren dieses Typs sind überhaupt im Einsatz (Vergleichsgruppe)?
• Sind diese zwölf Ausfälle clustert auf ein Revisions-Datum oder einen Hersteller-Los?
• Wie viele Betriebsstunden hatte jeder Motor beim Ausfall?
• Wie lange wird der Motor üblicherweise betrieben, bevor er gewartet wird?

Was heute schon im Ticket passiert

Im aktuellen Technical-Memory-Bereich eines Tickets sehen Sie:

Beispiel: Diese Störung gab es schon

Ein fiktives Szenario mit echten Prozessen:

Wo KI hilft – und wo nicht

Im Technical Memory nutzen wir KI für quellengebundene Assistenz: Der KI-Assistent (aktuell Pilot) schlägt vor, extrahiert aus Berichten, ordnet zu – aber jede Antwort verweist auf ihre Quelle. Ein Service-Mitarbeiter sieht immer: „Das System schlägt vor, dass die Ursache XYZ ist, weil Bericht 4711 und Betriebsstunden Y das zeigen." Die KI ist ein Helfer, nicht die Autorität.

Es gibt keine Antwort ohne Quelle als Ziel. Statements wie „Das System sagt, Ursache ist wahrscheinlich XYZ" ohne Beleg sind nicht akzeptabel. So bleibt das Wissen nachvollziehbar und justierbar.

Status und Roadmap

Eine erste stabile Version mit Wissensdatenbank, Freigabe-Workflow und ähnlichen Tickets ist für die Mitte 2027 geplant.