Vom Ticket zum Wissen: Wie Service-Daten Ihren Wissens-Hub automatisch anreichern

Jedes gelöste Ticket ist eine kleine Lektion, die meist verloren geht

Ein Sachbearbeiter, der ein kompliziertes Störungsticket löst, hat in diesem Moment mehr gelernt als in mancher Schulung, aber dieses Wissen bleibt fast immer in einem geschlossenen Ticket stecken, das niemand mehr aufruft, sobald der Fall erledigt ist. Beim nächsten ähnlichen Fall fängt ein anderer Kollege wieder bei null an.

Bei einem Landmaschinenhersteller aus Niedersachsen zeigte eine Stichprobe geschlossener Tickets, dass 22 Prozent der Störungsfälle inhaltlich einem bereits vor Monaten gelösten Fall entsprachen, ohne dass der neue Bearbeiter davon wusste. Im Schnitt kostete die erneute Fehlersuche 90 Minuten, obwohl die Lösung bereits dokumentiert, aber unauffindbar in einem alten Ticket lag.

Warum Tickets und Wissensdatenbank bisher getrennte Welten sind

In den meisten Unternehmen betreut der Kundenservice das Ticketsystem, während die Wissensdatenbank oder das technische Handbuch bei einer ganz anderen Abteilung liegt, oft in der Qualitätssicherung oder der technischen Dokumentation. Beide Systeme laufen unabhängig, niemand hat den Auftrag, Inhalte zwischen ihnen zu übertragen.

Das Ergebnis ist ein seltsamer Umweg: Das Wissen entsteht im Ticket, müsste aber manuell herausgeschrieben, umformatiert und in ein anderes System übertragen werden, ein Arbeitsschritt, der in der Praxis fast nie passiert, weil er niemandem konkret zugeordnet ist.

Was sich aus klassifizierten Tickets automatisch lernen lässt

Sobald Tickets sauber klassifiziert, einer Anlage oder Produktlinie zugeordnet und mit der tatsächlichen Lösung dokumentiert sind, lassen sich Muster erkennen, die vorher unsichtbar waren: Welche Störung bei welcher Maschine besonders häufig vorkommt, welche Lösungsschritte tatsächlich funktioniert haben und welche Ersatzteile dabei regelmäßig gemeinsam bestellt wurden.

Diese Muster sind genau die Rohstoffe, aus denen ein Wissens-Hub entsteht, nur dass sie hier nicht mühsam von einem Redakteur zusammengetragen werden müssen, sondern aus echten, bereits gelösten Fällen stammen.

• Häufigste Störungsursachen je Anlage oder Produktlinie
• Bewährte Lösungsschritte aus tatsächlich geschlossenen Tickets
• Ersatzteile, die im Zusammenhang häufig gemeinsam bestellt werden
• Wiederkehrende Kundenfragen als Grundlage für eine FAQ-Sammlung
• Frühindikatoren für mögliche Serienfehler bei neuen Baugruppen
• Erkennbarer Schulungsbedarf, wenn bestimmte Fälle immer wieder eskalieren

Der Weg vom Ticket zum Wissensartikel

In der Praxis bewährt sich ein Zwischenschritt: Erst wenn ein bestimmtes Störungsmuster mehrfach mit derselben Lösung auftaucht, schlägt das System einen Entwurf für einen Wissensartikel vor, den ein Fachexperte prüft und freigibt. So bleibt die fachliche Qualität gesichert, während die reine Fleißarbeit des Zusammentragens wegfällt.

Bei einem Sondermaschinenbauer aus Hessen entstanden auf diesem Weg innerhalb von vier Monaten 46 neue Wissensartikel allein aus wiederkehrenden Ticketmustern, ohne dass die technische Dokumentation dafür einen einzigen zusätzlichen Termin mit dem Service-Team ansetzen musste.

Wissens-Hub und Ticket-Assistent als zwei Seiten desselben Prozesses

Ein Ticket-Assistent, der Anfragen nur klassifiziert und verteilt, aber das gelöste Wissen danach wegwirft, verschenkt die Hälfte seines Werts. Wie stark sich früh erkannte, wiederkehrende Problemmuster für den Aufbau von Wissen nutzen lassen, zeigt sich besonders deutlich bei Anlagen mit häufigem Servicekontakt.

Damit dieses Wissen am Ende auch dort ankommt, wo es im Tagesgeschäft gebraucht wird, lohnt sich zusätzlich ein Blick auf die Anbindung des Wissens-Hubs an ERP- und MES-Systeme, denn erst dort trifft das Ticket-Wissen auf die Stammdaten der Anlage, die es beim nächsten Einsatz wirklich braucht.