Mit dem Hype um Digitalisierung im Service, dem Einsatz künstlicher Intelligenz und Maschinenlernen, kommt auch das Wissens-Datamining in Service-Tickets immer häufiger ins Gespräch. Die automatische Auswertung einer Vielzahl gelöster Service-Vorgänge verspricht, einen Schatz an Erfahrungen heben zu können. Zu Recht?

Erfahrung ist oft eine gute und verlässliche Wissensquelle. Wenn wir ein Problem bereits einmal gelöst haben, ist diese Lösung ein guter Ausgangspunkt, falls wir erneut vor demselben oder einem ähnlichen Problem stehen. Diese Erkenntnis ist die Grundlage der Wissensmanagement-Methodik Knowledge Centered Service (KCS®). Sie bezieht das kollektive Wissen einer Organisation mit ein, um Kundenprobleme zu lösen und zeitgleich eine wiederverwendbare Dokumentation der Lösung in einer Wissensdatenbank bereitzustellen.

Der Beitrag von Wissen zur Servicequalität

Eine gut aufgebaute Wissensdatenbank unterstützt bei der Problemanalyse, indem sie sich auf das Wesentliche eines Problems konzentriert. Die Struktur ihrer Wissensartikel hilft den Diagnoseprozess zu lenken. Hinweise zum Kontext der Kunden („Was wurde versucht zu tun, während der Fehler auftrat?“) und der verwendeten Umgebung („Welches Gerät, welche Ausführung, welches Betriebssystem, welche Applikation, welcher Versionsstand,….?“) helfen bei der Identifikation der Ursachen und verbessern die Auffindbarkeit der Artikel. Im Lebenszyklus eines Artikels können Informationen aus verschiedenen Kundenvorgängen nach und nach hinzugefügt werden und so das Verständnis des Problemes und seines Auftretens erleichtern. Für die Wissensdatenbank ist daher nicht der Verlauf eines bestimmten Kundenvorganges relevant, sondern das Muster, das sich in vielen gleich- oder ähnlich gelagerten Fällen erkennen lässt. Unser in der Datenbank dokumentiertes Wissen beruht auf unserer Fähigkeit, die unnötigen Details aus den vielen Fällen herauszufiltern. Relevant sind nur deren gemeinsamer Nenner und der Kontext der Kunden. Mit der KCS-Methodik ist es möglich, sich anhand der vorgegebenen Struktur auf die relevanten Teile eines Falles zu konzentrieren und als Nebenprodukt der Problemlösung einen Artikel zu generieren.

Die Hauptanliegen der Methodik sind:

  • Den Wiedergebrauch, die Verbesserung und (falls es nicht existiert) die Erzeugung von Wissen in den Problemlösungsprozess zu integrieren.
  • Den Inhalt der Wissensdatenbank auf der Basis von Nachfrage und Gebrauch weiter zu entwickeln.
  • Eine Wissensdatenbank zu entwickeln, die das jeweils aktuelle kollektive Wissen der Organisation widerspiegelt.
  • Die Fähigkeit einer Organisation zum Lernen, Kollaborieren, Teilen und zur Verbesserung zu fördern und belohnen.

Während ich über die Inhalte von KCS schon öfter geschrieben habe, möchte ich in diesem Artikel speziell darauf eingehen, warum Service-Tickets (als Synonym für „Incident“, „Case“, „Vorgang“ o.ä.) keine gute Ausgangsbasis für das Erlangen von Wissen und Erfahrung der Organisation sind.

Die Rolle von Service-Tickets

Service- oder Support-Tickets werden erstellt, wenn der Benutzer eines Produkts oder Services ein Problem oder eine Frage hat und die Hilfe des Unternehmens bei der Lösung benötigt. Es kann sich dabei sowohl um einen interne Anwender oder externe Kunden handeln. Das Ticket hilft den Wissensarbeitenden im Service, alle Interaktionen mit dem Benutzer zu verfolgen. Alle Schritte zur Lösung des Vorganges werden in dieses Ticket als Referenz eingetragen: Zum Beispiel die Diagnoseschritte bei der Problemanalyse, eine beantwortete Frage des Kunden oder eine Rückfrage bei den Entwicklern oder die abschließende Antwort der Supportorganisation im Allgemeinen. In dem Ticket werden in der Regel die Kontaktinformationen des Anfragenden festgehalten. Außerdem das Datum der Meldung, eine Beschreibung des Problems und die verschiedenen Maßnahmen, die zur Problembehebung ergriffen wurden.

Das System wird während der Bearbeitungsdauer des Vorganges mit neuen und relevanten Daten aktualisiert. Wenn das Problem behoben ist, wird das Ticket als gelöst oder abgeschlossen markiert. Kann es nicht gelöst werden, wird das Ticket als unvollständig, offen oder ausstehend markiert. Tickets können erneut geöffnet werden, wenn mehr Informationen zur Verfügung stehen, um das Problem zu lösen.

KCS-Workflow: UFFA

KCS-Workflow: UFFA (Use it, flag it, fix it, add it.)

Service-Tickets sind Fallakten, nicht mehr

Typischerweise haben Service-Tickets eine begrenzte Lebensdauer. Wenn ein Fall abgeschlossen ist, haben die Wissensarbeitenden keinen Grund, alte Tickets mit neuen Informationen zu aktualisieren. Hinzu kommt, dass das Kennzahlensystem in vielen Service-Organisationen darauf ausgelegt ist, Vorgänge möglichst schnell zu schließen. Aus diesem Grund werden etwaige wichtige Informationen, die nach der Lösung des Problems erhalten wurden, nicht mehr nachgepflegt. Damit gehen Klarstellungen, Revisionen von Annahmen, zusätzliche Diagnosemethoden oder das, was aus anderen ähnlichen Fällen gelernt wurde, für diesen Vorgang verloren.

Falls nun Wissensarbeitende versuchen, ein altes, geschlossenes Ticket nachzuvollziehen, fehlen ihnen viele Informationen. Sie sehen, was über den konkreten Fall und seine Lösung bekannt ist. Es fehlt jedoch das Wissen, was über den betreffenden Fall hinaus über das zugrundeliegende Problem bekannt ist. Das kollektive Wissen der Organisation fließt in die Ticketdokumentation nicht mit ein. Stattdessen wird nur die Historie eines bestimmten Auftretens dieses Problems dokumentiert. Tickets sind lediglich Fallakten und keine Anleitungen für die grundsätzliche Behandlung gleichgelagerter Fälle. Sie dienen dazu, die bei der Lösung eines bestimmten Falls ergriffenen Maßnahmen zu verfolgen.

Im Gegensatz dazu stehen Wissensartikel, die Anleitung dabei geben, das Problem grundsätzlich zu erkennen und zu diagnostizieren. Wissensartikel liefern zusätzliche Informationen über Ursachen und mögliche Analysen zu Differenzierung von anderen Problemen. Die Artikel sind so strukturiert, dass sie die Gemeinsamkeiten des Bekannten darlegen und nicht die Einzelheiten einer bestimmten Situation.

Das ist auch der Grund, warum die klassische  Herangehensweise des Knowledge Engineering bei der Auswertung von Service-Tickets an ihre Grenzen stößt. Mit dem Einsatz von technischen Redakteuren zur Aufarbeitung bereits gelöster Service-Tickets werden zwei Probleme offenbar:

  1. Die im Verhältnis zur Anzahl der Service-Mitarbeiter wenigen Redakteure stellen einen Flaschenhals im Prozess dar. Es dauert einfach zu lange, bis sie sich durch die gelösten Tickets gearbeitet und daraus Lösungsdokumentation erarbeitet haben. Der Aufwand der Wissenserarbeitung ist höher als das Einsparpotential durch den Wiedergebrauch der Lösung.
  2. An dem Bild der Fallakte wird klar, dass der wertvolle Kontext der Kunden im einzelnen Ticket nicht dokumentiert wird. Die Mustererkennung ähnlicher Fälle findet nachgelagert durch die Redakteure statt. Sie ergänzen den fehlenden Kontext mit ihrer Expertise oder auch durch Annahmen. Die von Experten verfassten Lösungen treffen in ihren Formulierungen nicht auf den Kontext der Anwender und werden in Suchergebnissen dadurch nicht auffindbar.
Nachfragekurve im Service mit klassischer Wissensarbeit

Nachfragekurve im Service mit klassischer Wissensarbeit

Macht Wissens-Datamining in Service-Tickets Sinn?

Die Idee, einen großen Datenbestand automatisch nach Mustern durchsuchen zu lassen, ist ein Ansatz, das erste Problem – die Geschwindigkeit – zu lösen. Das Wissens-Datamining verspricht, mithilfe von Algorithmen in einem Berg von Ticket-Heu die Wissens-Stecknadeln zu finden. Und aufgrund der verfügbaren Rechenleistung moderner Computer geht das sehr viel schneller, als menschliche Redakteure dies jemals könnten.

Allerdings löst der Ansatz nicht das zweite Problem, den in der Ticketdokumentation fehlenden Kontext.

Das Nachvollziehen des geschlossenen Tickets ist schon für Menschen nicht einfach, da die Dokumentation darin sich lediglich auf die vollzogenen Maßnahmen bezieht. Ob diese Schritte tatsächlich das Problem gelöst haben oder es andere Ursachen gab, bleibt unberührt. In vielen Serviceorganisationen ist es üblich, Tickets im Anschluss an die Übermittlung des Lösungsvorschlages an den Kunden nach einer vorbestimmten Zeit zu schließen. Und zwar auch (und gerade) dann, wenn der Kunde sich nicht mit einer Erfolgsbestätigung zurück meldet. So wird zwar die Ticket-Statistik befriedigt, doch bleibt offen, ob die Lösung korrekt war oder nicht.

Hinzu kommt, dass die Dokumentation von Tickets immer auf die Formulierungen eines Bearbeiters beschränkt ist. Während Mitarbeiter A das Problem auf seine Weise beschreibt, würde es Mitarbeiter B vielleicht ganz anders schildern. Vor dem Hintergrund Zusammenhänge ähnlicher Fälle bei der Suche im Ticketsystem aufzudecken, ist unwahrscheinlich.

Ein weiterer wesentlicher Aspekt ist die Unterscheidung gleicher Symptome bei unterschiedlichen Fehlerursachen. Und umgekehrt ebenso, dass eine einzige Ursache sich in unterschiedlichen Symptomen äußert. Während dies in einem Wissensartikel grundsätzlich differenziert werden kann, fehlt in dem Ticket eines einzelnen Vorganges immer der dazu notwendige Kontext.

Während das automatische Wissens-Datamining in Servicetickets sehr wohl das Flaschenhals-Problem durch Geschwindigkeit mindern kann, ist es keine Lösung für die Identifikation echten Wissens. Dieses entsteht nur durch die Kolloboration mehrerer Individuen, die an verschiedenen gleichen und ähnlichen Fällen den Ursachen der Probleme auf die Spur gekommen sind. Solches Wissen manifestiert sich nur in Wissensartikeln, die auch nach Abschluss einzelner Vorgänge fortgeschrieben und aktualisiert werden. Es ist also die Natur und der Bestimmungszweck von Service-Tickets, die sie für die automatische Suche nach Zusammenhänge und Service-Wissen ungeeignet machen.

Dafür sind aufgrund ihrer vordefinierten Struktur Wissensartikeln besser geeignet, wie sie in der KCS-Methodik gefordert werden. Deren Aufbau stellt sicher, dass der Kontext des Kunden erfasst und dokumentiert wird, zusammen mit der Beschreibung von verwendeten Systemen und Komponenten. Ergänzt um eine Ursachenanalyse sind diese Artikel eine vollständige Lösungsbeschreibung. Die Mechanismen von KCS stellen sicher, dass diese Artikel nur nach einem positiven Feedback der Kunden fortgeschrieben, aktualisiert und wiederverwendet werden. Sie spiegeln tatsächlich das kollektive Wissen der Organisation wider und sind für das Wissens-Datamining geeignet.