Eine Wissensdatenbank wird erst im Arbeitsablauf wertvoll

Die Wissensdatenbank enthält viele Anleitungen. Trotzdem fragt der Support im Chat, durchsucht alte Tickets oder ruft den Kollegen an, der das Problem schon einmal gelöst hat. Das Wissen ist dokumentiert, aber nicht Teil der Arbeit.

Eine Wissensdatenbank scheitert selten nur daran, dass zu wenig geschrieben wurde. Häufig wird sie als separater Dokumentationsort aufgebaut: Nach dem Ticket soll jemand einen sauberen Artikel erstellen, kategorisieren, freigeben und später regelmäßig prüfen. Unter Betriebsdruck bleibt dieser zusätzliche Ablauf liegen.

Der wirksamere Ansatz dreht die Reihenfolge um. Wissen wird beim Lösen gesucht, verwendet, korrigiert und mit dem Vorgang verknüpft. Dokumentation ist dann kein nachgelagertes Nebenprojekt, sondern ein Ergebnis der Supportarbeit.

Der Moment der Nutzung entscheidet über Aktualität

Ein Artikel kann formal geprüft und trotzdem praktisch unbrauchbar sein. Vielleicht verwendet er andere Begriffe als die Nutzer, setzt unbekannte Voraussetzungen voraus oder beschreibt eine Oberfläche, die sich verändert hat.

Diese Mängel werden am zuverlässigsten sichtbar, wenn jemand den Artikel für einen realen Vorgang benötigt. Deshalb gilt ein einfaches Prinzip:

• Vor einer neuen Lösung wird vorhandenes Wissen gesucht.
• Ein passender Artikel wird mit dem Ticket verknüpft.
• Eine erkennbare kleine Abweichung wird direkt verbessert oder markiert.
• Fehlt ein Artikel, entsteht ein erster nutzbarer Entwurf aus dem Lösungskontext.
• Wiederkehrende Nutzung und Rückmeldungen steuern die weitere Pflege.

Der KCS v6 Practices Guide beschreibt dieses Zusammenspiel aus Erfassen, Strukturieren, Wiederverwenden und Verbessern. KCS ist ein umfassendes Vorgehensmodell, das nicht vollständig übernommen werden muss. Für kleine IT-Teams ist besonders die Idee wertvoll, Wissen im Arbeitsablauf statt in einer parallelen Redaktion zu pflegen.

Suche beginnt mit der Sprache des Problems

Supportmitarbeitende kennen oft die technische Ursache noch nicht, wenn sie suchen. Nutzer beschreiben Symptome: „Anmeldung dreht sich“, „Rechnung hängt“, „Drucker ist weg“. Ein Artikel, der nur unter dem später ermittelten Fehlercode oder Produktnamen auffindbar ist, hilft in diesem Moment wenig.

Ein nutzbarer Wissenseintrag enthält deshalb unterschiedliche Perspektiven:

• beobachtbares Symptom in der Sprache der betroffenen Person,
• betroffener Service und Nutzungskontext,
• bekannte Bedingungen oder Abgrenzungen,
• Diagnose- oder Prüfschritte,
• Lösung oder kontrollierter Workaround,
• Warnungen und notwendige Berechtigungen,
• Eskalations- und Rückfallweg,
• Geltungsbereich, Version und letzte bestätigte Nutzung.

Die Struktur sollte so knapp sein, dass sie während eines Gesprächs oder Tickets verwendet werden kann. Lange Prosa mit allgemeiner Einleitung erschwert die Suche nach dem nächsten Schritt.

Ticket und Wissensartikel erfüllen verschiedene Aufgaben

Ein Ticket dokumentiert einen konkreten Vorgang: betroffene Person, Zeitpunkt, Priorität, Kommunikation, Entscheidung und Ergebnis. Ein Wissensartikel beschreibt den wiederverwendbaren Anteil einer Lösung.

Wer alte Tickets als Wissensdatenbank verwendet, übernimmt leicht:

• personenbezogene oder vertrauliche Angaben,
• einmalige Umgebungsdetails,
• veraltete Zwischenstände,
• unbestätigte Vermutungen,
• eine Lösung ohne Voraussetzungen und Grenzen.

Der Wissensartikel abstrahiert den Fall, ohne entscheidende Bedingungen zu verlieren. Das Ticket verweist auf den verwendeten Artikel; der Artikel erhält aus der Verknüpfung ein Signal, wie oft und in welchem Kontext er hilfreich war.

Der Beitrag „Ein Ticketsystem löst keine organisatorischen Probleme“ zeigt, warum ein Werkzeug den Supportprozess nicht selbst definiert. Dasselbe gilt für ein Knowledge-Modul: Es stellt Funktionen bereit, aber keine gemeinsame Arbeitsweise.

Ein Artikel braucht einen erkennbaren Zustand

Nicht jedes während einer Störung erfasste Wissen ist sofort für alle Nutzer geeignet. Statt jede Notiz durch eine zentrale Redaktion zu schicken, können wenige Zustände den Umgang steuern:

• Arbeitsentwurf: im Team sichtbar, fachlich noch nicht ausreichend geprüft,
• intern nutzbar: von qualifizierten Supportrollen verwendbar, Voraussetzungen und Risiken beschrieben,
• für Self-Service geeignet: verständlich, sicher und ohne interne Geheimnisse für die vorgesehene Nutzergruppe freigegeben,
• prüfbedürftig: durch Änderung, Widerspruch oder fehlgeschlagene Nutzung zu überprüfen,
• zurückgezogen: nicht mehr als aktuelle Lösung verwenden.

Die Berechtigung zum Erstellen, Ändern und Veröffentlichen kann nach Erfahrung und Artikelwirkung abgestuft werden. Eine kleine Tippfehlerkorrektur braucht nicht dieselbe Prüfung wie eine Anleitung mit administrativen Befehlen oder Sicherheitsauswirkung.

Ownership gilt für den Wissensbereich, nicht für jedes Komma

Wenn eine einzige Person alle Artikel schreiben und freigeben muss, wird sie zum Engpass. Wenn niemand verantwortlich ist, wachsen Widersprüche und veraltete Anleitungen.

Eine tragfähige Verteilung kann so aussehen:

• Supportmitarbeitende suchen, verknüpfen, markieren und verbessern im Nutzungskontext.
• Fachverantwortliche betreuen einen Wissensbereich, etwa Identität, ERP oder Netzwerk.
• Service Owner entscheiden über Self-Service-Eignung, Risiken und Priorität größerer Lücken.
• Die IT-Leitung verantwortet Regeln, Werkzeuge, Rollen und Wirkung des Gesamtprozesses.

Der Owner muss nicht jeden Satz selbst schreiben. Er sorgt dafür, dass kritische Inhalte einen angemessenen Zustand besitzen und erkannte Lücken bearbeitet werden.

Der Standard ISO 30401:2018 beschreibt Wissensmanagement als System, das aufgebaut, betrieben, gepflegt, überprüft und verbessert werden muss. Die Norm ist breiter als Supportwissen. Sie unterstreicht aber, dass ein Ablageort allein noch kein wirksames Wissensmanagement ergibt.

Konstruiertes Beispiel: Drei Lösungen, kein wiederverwendbarer Weg

Das folgende Beispiel ist konstruiert.

Nach einer Softwareaktualisierung können einzelne Mitarbeitende keine PDF-Dateien mehr erzeugen. Drei Tickets werden von drei Administratoren unterschiedlich gelöst. Einer dokumentiert einen Registry-Wert im Ticket, einer sendet einen Befehl im Chat, der dritte legt eine ausführliche Anleitung in einem allgemeinen Ordner ab.

Beim vierten Fall beginnt die Diagnose erneut. Erst als das Team die vorhandenen Hinweise zusammenführt, Voraussetzungen und betroffene Version ergänzt und den Artikel direkt mit neuen Tickets verknüpft, entsteht wiederverwendbares Wissen.

Die Verbesserung besteht nicht primär aus einem neuen Tool. Sie besteht aus der Regel, beim Lösen zuerst zu suchen und die gefundene oder neue Lösung im selben Ablauf zu pflegen.

Artikelmenge ist eine gefährliche Zielgröße

Eine Vorgabe wie „zehn neue Artikel pro Monat“ belohnt Produktion, nicht Nutzen. Sie kann Duplikate, oberflächliche Inhalte und fehlende Pflege fördern.

Sinnvoller sind Signale, die Nutzung und Wirkung beschreiben:

• Anteil wiederkehrender Vorgänge mit verknüpftem Wissensartikel,
• Verhältnis von Wiederverwendung zu Neuerstellung,
• Suchanfragen ohne hilfreiches Ergebnis,
• Artikel, die bei Nutzung korrigiert oder als prüfbedürftig markiert werden,
• Zeitanteil für Diagnose bei bekannten Störungen,
• Self-Service-Vorgänge, die ohne Ticket zum richtigen Ergebnis führen,
• häufige Themen, die statt einer Anleitung eine dauerhafte Problembeseitigung benötigen.

Auch diese Kennzahlen brauchen Kontext. Eine hohe Wiederverwendung kann auf gute Wissensarbeit oder auf ein ungelöstes Grundproblem hinweisen. Deshalb gehört die Verbindung zum Problem Management dazu: Wissen beschleunigt den Umgang mit bekannten Fehlern, soll deren dauerhafte Beseitigung aber nicht ersetzen.

Die Wissensartikel-Karte

Eine einfache Struktur unterstützt Erfassung und Wiederverwendung.

Feld	Inhalt
Titel	Symptom oder Aufgabe in suchbarer Sprache
Kontext	betroffener Service, Zielgruppe, Version und Voraussetzungen
Problem	beobachtbares Verhalten und klare Abgrenzung
Prüfung	kurze Schritte, um den Fall sicher zuzuordnen
Lösung	nachvollziehbare Schritte oder kontrollierter Workaround
Ergebnis	woran erfolgreiche Anwendung erkennbar ist
Risiken	Berechtigungen, Datenwirkung, Unterbrechung und Rückfall
Eskalation	wann der Artikel nicht angewendet werden darf und wer übernimmt
Zustand	Arbeitsentwurf, intern, Self-Service, prüfbedürftig oder zurückgezogen
Nachweis	verknüpfte Vorgänge, bestätigte Nutzung und wesentliche Änderungen
Wissensbereich	verantwortlicher Fachbereich oder Service Owner

Die Karte ist kein starres Formular für jede kurze Antwort. Sie beschreibt die Informationen, die ein anderer Mensch für eine sichere Wiederverwendung benötigt.

Der pragmatische Einstieg

Statt den gesamten Altbestand zu bereinigen, kann ein Team mit den häufigsten oder folgenreichsten Vorgängen beginnen:

1. einen Service oder Supportbereich auswählen,
2. Suche und Verknüpfung in den Ticketablauf aufnehmen,
3. eine kurze Artikelstruktur und wenige Zustände definieren,
4. Rechte zum Verbessern schrittweise an qualifizierte Mitarbeitende geben,
5. Suchlücken, Wiederverwendung und fehlgeschlagene Anwendung beobachten,
6. nach einigen Wochen Struktur und Workflow anhand realer Nutzung anpassen.

Die KCS-Praxis zur Prozessintegration zielt darauf, die richtige Handlung zur einfachen Handlung zu machen. Wenn Suche, Ticket und Wissenspflege mehrere getrennte Systeme und doppelte Erfassung erfordern, wird selbst eine gute Regel im Alltag schwach bleiben.

Für sicherheitsrelevante Vorfälle braucht es zusätzlich einen kontrollierten Umgang mit sensiblen Informationen. Das NIST SP 800-61 Rev. 3 bindet Incident Response in kontinuierliches Risikomanagement und Verbesserung ein. Nicht jede Erkenntnis aus einem Sicherheitsvorfall gehört unverändert in eine breit zugängliche Wissensdatenbank; Zielgruppe und Schutzbedarf bleiben entscheidend.

Eine Wissensdatenbank wird nicht dadurch wertvoll, dass sie vollständig wirkt. Wert entsteht, wenn ein realer Vorgang schneller und sicherer gelöst wird, der verwendete Artikel dabei besser wird und das Team aus wiederkehrenden Mustern eine dauerhafte Verbesserung ableitet.