Service Desk – Dokumentation mit Tools

In der ITIL®-Dokumentation findet sich ein ganz schönes Bild: Die SKMS (Service Knowledge Management System). Ich hoffe es ist konzeptionell und nicht technisch gemeint. In erstaunlich vielen Projekten werden nämlich diverse Tools für viel Geld miteinander verknüpft, teilweise mit unidirektionalen Schnittstellen oder ähnlichen faulen Kompromissen und danach kommt es nicht zum erhofften Wunder der Wissensvermehrung.

Bevor ich dazu komme der Wissensflut etwas Struktur zu geben, sei mir ein deutlicher Hinweis auf den Tool-zentrierten Unsinn erlaubt. Stellt Euch einmal vor ihr hättet einen Service Desk zu übernehmen der alles benötigte Wissen sauber mit Bleistift und Papier gepflegt hätte und euch den Ordner übergeben würde? Ist das als zukünftiger Provider eher eine gute oder schlechte Ausgangslage?

Wenn die Schrift nicht allzu krakelig ist, ist das doch wohl prima. Auf zum Kopierer und es kann sofort mit einem Teil des Trainings losgelegt werden. Währenddessen kann das Wissen sortiert, strukturiert und abgetippt werden. Der letzte Punkt ist sehr entscheidend, denn nur wenige Service Desk Agenten sind in der Lage Wissen aus den Köpfen der Kollegen in eine strukturierte Dokumentation zu transferieren.

Bei vielen Projekten wird sich auf das Tool gestürzt, die Anforderungsdefinition formuliert und vergessen das Teilprojekt Dokumentation voranzubringen. Dies ist jedoch auf jeden Fall das wichtigste Sub-Projekt. Dokumentation ohne Tool ist nicht toll, aber brauchbar. Ein Tool ohne Inhalt ist teurer Computerschrott, lieber abschalten das spart Strom.

Bei einem sehr technik-verliebten Kunden hatte ich den Fall, dass alle Energie in das Tool gesteckt wurde, dem wichtige Funktionen für den täglichen Gebrauch fehlten, die in Phase 2 kommen sollten. Wegen der langfristig ausstehenden Nutzbarkeit hatte ein Agent vom Service Desk Team eine eigene Piraten-Lösung gebaut, die gut brauchbar war, jedoch nach Entdeckung durch das Management eingestellt werden sollte. Um die Kosten-Nutzen Situation plakativ darzustellen: Das offizielle Tool hatte bis dahin pro Wissensartikel ca. 4.300 EUR Verwaltungskosten verschlungen. Ein echtes Knowledge Management, das seinen Namen verdient, hat diese Firma meines Wissens bis heute nicht.

Es ergibt sehr viel Sinn die Wissensdatenbank (KB) von dem ITSM-Tool (Ticket-Tool) zu nutzen, wenn denn die Kernfunktionen abgedeckt werden können. Was diese Kernfunktionen sind muss jede IT Organisation selbst bewerten, doch kann ich etwas Anleitung geben.

Zielgruppen

Die Wissenseinträge werden je nach Organisation von Endanwendern, dem Service Desk, den Resolvern (Lösungsteams), den operativen Teams (Technikern) und den Entwicklern (Programmierern) genutzt. Beispiel: Ein Dokument, das die Reparatur einer nicht startenden Software beschreibt, sieht für obige Zielgruppen unterschiedlich aus. Der Inhalt geht von „Bitte nicht selbst versuchen“, über Re-Installation bis hin zu einem Verweis auf die Knowledge-Base des Herstellers der Software.

Ein Inhalt muss demnach für unterschiedlich Anwender der KB unterschiedlich aussehen. Dies kann über eine ausgeklügelte Rechteverwaltung der KB aber auch durch eine gute Verschlagwortung geschehen. Wichtig ist, dass die Autoren immer sämtliche Dokumente so einer Serie im Auge haben, falls Angaben erneuert werden oder das Problem nicht mehr existent ist.

Einsatzfelder

Betrachten wir mal den Hauptnutzer der KB den Service Desk. Der Service Desk soll durch die KB lernen, um mehr Vorfälle lösen zu können. Also ist die Sofortlösungsquote (First Call Resolution) hier das Hauptthema. Den größten Erfolg hat ein Service Desk Agent, der die häufigsten Fälle aus dem Kopf lösen kann. Da sich die häufigsten Fälle von Woche zu Woche leicht ändern, sollte die KB eine Funktion dafür bieten. Das muss keine ausgeklügelte Statistik Funktion sein, es reicht wenn der Service Controller (Supervisor) Artikel markieren und für das wöchentliche Teammeeting herausfiltern kann.

Eine weitere Chance auf Erstlösung hat ein Agent, der während des Telefonats in der KB sucht. Zugegeben die Chance einen Artikel zu finden, zu überfliegen und anzuwenden ist klein, jedoch ist es möglich den Artikel so zu strukturieren, um den Endanwender nach den benötigten Informationen zu befragen und den Vorfall im Nachgang ohne Rückruf zu lösen. Eine simple Volltextsuche ist hier nicht angemessen, die Trefferanzahl wäre viel zu hoch, aber eine gute Verschlagwortung hilft.

Kategorisierung und Verschlagwortung

Die Verschlagwortung sollte so aufgebaut sein, dass Artikel aufgrund einer Beschreibung eines Endanwenders (bzw. der Zielgruppe) gefunden werden können. Ein Anwender umschreibt den Zugriff auf ein Archivierungssystem etwa mit den Worten „Auf dem Apollo-Server kann ich Rechnungen nur sehen, aber nicht ablegen.“, also muss auch so die Verschlagwortung aufgebaut werden. Produktnamen und Struktur sollte über eine Kategorisierung und möglichst nicht über Schlagworte kommen.

Der Kategorienbaum für die KB sollte sich an den Kategorienbaum im ITSM-Tool anlehnen. Wie das geht steht hier. Kategorisierung und Verschlagwortung ist – wie man sich vorstellen kann – ein Thema, das sorgfältig entwickelt, gepflegt und fortentwickelt werden muss. Dazu bedarf es eines verteilten Autorenteams in dem mindestens ein Vertreter aus jeder Zielgruppe sitzt. Dieses Gremium sollte einen Autorenleitfaden pflegen in dem die Grundsätze der Strukturierung festgelegt werden.

KPIs für die KB (Knowledge base)

Bei der Knowledge Base kommt es auf das richtige Maß von gut gepflegtem Inhalt an, deshalb sind absolute Zahlen an Einträgen oder ähnlich kein sinnvolles Messkriterium. Sehr schön funktionieren vorgegebene Auf- und Abbauraten. Zu Beginn etwa ein Zuwachs an 15 und Abbau von 5 Artikeln pro Monat. Nach einiger Zeit wird daraus 10/5 und später 5/5. Wichtig ist veraltete Artikel zu erkennen, zu löschen oder vollständig zu überarbeiten.

Um veraltete Artikel zu identifizieren bietet sich neben aufmerksamen Lesern, die den Missstand aktiv melden auch statistische Funktionen der KB an, wie oft ein Artikel gelesen wurde oder auch eine Möglichkeit der Bewertung ob ein Artikel nützlich war.

Funktionen die ein schöner Mehrwert sind

Ein Wissenseintrag sollte immer von einem Spezialisten geschrieben, von jemanden auf Zielgruppenebene redigiert, freigegeben und gewartet werden. Es ist absolut sinnvoll öffentliche Anmerkungen an einen Artikel anhängen zu können. Diese können dann sofort genutzt und schnell in eine nächste Version eingearbeitet werden.

Auch sind Funktionen sinnvoll auf fehlende Wissenseinträge hinzuweisen, sei es im Incident oder Problem Modul beziehungsweise die Möglichkeit einen Artikelvorschlag einzureichen.

Funktionen die meiner Meinung nach nicht taugen

Einige ITSM Tools ermöglichen aus Tickets Wissenseinträge zu machen. Da die meisten Tickets aber Kontextspezifisch sind, müssen diese verallgemeinert werden. Die Funktion ein Incident Ticket mal schnell in einen Knowledge Base Eintrag zu hieven führt zu vermehrtem Müll.

Wunderversprechende Künstliche Intelligenz basierte Funktionen, die automatisch Verschlagworten besonders tolle Treffer hervorbringen etc. haben sich in meiner Praxis bisher nicht bewährt. Spart das Geld uns beschäftigt dafür lieber ein kleines Lektorat, das entlastet die technischen Mitarbeiter und bringt einen echten Mehrwert.

Welche Vorgaben das Lektorat bekommt und warum „Alles“ keine gute Antwort auf die zu dokumentierenden Bereiche ist, lest ihr beim nächsten Mal.

Blog abonnieren: https://wernerroth.de/index.php/feed/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Dein Kommentar wird manuell freigeschaltet. Ich bitte um Geduld, das kann manchmal etwas dauern.