Probleme beim Einloggen

Knowledge Centered Service (KCS®)

KCS ist eine bewährte Praktik für das Wissensmanagement in Service-Organisationen. Hier geht es um Training und die Einführung der Methode.

Kai Altenfelder 26.03.2019: KCS in Action at Blizzard Entertainment (Websession)
Kommenden Dienstag findet wieder eine Websession "KCS in Action" statt. Eine gute Gelegenheit, hinter die Kulissen anderer Unternehmen zu schauen, die KCS bereits eingeführt haben und seit längerer Zeit betreiben:
https://www.eventbrite.com/e/kcs-in-action-at-blizzard-entertainment-web-session-registration-54715215683
Kai Altenfelder Wissens-Datamining in Service-Tickets
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.
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.
Der Artikel erschien zuerst auf https://www.pro-accessio.de/2019/03/18/wissens-datamining-in-service-tickets/ und enthält dort zusätzliche Grafiken.
KCS® ist eine Service-Marke des Consortium for Service Innovation.
Kai Altenfelder Erfahrungsbericht: Einführung einer Selfservice-Strategie mithilfe von KCS
Der ITSM-Toolhersteller TOPdesk beschreibt in einem aktuellen Blogpost von den Erfahrungen einer "ShiftLeft"-Strategie (Selfservice) und welche Rolle KCS dabei gespielt hat:
https://blog.topdesk.com/de/wie-shift-left-erfolgreich-eingef%C3%BChrt-werden-kann
Kai Altenfelder KCS User Group Meetings 2019
Nachdem ich vorvergangenes Jahr vermutlich einfach zu früh mit der Idee war (https://www.xing.com/communities/posts/erfahrungsaustausch-in-user-groups-1013935302), möchte in 2019 einen neuen Anlauf nehmen und KCS-Anwendertreffen durchführen.
Nach einem Blick auf die Mitgliederliste dieser Gruppe und Ihre jeweiligen Wohn- bzw. Wirkungsorte kommen meiner Meinung nach vier Treffen in Frage:
- Norddeutschland (KW 21, 22.05.)
- Westdeutschland (KW 23, 03.06.)
- Berlin / Ostdeutschland (KW 25, 20.06.)
- Deutschland-Südwest/Schweiz (KW 26, 27.06.)
In den anderen Regionen sind zurzeit noch zu wenige Interessenten und Anwender vertreten.
Um ein Stimmungsbild einzufangen, bitte ich Sie, Ihr Interesse unverbindlich zu bekunden: https://doodle.com/poll/xx8u4bibeaavt3tv
Herzliche Grüße,
Kai Altenfelder
Kai Altenfelder Lessons learned in Intelligent Swarming
Nachdem ich gestern noch selber ein Webinar als Überblick über den "Intelligent Swarming"-Ansatz gegeben habe (https://www.youtube.com/watch?v=blF92y6TuMc),
bin ich heute über einen passenden Artikel gestolpert:
https://www.linkedin.com/pulse/lessons-learned-intelligent-swarming-adam-maino/
Darin beschreibt Adam Maino, Director of Support bei FinancialForce.com, seine Erfahrungen mit der Einführung von Intelligent Swarming. Was bin ich froh, dass er im Wesentlichen die selben Aussagen macht wie ich gestern auch schon:
Der Erfolg der Einführung hängt davon ab, dass man den Fokus auf den Kulturwandel und nicht die prozessuale Umsetzung legt - die Belegschaft muss den Wandel aus freiem Antrieb heraus selber wollen. Die Prozesse und Tools hingegen müssen daher von Wissensarbeitenden selber gestaltet und designt werden, nicht vom Management.
Ich bin gespannt, welches Unternehmen sich hierzulande als erstes zur Swarming-Idee bekennt und sie umzusetzen versucht.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Knowledge Centered Service (KCS®)"

  • Gegründet: 03.04.2017
  • Mitglieder: 96
  • Sichtbarkeit: offen
  • Beiträge: 61
  • Kommentare: 6