Die Lösung kennt nur einer: Wissensmanagement für IT-Dienstleister

Beim Kunden startet ein wichtiger Anwendungsdienst nicht mehr. Zwei Techniker prüfen Logs, starten Komponenten neu, vergleichen Konfigurationen und suchen in alten Tickets. Nach zwei Stunden läuft der Dienst immer noch nicht.

Dann kommt der erfahrene Kollege aus seinem Termin.

„Ach, das hatten wir doch schon mal. Erst den Cache leeren, dann den Dienst mit diesem einen Parameter starten. Sonst hängt er sich wieder weg.“

Zehn Minuten später arbeitet der Kunde weiter. Der Kollege hat das Problem vor zwei Jahren schon einmal mühsam untersucht. Die Lösung stand allerdings nur in seinem Gedächtnis und irgendwo in einem 46 Kommentare langen Ticketverlauf von damals.

Das Unternehmen hat dieselbe Erkenntnis zweimal bezahlt. Der Kunde hat zweimal auf die Wiederherstellung gewartet. Und beim nächsten Mal beginnt die Suche wahrscheinlich ein drittes Mal, wenn der richtige Kollege gerade Urlaub hat.

Die kurze Antwort

Wissensmanagement für IT-Dienstleister beginnt nicht mit einem neuen Wiki. Es beginnt mit einer einfachen Einsicht: Eine bereits gefundene Lösung wird erst dann zu nutzbarem Unternehmenswissen, wenn andere Mitarbeiter sie finden, verstehen und sicher anwenden können.

Das betrifft unmittelbar die Verfügbarkeit Ihrer Kunden-IT. Wenn ein Dienst gestört ist, benötigt das Team nicht nur Zugriff auf Server, Monitoring und Tickets. Es benötigt auch die Information, wie sich eine bekannte Situation beherrschen lässt. Steckt diese Information ausschließlich im Kopf eines Mitarbeiters, ist sie für die Organisation bei dessen Abwesenheit praktisch nicht verfügbar.

Die ISO 27001 liefert dafür mit A.5.37 einen passenden Normanker. Der größere Teil der Begründung braucht allerdings keine Norm: Bereits bezahlte Problemlösungen bei jeder ähnlichen Störung neu zu erfinden, ist einfach grottenschlechter Service.

Wissen im Kopf ist für das Unternehmen nicht verfügbar

Der erfahrene Administrator darf selbstverständlich mehr wissen als ein neuer Kollege. Erfahrung lässt sich nicht vollständig in Formulare pressen. Niemand erwartet, dass zwanzig Berufsjahre auf drei Wiki-Seiten passen.

Kritisch wird es dort, wo der Betrieb von genau diesem persönlichen Wissen abhängt:

• Nur ein Mitarbeiter kennt die richtige Reihenfolge für den Wiederanlauf.
• Eine bestimmte Fehlermeldung wird nur von einem Kollegen richtig gedeutet.
• Der entscheidende Workaround steht in einem privaten Notizbuch.
• Ein Skript liegt in einem persönlichen Ordner, dessen Namen niemand kennt.
• Die Lösung wurde im Teamchat besprochen, ist dort aber kaum wiederzufinden.
• Der damalige Bearbeiter erkennt ähnliche Fälle am Bauchgefühl, kann die Merkmale aber nicht erklären.

Solange der Kollege erreichbar ist, wirkt das erstaunlich effizient. Ein kurzer Anruf ersetzt die Suche. Sobald er krank ist, Urlaub macht, kündigt oder parallel bei einem anderen Kunden im Einsatz ist, fehlt dem Unternehmen plötzlich eine betriebliche Fähigkeit.

Das ist nicht nur ein Personalthema. Der Kunde hat den IT-Dienstleister beauftragt, nicht das Privatgedächtnis eines bestimmten Administrators.

Ein geschlossenes Ticket ist noch keine bekannte Lösung

Viele Systemhäuser haben durchaus dokumentiert, wie eine Störung gelöst wurde: irgendwo im damaligen Ticket. Damit ist das Wissen theoretisch vorhanden. Praktisch findet es dort beim nächsten Incident natürlich niemand.

Ein Ticketverlauf erzählt die Geschichte eines konkreten Falls. Darin stehen Rückfragen, Logauszüge, verworfene Vermutungen, Kundennachrichten, interne Notizen und irgendwann die erfolgreiche Maßnahme. Wer unter Zeitdruck eine Störung bearbeitet, möchte daraus aber keine technische Archäologie machen.

Eine bekannte Lösung beantwortet kompakt andere Fragen:

• Woran erkenne ich, dass diese Lösung passen könnte?
• Für welche Systeme, Versionen oder Konfigurationen gilt sie?
• Welche Voraussetzungen müssen erfüllt sein?
• Was muss ich konkret tun?
• Welche Risiken, Freigaben oder Kundenauswirkungen sind zu beachten?
• Woran erkenne ich anschließend, dass die Maßnahme funktioniert hat?

Das ursprüngliche Ticket bleibt wichtig. Es belegt den konkreten Vorgang und enthält bei Bedarf die ganze Untersuchung. Der Lösungseintrag macht das Ergebnis wiederverwendbar. Beides kann miteinander verlinkt sein, erfüllt aber nicht denselben Zweck.

Dass Kundenmeldungen überhaupt zuverlässig in einer gemeinsamen Arbeitslage ankommen müssen, behandelt unser Artikel über das Ticketsystem für IT-Dienstleister. Dieser Artikel setzt einen Schritt später an: Was passiert mit dem Wissen, das während der Bearbeitung entsteht?

Gleicher Fehler ist einfach – ähnliche Fälle sind der eigentliche Gewinn

Eine gute Wissensbasis hilft nicht nur, denselben Fehlercode wiederzufinden. Sie hilft dem Mitarbeiter, Ähnlichkeiten zu erkennen.

Vielleicht meldet Kunde A: „Die Anwendung startet nach dem Update nicht.“ Bei Kunde B lautet die Meldung zwei Wochen später: „Anmeldung nicht möglich, Dienst antwortet aber.“ Auf den ersten Blick sind das unterschiedliche Incidents. Tatsächlich können beide dieselbe Ursache haben: eine veraltete Cache-Datei in derselben Produktversion.

Wenn der Lösungseintrag nur den exakten Wortlaut der ersten Kundenmeldung enthält, bleibt die Verbindung unsichtbar. Hilfreicher sind Merkmale wie:

• betroffenes Produkt und Version;
• Zeitpunkt oder vorausgegangene Änderung;
• beobachtetes Verhalten;
• typische Logmeldung;
• betroffene Komponente;
• bekannte Ursache;
• Systeme oder Konfigurationen, bei denen die Lösung ausdrücklich nicht angewendet werden darf.

Damit wird aus „Peter erinnert sich an diesen einen Kunden“ eine Information, die ein Kollege auf einen verwandten Fall übertragen kann. Dafür muss er weiterhin denken. Die Wissensbasis nimmt ihm nicht die Diagnose ab. Sie sorgt nur dafür, dass vorhandene Erfahrung bei der Diagnose überhaupt mitspielen darf.

Welche Kunden dieselbe Software, Version oder Konfiguration einsetzen, sollte ebenfalls nicht vom Gedächtnis abhängen. Der Beitrag zum Asset Management für IT-Dienstleister zeigt, wie die Zuständigkeit für konkrete Kundensysteme und ihre Eigenschaften sichtbar wird.

Vom Problem-Ticket zur nutzbaren Lösung

Eine bekannte Lösung fällt selten fertig aus einem Incident-Ticket. Häufig entsteht sie im Problem Management.

Der Incident beantwortet zunächst: Wie bekommt der Kunde seinen Dienst zurück? Gibt es bereits eine bekannte Lösung, kann der Mitarbeiter sie anwenden und das Ergebnis prüfen. Gibt es keine Lösung und keinen brauchbaren Workaround, wird zusätzlich die Ursache untersucht.

Unser Artikel über Problem Management bei IT-Dienstleistern beschreibt diesen Weg ausführlich. Für das Wissensmanagement ist der letzte Schritt entscheidend: Wenn Ursache und Lösung gefunden wurden, darf das Ergebnis nicht im geschlossenen Problem-Ticket begraben werden.

Ein schlanker Ablauf genügt:

1. Im Incident wird nach einer passenden bekannten Lösung gesucht.
2. Fehlt sie, wird die Ursache im Problem-Ticket untersucht.
3. Die gefundene Lösung wird technisch geprüft.
4. Aus dem Ergebnis entsteht ein kurzer Lösungseintrag.
5. Der Eintrag wird mit betroffenen Produkten, Versionen, Symptomen und ursprünglichen Tickets verknüpft.
6. Beim nächsten Einsatz meldet der Bearbeiter zurück, ob die Lösung noch passt oder verbessert werden muss.

So wächst die Wissensbasis aus echter Arbeit. Das Team veranstaltet keinen monatlichen Workshop, in dem vorsorglich Lösungen für Probleme erfunden werden, die noch nie jemand hatte.

Die zugrunde liegende Unterscheidung zwischen Service Request, Incident und Problem sorgt dafür, dass die Lösung am richtigen Vorgang entsteht und später beim richtigen Vorgang wieder genutzt wird.

Was in einem brauchbaren Lösungseintrag stehen sollte

Der Eintrag muss nicht lang sein. Er muss die nächste Bearbeitung verkürzen, ohne den Mitarbeiter zu einem riskanten Blindflug zu verleiten.

Sinnvoll sind meistens:

1. Titel und Suchbegriffe: so formuliert, wie Mitarbeiter das Symptom tatsächlich beschreiben würden;
2. Erkennungsmerkmale: Fehlerbild, Logmeldung, vorausgegangene Änderung oder andere typische Hinweise;
3. Geltungsbereich: betroffene Kunden, Services, Systeme, Versionen oder Konfigurationen;
4. Voraussetzungen: benötigte Zugänge, Sicherungen, Wartungsfenster oder Rücksprachen;
5. Lösungsschritte: kurz, eindeutig und in der richtigen Reihenfolge;
6. Sicherheitsgrenzen: notwendige Freigaben, mögliche Datenfolgen und Fälle, in denen abgebrochen werden muss;
7. Erfolgskontrolle: woran der Bearbeiter erkennt, dass der Dienst wirklich wieder ordnungsgemäß funktioniert;
8. Herkunft und Pflege: verknüpftes Problem-Ticket sowie eine zuständige Stelle für notwendige Aktualisierungen.

Nicht jeder Eintrag braucht acht Überschriften und eine Freigabezeremonie. Für einen einfachen, risikoarmen Workaround können wenige klare Absätze reichen. Eine Wiederherstellung, Berechtigungsänderung oder Maßnahme an einem Produktivsystem braucht entsprechend mehr Sorgfalt.

Und ja: A.5.37 erwartet genau diese Verfügbarkeit

ISO 27001 A.5.37 verlangt dokumentierte Betriebsverfahren für Informationsverarbeitungsanlagen, die dem Personal zur Verfügung stehen, das sie benötigt. Unser eigener Praxisartikel erläutert ausführlich, welche Betriebsabläufe nach A.5.37 dokumentiert werden sollten.

Nicht jede bekannte Lösung ist automatisch ein vollständiges Betriebsverfahren. Und die Norm verlangt weder eine Lösungsdatenbank noch ein bestimmtes Ticketsystem. Wenn der sichere Betrieb eines Kundensystems aber davon abhängt, dass Mitarbeiter in einer bestimmten Situation die richtigen Schritte kennen, ist eine verfügbare und brauchbare Anleitung ziemlich offensichtlich sinnvoll.

Mehr Normtheorie braucht es an dieser Stelle nicht. Wenn ein fachkundiger Vertreter eine bekannte Störung nicht lösen kann, weil alle entscheidenden Informationen im Kopf des abwesenden Kollegen stecken, ist das Verfahren für ihn nicht verfügbar. Genau das sollten Sie ändern.

Wiki, Ticketsystem oder Datenbank: Der Name ist ziemlich egal

Sie müssen kein neues Werkzeug kaufen. Eine Wissensbasis kann im vorhandenen Ticketsystem, in einem internen Wiki, in einer geeigneten Datenbank oder in einem anderen gemeinsam nutzbaren System liegen.

Wichtiger als der Produktname sind praktische Eigenschaften:

• Mitarbeiter finden Einträge mit den Begriffen, die sie im Alltag verwenden.
• Der Zugriff ist für die benötigten Rollen möglich.
• Kundenspezifische und sensible Informationen sind angemessen getrennt.
• Veraltete Lösungen sind erkennbar oder werden entfernt.
• Einträge lassen sich mit Tickets, betroffenen Systemen und Änderungen verbinden.
• Rückmeldungen aus der Anwendung können unkompliziert eingearbeitet werden.

Ein Ordner mit 700 PDFs kann all diese Bedingungen theoretisch erfüllen. In vielen Betrieben ist er trotzdem nur ein sehr ordentlich sortierter Friedhof. Das beste System ist das, in dem der Mitarbeiter während eines echten Incidents tatsächlich sucht und eine brauchbare Antwort findet.

KI hilft erst, wenn es etwas Brauchbares zu finden gibt

Hier wird KI wirklich interessant. Sie kann neue Tickets mit vorhandenen Lösungen vergleichen, Synonyme und ähnliche Fehlerbilder erkennen, passende Einträge vorschlagen oder aus einem abgeschlossenen Problem-Ticket einen ersten Lösungsentwurf erzeugen.

Gerade kleinere IT-Dienstleister können davon profitieren. Ein Mitarbeiter muss dann nicht exakt wissen, ob der Kollege den Artikel unter „Anmeldung gestört“, „Dienst startet nicht“ oder „Cache nach Update“ abgelegt hat.

Die KI ersetzt allerdings nicht die fachliche Prüfung. Sie weiß nicht automatisch, ob der Neustart bei diesem Kunden erlaubt ist, ob die dokumentierte Version noch stimmt oder ob ein scheinbar ähnlicher Fall eine andere Ursache besitzt. Ein fachkundiger Mitarbeiter muss beurteilen, ob die vorgeschlagene Lösung passt und sicher angewendet werden kann.

Ohne gepflegte Wissensbasis wird KI außerdem schnell zu künstlichem Hörensagen. Sie findet dann alte Ticketkommentare, verworfene Vermutungen und Lösungen, die bei einem anderen Kunden zufällig funktioniert haben. Das ist kein Wissensmanagement. Es ist sehr schnelles Stochern in alten Gesprächen.

Typische Fehler

Die Wissensbasis wird zum Großprojekt

Zuerst sollen Kategorien, Rechte, Vorlagen und sämtliche Altbestände perfekt werden. Nach sechs Monaten steht die Struktur, aber noch keine einzige Lösung hilft dem Service Desk. Beginnen Sie mit echten wiederkehrenden Störungen.

Das ganze Ticket wird als Lösung kopiert

Damit bleiben Irrwege, Kundennachrichten und unklare Zwischenstände erhalten. Der nächste Bearbeiter braucht das geprüfte Ergebnis und bei Bedarf einen Link zur Geschichte dahinter.

Niemand schreibt so, wie später gesucht wird

Der Artikel heißt „Applikationsinstanz nach Wartungsereignis reinitialisieren“. Der Mitarbeiter sucht nach „Anwendung startet nach Update nicht“. Gute Suchbegriffe stammen aus echten Tickets und aus der Sprache des Teams.

Eine einmal richtige Lösung gilt für immer

Versionen, Konfigurationen und Abhängigkeiten ändern sich. Ein Mitarbeiter muss erkennen können, wofür ein Eintrag gilt und wann Zweifel angebracht sind.

Kundendaten landen in allgemein sichtbaren Einträgen

Passwörter, vertrauliche Konfigurationen und unnötige personenbezogene Daten gehören nicht in eine für das ganze Unternehmen sichtbare Anleitung. Wiederverwendbares Wissen und kundenspezifische Details lassen sich trennen.

Dokumentiert wird irgendwann später

Zwei Monate nach der Ursachenanalyse erinnert sich niemand mehr an die entscheidende Prüfung. Der Lösungseintrag sollte entstehen, solange das Problem-Ticket und die beteiligten Mitarbeiter noch warm sind.

So starten Sie ohne Wissensmanagement-Kathedrale

Nehmen Sie die 20 häufigsten oder teuersten wiederkehrenden Störungen der vergangenen Monate. Fragen Sie nicht zuerst nach dem perfekten Tool, sondern nach vorhandenen Lösungen.

1. Welche Fälle wurden mehrfach bearbeitet?
2. Bei welchen davon kann nur ein bestimmter Mitarbeiter schnell helfen?
3. Welche Lösung wurde bereits geprüft und wiederholt erfolgreich eingesetzt?
4. Welche Merkmale verbinden gleiche oder ähnliche Fälle?
5. Welche Sicherheitsgrenzen und Freigaben müssen Mitarbeiter kennen?
6. Wo kann das Team den Eintrag beim nächsten Incident tatsächlich finden?

Erstellen Sie zunächst fünf brauchbare Einträge. Lassen Sie sie von einem Kollegen verwenden, der an der ursprünglichen Untersuchung nicht beteiligt war. Jede Rückfrage zeigt eine fehlende Voraussetzung, einen unklaren Schritt oder einen schlechten Suchbegriff.

So entsteht nach und nach eine Wissensbasis, die aus Ihrem echten Betrieb lernt. Sie macht neue Mitarbeiter schneller handlungsfähig, reduziert die Abhängigkeit von einzelnen Köpfen und verbindet Ihre Betriebserfahrung mit einem steuerbaren ISMS für IT-Dienstleister.

Interesse geweckt?

Sie möchten Ihr Betriebswissen so verfügbar machen, dass bekannte Störungen nicht bei jedem Kunden neu erforscht werden müssen? Sprechen Sie mit uns.